I recently participated in a panel discussion on SCA at JavaOne. The panel included Mike Edwards from IBM, Mike Rowley frorm BEA, Sanjay Patel from SAP, Mark Hapner from Sun, and Tibco. It was moderated by my namesake, the mostly-Microsoft-centric consultant David Chappell of Chappell & Associates. David asked questions which we took turns answering during the first half hour, then turned it over to the audience for questions for the 2nd half hour. The panel went pretty smoothly, with 2 of audience members taking time at the "question" mic to tell the rest of the audience that they were already big fans of SCA.
The only somewhat contentious point, which Mr Chappell was trying to tease out of the panelists, was whether SCA represented a new programming model, and if so does that mean we are adding complexity over JEE and JAX-WS, or whether we are simplifying it. My answer to David's question about whether Oracle liked the Java programming model is that we had some folks who had some issues with it, but we may still consider it in the future. I stated that we do allow you to call java classes from within an SCA composite, and package them up in the same jar file, we just haven't yet bought into the whole Java programming model yet (more on this in a bit). I think it was because of this that the other David posted a blog which portrays some misalignment between the vendors.
I went to dinner after the panel with my distinguished namesake and Mike Rowley, joined by Gregor Hohpe of EIP fame, and Jim Marino and Jeremy Boynes from the Apache Tuscany/Fabric 3 projects. We had lots of great discussion around the question of where is the "service" in SCA? David seemed a bit perplexed over whether an SCA composite can be split up and deployed across different platforms. Gregor had missed this point in earlier analysis of SCA, but then joined in the why can't you split it up camp, which prompted him to write this up -
When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor. This does not mean that SCA is useless, but it means that it targets "programming in the middle" (wiring components in a single vendor environment) as opposed to "programming in the large" (wiring services in an enterprise setting). This makes all sense because the "programming in the large" is the realm of the WS-* specs but it was still surprising to me that I missed this critical part.
So here is Oracle's take on the multiplatform issue - - the SCA specs say nothing about single node/multi node, single platform/multi-platform. There is no restriction if the particular implementation chooses to make that work.
That being said, the model as it stands kind of presumes that a composite can be used to model a unit of deployment. The first order priority is to make sure this is portable, however the assembly spec should be sufficiently flexible for folks to use this in different ways. In principal, since composites can recursively nest other composites, you can implement a system that fans out the leaf nodes to different systems but treats them all as a part of the same "administrative" domain. We came to concensus about that over dinner and I thought we all agreed it was a good thing.
On the Java programming model issue, I think the mostly-MS David Chappell is missing the value proposition of SCA. The current Java programming model is not the most central part of SCA. SCA allows one to create composite applications using a variety of different technologies, languages, frameworks, transports, protocols, then wire them together, configure them, deploy, manage them. You can do that for SCA-enabled technologies, for non-SCA-enabled technologies (using existing artifacts), as well as have external (non-SCA) dependencies. In his blog David correctly characterized that Oracle's view on the value prop of SCA is mostly about composition. In the panel discussion I pointed out that SCA is a stated direction for our own internal architecture for Oracle Fusion Apps and Fusion Middleware. That means we'll be using it to let you build apps that combine your business logic with BPEL processes, business rules, BAM components, CEP etc all rolled into discrete SCA composites that can be individually deployed and managed. In keeping with the spirit of our hot-pluggable architecture, you'll be able to deploy that on a variety of appservers and containers, whether EJB3 based or Spring based.
First, lets call out and be clear about what the "Java programming model" is in JCA. Here's some background info on the Java Component Implementation spec (JCI) and Java Common Annotations and API spec (JCAA).
The JCI spec and JCAA spec used to be a single specification called Java Client and Implementation spec. We championed the cause to split it into two specs and make JCAA reusable. The JCAA spec contains common annotations and APIs (as the name implies) that are meant to be used by various Java-related specs in an a la carte fashion. Currently, the JCI uses all of JCAA. It is quite possible that when we are done with SCA/J2EE integration that we'll use the JCAA spec (or a subset) in the integration spec or even in the Spring spec. What we aren't big fans of is the JCI spec, but we do like the JCAA spec.
I spoke with Anish Karmarkar, one of the Oracle engineers who is working on the SCA collaboration, who had this to say - JCI, which is the particular Java language binding is a small spec that talks about how to do implementation.java. The common API/annotations spec is meant to be used by all kinds of Java-related specs including Spring component implementation and JavaEE integration. What we don't want to see is something competing with established/preferred models for web applications. Trying to destroy Spring is a mistake, for example. We want SCA to be the model for building network facing services first and foremost.
In addition, most of what I think the other David means by programming model is about SCA metadata that gets reflected into technology-independent SCA artifacts (composite, componentType, constrainingType). The only specific programming construct that is very likely JCI-specific (although it is defined in the common API/Annotation spec) is the ComponentContext class. This class is useful only in unmanaged environment or when dependency injection is not possible. Even when using JCI, I don't envision that people would use ComponentContext, but instead use the @reference, @property, @service (and related) annotations.
Sanjay Patil, Greg Pavlik, and Mike Rowley have posted detailed responses about one of the other issues of contention, which have to do with the programming model -
Sanjay -
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6567
Mike Rowley -
http://dev2dev.bea.com/blog/mrowley/archive/2007/05/does_sca_define.html
Greg Pavlik - http://gregpavlik.blogspot.com/2007/05/other-dave-on-sca.html
Cheers,
Dave
