02/09/08 :: [SOA] SCA Rocks [permalink]
This is week, the Tuscany team released the Tuscany Java 1.1 version. This is a major leap forward for SCA as it adds assemblies to Web 2.0.
Tuscany's fruit market sample shows how all this works:
Here is the assembly:
You just need to decorate your favorite JavaScript code as follows:
//@Reference
var catalog = new
Reference("Catalog");
//@Reference
var shoppingCart = new
Reference("ShoppingCart");
And the SCA infrastructure generates a store.js that does all the Ajax plumbing (JSON RPC or Atom).
<script type="text/javascript" src="store.js"></script>
This is pretty much what I was explaining in this post (Understanding SOA). I would not be surprised if the Tuscany team later develops the same kind of capabilities for WS-BPEL HumanTasks to complete the presentation layer.
I also spent some time exploring the latest Oracle SOA Infrastructure (11g) which includes an SCA implementation. I liked a lot what I was seeing. The latest beta has still a couple of glitches. I would like to draw you attention on the Mediator concept which basically provides a model driven implementation of the LC code that I was talking about in my infamous post about loose-coupling.
With so much power under the cover, I don't see why anyone would waste any more time with REST or Erlang. You have one of the most powerful development environment offering a true Resource Oriented Architecture, founded on asynchronous, peer-to-peer inter-actions (WSDL & BPEL) and composition (assemblies). It is not perfect here there are still a few things to fix, but be assured that this will happen.
There was also an interesting discussion on the Tuscany user list. Can a web service call another? I still owes this sample to David Chappell. Basically, Simon Nash says yes:
We have a few samples that show how to do this. You can either define the reference and service using explicit WSDL files, or you can let the Tuscany runtime generate these for you.
But, I want to build a "real-world" example to prove David wrong. See the tremendous value that SCA brings is that it separates the bindings from the WSDL definition (which is really what ebXML has been doing from the very beginning with the concept of Collaboration, Collaboration Profile and Collaboration Agreement). SCA doesn't really need a "collaboration profile" because the point of the SCA infrastructure is to support all possible of bindings and choose the one that's most appropriate for a given assembly. The "agreement" is the assembly. The ebXML ebBP specification supports arbitrary Web Service "assemblies" since 2004 (yes I meant to say WS assemblies, not just ebXML collaborations since being such good citizen we did not discriminate we allowed both to coexist in a collaboration, and in particular, Web Services only collaborations).
This is the example that Simon is talking about:
What you can see here is that the "end-point" is defined at assembly time and no longer at the time you design the WSDL. This is a major change, but it is profound. It is resolving a vexing issue that made it difficult to deal with "outbound" operations (out and out-in). The old remoting guys can now retire, the game is over. There is a new programming model in town. It is here to stay, it is here to change fundamentally everything we have done "the old way".