BT

JBI Spec Lead Criticizes Competing SCA Initiative

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Stefan, you've got it all wrong by Ron Ten-Hove

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.

Re: Stefan, you've got it all wrong by James Strachan

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

Re: Stefan, you've got it all wrong by Floyd Marinescu

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? :)

Re: Stefan, you've got it all wrong by Stefan Tilkov

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.

Re: Stefan, you've got it all wrong by PJ Murray

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.

Re: Stefan, you've got it all wrong by Jason Carreira

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?

Missing the point? by Rob High

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT