Java Platform, Enterprise Edition

Java EE Journal

Subscribe to Java EE Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java EE Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

J2EE Journal Authors: Stackify Blog, APM Blog, Sumith Kumar Puri, Javier Paniza, Yakov Fain

Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

SOA Solutions with J2EE

Using different technical and functional requirements

Throughout this article I'll describe how an effective service-oriented architecture (SOA) can be achieved using J2EE technologies. In particular, I'll focus on which J2EE component types and communication channels to choose according to specific, real-world situations.

Description of the Example System
To illustrate an SOA system made of J2EE technologies, nothing is better than a good old example. Figure 1 depicts the main situations that can arise in a realistic SOA system. A component stereotype indicates the type of client or service; a dependency stereotype indicates the communication type, either as a technology (such as Web services) or as a protocol (such as CORBA IIOP); and a no dependency stereotype indicates RMI communication.

The system allows client systems to process an order (service OrderWorkflow), manage customers (service Customer), and produce reports (service Reporting). The OrderWorkflow service checks product availability and retrieves product details (service Product), creates a new customer if needed (service Customer), and orders the selected products (service Order). The Order service persists the order (service OrderData), manages the payment (service Payment), and triggers some process in a legacy system (service BackOfficeOrder).

Service Layers
Services differ according to multiple criteria. Whether the service is business oriented, public or private, or stateful or stateless dictates what layer the service is in and ultimately how it is implemented and what interfaces it exposes.

Top-layer services such as OrderWorkflow are coarse-grained business services, often stateful, that depend on one or more finer-grained stateless business services. Bottom-layer services are fine grained and data oriented, not business oriented.

Services are also separated into public and private services. Public services are services that are available outside of the system, and possibly outside of the organization. They are typically services that have a business meaning. Private services have no business meaning; they exist to support business services and there's no point in making them available to other systems. In Figure 1, public services are colored in blue and private services are not colored.

Although the number of layers of an SOA system is arbitrary, we can categorize them and associate usual J2EE component types to them as shown in Table 1.

Service Communication Interfaces
In SOA systems, service interfaces are even more important than service implementations, because interoperability essentially depends on the communication technologies supported by the service interfaces. Remember one of the founding principles of service architecture: the service implementation is separated from the service interface(s).

To continue this discussion, we'll distinguish between "internal" and "external" clients. A client is internal if the organization controls the network path between the client and the service. In all other cases the client is external. This distinction is driven by the fact that firewalls might be located between the external client and the service, and no assumption can be made on which ports the firewall keeps open and which protocols the firewall lets pass, except that it allows text over HTTP. In particular, this is true if the client component is located on the Internet.

The major condition to decide on in a service interface technology is whether the service clients are internal or not. In Figure 1, external clients are red and internal clients are green. ExternalMainClient uses the Internet. As mentioned earlier, this causes severe restrictions as to which ports and protocols are available for communication. For example, communicating in RMI or IIOP is not realistic, since most firewalls will not let these protocols go through. In such a situation, only text-based protocols over HTTP (or HTTPS) should be considered.

Web services, a standardized technology that leverages the convenience of XML as text over HTTP, is the best technology available, provided that the client platform supports Web services. The .NET client from our example understands Web services. If it were not the case, we would have had to downgrade the communication to, for example, plain XML text over HTTP, with custom XML generation and parsing on the client side.

Now let's have a look at internal clients. OrderClient is a J2EE application client using RMI to communicate with OrderWorkflow. Why RMI and not Web services? Isn't Web services the most cool technology that every supporting platform should use when possible? Well, no. Using Web services between "internal" J2EE components has a heavy performance toll. Performance, which is a critical factor for most systems, is much more favorable to RMI than to Web services. It must be noted that Web services still has opportunities for significant optimizations, but current Web services implementations are notoriously slower than RMI.

The golden rule is: if a J2EE service only has internal J2EE or Java clients, stick to RMI, but if you can't make this assumption, consider Web services.This rule can be understood with a bit of logic: the closer the interface technology is to the implementation technology, the less work that has to be done to translate between the two. For example, XML, which Web services messages are made of, is farther from Java than RMI is. The gap between XML types and Java types is wider than the gap between CORBA IIOP types and Java types, which in turn is wider than the gap between RMI types and Java types. To generalize this rule, we can say that the more interoperable a technology is, the slower it tends to be. Although technology implementations can provide exceptions to this rule, the rule remains true in the vast majority of cases.

Each situation requires a decision based on the trade-off between interoperability and performance.

Fortunately, interoperability and performance benefits can be combined thanks to the fact that a service can have more than one interface. OrderWorkflow is a good example. While its implementation of the application logic is developed only once, the service presents two different interfaces: one RMI and one Web services.

Moreover, with the right tools, service interfaces can be generated automatically from one another. For example, a tool such as Castor XML or a JAXB implementation can generate Java classes from the XML Schemas. The RMI interface is thus generated with minimal hand coding. Enabling Web services as EJB endpoints is also a good alternative.

Figure 2 focuses on the OrderWorkflow service to illustrate how a single service is accessed through two communication channels. ExternalMainClient accesses the service through its Web services interface, which in terms of J2EE component types is a Web application resource (WAR). Upon receiving a Web services request, the WAR makes an ordinary Java method call to the business delegate located in the JAR, which in turn makes an RMI call to the EJB.

In contrast, the local OrderClient J2EE client directly calls the delegate without going through the WAR. The service business logic is located in the EJB-JAR component, and the WAR implements a Web services interface layer above the ordinary business delegate. Both interfaces share exactly the same business logic. This design pattern ensures a multiple-communication-channel SOA as well as the scalability, distributability, and other capabilities provided by the EJB technology.

The marketing application is a C legacy application that calls the reporting component to present statistical data to the user. Marketing is an internal client, but does not support RMI. CORBA is an effective and mature distributed architecture available to both C and J2EE platforms. Again, the reason for choosing CORBA over Web services is the performance. As a general rule, internal components should not communicate through Web services unless some other capability of Web services, such as the UDDI publish-discover mechanism, for example, is a deciding factor.

More Stories By Bruno Collet

Bruno Collet is a seasoned J2EE architect with five years of experience. He recently founded Studio 184 (, where he is developing the ApolloNews news aggregator. Bruno holds a masters in computer science from ULB (Belgium), as well as several industry certifications (

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.