This article is more than 1 year old

With SCA, reality bites J2EE again

But is that the whole story?

If you want to a winner, you can’t only champion Java

Moreover, IBM and BEA have done little to hide their antipathy regarding the JCP. Both abstained from voting on a recent specification proposal concerning the creation of a standard Java integration framework (JSR 208, for anyone interested ;-). IBM has taken to adding a statement to all its JCP submissions to the effect that it disagrees with the JCP’s licensing model. And IBM and BEA have been collaborating heavily, along with a number of other very significant vendors, on two new programming model specifications: Service Component Architecture (SCA) and related Service Data Objects (SDO).

The technical details of SCA and SDO (such as they are, at this early stage) clearly borrow from the innovations of the open-source Java frameworks – as well as from Microsoft’s own programming model innovations in .NET 2.0, the Windows Communication Framework, ADO.NET and LINQ. Most importantly, however, they are explicitly "multi-language". Support for Java is obviously important, but Java is just one language that the project will target: the other "first class citizens" are C++ and PHP.

For IBM and BEA watchers, this move is very significant. Both companies are betting a lot on SOA being a Big Thing – and the truth is that SOA is about integration first and foremost – irrespective of runtime environment or programming language. A SOA technology proposition based solely on Java is a three-legged dog in what will turn out to be a fiercely-contested race. Both IBM and BEA have some serious technical and marketing work to do in this regard, as they have spent many years and hundreds of millions of dollars convincing the world that they are synonymous with “enterprise Java”. BEA’s acquisition of the language-neutral Plumtree was a good step forward; and IBM is constantly being reminded of the need to something by its Global Services outfit, which makes a lot of money away from the Java world. IBM and BEA’s roles in the development of SCA and SDO are clearly there to support the companies’ moves away from Java-centricity.

For J2EE watchers, the introduction of SCA and SDO is also of paramount importance: it’s yet another sign that J2EE is increasingly seen by many of its big vendor champions as just one possible platform design which will work for customers looking to build and integrate modern business applications. In my opinion, it’s not before time.

SCA: the next J2EE?

The SCA/SDO programming model initiative has a lot of potential to help development shops in the software community, as well as in other industries, get to grips with the challenges that SOA brings. But there are some challenges that the promoting group will have to overcome if it is to really serve the needs of customers – and if it is to avoid the slide into disillusionment that software vendors and enterprises are now experiencing with J2EE.

The group says it’s committed to developing open and royalty-free specifications. But will it also work to keep specifications simple, so as to ensure that a wide range of participants can implement them?

When and how will the group transfer the specifications to an independent standards body? This question is crucial and also tricky. There are many who say that the JCP is too quick to adopt new specifications – leading to endorsements of specifications which aren’t fully road-tested in industry. Standardisation of a technology has to both take input from commercial experience from technology innovators and early adopters; as well as making the technology appealing to the larger population of mainstream adopters.

The philosophy is language-neutral. But will the group make explicit provisions for the addition of new language bindings to SCA and SDO by third parties that may come along later, and how easy will this be?

If SCA and SDO are set up to compete against Microsoft’s programming model initiatives, the sponsoring group needs to ensure that they make solid, compelling development tools available quickly. Unless progress is swift they will leave potential customers with a complex set of specifications which are difficult to implement.

Copyright © 2005 Macehiter Ward-Dutton

About the author

More about

TIP US OFF

Send us news


Other stories you might like