This is a standard sort of SCA view. So what are the good things about SCA?
- SCA helps you think about the business services not the technology
- SCA helps you construct services, and their teams, around a service view
- SCA gives you a management entity that fits with a service architecture not a technology architecture
- SCA destroys the dreadful layer marketectures that vendors push
- Think about your services
- Organise your teams around those services
- Work out the best way to build each service
- Delivery
- Operate
So that is what SCA is good at. What about JBI? Well lets first be clear JBI is not for developers its for product companies. JBI is one of the few standards out there (SCA is another) that actually has a business case for its existence. The various scripting JSRs and some of the other fanboy elements out there just have a technical case. This is typical of lots of IT which aims to deliver technical flexibility to the detriment of business flexibility.
So how does JBI work with SCA? Well JBI is about Service engines communicating so its not about the services its about how the engines talk together. This means that it works underneath the services. Combining SCA and JBI therefore is pretty easy
In reality the call isn't from one code area to another its really between the service engines, i.e. the bit that JBI does. The goal of JBI therefore isn't portability of the code/service its portability of the engines.
This solves one of the big issues of SCA which is that implementations are limited to a single vendor's platform. It also doesn't really have a great upgrade story so you are again linked to what the vendor wants to do, if the BPEL engine you are happy with is upgraded and the rules engine that you don't like is upgraded and they all run on the same platform which is upgraded then you have to move everything at once, which is a bit of a pain.
So the real vision here is for SCA and JBI to work together, unfortunately at the moment the JBI group is missing Oracle, IBM and SAP which makes it unlikely that this will be done. This is to the detriment of customers as it means that SCA will remain a great single vendor platform but will not have the portability and operational flexibility that JBI could deliver.
Politics appears to be getting in the way of an SCA/JBI match up as no-one I've spoken to on either side of the divide thinks it isn't technically a good idea.
Technorati Tags: SOA, Service Architecture
3 comments:
Great article,
and I certainly agree that these two can and probably *should* integrate with each other,
people have been contributing opinions (including Mike from IBM and Peter from Sun) concerning jbi and SCA on one of my posts at
http://agileconsulting.blogspot.com/2008/05/highlights-of-sca-at-javaworld-2008.html
Peter has told me that Sun could basically consider SCA if there was clear user demand. I'm doing my best to drum up such demand, feel free to post your support, l will make sure to be forwarding them to him.
Jeff Anderson
http://agileconsulting.blogspot.com
I enjoyed the article, great stuff. One can only hope JBI will can acceptance as a compliment to SCA. I'm a novice but it seems odd to me to take a technology neutral architecture and bind it to a vendor's implementation.
The link for "should work together" appears to be broken. It points to http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html. Is this post still available elsewhere?
The talk is ultimately interesting, and yet open wide discussion areas from a verity of role players in this arena. As known to all and especially in the Cloud Computing landscape, that cloud users differ in their perspective role types and domains, thus for a business process management, terms like goal, tactics, intents are high level aspects of a business motivation model (OMG - BMM), moving towards agility retains these elements and their behaviors to business process owner, process designer, business rule authose, policy author,.. and so on. These parties could be defined at two realms design and run-time, their sort of requirements differ from one another as from SOA viewpoint when each of them is a service provider who are the service consumers and vice versa, the interaction model in SOA architectures including SOA applications is yet still a good material of research. JBI is made by Sun to support technology integration for different "models" and their "implementations" under one container based on Java JSR's standards. JBI is quite interoperable and yet it also prevails high level of integrity between different aspects (AOP Plugin's), thus it provides a good conceptualization of SOA main concepts like separation of aspects and loose coupling. But to also remember that this support is totally subjected to "business" landscape not for programming paradigm. Forfeited programmer's concerns like code portability, code mediation are still beyond the reach even when Model Driven Development tools like UML tried to narrow this gap. SCA architecture came like a savior in this long episode. SCA bridges the gap between development and business (including BPM) paradigms, thus by giving a good understanding to SOA concepts represented by service composites and components. Many engines over SCA model are made to support runtime behavior through many implementation types to support traditional languages like c++, cobol and new like Jruby and JPython. The most interesting one is the link to business through BPEL model. Recently Petals ( a JBI container) supported linking to SCA container as Service Engine. So a semi concrete relationship now between EJB container through Session Beans(Application), SCA composites and components, BPEL model are all in one depot of JBI container.
Post a Comment