Evolving Architecture

ENOVIA Business Process Services is an extendable object-oriented framework that leverages filters, inheritance, polymorphism, hooks, and a wealth of APIs.

The following topics are discussed:

The framework is a web-based architecture based on J2EE, which hides the complexity of authentication, session management, transactions, and so on. Any changes must be backward compatible and offer a clear migration path. The Java ENOVIA Studio Customization Toolkit was the beginning of it all and has been around a long time. JSPs have been part of applications since their introduction, with Beans added to ENOVIA Business Process Services and JPOs added to the core in version 9.5.

ENOVIA Business Process Services continues to evolve as Java evolves and WILL accept such changes as the Sun Model 2 architecture, a controller framework (Struts, Springs, or JavaServer Faces), and the Front Controller pattern.

Because of this on-going evolution, different applications (and custom code in the field) are at different stages of adherence to the latest architecture.

Organization of Java Code

Java code in ENOVIA products falls into the areas described in this section.


  • Java Server Pages (JSPs). About 200 web forms & tables and 100 web wizards
  • Java classes (Beans). About 370 and growing.
  • Java Program Objects (JPOs). About 150 pairs (base/derived) and growing.
  • ENOVIA Studio Customization Toolkit. About 185 db classes, 54 utility classes and growing.

The ENOVIA Studio Customization Toolkit classes maintain a tight cohesion and loose coupling. Beans expose a higher abstraction than the ENOVIA Studio Customization Toolkit. Business logic Beans are the "business objects" (Business Delegate pattern) exposed to the JSP. These business objects never contain web-specific logic, so they can be freely used in stand-alone applications that do not run on an application server. Additional logic that does not belong to a specific type is placed into utility Beans.

The grouping of logic is often determined by the nature of the functionality. For example, a Bean could represent an administration type, such as Policy. There might be another Bean used for referencing properties, either externally or internally. Another grouping of logic is found in the UI Beans which provide an API to the underlying UI components, such as tables, forms, and commands.

Layers Design

In a layers design pattern, each layer can only call downward. JSPs call Bean methods, which in turn call JPO methods, which in turn call ENOVIA Studio Customization Toolkit methods. Beans currently contain calls to ENOVIA Studio Customization Toolkit methods (since they were developed before JPOs existed) but most of these calls are isolated in the DomainObject base class.

The most used methods in DomainObject are findObjects(), getInfo(), and getRelatedObjects(). Beans represent Business logic (grouped by type), Utility logic (grouped by function), and access to UI components. Trigger logic should live in JPO methods. Trigger methods should be grouped into classes by type. Column support methods can be grouped into a companion JPO responsible for UI.



Each layer performs specific roles:


  • JSP (view). JSPs are packaged by application. They are for presentation only so they use tags and call Beans. This is known as "Business Delegate design pattern."
  • Bean (model front-end) . Beans are no longer distributed in a single jar. They contain business logic, the (web) services API, and call JPOs. This is known as "Bridge design pattern.".
  • JPO (model back-end). JPOs are installed by ENOVIA products. They implement business logic, call the ENOVIA Studio Customization Toolkit, and are used for triggers and UI component support.

The ENOVIA architecture uses a Model View Controller design pattern, where presentation is isolated from business logic. This design allows multiple views for a common model, and facilitates the management of code. ENOVIA highly recommends that your customizations adhere to this design pattern. The view portion is defined in the JSPs. The model portion is spread over Beans and JPOs. The ultimate goal is to have all business logic live in JPOs. ENOVIA has been moving business logic from JSPs into Beans, and now is moving it from Beans into JPOs.

Business logic is accessed through Beans. There is a type Bean for each business type, and Beans for some relationship types. The Part Bean provides services that one would expect to operate on Part objects. Currently, JSPs and stand-alone applications are consumers of these services. Eventually, a subset of these services will be turned into web services so that they can be accessed remotely, say from a portlet. The controller portion will be formalized through the addition of a Controller to be incorporated into the architecture.