During JavaOne this year, there was a panel discussion on the topic of Service Component Architecture. The panelists were from BEA, IBM, Oracle, SAP, Sun and TIBCO, and I represented SAP on that panel. The panel was moderated by David Chappell (a popular figure in the world of Microsoft technologies), who also posted a blog after the panel event, which I believe deserves some follow-up … I think David (the moderator) did a great job in running the panel. The topic of SCA is some what complex, both technically (10 specifications for a starter!), and politically (why are some Java specs done under OASIS, where is Microsoft in all of this, etc.). David started with a brief SCA tutorial (an oxymoron!) to set the context for the audience and very quickly jumped upon some key questions that keep nagging to many, such as – what problem does SCA solve, why does the world need SCA. The panelists explained their individual view points regarding business value of SCA, which more or less centered around – SCA enables a simplified view of components and communication infrastructures of various kinds, so that they can be easily composed and managed together. So far so good … And then – David asks – what about the new SCA programming model? It seems to compete with some of the existing Java technologies like EJB, JAX-WS, etc? What is your take on that? The panelists were seated in alphabetical order of their company names, so BEA goes first, followed by IBM, Oracle, then SAP, Sun and TIBCO. BEA and IBM expressed support for the new programming model and one of them (not sure who) also made a point that SCA defines a valuable feature of asynchronous and conversational interactions. Oracle’s rep (one of my long time acquaintances who have joined Oracle just two weeks ago) said that they haven’t made up their mind yet. Upon my turn, I expressed my disagreement with the characterization that SCA defines and requires a new programming model. SAP has been demonstrating at the booth in the JavaOne pavilion, how Java EE stack can be extended with SCA functionality. Java EE 5 provides a rich and simplified platform for building new business logic. At the same time, we realize the need for enabling integration of components built using other technologies such as BPEL, etc, in the Java EE. For example, in the SAP’s demo scenario, we start with showing a Java EE application comprising of a web module and a few EJBs. The demo then points out a scenario where by it is decided to replace one of the EJB implementations with a BPEL process (because it is easier to represent the process oriented logic in BPEL, etc). Note that, just because BPEL is chosen to capture the business logic, the communication between the BPEL and the other EJBs need not be required to flow over Web services. So this scenario makes a good case for how a simplified and common view of existing different component types (EJB, BPEL) and communication infrastructure (Web services, RMI/IIOP) is useful to make the needed changes quickly – that is, compose the BPEL component with the other Java EE components. The demo shows how SCA technology can be used for providing the extensibility in Java EE environment such that Java EE applications can be composed with components of other types. The demo did not require a brand new programming model or component technology. The main requirement is for each component technology that wants to participate in the SCA framework should be able to support the SCA metadata. Who wants to re-invent the wheel, when in reality, an extension would do the job? In fact, I posed this question to the audience (David Chappell’s blog mentions that Sun’s rep asked the question – but I guess it doesn’t matter — the audience would have answered the same, I suppose). When asked with the question – who wants a new programming model, the audience did not move an inch, and when I flipped the question to – who does not want a new programming model, many hands went up in the air. I do not remember all that the Sun’s rep said, but I think the gist of it was that it takes a lot for creating new component models and any attempt to layer a common metamodel across heterogeneous environments may quickly starts falling apart, so I guess their approach is to wait-and-see how this effort pans out. So David quickly spotted this point of disagreement among the panelists and elaborated further in his blog. The picture he paints in his blog is:– SCA specifies two things – a> a new programming model in Java that aims to be superior (simpler and more service oriented) that EJB, JAX-WS, and b> how to assemble components developed using the new programming model or of other types into composites. David says that – SCA does not specify a new programming model for the other types (BPEL, Spring, etc) but just describes how components built using them can be made part of a composite. He further expresses his experience and view point that – establishing a new programming model typically faces stiff resistance from the developer community but in some cases the pain has been worth the effort. He hints that a new programming model (better than JAX-WS and EJB) and broad support for the same by the different vendors is crucial for the success of SCA. So, I think there is a lot of level setting and clarifications to be made here … First, the main focus of the various language binding specifications in SCA (EJB, Spring, Java, BPEL, etc) is to define mapping of SCA metadata. In order to participate in a SCA composition, an implementation artifact needs to expose metadata declaring the provided services, consumed services (aka references) and configurable business properties that can affect the behavior of that implementation. Exposing such SCA metadata is handled differently by each language. For example, in the case of BPEL, the information about services and references of a BPEL process can be derived from the partnerLinks. In the case of Java, annotations can be used to decorate the Java constructs (interfaces, classes, variables, etc) for declaring the SCA metadata. Of course, there are many more details in the specifications than what I am hinting at here. Never the less, the key focus of SCA language binding specifications remains to be exposure of SCA metadata, primarily related to composition (and also for policies and bindings). So bulk of what we call as SCA programming model is really about binding SCA metadata! SCA does defines a small set of features that are commonly perceived to be valuable for building service oriented environments such as – asynchronous invocations, conversational interfaces, bidirectional communications, etc. In that regard, SCA defines the concepts and some language neutral metadata in the assembly specification and then the related mappings in various languages can be found in the individual language binding specifications. So for example, in the Java binding specification, you can find annotations defined for — @OneWay, @Conversational, etc. Similarly, you can find support for Conversational interfaces addressed in the SCA BPEL binding specification. So the point is – SCA does provide a more or less equal support for the SCA metadata and key features in different languages (and not just Java). In other words, it is not quite right to say that – SCA defines a new programming model for Java and for other languages it only describes compositional aspects. Now it is true that SCA has a lot more content for the Java world compared to the other languages (after all, Java deserves some special treatment, wouldn’t you agree?). For Java, SCA has one shared specification called – Java Common Annotations and API. As the name indicates, this specification is supposed to be common, and is expected to be utilized by various other SCA specifications related to Java such as – binding to Java EE, or Spring. Most of the useful things such as annotations for declaring SCA metadata, API for lifecycle instance management, API for conversational and asynchronous programming, etc, are part of this common specification. So the main idea here is that vendors starting with existing component runtimes such as Java EE or Spring can provide SCA enhancements by supporting the Common Annotations and API. Note that supporting SCA in this manner allows existing component technologies with SCA capabilities, and does not require supporting a fundamentally new programming model. You may think of it as a face-lift rather than a face-off. OK, SCA also defines a short specification called Java Component Implementation (perhaps the root cause of the current discussion), which can be used to create SCA runtime implementations in Java from scratch (bravo!). I would point out that this is a very small specification (14 pages, of which 4 pages contain boiler plate material) and I can not possible imagine how this alone can be the basis for building runtimes that can compete with the mature component technologies such as Java EE and Spring. For creating any non-trivial applications, one needs a lot more than what is specified here – how do I handle transactions, security, data persistence, registries, so and so forth?. I don’t think anybody would like to re-invent solutions for these non-trivial aspects of component technologies. To summarize, what is called as SCA programming model in David’s blog is really nothing but – a> means for exposure of SCA metadata, and b> a small set of features relates to async/conversational/bidirectional communications. Both of these can be supported on top of existing runtimes such as Java EE. One of the main goals of SCA is to enable certain uniformity across different component technologies, and I don’t think SCA should define yet another component technology. Different vendors may choose a different starting point for providing SCA support. SAP has decided to use Java EE 5 as the starting point. We believe that Java EE 5 provides a great foundation as it already embodies the collective wisdom culled over a long and laborious path of simplification (like POJOs) without losing the power (something one would expect for creating enterprise applications!).