Will Sun Add SCA Integration to the Java EE Specification?
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.
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:
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?
JBI: Java Business Integration
TLA: Three Letter Acronym ;-)
JCP, POJO, POPO, EE, IMHO, Jax-WS, Jax-RS, XML, DI...
True value of SCA? Portability or 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?
Re: True value of SCA? Portability or interoperability?
York Xyander, Bodo Junglas Jul 31, 2015