Composite Materials

The Developer's View of SOA: Just adding complexity?

Modern incarnations of SOA don't (yet) agree on the definition of SOA, let alone how a typical software developer ought to use SOA. In fact, some versions of SOA impose a unreasonable amount of extra conceptual baggage on developers. From my perspective, this is a Big Mistake -- anything that slows down development of new applications (or services), especially complexity, is Wrong with a capital 'W'.

What SOA should be about is what I like to call "invisible plumbing" that enables reuse and refactoring of composite applications. The key part for developers is the word "invisible". When I write an EJB, for example, I don't want to have to simultaneously think about how the EJB is used in a composite application. I don't want the developer concurrently developing business logic (which he ought to be doing), and providing for the system architecture (which is conceptual overload). Instead, the developer ought to work exclusively in domains he is expert in, and leave the business of weaving the EJB he writes into the overall SOA fabric to another expert. The SOA plumbing ought to be invisible to the developer. This isn't anything new; separation of concerns is a standard approach to reducing complexity in software development.

A standard like JBI, by creating a "plumbing standard" that uses the WSDL services model as its exclusive foundation, is invisible to any developer using technologies that map to/from the WSDL services model. I can write, say, EJB 3 business logic, using standard web services technologies (like JSR 181 annotations or JAX-WS), without thinking about JBI (or, indeed, even knowing that a JBI service engine will host the EJB). No extra conceptual baggage: I just use standard Java EE technologies, in the usual fashion. The JBI plumbing that puts my EJB into an integration fabric is invisible to me, the developer.

This contrasts sharply with other SOA models. Some embrace a wider definition of "service", including annotated Java, WSDL, IDL, and even annotated C++, all at once. Setting aside practical issues of interoperation and semantic mismatches between these different technologies, we are left with a problem for our developer: the plumbing is more visible. By having to deal with multiple service implementation technologies, the developer must necessarily be aware of this services model before he can use it from within his application code. This adds complexity. (An aside at this point: Don't think I'm advocating this wider, "mixed" model of services. I'm warning against it!)

This "mixed" services model, despite its complexity, has some attractions. In particular, it allows for creation of a component model that combines close-coupling and loose-coupling in a uniform fashion. This is attractive, at first blush, but the problems I mentioned previously of reconciling the different service technologies (interop & semantics) make this approach difficult, perhaps problematic. It certainly makes the developer's view of SOA much more complex, and virtually mandates complex tooling to handle many of the development issues it creates.

This business of a "mixed" vs. "single" services model is more than a detail, or simple generalization. It is a basic choice affecting complexity that is surfaced to the developer. It also affects the basic cost of creating and maintaining an integrated system, based on multiple services. It will often be the case that the developer in the "mixed model" environment will need to reconcile the differences between service technologies. For example, what happens if an EJB developer wants to call a service that happens to be offered through a C++ interface? Complexities galore for the developer.

(The architectural picture also suffers under the "mixed" services model. A key feature of SOA is decoupling -- the minimization of the "knowledge" a service consumer has of a service provider it is is using, and vice versa. This enables reuse and refactoring, since the points of coupling are well known in a SOA. The coupling should be fully described in a simple place: the service description, published by the service provider. The "mixed" model adds close-coupling to this picture. Reuse becomes far more limited (implementation technology is exposed), refactoring becomes problematic (details of coupling between consumer and provider are now in multiple places, requiring multiple co-ordinated changes to accomplish a single change in the system).)

It is certainly true that the developer can avoid many of these problems by avoiding certain features of the "mixed" services model. This requires that the developer keep in mind the overall system being built, in order to avoid problematic combinations of technologies. This is an additional conceptual burden for the developer, which serves only to slow him down. I don't think the developer would thank us for adding to his list of worries; I wouldn't blame him if he "voted with his feet" and found a simpler way to get his job done. SOA's loose-coupling ought to work at design-time as well as run-time.

To summarize: Developers don't need to think like architects. They need to concentrate on smaller problems. Composition of what developers create into larger systems is a separate task.

Mapping this to JBI: developers don't "use" JBI for developing SOA applications. Instead, they use domain concepts and technologies related to the problem they are addressing. Thus an EJB developer can happily work using JSR 181 annotations and JAX-WS 2.0 as his ways of interacting with the SOA world. Such EJBs can be hosted in JBI environments (like the GlassFish EJB Service Engine). The full power of the JBI "plumbing" can be used to use EJB logic in composite applications, make such logic available through a host of binding component types, and make other services from other service engines (or external service providers) available to the EJB. All of this is accomplished, not through new APIs and requirements that the EJB developer must master, but through already known technologies. Yes, that's right: no new APIs, SPIs, design patterns or micro-architectures. Thus the "invisible plumbing."

Posted at 08:22AM Apr 10, 2006 by rtenhove in Service Oriented Architecture  |  Comments[4]