Tuesday, March 15, 2016

Java EE as a Platform for Enterprise Application Integration

Enterprise application integration (EAI) combines separate applications into a co-operating federation of applications. Using any EAI solutions like IBM Integration Bus, Oracle Service Bus, SAP PI/XI, Mule ESB, etc., etc., etc. is definitely the best option, but sometimes a customer doesn't wish to pay for a solution created by a well-known vendor for a wider market. A custom-developed solution is an answer here. There are many technologies and frameworks for linking enterprise applications within a single organization together, but I would describe some Java EE advantages in this article and share my personal experience of developing a real production-ready integration application.


Challenge


The integration application that is under consideration loads data from a number of billing systems to a CRM system. The enterprise that application was developed for has many business branches, and a billing system is installed for every branch.

Every billing system is a two-tier application built over an Oracle Database using PL/SQL. The application publishes events through a special event table. When an event occurs, the developed integration application reads a record described the event and gets a change from the billing database, then the information is transformed into a CRM system related format and loaded to the CRM.

One picture is better thousands words:



Application design


The integration application is divided into three parts: a loader, a control module, and a user interface, which is used for configuration and monitoring. The loader, as it referenced, reads the information from every billing system and loads it to the CRM. So, the loader implements the core logic of the application. The loader connects to each application using plain JDBC. For each data type here is a pair of query objects: a load query object operates with a billing system and a save query object stores the data of a type to the CRM. Functional programming is used for data transformation. The loader is accessible as a service, but no data is transmitted here, the service is used only for kick-off messages handling. The controller module manages the load logic sending the kick-off messages every ten or more seconds (it can be configured). Because a thread is created for every business branch of the enterprise, the controller module invokes the loader concurrently. The threads are managed by an application server the application is deployed on.


The purpose of the user interface is just configuration and monitoring. The application configuration is stored as XML in a database CLOB field. JAXB is used for XML marshalling/unmarshalling.

Java EE in use


In this part, I'll describe some techniques and Java EE related specifications used during the development of the application.

CDI

Since Java EE 6, a new component model for EE is here. I mean Context and dependency injection (CDI). In the Java EE 5 time, only EJBs were a kind of components the inversion of control container could have a deal with. So, EJBs were injected into servlets as well as into other EJBs. The situation has significantly improved, and every kind of management components are operated by CDI, i.e. EJBs, managed beans, data sources, queues, connection factories or even POJOs.

Injection points are configured by annotations. If a number of the same interface implementations have to be injected into different points, the injection is qualified by an annotation too.


Here are a number of classes instances of will be injected:


The injection points:


During the development of the application, CDIs also were used for injection resources into some application objects. For example, a reference to a data source has to be injected into the classes implement the DAO pattern. A specific class marked with the @javax.enterprise.inject.Produces annotation was used for the injection.


Well, for the application, CDI significant reduced a number of used EJB components and let implement such complicated in terms of developed classes number design patterns as Query Object. Since Java EE 6, it is recommended to inject even JSF managed beans and EJBs by using the @javax.inject.Inject annotation instead of @javax.ejb.EJB.

CDI also supports programming techniques like interceptors and aspect-oriented programming as well as publish and subscribe to events, but, during the development of the described application, these techniques were not used.

Startup components

Each IoC container implemented in the Java EE world (EJBs and CDI components) provides only lazy injection, so an injected object will be built only if a component dependent of is being built. For example, a cache of some objects will be built only in case an object containing the cache is being invoked somewhere in a program. Since Java EE 6, here is the @javax.ejb.Startup annotation, a component marked with the annotation will be started, it means every component's method annotated using @javax.annotation.PostConstruct will be executed. These methods are used for a number of typical startup operations such as cache registration or timers starting.

If a component has to be built after the successful starting of another component, the @javax.ejb.DependsOn annotation should be taken into account. The component has to be marked with the annotation and the dependency is assigned as the parameter.



Only singleton session beans can be annotated with @Startup.

Singleton session beans and concurrency

For EJB's long time of life, the pool of components has been being existed because the Java EE environment was designed for multithreading. Each component instance is executed only in one thread, so the component developers don't care about concurrency and multithreading. The situation is totally different from servlets, so a servlet instance handles all made requests concurrently and must have only isolated access to shared data. Any implementation of an object pool consumes more resources than a single object, so singleton session beans have been added to the specification since Java EE 6. This kind of components works just a servlet, only one instance of a component handles all made requests, but, unlike a servlet, by default each business or timeout method of a singleton session bean is being locked to other clients while a client is calling that method. If the method may be concurrently accessed, the method should be annotated with @Lock(READ).


Timers

The integration solution loaded data to the CRM system by a small piece in a unit of time. The control module invokes the service every 10 seconds (the interval can be changed). The timer Java EE feature is utilized as a core of the control module logic. Let's look at the LoadDataTimerBean class.


For each connected application (so, an billing system installed for a particular business branch of the enterprise), a timer is registered into the Java EE timer service. The registration is performed in the initTimers method annotated with @PostConstruct, and the timer is canceled in the removeTimers method annotated with @PreDestroy. The both methods are the methods of a singleton session bean, marked with the Startup annotation. The business logic is implemented in the timeout method annotated with @Timeout. Because here is a thread for every business branch of the enterprise, the method was concurrently called from multiple threads and is annotated using @Lock(LockType.READ), data from every business branch can be loaded into the CRM system simultaneously.

JSF 2.x

The application has a user interface developed using the JSF 2 specification. JSF 2 was a big step forward since the JSF 1.x times. Faceletes rock, goodbye, old JSPs, we will remember about you. In my personal opinion, templates provide a common look and feel for application pages and managed component methods invocation just from markup are brilliant things.

There is a project, maintained by the top JSF enthusiasts: Arjan Tijms, Bauke Scholtz, and Jan Beernink, focuses on utilities that ease everyday tasks with the standard JSF API. Well, I mean OmniFaces. The project is a response to frequently recurring problems encountered during ages of professional JSF development of the JDevelopment team and from questions being asked on Stack Overflow. The beautiful visually oriented components are the purpose of other libraries and are already known and loved for. OmniFaces is a powerful replacement for reinventing the JSFUtils or FacesUtils utility classes for every JSF web application as well as many custom components, tag handlers, and workarounds or enhances in JSF.

What to add to Java EE


Unfortunately, Java EE proposes nothing for application configuration management, so here isn't a standard API for processing .properties files. For the application, all properties were serialized into an XML file persisted in a CLOB database field. JAXB was used for parsing/serialization XML data. It is unnecessary to store the configuration in a database, but I did it because Java EE warns of using a server's filesystem. It would be a right decision if an API for configuration file handling was added to the specification.

Conclusion


Each new version of Java EE is becoming more and more useful for development. Much time has gone since the EJB 2.0 days, when two interfaces, one class, and a deployment descriptor must be implemented. Java EE 5 was a breakthrough innovation, Java EE 6 added many brilliant things, and finally, Java EE 7 has brought a number of addition cosmetic techniques. As shown in the article, context and dependency injection, concurrent singleton session beans, and Java Server Faces 2.x provide a new way of enterprise application design.

If you are starting a new project, and a production-ready application server is allowed, Java EE can be a good choice. Except some grumbling, Java EE is a good platform for designing and developing an enterprise application, including enterprise application integration solutions.

Nice article? You also can read the following:


Would you like to give a 'Like'? Please follow me on Twitter!