David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

Opinari

Get the Feed! Subscribe

Supporting SCA’s Java Component Model: Which Vendors Will Do It?  
# Friday, May 11, 2007
 
This year's JavaOne conference included a panel on Service Component Architecture (SCA), for which I was the moderator. Representatives from BEA, IBM, Oracle, SAP, Sun, and Tibco spent an hour answering questions posed by the audience and me. It quickly became apparent that even though all of these vendors supported SCA, they had quite different ideas about what this meant.

To understand the main division, recall that SCA 1.0 defines two main things: a new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites. Composites can contain components built using SCA’s new programming models, but they can also contain components built using other technologies, such as Spring and BPEL. SCA doesn’t define a new programming model for these other technologies, however; it just describes how components built using them can be made part of a composite.

I’ve argued before that the new programming model for creating Java components is a fundamentally important part of SCA. Because it provides a simpler and more service-oriented approach to building business logic, developers can use it instead of EJB, JAX-WS, and perhaps other parts of Java EE 5. As the JavaOne panel discussion made clear, not everyone agrees.

While IBM and BEA strongly support the new SCA Java component model, Oracle, Sun, and SAP appear to have a different perspective. All were big fans of SCA’s assembly aspects, but none of these vendors seemed happy about the prospect of another component model competing for the hearts and minds of Java developers. SAP's panelist asked the audience for a show of hands: Who wants to see a new programming model for Java components? In a crowd of several hundred people, not one hand went up.

Yet asking this question of a .NET developer audience before the announcement of Windows Communication Foundation (WCF) , the .NET analog to the SCA Java component model, would have elicited the same response. Most developers want to get their jobs done, not devote scarce working hours to learning yet another way to do them. Nevertheless, it’s incumbent upon platform vendors to improve the technologies those developers use. Moving from COBOL and CICS to the Java platform annoyed a lot of people, as did Microsoft’s move to the .NET Framework. But in both cases, the resulting boost in productivity and functionality made the pain worth the effort.

Although it’s nowhere near as big a change as these earlier shifts, SCA’s Java component model has the potential to offer another boost. Yet judging from the vendor responses on this JavaOne panel, there’s no guarantee that this will happen. Strong support by BEA and IBM improves the odds of success, since these two vendors dominate the market for commercial Java platforms. Still, if their competitors fail to support this new approach, SCA could miss a chance to modernize and simplify the Java environment.

One more point to take away from this is that when a vendor says they support SCA, you can’t know what they mean until you ask them. When Oracle says it, they seem to mean the technology’s assembly aspects. When BEA says it, they seem to mean the assembly aspects and the Java component model, but not necessarily the C++ component model. When IBM says it, they seem to mean pretty much everything in the current 1.0 specs. When Sun says it--well, I’m afraid I can’t tell what they really mean.

The unity that let J2EE compete so successfully against Microsoft is breaking down, and the result isn’t pretty. If the vendors in this camp can’t agree that supporting SCA’s Java component model is worth doing, I can’t help worrying about the future of the Java platform


8 comments :: Post a Comment

 


Comments:

Hi David

Interesting to hear your views.

At Blue Prism we have bet our shirt on the .NET horse and expect it to romp home....one day.
 

First of all, I think David did a great job in moderating the SCA panel at JavaOne. Introducing SCA in 5 minutes, bringing forth most of the key questions in such a short time and keeping the audience engaged through out the session is not a simple challenge, I think.

Now, there are a few things in David’s blog that I think deserve further discussion, in particular - whether SCA defines a new Java programming model and how critical it is for the success of SCA.

In SCA, component implementations are highly configurable and rarely should you need changes to the actual code. SCA defines a lot of metadata for implementations to declare such as -- compositional aspects (provided services, dependent services, and configurable business properties), policies affecting execution and interactions, bindings to communication infrastructure, etc. Besides such metadata, SCA also defines a set of commonly useful features such as - asynchronous, bidirectional, conversational interactions!

For the above (declarative metadata and the small set of features), mappings to various programming languages are defined (not just for Java, but also for BPEL, C++, etc). So I guess, SCA does introduce some new programming model for the various languages. Now when I say "new", I am not implying that it is replacing anything existing or old, but simply that - SCA defines some new concepts and thereby introduces the corresponding new programming model. That's all. Your blog, however, seems to imply that SCA defines a new programming model in Java that competes and should win over Java EE (and EJB in particular). I don’t think this comparison is quite right. EJB is primarily an implementation technology which addresses a different set of problems. Java EE includes support for many aspects such as security, transactions and combines many critical Java technologies and frameworks together that are commonly used by application developers. So although there is possibly a thin overlap, I don't think of Java EE and SCA as competing technologies. OTOH, I think that they are highly complimentary technologies.

