SCA and JBI
With any luck, 2008 will be the year of JBI (at long last!)
His (long) entry is very much worth reading if you’re interested in both JBI and SCA. But while I have a lot of respect for Mark, I still maintain my opinion that both JBI and SCA are not worth the hassle.
JBI aims to standardize something that’s not worth standardizing — namely the internal interfaces between an ESB’s components. I’m not at all an ESB fan, but much less do I see the vendors collaborating to create pluggable components. JBI 1.0, to be quite frank, is not a great standard — it leaves such an amazing number of things open that I’d place almost any bet that two independently developed JBI components will not work together unless they’ve been built specifically for the same container. Even WS-* Web services are much more interoperable than JBI components, even though they can be developed in different languages and run on different platforms (which is not the case for JBI). Sure, maybe JBI 2.0 will improve dramatically, but I remain highly doubtful.
Regarding SCA, I simply refuse to believe both in a server-side component assembly model (the “just build those Lego™ bricks and stick them together” model) based on arbitrary interfaces, as well as in the possibility of having the same kind of abstract model for both fine-grained and coarse-grained services. I admit I’ve not yet looked into the programming model, but I thought we already had one (whatever its quality) in the Java space.
And last of all, I don’t see that you lose anything by using neither JBI nor SCA — independently of whether you’re a WS-* or REST guy, they just seem to be another great excuse for the vendors to build new products.
The point of both JBI and SCA (which attack different problems) is for multi-technology development. So sure JAX-WS is great if you want to write in Java, but what if you have a service that wants to have some BPEL, Biz Rules as well as Java, how to you package that up and how do the different bits of that service communicate (as infrastructure).
JBI and SCA are both aimed at multi-technology problems which aren’t solved elsewhere.
If I have a Java client written using JAX-WS, a service implemented in .NET/WCF, and a WS-BPEL engine, they’ll all be able to work together (in theory, at least) — all without SCA or JBI. I question the need for another integration layer, especially a Java-based one (JBI) and I don’t believe in the usefulness of an assembly model.
On JBI its not a developer integration challenge (which is where some of the crap examples have talked about it) its a product integration challenge. So its how the rules engine will share messages and information with the process engine and how these two can be split effectively so you can replace the bits independently and do upgrades independently.
Its true that WS gives you a way to do invocation of the end-point across platforms and that it great for external integration, but SCA gives you the ability to have a single development model across the WS and other protocol stacks (in this way the client side model is like WCF, but its just part of the puzzle).
For SCA the big win (for me) is around service deployment and for JBI its around the service lifecycle. There is a big assumption in JAX-WS and WCF that a service is a single technology thing, which means its pretty fine grained and then you have your BPEL “service” calling your Java “service” and your rules “service” being called from both. The SCA (and in a different way JBI) view is that actually a service might include all of those technologies so its important that these are deployed and managed as a single entity (SCA) and that the engines that they rely on work in a known and consistent way (JBI).
For services to be bigger things that just low level technologies then this sort of technology agnostic binding is (IMO) certainly required.