Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

This is a draft document - it can be changed at any time by anyone.

Document Purpose

This document is intended to introduce a high level design of an application framework for the Apache Open for Business project.

Overview

The application framework will be written in Java and it will provide the basic structure to write an application. The framework will provide the following basic functionality:

  • Configuration.
  • Globalization (locale, time zone, currency).
  • Logging.
  • Security (authentication/authorization).
  • Actor Management (profiles, roles - required for security; Actors - people, external services) Think of UML Actor. Required to remove dependency on Party
  • Data Store (entity engine).
  • Lang package to provide classes that are fundamental to the framework
  • Services.
  • Runtime management.

Design Goals

  • Single jar file.

  • Compact, small memory footprint.
  • Scalable from SBCs to enterprise-class ERP systems.
  • Reuses existing technologies.

  • Easy to configure and maintain.

    Design Participants Note

    Please take some to watch this presentation by Joshua Bloch: How to Design a Good API & Why it Matters.

Basic Architecture

Configuration
Globalization
  • Library: IBM ICU4J
  • Java package name: org.apache.ofbiz.foundation.globalization
Logging
  • Library: SLF4J
Security
Actor Management
Data Store
  • Library: OFBiz Entity Engine, JDBC
  • Java package name: org.apache.ofbiz.foundation.entity
Services
  • Library: JMS, Quartz Scheduler
  • Java package name: org.apache.ofbiz.foundation.service
Lang - Data Types
Cache
  • Library: eHCache
  • Java package name: org.apache.ofbiz.foundation.cache

 

 

 

Security Configuration Globalization Logging Data Store Cache Services Lang

 

 

  • No labels

