J2EE Components and Services
- J2EE Application Programming Model
- J2EE Application Components
- J2EE Enterprise Services
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In this article, we look at the J2EE Application Programming Model, which is the underlying blueprint for all J2EE applications. We then examine the J2EE components and enterprise service APIs, which constitute the Application Programming Model—one by one. En route, the relationship between J2EE APIs and vendor-specific drivers, resource adapters, and connectors is also explored briefly.
J2EE Application Programming Model
We have already discussed various components, enterprise services and runtime environments that constitute J2EE in earlier articles. Now it is time to assemble all of them in one place, and take a comprehensive look at the overall J2EE platform.
Have a look at Figure 1 below.
)
Figure
1 J2EE Application Programming Model.
This famous model is often known as the J2EE Application Programming Model. All enterprise J2EE application architectures are built on top of this basic design.
Because our main focus in this series is on the application server area, we will first consider Web and EJB containers in our discussions.
Points to be noted in Figure 1 are as follows:
There is a clear-cut distinction between Web containers and application containers—implying that they are relatively independent of each other, and may represent products from two different vendors.
Enterprise services are available to both containers. In other words, access to facilities such as database connectivity, e-mailing, directory services, and messaging are available to Web container components as well as EJBs.
Components can access EIS resources only through one or more enterprise service implementations in the form of drivers and adapters.
The Java Virtual Machine permeates the application server environment, implying that the Java Runtime Environment (JRE) is available with all application servers.
In any project, it is generally a good practice to consolidate all custom-made services and libraries that are frequently used by application components into a separate layer. In the J2EE model provided, I've termed these services custom component libraries.
These libraries are developed in-house, and are not a part of standard J2EE application server. These libraries typically tend to grow over a period of time as the projects mature.
An example of this is a configuration file utility, which reads a configuration filename, finds out its exact physical location in the file system, and returns the necessary parameters as integers or strings.
It is also typical to find developers ending up on the top of core enterprise services provided by J2EE when writing their own customized access routines. It is worthwhile to consolidate them into a separate layer called service access libraries.
For example, let us say we are using IBM's MQ series as the messaging system in a project. We often end up writing some simple APIs on the top of the JMS codes used to access the MQ series services—such as adding standard, enterprise-defined headers and footers for all outgoing messages. It is better to consolidate these services as common APIs, and make them available across the enterprise platform.
In short, service access libraries provide a level of abstraction above the J2EE APIs, which is very specific to a given enterprise platform.
Kindly note that custom component libraries and service access libraries are not shown in the official J2EE Application Programming Model released by Sun.