Update: I may have misunderstood the intent of the original posting — see the comments below.
Ron Ten-Hove, JBI spec lead, makes a number of points regarding the developer’s view on SOA — and I fail to get them. Let’s see:
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’.
No disagreement, I guess ;-)
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.
“No!,” I cry, this can’t be true. I thought we had left this idea behind, and I thought even the JBI folks accepted that distribution in itself can’t be hidden via configuration. Distributed programming is not a simple aspect than can be added as an afterthought …
Ron then goes on to describe the benefits of JBI as the “invisible plumbing”, and then writes:
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.
Guess what: Some even embrace a definition that says a service is completely independent of the underlying technology. Wasn’t that the whole point of Web services in the first place?
More stuff I just don’t get:
This “mixed” services model, despite its complexity, has some advantages. 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.
I notice that I would have to quote the whole posting if I wanted to cite everything I disagree with. This is just amazing …
In summary, the argument seems to be that JBI simplifies things because it streamlines everything … although I don’t understand how that relates to its purported invisibility … or why JBI has benefits for a JAX-WS service implementation, which could talk to a WSDL-defined C++ service just as easily … nope, I fail to see the argument.