Tuesday, May 13, 2008

The Highlights of SCA at JavaWorld 2008

Upon rereading my original post on SCA and Java world, I've realized that it's a little bit on the long winded side, so I thought I would summarize the key points in the following paragraphs.

What and why SCA?
· SCA is a set of specifications dedicated to developing a platform neutral service component model.
· SCA extends Web services to include multiple binding technologies (REST, RMI, JMS, and yes WSDL/SOAP) under a consistent model
· SCA makes SOA simple and possible by providing a clean POJO (or POCO, or POPO, etc.) development model, dirty nasty protocol details and service platform API calls are completely removed from service code,
· SCA does for service architecture what Spring did for the Java platform

Why is SCA better than JAX-WS, JAX-RS, etc.?
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 JavaEE world. The specifications have been submitted to Oasis for proper standardization, I have contributed to the process, although less than I like, but it truly is an open approach.
SCA offers a consistent programming model that is simpler, dependency injection-based, and consistent. We all know the realities of JavaEE, I know it's getting better, but in my opinion no comparison.

Tuscany is a great open source implementation of SCA, with real-world production implementations
Jean-Sebastien Delfino and Mario Antollini gave a incredible presentation on Tuscany my favorite open source implementation of SCA. The highlight of the presentation (IMHO) was when Jean-Sebastien showed had easily extend the SCA specification to include mashups/Web 2.0 component creation. My opinion this is one of the highest values of SCA, a truly comprehensive component model that spans technologies, from simple AJAX/ATOM components to more complex WSDL/SOAP style services. Brilliant.
This session really showed how easy it was to make services, or components of any nature using SCA

Sun has no intention of working with SCA, and there are some concerns about a fracture within the Java community
David Chapelle moderated a panel that included all the big SCA vendors. David made a big deal about the fact that SCA is causing a splinter in the Java community by offering another programming model. He also expressed big concerns around the fact that not everybody at the panel agreed on the level of support for the proposed programming model. I think David is being a little ridiculous, possibly intentionally so, he does come off as a really clever guy, and he is a "Microsoft" guy.

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.

I did speak to Peter Walker from Sun after the panel was over, and certainly a good thing that Sun was actually at the panel this year, but according to Peter, Sun still sees no need to adopt SCA. As far as he is concerned, his "users" aren't asking for it. Ridiculous, there was a CapGemini employee as part of the panel, and I also know that Deloitte has huge interest in SCA. (I won't say why hint, hint) so the two major technology consulting firms don't count as users then who do? I think I smell a e-mail letter campaign coming...