Also note that, for Java, it is envisioned that different vendors may want to support SCA on top of different Java component technologies such as Java EE or Spring. SCA makes this easier by defining - a> Java Common Annotations and API specification and b> bindings to individual technologies such as Java EE and Spring. So the idea is to allow enhancing different existing Java component technologies and not to re-invent a new one.

I have blogged on this topic a little more on SAP's SDN at - https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6567

-- Sanjay
 

I've blogged my take on this issue. Short version is that I think that the term "programming model" seems to be in dispute. However, rather than dealing with terminology, I just give a brief summary of what SCA is and note that some (but not all) JavaEE technologies aren't really needed when SCA is available. I'll let others decide if that qualifies it as a programming model.
 

Both Sanjay from SAP and Michael Rowley from BEA were on this panel, and it seems to me that their comments underscore my point: Different vendors see this differently. Sanjay's referenced blog entry says "Java EE 5 provides a great foundation" for SCA, while Mike's entry says "EJB session beans, MDBs, JAX-WS and even JMS aren't usually necessary in an SCA universe". It's worth noting that both of them are listed as authors on some of the main SCA specs. (Those must have been interesting meetings!)

And I'd argue strongly that SCA does define a new programming model for Java components. If it can be used in place of EJB, etc., surely this is enough to qualify as a new model.

It's hard to overstate the importance of this new approach. If the Java world doesn't adopt it, enterprise Java developers will be stuck in a world that's significantly more complicated and less modern than that provided by its biggest competitor, the .NET Framework.
 

I really think that this is missing the forest for the trees. What is happening in the Java world is simple: programmers are becoming more and more able to work with plain old Java objects for modeling their business logic and layering on "container" management as (mostly) orthogonal concern. The "model" for Java in SCA is almost identical to the "model" for Java in Spring. As I've pointed out elsewhere, it's possible to run "SCA Java code" in the Spring framework. EJB is moving in this direction as well, albeit somewhat more slowly. To be honest, it looks like the trend is convergence toward a single approach in the long run.
 

From a purely technical point of view, Greg, I agree with you: The various competing platform technologies are moving toward a similar approach. If your only concern is what the technology will look like in a few years, then your perspective is wholly valid.

But what about a vendor trying to choose which horse to back today? What about an end user trying to determine which platform will be safe to bet on? What about a developer trying to decide which skill set to invest time in acquiring? All of these are much more immediate concerns, and all of them require dealing with the various competing choices that exist in the aftermath of J2EE 1.4.

Long-run views are useful, but making decisions in the here and now can't be avoided. Unless the Java world wants to see .NET's market share continue to grow, it needs to choose what its primary business logic platform will be.
 

David,
I realize that this is a somewhat old topic and your views have probably been updated thanks to new information by thought I would post my two cents anyway ...

in my opinion, the whole purpose of a IOC/injection programming model such as the one provided by SCA is that it frees our client from having to bet the farm when backing any "particular horse". Service logic code is completely decoupled from the underlying infrastructure of any particular SCA or non-SCA runtime. This should sufficiently isolate any early adopters of SCA in case they wish to switch to an alternate approach. As long as that alternate approach also supports simple declarative/annotated interactions then the migration will be quite painless. I don't think there's any confusion within the Java vendor community around the vision that injection is the ideal way to define the interaction between container and business logic code. The major conflict comes from what the nature of the annotation and declarations should be. The beautiful thing is that as a systems integrator I no longer care, as long as my POJO's are supported then I can drop them into whatever container I like.
Jeff
 

Actually, Jeff, my view hasn't changed. The SCA Java component model is about a lot more than IOC. (In fact, in the big picture of SCA, IOC is almost a detail.) Developers will surely care whether they build business logic on the latest version of EJB, on Spring, on the SCA Java component model, or on something else. It's always possible to port code, of course, but it's also something you want to avoid whenever possible.

The conflict among the various potential successors to J2EE 1.4 is very real, and it's a significant threat to the enterprise Java community.
 

Post a Comment


<< Home