In the J2EE world, there are generally four layers: a client, a Web application built with either Java servlets or JavaServer pages (JSP), a business logic layer built on Enterprise JavaBeans (EJB), and a persistence layer that accesses a relational database. Application Server (AS) provides the container for the Web application and the EJB, and the relational database (Oracle, DB2, Microsoft SQL, etc.) provides the means to persist the data in reliable way.
Multi-tier designs solve a lot of problems but can also create a few. Separating the user interface, business logic, and application data makes the overall design easier to comprehend and allow different teams to work in parallel on different components, but there is a trade-off: increased communications overhead between the tiers. The J2EE platform is fundamentally a multi-tiered, distributed application model where application logic is divided into architectural components according to the chosen architectural strategy. This allows the various application components that make up a J2EE application to be distributed across multiple servers, enhancing overall performance and reliability. However, if you aren't careful with J2EE or any multi-tier architecture, you can end up with a system that is many times slower than a two-tier system.
Multi-tier designs have more components to keep track of and the success of many multi-tier projects hinges on divvying up tasks into appropriate components and properly organizing the results. The following patterns are used to improve the performance of the multi-tier system and make it more maintainable by reducing complexity. Because these patterns are all related to application (architectural) partitioning, they are essential patterns for almost any J2EE application and highly relevant for Oracle developers. The model-view-controller (MVC) pattern enforces a modular, maintainable design and enforces separation of tiers. The session façade pattern organizes business logic for the client. The data access layer (DAL) provides a flexible interface between business logic and real data sources. Finally, the data access (transfer) object (DAO), also known as a value object, eases communication between the tiers.
One of the main design goals of the HxGN EAM product was achieving support for multiple front-end agents (browsers, wireless devices, Java, and .NET reach clients) while maintaining a single uniform code base. HxGN EAM system was also designed to run in a wide range of environments – from customer installation sites to the on-demand hosting services (AIS) capable of hosting unlimited number of customers and client seats. And finally, the system can maintain backward compatibility with old versions on the same installation base. These goals were achieved by applying the principles of Service Oriented Architecture.
The term SOA refers to a new kind of architectural model that refocuses on the old problem of software reuse, extensibility, and interoperability. SOA takes advantage of XML and HTTP and provides a new level of distribution and reuse of computing functionality that has never been seen before in software.
SOAs aren't intended to replace or "front-end" all existing or new back-end systems. They are intended only to replace the ones that require cross-platform, multi-agent access and standardized, self-describing interfaces (i.e., XML schemas). SOAs are currently evolving and are still in their early stages. As it stands, there are still many open issues with respect to how SOAs should, and can, provide basic functions around services such as security, failure, and contracts.
Today, because SOAs are so new, application developers are forced to use SOAs in conjunction with more traditional means of accessing application resources, such as tightly coupled Enterprise JavaBeans (EJBs), message queues, and language-specific, API-based connector architectures.
SOAs make it easier for business functions from different back-end systems to be seamlessly integrated into user-facing applications. This is because it is easier to transform data from one format to another when it is represented in XML, and accessed by way of independent, self-sufficient services. For example, an SOA can enable an SAP system to be linked with a Lotus Domino system at the application session layer to provide a comprehensive employee travel expense reporting system.
Specifics of the HxGN EAM SOA implementation will be covered in the following section "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 Extended 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 tier.
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, Web Logic) 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, but not the least, 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.