Java-Based Service Oriented Architecture

Service Oriented Architecture (SOA) is a hot topic in the past few years. When you say "SOA", most people think in terms of XML-based web services (mostly SOAP on http) communicating through an Enterprise Service Bus.

There's a funny thing about it; people claim that one of the selling points is language-neutrality, but they don't actually practice it.

If you ask corporations that are implementing SOA what languages they expect to be using to implement their services, you get roughly the following responses (informal survey, of course)

• 90% or so will say either Java or dot-Net
• 5% or so will say Java for the business logic with dot-Net front-end
• Maybe 5% will say they actually have a mix of languages in the SOA

So, people are mostly implementing SOA in Java, and yet, they spend huge amounts of effort encoding all their interfaces in WSDL, defining all their data in XML Schema, and implementing Enterprise Service Buses to provide protocol-neutral connectivity.

If it were easier to get up and running, Jini would be a great solutions for most current users of SOA (we'll just ignore the fact that Jini predates current ideas of XML-based SOA).

The archetypal SOA looks like this:

Looking at this from a Jini/River perspective, we can make a few observations:

• By decoupling service location through the registrar, and allowing for dynamically downloaded proxies that implement whatever protocol the service wants, Jini makes most of the ESB functionality (a magic connectivity cloud) unnecessary.
• Standard SOA's concept of adapters could be seen as a variant of the Surrogate architecture. The big difference is that Surrogate assumes that the non-Java service is an active participant in the Jini network. To implement the SOA adapter pattern, we need to be able to add a surrogate without the non-Java service initiating it (not a big change to the Surrogate architecture).
• Jini/River services can be readily accessed from traditional Java user interface technologies, both Swing and Web Apps. The only sticking points are the need to run the client with a security manager, and the difficulty of having the client export a codebase. The security manager is not a problem (e.g. Tomcat runs happily with a security manager) and the codebase issue can be handled by careful design of the service interface, when the service is meant to be called directly from a UI (basically make sure the API only uses platform classes that won't require downloading bytecode; this is no different from what people do for EJB usage).
• As of August 2011, Jini/River doesn't have anything similar to a BPEL engine that would automatically handle business process persistence, compensation, etc. That functionality would be convenient, however it is possible to implement a business process in plain Java. For short-lived processes (micro-flows), it's probably easier to use plain Java.
• The Service Registry/Repository in XML-based SOA is used for a different purpose from Jini's registrar; it is more of a design-time repository of service metadata. A user-friendly front-end to an SCMS would do just as well for that purpose.
• Jini/River currently lacks "enterprise-y" features like deployment lifecycle governance, centralized monitoring, centralized authorization, etc. Centralized authentication and message-level privacy is already built in to the JERI stack.
• We also lack a development environment that is friendly to "corporate-type" programmers. Although the overall complexity of Jini/River is arguably no greater than in the WS-* stack, a WS-* organization has the option of just buying IBM's RAD or using the Weblogic stack. At the same time, these are expensive propositions.

With a little work on the deployment model, and perhaps a usable process engine, Jini/River is an attractive SOA stack.