Ron's View of SOA
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.
Huh?
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.
I think you failed to recognize a critic of SCA. Read it again with than in mind.
Stefan,
I’ve been accused of putting too much information into my blogs, and perhaps you are a victim of this. I’m not advocating the “mixed services model” that I was discussing. If you read carefully, I was warning against it! I suspect that we agree on many of these points.
We obviously disagree on other points. I believe that allowing developers to work within a straightforward web services model is a good thing, and that attempts to introduce new component & distribution models to existing programming models (such as EJB or JSP) is unneeded. Technologies like JBI will transparently host such application artifacts (EJBs etc) within a SOA environment.
My measure of transparency of the application “distribution” mechanism is simple. Do I have to change any application code to alter application partitioning? For example, say I have an EJB that uses JAX-WS to consume a particular service. What do I have to do to change the endpoint of the provider? In most SOA alternatives, the answer would be “change the WSDL, run wsimport, recompile the EJB, and redeploy it.” That is a terrible answer! Invisible plumbing, such as JBI, allows such changes to be made without touching application code, or deployed application artifacts.
Note that I’m not saying that the distributed nature of a composite application built atop a SOA is completely hidden from the deveolper. That is simply impractical, given the nature of networks. That’s why I’m careful to use examples where web service technologies are used; these already reflect Deutsche’s eight fallicies of distributed computing (http://today.java.net/jag/Fallacies.html). While JBI enables integration of a virtually unlimited range of application/technical domains to the WSDL 2.0 services model, the most straightforward way to discuss composite applications running atop a JBI infrastructure is to talk about web service from the application level. This does JBI something of a disservice, but it general discussions of JBI and SOA, it serves well.
Oh, and one other thing: JBI is structured so that locality of service providers and consumers is not a primary feature of the messaging APIs. Determining locality CAN be done, but ordinarily isn’t. The reasons are quite simple: to get the main benefits of SOA, you have to decouple provider from consumer. Bringing locality to he fore of interactions between consumer and provider introduces several undesirable side effects: - more coupling - two different interaction models, with potentially different semantics - testing. Many partitioning combinations must be exercised in order to exercise all the code paths!
Hi Ron,
Thanks for the comments. As to the first one, I agree with basically everything you write here. I’m still not sure what you mean by the “mixed model” — I understood your post to mean that advocated against it, so that’s not the problem. My disagreement was that to me, SOA is explicitly about being able to mix C++ and Java and C# and Ruby implementations, since all I’m focusing on is their interfaces. Now I guess what you really meant is that none of these technologies is suited to describe the interface — which I totally agree with.
I’m not positive I really understand your second comment, though.
Stefan