34 Comments

  1. Adrian Crum

    Ron - actor management is a function of security (authentication/authorization). Your dependency diagram is nice, but it is wrong. See the Framework Vision document for a description of the dependencies.

    1. Ron Wheeler

      I tried to correct it based on the Vision document.

      You may want to make some more changes and document the nature of the dependency using edge labels.

  2. Ron Wheeler

    Can you just fix the diagram or point me to Framework Vision Documment. Is it linked to this page?

  3. Ron Wheeler

    I see this new framework as a set of smaller services where the interface for each piece is well defined.

    One does not care about the persistence/cache implementation details to work on Security and/or Actor.

     

    Breraking them into separate projects that create testable jar files may help people to do more testing and will be much easier to control from a project management POV.

  4. Taher Alkhateeb

    I've been reading a lot into OSGI lately and it seems to be a candidate solution to incorporate into the framework. It enforces package isolation with only partially accessible public interface. Of course it is also much more in terms of runtime plugin management and component dependency management. So I'm throwing this idea around also as a possibility. Apache Felix comes as a mature solution to mind.

    1. Jacques Le Roux

      I'd rather use the Jigsaw's features in Java 9. In one year it will be officially available. Since we are just starting, better to use this JVM embedded feature with a bright future (some even say it might replace Maven, I'd love it (big grin))

      So we can just declare our dependencies and more inside the JVM context...

      1. Taher Alkhateeb

        Hi Jacques,

        I think JDK 9 is scheduled for the GA release at September 2016. That's quite a long wait no? I do however see your point, less is always more and I am a minimalist myself.

        1. Jacques Le Roux

          Hi Taher,

          I think this endeavour will not be complete before one year. Java 9 (Early Access Releases) with Jigsaw in is already available http://mail.openjdk.java.net/pipermail/quality-discuss/2015-July/000410.html

          I'd recommend to read (in this order)

          http://www.codergears.com/Blog/?p=310

          http://blog.codefx.org/java/dev/features-project-jigsaw-java-9/ or (longer but more recent and complete) http://www.infoq.com/articles/Project-Jigsaw-Coming-in-Java-9

          http://blog.codefx.org/java/dev/how-java-9-and-project-jigsaw-may-break-your-code/

           

          About Java 9 but not Jigsaw: blog.takipi.com/5-features-in-java-9-that-will-change-how-you-develop-software-and-2-that-wont/

  5. Jacques Le Roux

    When you comment in the document body like

    Ron, what you are describing is the current mess we are trying to fix. Consolidating the closely-coupled components into a single component (and jar file) is one of the main reasons for the rewrite - that is why it is first on the list of design goals.

    Please use the confluence author auto-completion (ie use @ and then put a name, like Jacques Le Roux). It makes things much clearer for others, to follow the flow...thanks!

     

    1. Adrian Crum

      Actually, it would be best to keep all comments in the comments section instead of marking up the design document. Eventually, the document becomes unreadable.

      1. Jacques Le Roux

        I agree (smile)

  6. Ron Wheeler

    Perhaps we could do the development as separate projects that produce individual jars that are easy to test and can depend ofn stubs and mock features diuring development.

    We could add a project that produces a single jar to make it easy for application developers to depend on the whole framework.

    I am really opposed to a monolithic project during development for the following:

    • Takes longer to build than just the module that you are working on.
    • Encourages people to not respect the boundaries between components
    • Makes it hard to test with mock components
    • Makes it hard to have a stable environment while testing since lots of people (or a few) are changing other code while you are trying to test your stuff.

    OSGI looks interesting but is not a completely trouble-free solutution either. I use Eclipse/STS which is made up of OSGI components and every now and again an update will not work because of OSGI issues.

    Eclipse is a lot more complex that the Framework but I am not convinced that OSGI is going to make our life easier and it may force our "customer" into something that they may prefer not to use.
    Individual jars with clean POM files available from Maven Central or as downloads will probably make the largest number of developers happy.

    1. Taher Alkhateeb

      Hi Ron,

      Please note the eclipse OSGI is based on Equinox, not Apache Felix, and even the founders of eclipse mention many problems in the design of the eclipse plugin system which makes it sort of weird to develop on it.

      OSGI at its heart is really just an enforcement of modularization which Java as a programming language does not support. Layers, components and plugins are all concepts, not Java constructs. All that you really have in Java is classes and packages. Even with the best intentions in design, people can still muck around with your code because of visibility (public or protected) which you have to expose for the whole component to work correctly.

      I am sure we can design a pure Java solution that is beautiful and works. I would like to point your attention though that the effort to maintain and protect the design from unintentional coupling is highly reduced by an automatic enforcement mechanism like that in OSGI, especially when bundled with the proper tools like Bndtools in eclipse.

    2. Jacques Le Roux

      Magic words: Jigsaw in Java 9! Better be ahead than behind...

    3. Adrian Crum

      Please keep in mind that I have already implemented this framework in my own project. There are no problems collaborating on code, the library is small (500k jar file), and my unit tests have nearly 100% coverage and they take less than a minute to run. So all of the arguments against consolidating the described functionality into a single jar file are invalid.

      The goal of this effort is to make things easier, not harder.

      OSGI would be appropriate at a higher level, but it doesn't make sense to take this library and break it up into pieces. The components are tightly coupled and depend on each other.

      1. Jacques Le Roux

        Yes that was my thought on this also lately. Jigsaw is more interesting for the applications...

        1. Jacques Le Roux

          Mmm, but what about dependencies on external libs? (Quartz, etc.)? Don't you use them?

  7. Jacques Le Roux

    Why do we get so much changes of the graph (picture) when it seems it does not change?

  8. Ron Wheeler

    I am not sure but I did a few changes last night that were cosmetic.

    The e-mails that I found in my inbox this morning seemed to attributed these changes to other people. 

    I am not sure in Confluence is bug-free in this area.

    Perhaps it is sending out notices each time someone looks at the page.

    I am not sure that Confluence is actually showing you the drawing at the time of the change if you click on the link.

    I suspect that it shows you the current image each time.

    1. Jacques Le Roux

      Yes, maybe the Graphiz plugin has some issue (rather than Confluence itself (wink)), thanks!

    2. Adrian Crum

      I am getting a lot of notifications too - even though I unsubscribed. Maybe we can change how the image is embedded in the page.

      1. Jacques Le Roux

        I have no ideas, maybe we should look for issues with the plugin...

  9. Adrian Crum

    Ron, I fixed the graph. As I said before, there is no 'Actor Management' because what you are describing is a security principal, and security principal management is a part of Security.

  10. Jacques Le Roux

    I think we should here mention OFBIZ-3500 - Getting issue details... STATUS

    and OFBIZ-1867 - Getting issue details... STATUS

    Adrian has an issue with Confluence automatically transforming links to JIRA issue, so here are not transformed links for him

    https://issues.apache.org/jira/browse/OFBIZ-1867

    https://issues.apache.org/jira/browse/OFBIZ-3500

    I will check with infra why Adrian gets errors. I believe it's because his Confluence and JIRA usernames are different (adrianc @ hlmksw.com on JIRA vs adrianc on Confluence)

    1. Jacques Le Roux

      I created https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10653 for this

  11. Taher Alkhateeb

    The graph above keeps changing but I cannot see the basis for change. Is this being discussed somewhere? I feel sort of lost

    1. Adrian Crum

      Yes, the changes are discussed in these comments. See my comment from yesterday.

  12. Ron Wheeler

    I think that Actor management is a lot more than what security provides.

    Can Security allow a photo or log to be associated with a security principle or an e-mail address or a URL or  web site or birthday?
    Every application needs to have ways to track external actors which may or may nor participate in security.

    Any service layer will need to track actors (mail servers, payment companies, EDI services) and it would save a lot of code to have an Actor Management component that provides the common methods for actor management.

    1. Adrian Crum

      A photo is CONTENT, and content will be in another component. Email addresses and website URLs are CONTACT MECHANISMs, and those will be in another component. What you are describing is an APPLICATION. We are not designing that here. The application will most likely use parts of this library, but the library will not contain the application.

  13. Ron Wheeler

    I don't have any objection to scheduling this for later although I wonder if Security is going to require a more rich data structure to support biometrics, external authentication services, SSO and federated login services.

    I don't agree that this is an application although it will help build many different application-level components.

    Actors are part of almost every use case and a general way to handle actors would would be very useful and reduce a lot of code.

    It would simplify Party and a lot of the other components that deal with external actors.

     

  14. Adrian Crum

    Ron,

    As you mentioned previously, the term "Actor" comes from UML. There is no way to make a one-to-one mapping from an Actor in a UML diagram to a security principal in code. For example, a UML diagram might show a carrier (Actor) delivering a package to a warehouse. The carrier (Actor) is not a security principal - he/she is merely delivering a package to a warehouse. A warehouse worker (Actor) might receive the package contents into inventory - which makes that Actor a security principal.

    I don't know how I can make this any simpler for you to understand. If you can't understand it, then you will have to trust me when I say that "Actor Management" is not a part of this effort.

    1. Ron Wheeler

      You have it backwards. A Security Principle is an Actor as is the carier in your example. Not all Actors are Security Principles.

      Many Actors will be represented in code and I hope that a flexible API for Actors can be developed that will allow application developers to more easily represent the diverse set or Actors that need to represented in an application.

      It is a bit too early to say what will be in or not in even in the first phase.

       

       

      1. Adrian Crum

        You just repeated what I said, so how can I have it backwards?

        You said "Not all Actors are Security Principals." Exactly! That's why this library does not have "Actor Management" in it. It has a security component - which accommodates security principals.

  15. Ron Wheeler

    I guess that we will see what the security principle requires and if that duplicates any properties and functions that Actor management would provide..