Will Sun Add SCA Integration to the Java EE Specification?

Posted by Masoud Kalali on May 21, 2008

Sections

Development,

Enterprise Architecture

Topics

SOA ,

SOA Platforms ,

Java ,

WS Standards ,

SOA Appliance ,

Web Services

Tags

Service Component Architecture ,

Java EE ,

JBI

While the Java community debates over backing SCA or JBI, there are some signs of getting both of them formally incorporated into Java EE 6 (see our earlier coverage of SCA becoming more Java EE-friendly).

There are already some specifications and ongoing efforts for better interoperability of Java EE and SCA artifacts, but to have it officially in the specification is something else.

Recently Jeff Anderson wrote about his chat with Peter Walker, a Senior Staff Engineer at Sun, who is the co-specification lead of JSR 208 - Java Business Integration, concerning formal integration of SCA into Java EE.

The chat between them took place after the discussion panel about SCA at JavaOne 2008, and Peter's answer to Jeff's question about whether Sun will support SCA or not is interesting:

I again tried to press him concerning the rationale of why Sun would not consider SCA, I certainly don't see anything being offered comparably by Sun. His response was that Sun would certainly be open to it, but that their users were simply not asking for it...

Later on Jeff posted The Highlights of SCA at JavaWorld 2008 which includes some interesting points:

IMHO SCA is a better approach than comparable offerings from the JCP world (e.g. Jax-WS, Jax -RS, JBI, etc.). SCA is a true community process backed by both vendors, independence, and professional services organizations. We all heard complaints about Sun's dominance in the Java EE world...

In another part of the blog, Jeff expressed his view about David Chapelle's idea about possible fraction in the Java community because of different programming models:

First of all, Java already has a multitude of programming models; Spring explicitly says that it has its own component model. Not to mention that working with components in a scripting language (like jRuby) is going to use a very different programming model than working with components using the core Java platform language. One of the core strengths of the Java platform is the diversity offers, Microsoft seems to like one approach, one platform, one model, sadly this approach suffers from getting rapidly date, and irrelevant to the people who actually need to use this stuff i.e. the developers.

and

Secondly, the SCA programming model is a POJO programming model, it's based on annotations, XML configurations, and dependency injection. So is uneven adoption somewhat of a concern? Sure because it's a great programming model, but the beauty of DI is that code can be easily plugged into different containers regardless of the model being supported, as long as it's a POJO one, (or POPO) with very little pain, so I think this big concern about disparate programming models is a much ado about nothing.

Appearance of the following comment from Peter prompted Jeff to post a public letter to the Tuscany mailing list asking for any comment or story related to SCA adoption or people's opinion about Sun adoption of SCA:

Peter's comment:

Tell me more about what users want, I'm not hearing it yet. Oh and I'll point out again that JBI and SCA are not in conflict.

What do you think?
Do different programming models really cause fraction in the unified Java community?
Will real world adoption stories and community members comment make Sun add SCA to the Java EE 6 specification?

1. Back to top

   TLA

   by Thomas Mueller

   SCA: Service Component Architecture
   
   JBI: Java Business Integration
   
   TLA: Three Letter Acronym ;-)
   JCP, POJO, POPO, EE, IMHO, Jax-WS, Jax-RS, XML, DI...
   
   BSB anyone?

   Reply

2. Back to top

   True value of SCA? Portability or interoperability?

   by Jeff Anderson

   I also had some additional off-line conversations with David, it seems that the root of our disagreement over SCA is that David feels that the primary value of SCA is being able to create portable services. In my opinion, I like SCA because it allows me to create composite's out of components made of disparate technologies, hence a focus on promoting interoperability.
   
   Something else I would also like to get other people's opinions on? I.e. where do people see the true value in SCA?

   Reply

3. Back to top

   Re: True value of SCA? Portability or interoperability?

   by Boris Lublinsky

   In my mind it is composability. The strength of SCA is its support for explicit dependencies specification without definition of their implementation (dependency injection). This allows to build more loosly coupled components. When components are in place you can combine them into composites, specifying which component implements which dependency and how exactly it can be invoked (bindings + policies). SCA support for components creation using multiple technoloies is an extra bonus.

   Reply

• Older >