Sometimes we have to deal with a component that does not support any high-level communication technology. In this case, only low-level protocols remain. The Order service accesses the BackOfficeOrder legacy system by writing XML text on a TCP socket. BackOfficeOrder is nonetheless a service, but its interface is very restrictive in terms of communication technology and message format. Unfortunately, this situation is rather common. Access to BackOfficeOrder is managed through a resource adapter (Java Connector Architecture technology), a special kind of data source.

Communication Interface Summary
Figure 3 is a chart that summarizes the decision process for selecting an appropriate interface communication technology according to most usual situations. Alternatives such as JINI, HTTP tunneling, middleware systems, and the proprietary technologies of application servers are not covered.

Other Considerations
Asynchronous Services
Until now we've discussed only synchronous services. Indeed, RMI, CORBA, and Web services are inherently synchronous. Asynchronous services bring interesting capabilities when the time to perform an operation is likely to exceed the time that the client component is willing to wait. It also allows event-driven processes. Java Message Service (JMS) is the J2EE technology providing asynchronous capability.

In Figure 4, ExternalMainClient calls the Reporting service via Web services, and the marketing legacy application accesses the service via CORBA IIOP. For Reporting, the messaging queue is not visible for the client. Instead, to provide a degree of abstraction, producers and consumers are hidden under Web services and RMI interfaces. To switch from synchronous technologies such as Web services and CORBA to asynchronous JMS, the producer EJB generates a token that is immediately sent back to the client. After the reporting process is completed for a request, the response (the report) is placed in secondary storage (in a database, for example). The client can call back with its token at any time to check whether the report is ready. If it is, the report is sent back to the client. Alternatively, the client component could provide the server with a callback system, so that the server automatically sends the response to the client when the job is done.

Publish and Discover
SOA also promotes publishing and discovery of services. Publishing services is useful when we need very loose client/server relationships. In other words, it's important if the clients don't know where and how to reach the service directly. For example, if we set up a free news service that any client can use, we would publish the service so that any client is able to discover it and get a description of its message formats. In most other situations, the publish-discover mechanism is of little use. In the example system, the client/server relationships are static, as is usually the case in intraorganization systems, and makes publish-discover irrelevant. For Web services, publish-discover is provided by UDDI. No such mechanism exists in RMI, but, although it would not comply with any standard, it's easy to design an entry point that provides clients with the localization and interface descriptions of EJBs and other resources.

Transactions
As a small reminder, atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures. The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, and Durability) ensure that even in complex business applications, consistency of state is preserved despite concurrent accesses and failures.

In an SOA system transaction, demarcation typically defines whether a service creates a new transaction, uses an existing transaction, or does not support transactions. In our system, OrderWorkflow automatically starts a new transaction and all underlying services (Product, Order, Customer) use it. If at the end of the transaction the process of creating the order fails, the creation of the customer is rolled back and data integrity is preserved.

Support for transaction management differs according to communication technologies. RMI does support all that is needed, so that is again a strong point of RMI. Web services does not support transactions out of the box. There are, however, proprietary extensions, and a couple of extensions-in-the-making by Sun, OASIS, and others. This restriction means that a transaction started by the Web services client cannot be propagated to the Web services service, but the service is still able to start its own transaction as OrderWorkflow does.

RMI is CORBA-based; it's theoretically feasible to propagate a CORBA transaction to an RMI service and vice versa, but the lack of support for the specification makes it difficult at best.

To make things worse, it is notorious that transactions management across J2EE servers from different vendors is not seamless, due to the lack of compliance with the J2EE specification.

Security
J2EE provides authentication, authorization, and encryption. We can thus build secure channels between J2EE components.

For the same reason as for transaction management, interoperability of security mechanisms between CORBA and J2EE is far less obvious than the theory suggests.

As for Web services, current security capabilities are those of HTTP, because Web services works over HTTP. It means that Web services security can make use of SSL authentication and encryption, and this is enough for most business applications. When reaching a J2EE container, the container authenticates the user/password received via HTTP and retrieves user credentials to check authorization when the transaction wants to access protected resources.

Conclusion
The most important conclusion is that, because it has a significant performance cost, interoperability is not always desirable. To alleviate this hard truth, remember that a service can implement more than one interface, achieving interoperability as well as decent performance for a little extra work.

Also, it must be noted that the component approach underlying J2EE is well suited for SOA. For RMI services in particular, applying common design patterns such as session facade, business delegate, and service locator to EJB-based services enables compliance with all SOA principles except interoperability. This makes EJB-based services a great solution for SOA in a J2EE environment.

Even as we have seen that Web services technology is far from being a magic bullet for SOA systems, it is nonetheless the most effective technology to expose services when no assumption can be made as to the platform or the location of the client/server components, which is a common situation for top-layer business services. In other words, Web services is the best solution when interoperability is a requirement.

Resources and Further Readings

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Table 1