Business logic implementation - HxGN EAM - 12.0 - Customization & Programming - Hexagon

HxGN EAM Architecture and Server Management

Language
English
Product
HxGN EAM
Search by Category
Customization & Programming
HxGN EAM Version
12

Business Tier was implemented according to the ideas of the component-based architecture (CBA).

There are two ways to look at component-based architecture: from the software development level or the systems development level.

In software development, many experts use component-based architecture to refer to pieces of code that can be swapped among several software applications due to the well-defined interfaces and high levels of abstraction and encapsulation.

That concept can then be applied to systems development, where a piece of software can be plugged into many different systems. This approach, also called the modular approach, is often used in enterprise resource planning systems, with organizations able to mix and match financial, human resources and other modules.

When using commercial off-the-shelf (COTS) software, it is difficult to find true plug-and-play components from multiple vendors because they do not design their software to be able to "talk" to software from other vendors.

In case of the HxGN EAM the former definition is used. Good examples of the components used in the application are Work order component, Asset Component, etc. Component-based development, while being more time consuming in the beginning of the development process, produces much better results for the large-scale projects. It allows maintaining clear traceability between business requirements and product code base.

Architectural design of the business component is presented on the following diagram:

Figure 2. Business Tier Implementation.

Implementation of each component can be divided into architectural and business logic tiers.

Business logic tier is responsible for implementation of the product functionality. This functionality is responsible for creation of the work order, associating it with asset(s), changing the state of the work order, etc. All business components are tightly encapsulated – all external calls to the component must go through the component manager. Component manager delegates the call to the classes that implement requested functionality.

This architecture allowed us to create a product consisting of a set of loosely coupled, but cohesive components, that can be changed (or versioned) with minimal or no impact on the other component functionality.

Architectural layer represented on the diagram consist of the corresponding stateless enterprise session bean. A stateless session bean does not store session or client state information between invocations—the only state it might contain is not specific to a client, for instance, a cached database connection or a reference to another EJB. At most, a stateless session bean may store state for the duration of a method invocation. When a method completes, state information is not retained. Any instance of a stateless session bean can serve any client—any instance is equivalent. Stateless session beans can provide better performance than stateful session beans, because each stateless session bean instance can support multiple clients, albeit one at a time.

Despite the widely used perception about logical equivalence of the enterprise beans and software component, we chose to take a different approach. In our architecture session bean is used just as deployment entity rather than business component.

It serves three purposes:

Scalability - We treat session bean as the standard way to create distributed threads using application server (JBoss) as the thread container. Using this approach, we can easily scale up the application using either standard application server clustering approach or using highly scalable custom clustering that will be discussed in the deployment section of this document.

Transaction management - Session began running inside the container acts as the gateway to the back end of the application. Being used in this way it was chosen to provide transaction boundary for the application. This approach greatly simplifies managing of the transactional behavior of the application. Being applied in conjunction with persistence layer described in this document, it allows fulfilling even functionality not supported by most vendors – nested transactions.

Portability - The last reason to use session beans is compliance with J2EE architecture. This is the simplest way to ensure portability between different application servers running on different software and hardware platforms.