Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Stefan Tilkov on Jun 29, 2006
In a blog entry titled "What's wrong with SCA?", JBI spec lead Ron Ten-Hove criticizes the Service Component Architecture (SCA). Some choice quotes:The more I look at it, the less I like it. I have a couple of major reasons: it is too complicated, and it is a very poor approach to creating a service-oriented architecture.
SCA isn't a way to define a SOA: it is just another software component model. Give enough time, money, and consultants you could probably use SCA to realize a SOA, but SCA itself would be of little assistance along the way.
SCA is a poor choice if you are vested in Java, especially Java EE. SCA collides rather badly with technologies like JSR-181 JAX-WS, and EJB 3. At best SCA creates a more confusing story for Java developers; at worst it mandates a certain amount of rip-and-replace to fit into the SCA model & metadata requirements. This really forces the question: is this necessary? Unless someone can demonstrate why such pain would be worth enduring (and paying for!), I'd say the answer is a resounding NO.In Ten-Hove's opinion, the key problem of SCA is its multi-language/multi-interface support. The Java Business Integration (JBI) specification, standardized in the JCP as JSR-208, originally had support from many vendors. IBM and BEA later withdrew and abstained in the Approval Ballot, both citing doubts about JBI's value contribution for their customers as the reason. The SCA initiative was started by IBM and BEA, with support from IONA, Oracle, SAP, and others. The latter three support both JBI and SCA. In the view of Oracle's Edwin Khodabakchian, described in a blog entry written at SCA's release, the two technologies are supposed to coexist:
One of the beauty of SCA is that it is focusing only on things that a SOA developer sees and touches. SCA does not care about how the runtime that is going to execute a SCA module is architected. The runtime could be implemented as an ugly monolithic server which would compile all the SCA service components into Java classes or it could be implement as a modular set of engines (one for each component type) communicating between each other using an enterprise service bus.
JBI on the other side is a set of APIs focus on building an open, extensible and modular Enterprise Service Bus. So at the core there is very little overlap between SCA and JBI. I would say in the contrary that they are very complementary.
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
Right Collaboration Architecture Drives Business Transformation
Regaining control of the data centre
The 5 Mandates of Software Development Teams - Presto Manifesto
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
Please stop trying to spread misinformation. JBI and SCA are not competitors. Read Edwin K's quote: SCA and JBI are very complementary. SCA is a design-time model; JBI is about run-time infrastructure. You can use JBI to help execute SCA models.
Agreed. For example Apache ServiceMix is a JBI container which has an SCA component that allows you to drop your SCA POJOs - or JAX-WS/JSR 181 POJOs - into the JBI container to provide smart routing, mediation, orchestration and management etc. SCA and JBI are proven to work nicely together.
James
LogicBlaze
Fuse: Open Source SOA
Please stop trying to spread misinformation. JBI and SCA are not competitors. Read Edwin K's quote: SCA and JBI are very complementary. SCA is a design-time model; JBI is about run-time infrastructure. You can use JBI to help execute SCA models.
Ron, I don't see anywhere in Stefan's post that he said they are competitors, all he did was quote your own statements about SCA. He even ended the news post with a quote about how they are supposed to co-exist.
If they aren't competitors, perhaps you should not be so competitive? :)
Ron, I did read Edwin's quote - that's why I posted it ;-)
Maybe I should have left the "competing" out of the news item's title. I will not change it now (that would be sort of revisionist), but remember next time. Other than that, I stand by my view that (some of) those who did not like JBI created SCA, and (some of) those who created JBI don't like SCA.
Everyone can draw their own conclusions.
Other than that, I stand by my view that (some of) those who
did not like JBI created SCA, and (some of) those who created JBI don't
like SCA.
Everyone can draw their own conclusions.
I think you're right about the problems between the JBI and SCA supporters. But the reasons for the friction are not technical.
The two specifications are clearly targetted at different problems, with JBI business problem being a subset of the much broader SCA specification.
There's no reason why you can't use both JBI and SCA in a solution.
It's possible to speculate about some of the reasons for the potential friction between the two groups:
-JBI is Java-only and part of the JCP, whereas SCA has yet to be submitted to a standards organization and very much gives C++ equally status with Java. So it is unlikely to be part of the JCP.
The inclusion of C++ means that the SCA promoters are clearly aiming at large corporate customers with existing pre-Java business applications written in C++ (extremely common, especially in larger corporations).
-JBI does not have the support of BEA or IBM. Any Java specification, no matter how good (think JDO), is doomed to be marginal without the support of the two main Java vendors. This can't help the mood of the JBI spec team, especially given the high quality of their work.
-Some industry analyts (look up Forrester's latest report) have speculated that if the companies supporting SCA/SDO bring out products then JBI will probably find a niche as a Java-only subset of SCA. I'm not sure about this point given the different problems that the two specifications are addressing. It's more likely that they will be complementary.
-IBM has always maintained that ESBs are a design pattern, rather than a product or specification. However, IBM does have multiple technologies labeled as ESBs so its position is somewhat confused.
James, since you're a supporter of JBI and have SCA working with it, perhaps you can give us your view of the value of SCA? I looked at it briefly and it didn't seem terribly interesting. Seems pretty complicated for just another component model... Seems like if I wanted those systems built on different technologies to work together, I would just use web services instead and use a BPEL engine for orchestration. WS-Security is finally advancing to where it's useful, so what's the big advantage of the (still non-standard) SCA?
We all know that SOA applications are loosely-coupled. What does this mean? Lack of temporal constraints, lack of organizational constraints, and lack of technology/language constraints. Not all of services of a composed application are going to be written in Java. Don't get me wrong -- I love Java, and there's a huge commitment to Java out there. But not everything is or will be written in Java. Any specification for composing services has to enable different languages and technologies.
JBI has some interesting ideas, but two things need to be addressed:
a) JBI spends alot of its time worrying about the SPIs for interconecting containers as though all component containers are going to be written in Java. That may be useful for the general problem of container integration, but represents only a fraction of the kinds of containers that need to interoperate to enable cross-language and cross-technology composition of services. In fact, I think the majority of people who are using JBI now are using it primarily for integrating containers -- irrespective of SOA. I seriously doubt that container integration is the right way to achieve agile and loosely-coupled composition of services in any way. Loosely-coupled systems will only scale if they're constructed without depending on tight-coupling of the underlying component containers.
b) On the other hand, JBI spends only a little time focusing on the problem of an assembly language for the modularity of services. Interestingly, however, the part that does focus on assembly is all written in XML - having (rightfully, in my opinion) nothing to do with Java. So why is the assembly model being standardized as part of Java? Wouldn't it be more powerful and meaningful to be standardized as something that applies to many languages and technologies?
This is precisely what SCA is attempting to do -- to create a technology and language neutral assembly model for composing services, some of which may be implemented in Java, some of which may be implemented in BPEL, in C++, in COBOL, PHP, whatever.
Now, there is definitily a need to standardize the Java bindings to SCA -- to define how a Java-based implementation of a service can fit into the SCA model. But that's not what JBI is currently.
If you take JBI for what it really is in practice (that is, an SPI for integrating Java containers, and ignoring the Assembly spec for a moment), then I think the two could be compliementary -- solving two distinct problems with the information systems integration world. I don't think the language-neutral assembly model should be standardized by Java -- doing so will only limit its utility and relavence to the rest of the IT world.
Whether SCA is too complicated is a major point of concern -- we absolutely do not want the SCA assembly model to be complicated. The set of vendors working on the SCA are very sensitive to this and I know they are working hard to avoid any undue complexity.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply