Tuesday, May 13, 2008

JavaWorld 2008 part 2: Service Component Architecture

For the second part of my JavaOne 2008 coverage I'd like to talk about Service Component Architecture (SCA). I was very lucky in that I was able to go to three sessions talking about SCA pretty much in a row.

What is exactly SCA?
For those of you who are unaware of what SCA is, I'll give a brief introduction. SCA is a suite of specifications being considered on the the oasis mantle dedicated to defining a protocol and platform neutral service oriented component language. The primary purpose of this language is to allow developers or service assemblers to define a set of services, references, and bindings into a suite of composite structures.

SCA allows a developer to take code assets developed in a number of languages such as Java, Python, BPEL or C++ and wire them together with a minimum of protocol or SOA infrastructure knowledge. This wiring is typically done using the type of dependency injection techniques that many Java developers may have first come across when looking at the Spring framework.
In point of fact, when trying to describe SCA to people who have never heard of it before, I often compare frameworks using SCA to the Spring framework. But where Spring is focused on providing cross cutting concerns and dependency injection within a service platform, SCA focuses on how to use dependency injection to wire various components together regardless of the protocol of the wire, or the target platform/language of the service.

Services built using the SCA specifications have no inheritance or API dependencies like services often built using the set of JAX/Java EE approach. The approach is much more Spring like, with a focus on XML configuration and annotations where appropriate.
SCA is in my opinion, an extremely important specification, the "why" is hopefully self evident.

SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications

The first session I went to was titled SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications. The session was held by Mike Edwards, who's one of the main authors and contributors of the SCA specification, and is a SOA strategist for IBM.
The session was pretty good, basically a general overview of SCA, its value proposition, along with a couple of examples/usage scenarios. I had seen most of the information before, and much of it can be found at the OpenSOA website. The important point to note about this session was that it was full, also thousand people attended, which is a great indicator of the interest in SCA from members of the Java community.

Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany


The following morning I went to the Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany session. The session was presented by Mario Antollini, Jean-Sebastien Delfino and the topic was focusing on an open source implementation of the SCA specification.
I've had the opportunity to work with the Tuscany group developing an SOA solution so I have to admit that I am a little bit biased, but I thought that this session was fantastic. Mario gave an overview of SCA, and its importance as well as a general overview of Tuscany, talking about the number of downloads, and the size of the community. I'll admit to not be nailed to remember the exact numbers, but the growth looked impressive. Mario also mentioned that Tuscany was in production, and that the project had been implemented by Deloitte, which I thought was a great plug.

Jean-Sebastian then gave a great demo of Tuscany, using a fruit and vegetable store as an example. She sure how to do some examples using typical SCA functionality, i.e. how to create a component, expose some of its functionality as services and how to bind the component to other services using references and wires.
From a technical point of view, the demo is interesting because it showed two things. One, the service code was completely uncluttered with any service API or service protocol concerns. The only way one could differentiate the services in the examples from a regular POJO was the import statements necessary to bring in the @remottable and @reference annotations. I've yet to see any examples from the JAX/Java EE world that comes close to creating business services that are this clean.

Secondly, was the fact that the services were using two different protocols (JSON and ATOM believe) for each operation, not necessarily a realistic scenario, but as Jean-Sebastian put it, it was certainly "fun to do" and also more importantly it should have easily it was to switch binding protocols and have no impact on the service code.

Next, Jean-Sebastian showed how Tuscany was being used to prototype various bindings and implementation types that the formal always has SCA specification have not yet considered. One of the mission statement of Tuscany is to act as a live test bed for the specification work, providing very realistic feedback on what works, and what doesn't. Jean-Sebastian extended the demo to include "Web 2.0" style bindings. Showcased the
Jean-Sebastian demoed the use of a "implementation.widget" to create a JavaScript style component that would be hosted by the browser and was able to take advantage of the same annotations they were used in the Java examples. These JavaScript SCA Web 2.0 widgets were able to take advantage of asynchronous communications à la Ajax, while using the same dependency injected, nonintrusive approach showcased in the server-side components. I think the ramifications of this are incredible, a common component model that can describe how to wire components together, regardless of whether they are JavaScript/Ajax widgets, EJBs, REST services or full-blown WSDL/soap web services.

Open Standards for SOA and Java Technology

The final session they went to concerning SCA was titled Open Standards for SOA and Java Technology, and was basically a discussion panel hosted by David Chapelle, and attended by the following SCA experts.

  • Mike Edwards of IBM
  • Steve Jones of Capgemini UK
  • Patrick Leonard of Rogue
  • Mark Little of Red Hat
  • Sanjay Patil of SAP AG
  • Michael Rowley of BEA Systems, Inc.
  • Scott Vorthmann of TIBCO Software Inc.
  • Peter Walker of Sun Microsystems, Inc.

