White Paper on Enterprise Application Development using EJB

COURTESY :- vrindawan.in

Wikipedia

Jakarta Enterprise Beans (EJB; formerly Enterprise Java Beans) is one of several Java APIs for modular construction of enterprise software. EJB is a server-side software component that encapsulates business logic of an application. An EJB web container provides a runtime environment for web related software components, including computer security, Java servlet lifecycle management, transaction processing, and other web services. The EJB specification is a subset of the Java EE specification.

The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999 and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) and JSR 345 (EJB 3.2).

The EJB specification provides a standard way to implement the server-side (also called “back-end”) ‘business’ software typically found in enterprise applications (as opposed to ‘front-end’ user interface software). Such software addresses the same types of problem, and solutions to these problems are often repeatedly re-implemented by programmers. Jakarta Enterprise Beans is intended to handle such common concerns as persistence, transactional integrity and security in a standard way, leaving programmers free to concentrate on the particular parts of the enterprise software at hand.

The EJB specification details how an application server provides the following responsibilities:

Transaction processing
Integration with the persistence services offered by the Jakarta Persistence (JPA)
Concurrency control
Event-driven programming using Jakarta Messaging (JMS) and Jakarta Connectors (JCA)
Asynchronous method invocation
Job scheduling
Naming and directory services via Java Naming and Directory Interface (JNDI)
Interprocess Communication using RMI-IIOP and Web services
Security (JCE and JAAS)
Deployment of software components in an application server

Additionally, the Jakarta Enterprise Beans specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container. Note that the EJB specification does not detail how an application server provides persistence (a task delegated to the JPA specification), but instead details how business logic can easily integrate with the persistence services offered by the application server.

Businesses found that using EJBs to encapsulate business logic brought a performance penalty. This is because the original specification allowed only for remote method invocation through CORBA (and optionally other protocols), even though the large majority of business applications actually do not require this distributed computing functionality. The EJB 2.0 specification addressed this concern by adding the concept of local interfaces which could be called directly without performance penalties by applications that were not distributed over multiple servers.

The EJB 3.0 specification (JSR 220) was a departure from its predecessors, following a new light-weight paradigm. EJB 3.0 shows an influence from Spring in its use of plain Java objects, and its support for dependency injection to simplify configuration and integration of heterogeneous systems. EJB 3.0 along with the other version of the EJB can be integrated with MuleSoft-v4 using MuleSoft certified PlektonLabs EJB Connector. Gavin King, the creator of Hibernate, participated in the EJB 3.0 process and is an outspoken advocate of the technology. Many features originally in Hibernate were incorporated in the Java Persistence API, the replacement for entity beans in EJB 3.0. The EJB 3.0 specification relies heavily on the use of annotations (a feature added to the Java language with its 5.0 release) and convention over configuration to enable a much less verbose coding style. Accordingly, in practical terms EJB 3.0 is much more lightweight and nearly a completely new API, bearing little resemblance to the previous EJB specifications.

Enterprise application integration (EAI) is the use of software and computer systems’ architectural principles to integrate a set of enterprise computer applications.

Enterprise application integration is an integration framework composed of a collection of technologies and services which form a middle ware or “middleware framework” to enable integration of systems and applications across an enterprise.

Many types of business software such as supply chain management applications, ERP systems, CRM applications for managing customers, business intelligence applications, payroll, and human resources systems typically cannot communicate with one another in order to share data or business rules. For this reason, such applications are sometimes referred to as islands of automation or information silos. This lack of communication leads to inefficiencies, wherein identical data are stored in multiple locations, or straightforward processes are unable to be automated.

Enterprise application integration is the process of linking such applications within a single organization together in order to simplify and automate business processes to the greatest extent possible, while at the same time avoiding having to make sweeping changes to the existing applications or data structures. Applications can be linked either at the back-end via APIs or (seldom) the front-end (GUI).

In the words of research firm Gartner: “[EAI is] the unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.

The various systems that need to be linked together may reside on different operating systems, use different database solutions or computer languages, or different date and time formats, or could be legacy systems that are no longer supported by the vendor who originally created them. In some cases, such systems are dubbed “stovepipe systems” because they consist of components that have been jammed together in a way that makes it very hard to modify them in any way.

If integration is applied without following a structured EAI approach, point-to-point connections grow across an organization. Dependencies are added on an impromptu basis, resulting in a complex structure that is difficult to maintain. This is commonly referred to as spaghetti, an allusion to the programming equivalent of spaghetti code.

For example, the number of connections needed to have fully meshed point-to-point connections, with $n$ points, is given by ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ (see binomial coefficient). Thus, for ten applications to be fully integrated point-to-point, ${\tfrac {10\times 9}{2}}=45$ point-to-point connections are needed, following a quadratic growth pattern.

However, the number of connections within organizations does not necessarily grow according to the square of the number of points. In general, the number of connections to any point is only limited by the number of other points in an organization, but can be significantly smaller in principle. EAI can also increase coupling between systems and therefore increase management overhead and costs.

EAI is not just about sharing data between applications but also focuses on sharing both business data and business processes. A middle ware analyst attending to EAI will often look at the system of systems.

EAI can be used for different purposes:

Data integration: Ensures that information in multiple systems is kept consistent. This is also known as enterprise information integration (EII).
Vendor independence: Extracts business policies or rules from applications and implements them in the EAI system, so that even if one of the business applications is replaced with a different vendor’s application, the business rules do not have to be re-implemented.
Common facade: An EAI system can front-end a cluster of applications, providing a single consistent access interface to these applications and shielding users from having to learn to use different software packages.

This section describes common design patterns for implementing EAI, including integration, access and lifetime patterns. These are abstract patterns and can be implemented in many different ways. There are many other patterns commonly used in the industry, ranging from high-level abstract design patterns to highly specific implementation patterns.

EAI systems implement two patterns:

Here, the EAI system acts as the go-between or broker between multiple applications. Whenever an interesting event occurs in an application (for instance, new information is created or a new transaction completed) an integration module in the EAI system is notified. The module then propagates the changes to other relevant applications.

In this case, the EAI system acts as the overarching facade across multiple applications. All event calls from the ‘outside world’ to any of the applications are front-ended by the EAI system. The EAI system is configured to expose only the relevant information and interfaces of the underlying applications to the outside world, and performs all interactions with the underlying applications on behalf of the requester.