12 comments:

  1. 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.

    Peter Walker.

    ReplyDelete
  2. Peter ,
    thanks for commenting on this post.

    What kind of users would you be interested in hearing from?

    I would be happy to forward the opinions of people who be very supportive of the notion Sun being more active player in the SCA specification.

    ReplyDelete
  3. IMHO, people are not emphasizing enough how significant SCA's contribution is to the evolution of the programming model of information systems (while accomplishing it without disrupting existing investments).

    People have been building information systems with a CRUD-Oriented Synchronous Client/Server application model for the past 40 years or so (since the OLTP days). A COSC/S is not well suited to create composite information systems (a.k.a connected systems). SCA augments COSC/S (without disrupting it) with an Asynchronous Inter-Action Oriented Peer-to-Peer programming model. The foundations of this programming model include bidirectional interfaces, orchestrations and assemblies (I would also add resources, but that's another debate). I have written a minibook on "Composite Software Construction" (free to download after registration) (http://www.infoq.com/minibooks/composite-software-construction)

    If you want to see a spectacular application of SCA, think BPM, but think BPM in a totally different way that people have thought about it. Today we are hitting a hard wall in the BPM space. Lots of people have tried it without much success. SCA opens up the way to make Composite Information Systems a reality by offering a "service oriented, process centric, model driven programming model". I explain the relation between BPM and SCA in this article: http://www.infoq.com/articles/seven-fallacies-of-bpm

    I urge you to consider the business case for creating "Composite Information Systems" (http://www.ebpml.org/com/an_introduction_to_SOA.htm) and focus on that. If people see SCA as a replacement for J2EE or Spring the interest will remain marginal.

    ReplyDelete
  4. Jeff,

    I'd like to comment on "real-world" use of SCA and its relation to JBI...

    In my opinion, the slow uptake of SCA relative to past technologies has been a result of the lack of mature runtimes and a poor job by the vendors explaining what SCA is. However, over the past year, there definitely has been a steady increase in people using SCA.

    For example, VocaLink (one of the largest clearing houses in the UK) has several very large SCA-based projects underway. One is a payments processing system designed to handle more than 100 million transactions every three hours. This system is built on the open-source Fabric3 runtime (www.fabric3.org). We presented on this project at ServerSide last March (http://javasymposium.techtarget.com/lasvegas/casestudies.html#JMarinoSCA).

    Some of the key benefits that convinced VocaLink to choose SCA and replace their existing technology stack was the asynchronous programming model, the simplicity of remote interactions that are not tied to transport APIs, and modularity through SCA's notion of composites. Meeraj and I also discussed this in the InfoQ interview posted here: http://www.infoq.com/articles/sca-fabric3.

    As for JBI, I agree SCA overlaps little with it from a functional perspective (JBI is what middleware providers use to extend runtimes; SCA is what developers use to write and compose services). However, it is important to say that JBI and SCA are centered on very different design principles. The last time I looked, JBI was based on the concepts of a normalized message and a message router. SCA, in contrast, is fundamentally about point-to-point wiring (mediation can be done in SCA, but it is generally performed as part of point-to-point wiring or a component implementation type). I imagine an SCA runtime could be built on JBI-based infrastructure, but I don't know of any taking that approach, commercial or open source. We made a conscious decision not to choose a JBI-based architecture in Fabric3, as we were able to obtain numerous performance and optimization benefits from a point-to-point design.

    Jim Marino
    (One of the SCA spec and Fabric3 people)

    ReplyDelete
  5. First, Jeff, let me compliment you on a great writeup of the SCA buzz at JavaOne.

    I think that SCA is a significant advance in application development technologies which is directed to simplifying the building of agile and adaptable business systems.

    Organisations are already reaping benefits from using SCA - IBM customers in particular have been able to exploit an version of SCA in the WebSphere Process Server and in the WebSphere ESB products for a couple of years now. We also have customers who are excited about the latest SCA functionality that is found in the Tuscany project and which IBM has made available as part of the WebSphere 6.1 SOA Feature Pack. I talked about one of these customers (anonymously) at the recent OASIS Symposium in Santa Clara - the talk is now posted on the OSOA site here:

    http://www.osoa.org/download/attachments/250/
    Flexible_Agile_Composition_01.pdf

    I am sure that many more businesses will benefit as SCA implementations become available from a wider range of suppliers - TIBCO, Oracle, BEA and Rogue Wave all have products either available or in late beta stage.

    As far as Sun are concerned, I encourage them to provide support for SCA in their products. If they need to hear more about "what users want" - they could do well to listen to Steve Jones of CapGemini who was on that SCA Panel at JavaOne and who spoke eloquently about SCA as being of great value in unifying activities on the large projects that they undertake.

    It is curious in some ways that Sun saw value in building runtimes for composite applications and have pursued the JBI specification for about the same length of time as the OSOA collaboration of companies developed the SCA specifications. The hole in that approach is that JBI is really a specification for runtime builders (read "vendors"), providing little in the way of a model for building applications, which is what customers really care about. Sun would do well to recognise this and adopt SCA as the application layer which can sit above a JBI runtime.

    Interestingly, a couple of guys from Atos Origin gave a talk at JavaOne about their work on exactly this topic - “The Best Of Both Worlds with Java Business Integration and Service Component Architecture” presented by Jos Dirksen and Tijs Rademakers. To me, this showed the value and power of the combination.

    I think that the evidence is there that customers already see the benefits of SCA - and that interest is continuing to grow and should expand rapidly once there is a good range of runtimes and tools that support the SCA model across the industry.


    Yours, Mike.

    ReplyDelete
  6. FYI a parallel conversation accompanying this post is taking place on the Tuscany-user mailing list.
    Peter has made some comments indicating he could be open to a SCA JBI combined approach.

    Mike Edwards wrote:

    -snip-

    It is curious in some ways that Sun saw value in building runtimes for composite applications and have pursued the JBI specification for about the same length of time as the OSOA collaboration of companies developed the SCA specifications.
    -snip-

    Actually we started before OSOA.

    ..and yes JBI is for middleware builders. I've never said anything to the contrary.

    -snip-
    The hole in that approach is that JBI is really a specification for runtime builders (read "vendors"), providing little in the way of a model for building applications, which is what customers really care about. Sun would do well to recognise this and adopt SCA as the application layer which can sit above a JBI runtime.
    -snip-

    We may ...and will SCA platform vendors employ JBI? That could enable an ecosystem of engine/binding offerings based on an open standard as opposed to the vendor dominated one I heard described at the panel.

    Peter.

    I for one would be very excited about a SCA over JBI reference implementation, how about anybody else?

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. The point of offering a business function as a service accessible via the network is to make it available for use by a diverse community, with the only technical requirement being the ability to produce and consume the service's requests/messages. This is succeeding because it allows consumers and providers great flexibility in selecting their implementation platforms. One may choose to use UML to help design Java code; another may use BPMN to design their BPEL; a third might implement directly in Python. In this context, SCA is yet another technology that can be mixed into an implementation.

    The claim that SCA is 'universal' for services in much the same way that UML is 'universal' for business logic is something that bears closer examination. We are now familiar with the 'universal' elements the web offers - TCP/IP, HTTP, HTML, XML, JavaScript/AJAX, etc. These are all active technologies in the sense that they demonstrate their value when produced by one party and actively consumed by another. When judged by this standard, both UML and SCA appear a bit less 'universal'. They are both attempts to capture certain design concepts, that with the assistance of tooling, helps a developer implement program logic. Their role in relation to web 'universals', programming languages, web/app servers, etc. is much more arms length and far less 'active'.

    By nature, the web supports peer-to-peer interaction. BPEL makes use of this to support asynchronous conversations through messages linked by correlation values (these are usually just business message values that are designated to 'control' conversation flow). BPEL includes support to associate specific correlation values with specific process instances; a Ruby on Rails app with a bit of code can accomplish much the same thing by treating the correlation values as foreign keys. While SCA may attempt to describe some of these peer-to-peer communication patterns, their use exists independent of SCA.

    All of this, as well as later developments such as mashups, rich internet clients, platform as a service offerings, etc. preceded SCA. It's unlikely that a service offering would expose itself in a way that required a consumer to use SCA. It seems likely that this lack of dependence on SCA at the network composition level will continue.

    Whether you see developers 'coding' in SCA or using it as a form of 'services' UML is currently in the eye of the beholder since it's still SCA early days. Developers select between Eclipse and NetBeans based on a wide range of criteria. Both are being effectively used today to implement service providers/consumers. Both provide support for UML that's used by those who find UML useful. If developer demand materializes for SCA as a 'service UML' both will likely support it for those that find it useful. The same is true for SCA metadata 'side files'.

    The degree to which SCA artifacts penetrate into the source code developers produce is a different question. Since most platforms already provide some form of service abstraction, it would be useful to see actual source code examples that demonstrate, side-by-side, SCA artifact's ability to simplify service implementation/use. If this is compelling, perhaps developers will be stumbling over each other in the rush to put them in their code.

    Does industry's ability to get value out of services hinge on the delivery/use of SCA? It hasn't as yet. On the other hand, SCA may add some value. Happily, it will be developers rather than middleware vendors that decide.

    ReplyDelete
  9. Mark,
    uh, okay...

    That was a great overview on, lots of things, but I wasn't exactly sure of the point you're trying to drive to.

    Do you find SCA to be useful? And should Java be considering it? (In 100 words or less) :-)

    ReplyDelete
  10. This comment has been removed by the author.

    ReplyDelete
  11. To answer the 'usefulness of SCA' question requires a technical definition of SCA in '100 words or less'. If you can tell me what it is, then I'll take a stab at describing how useful I think developers on any platform will find it.

    My original comment was my attempt to describe various things SCA might be and, if it were those, how useful they would be to developers.

    When I've spoken to various people about the relevance of SCA I've often found that while each thought they knew what SCA was, their technical understanding of what it was differed considerably from each other. I would say the same for the comments in this blog.

    This makes it very hard to have a rational conversation about SCA. The best you can do is to take a real technology like Tuscany and see what role SCA plays in its application model. In this case, it's my opinion that Tuscany treats SCA as a services UML.

    ReplyDelete
  12. This is great info to know.

    ReplyDelete