David started out with an extremely fast "SCA in less than five minutes" introduction. I must say that for the most part I found David to be quite entertaining, a great speaker, and he did a great job of introducing SCA.


The format of the question-and-answer portion was as follows. David asked a question to one of the members of the panel, going from left to right (top to bottom on this list) once the panel member had answered, other members of the panel were free to join in with their own opinions. Rather than try to repeat every question-and-answer code like to get to the heart of the controversy of the panel, namely that David seemed intent on representing SCA as a fracturing of the JavaEE community, and that it was mainly a competition to the JavaEE model. Although many different kinds of questions were asked of the panel, David kept circling back to this idea. David also seem to take a lot of pleasure in stating that SCA was an awful lot like the Microsoft method of composing components, known as WCF. I guess I could agree with the statement, if SCA was built by one vendor, had no grassroots community involvement, supported one platform, and one real language, (sorry Visual Basic is not a language)

One of the first questions asked by David was "is SCA reinventing the wheel?" Mike Edwards responded to this one, stating that SCA is being worked on by a diverse group of industry and non-industry members, under the Oasis umbrella. While currently SCA is only a specification, it has been submitted to oasis as an official standard. He then commented on the fact that while SCA does include a Java programming model that defines how to code Java in the SCA world, it does have a much larger scope than many of the JavaEE branded specifications. Mainly, SCA is concerned with how to compose services out of components using a variety of languages and platforms including but not limited to the Java platform. Eventually COBOL components could be wired together with SCA
Mike Edwards also discussed the fact that we are SCA did compete with Java (mainly the programming model) SCA offered a much more declarative, API free, dependency injection -based approach it was not limited to just the Java language, but also to other languages that could support it like Python for example.
Other members of the panel also jumped in to state that a new JavaEE SCA specification was also being built to allow components built in the JavaEE world to also be extended with SCA specific annotations and configurations.

Another contentious question asked by David was whether SCA was causing a serious fracture in the Java community, namely because Sun was not supporting it. David then stated that it looks like the Java community has lost "it's fear of Microsoft" because they are no longer united. It was entrusting that unlike last year, a member of Sun was present. Peter, that there has been a lot of distorted press around a comparison of SCA and the Sun backed JBI specification. Peter stated that the JBI specification is a bottom up infrastructure technology. JBI is meant to address concerns of the much lower-level than SCA.

Throughout the panel David repetitively came back to the issue of a fracture within the Java community because of the alternate programming model offered by SCA. Sanjay Patil of SAP had in my opinion a very eloquent response. According to Sanjay, while it is true that the originals of J2EE may have come out of a vendor unification is Microsoft, it is long since matured past those humble beginnings. Currently Java is now about bringing together a extremely diverse community that plays in a extremely diverse ecosystem. Java now caters to the "tattooed, and orange haired" scripters, as well as the business oriented application developers, as well as mobile software implementers.

This means that there are a large number of programming models out there already everything from the vanilla JavaEE, to the more scripting oriented ones offered by jRuby, Jython, to the spring programming model, to the one offered by SCA . This diversity is good for the platform, as it makes it stronger, and able to cater to different needs. An excellent comment, and one I'm not sure that an advocate of Microsoft would ever understand. That, or I believe David is just being extremely clever, and trying to add a little bit of confusion where possible.

Steve Jones, the only non-vendor at the table, (a member of Gemini) also made an excellent point around the value of SCA. Namely that SCA allowed one to declaratively describe the architecture of the system from the point of view of the various component technologies being used, and how these technologies relate to each other. This would allow very large programs to structure teams according to each component technology, with the programming provided a explicit description around how these terms should interface with each other. This sounds an awful lot like a bounded context map described by Eric Evans' Domain Driven Design book. In my opinion, this point of view alone was worth the price of admission for this panel. After the panel made sure to discuss this with him, and was very pleased to receive his opinions which were insightful.

Once the panel was over speak to Peter, as I want to get his opinion on whether Sun would ever think about formerly incorporating SCA into JavaEE. In my opinion piercing slightly defensive, and quickly tried to switch the discussion around the benefits of glass fish, the benefits of JBI, et cetera. What I certainly had no disagreements in anything that he was saying, 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. So my final comment on this would be that if any of you out there see SCA as being something of value let Peter know, because he is currently unaware.

No comments:

Post a Comment