Saturday, December 16, 2006

JAVA EE 5, SOA, the bad, the good... (Part 2)

+
This is the Part 2 This Special Report from WebServices.com about JavaEE 5 and Enterprise SOA.

1. The Bad (by Bruce Snyder, co-founder and developer for the Geronimo project and a senior architect at LogicBlaze Inc., an open source SOA provider)
Snyder said enterprise-grade SOA should have flexibility on the back end as well as on the developer side, and by that he means making it easier to do things. "There's a portion of Java EE trying to standardize on that," he said, such as the move toward annotations with the JAX-WS spec. "It's good in terms of standardization, but in terms of flexibility and simplifying things, I'm not sure Java EE 5 does that. I still see people going outside of Java EE to look for solutions."

2. The Good (by Michael Bechauf, vice president of industry standards at SAP AG)

All this said, organizations have to be asking themselves, just how much work is involved in taking existing enterprise apps and componentizing/service-enabling them? And does Java EE 5 make it easier?

"Java EE 5 as a technology platform has made it dramatically easier to service-enable an existing Java application," said SAP's Bechauf. "For example, Java annotations can easily service-enable a Java method. Tools also may help a great deal with the service-enabling. If you wanted to do this with a bare-bones IDE and had to write all of the code yourself using Web service APIs, it could be a fair amount of work. If you were to use a tool which helped automate this process, it would be much easier.
3. A sensate opinion (from J.Bloomberg, ZapThink.com)
Vendors that are part of the EE 5 ecosystem like SAP and JBoss are offering broader capabilities than just Java EE 5, said Jason Bloomberg, a senior analyst with ZapThink LLC. "You still need scalable, transactional Web sites, and if you want [IBM] WebSphere or [BEA] WebLogic that makes sense, but if you're looking to do SOA you're not going to focus on the same priority. It's what BEA is struggling with as it moved to SOA 360 º, for example. [Vendors] are rethinking what it means to provide a SOA platform."

4. A word from Bill Roth, Vice-President of BEA

While Roth said the company is not looking to distance itself from the Java platform, "are we saying things other than J2EE? Yes, for example an ESB is a useful way to think. There's no J in SOA, it opens up whole new world for us. The SOA world is not necessarily Java. Is Java the most productive platform for creating building blocks in SOA? Of course. Is it the best way to build everything? No.

Roth said he views building composite applications and Java EE 5 as orthogonal. "There are new technologies like Service Component Architecture, which describe how larger services are woven together and BPM [business process management], which talks about how services talk to each other. Java EE 5 [is about] how to build better services, but the process of weaving them together as an SOA is at a much larger level and might not involve Java."

5. And finally, the Importance of Service Component Architecture (SCA), by Richard Monson-Haefel, a senior analyst at Burton Group Inc.

Monson-Haefel said the Service Component Architecture (SCA) initiative "is supported by all the big players in EE space and SCA has little or nothing to do with EE."

SCA supports service implementations written using a variety of programming languages, including object-oriented languages, as well as Java, PHP, C++, and Cobol; XML-centric languages such as BPEL and XSLT; and declarative languages such as SQL and XQuery.

The fact that SCA is implemented on top of Java EE, but "doesn't reference Java EE specifically," is telling, Monson-Haefel said. "I don't have a lot of confidence that SCA will go anywhere, but all the vendors [involved] is indicative they're hedging their bets.

No comments: