Skip to Content

Does SCA need a new Java programming model?

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!). 
You must be Logged on to comment or reply to a post.
  • Hi Sanjay,

    This is good work being done by SAP in promoting the SCA component model and associated specs. I would be interested to know how it might interplay with “objects / components” resident with the ABAP virtual machine. It would be a good idea to be able to expose current investments in ABAP based business logic as SCA-wrapped components through exposing SCA-compliant meta-data. Does this sound practical ?

    – Manish

  • Sanjay,
    I agree with your assessment that SCA does not require a new programming model for Java.  I believe that David’s comments concerning the issue of  “the unity… break down” among Java vendors concerning a Java programming model somewhat misses the point of SCA.  Of course, this only highlights the confusion around the purpose behind the SCA specification.

    In my opinion, stated simply, I believe SCA has two fundamental objectives:

    1) to provide a component meta-model that is geared towards a platform diverse and federated enterprise landscape.
    2) to provide developers with the capability to create services without requiring a new programming paradigm

    Both of the capabilities require that the current Java containers (as well as PHP, C++, COBOL, or any other asset that wishes to partake in a SCA composite) be extended to support the description of platform interoperable components.  It is important to note that current assets (such as EJBs) may still be developed using current approaches and tools, and then “wired” in as necessary.  This does not imply a “new” Java programming model, rather it implies that the creation of enterprise-level platform/language neutral constructs would boost developer productivity in today’s technologically diverse enterprise landscape.

    My thoughts around the “new SCA Java programming model” that is the cause of so much confusion are as follows:
    The new programming model offered by SCA for Java is really the “no programming model” model.  What I mean by this is that SCA allows developers to employ a inversion of control/injection-based approach (just like spring) to develop new services using plain Java object that only contain business logic code.  At most, Java methods and classes will require some annotation to declare how a particular piece of Java code should interact with other service components.  It should be noted that Java-EE is also going in the same direction.  This new paradigm basically frees developers from having to conform to any particular specification , whether it be SCA or Jax WS or no service container/approach all.  Developers simply create simple Java object, and annotate the code as appropriate in order to follow the appropriate specification.

    At Deloitte, we are currently developing our first SCA-based project using Tuscany, and one of the the biggest benefits that we are seeing is that our service developers are completely ignorant of all things SCA.  Likewise, the service code has no references to the SCA runtime.  Of course, what this means to us is that we can very easily migrate our service code in case the SCA specification is a complete failure, which we highly doubt.