By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In these embryonic days of service-oriented architecture, the notion of what will ultimately constitute "enterprise-grade" is still in flux, as is the role of the Java platform and, more specifically, Java EE 5.
During this transitional period from what enterprise Java was to what building an enterprise-grade SOA—with or without Java—will be, the Java ecosystem players are exploring the possibilities and many are putting their eggs in more than one basket.
Bruce Snyder, co-founder and developer for the Geronimo project and a senior architect at LogicBlaze Inc., an open source SOA provider, said "enterprise-grade" means different things to different organizations, but that building an SOA should not require a "forklift upgrade."
"Enterprise-grade is something that scales to support your business," Snyder said. "An enterprise-grade grade SOA should be flexible enough to do what you need it to do, but SOA shouldn't be a great big forklift change or an upgrade to another piece of software like EAI [enterprise application integration] was. It's about biting off as much as you can chew and doing as much as you want. There are solutions out there that are forklift upgrades, they require a substantial financial investment in software and require you to change way you develop. That's quite a lot to swallow."
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."
Michael Bechauf, vice president of industry standards at SAP AG, said enterprise-grade SOA "must be secure, reliable and interoperable. However, beyond those technical characteristics, what's key is that a company needs to employ a consistent set of design rules across all its services. The services also need to be designed in a way that they can cover use cases across multiple industries. They need to use a consistent set of data types that interoperate with common industry vocabularies such as RosettaNet."
He continued, "The services need to have the right granularity to allow for both coarse-grained, message type, business-to-business communication, as well as fine-grained access into a business system so that customers can exploit those services for business flexibility and best practices in their lines of business. For fine-grained services, each call needs to transition the business system from one consistent state into another. Sometimes, flexibility needs to be traded-off against system consistency."
Enterprise-grade SOA means addressing all of the "ilities" -- scalability, reliability, manageability, etc. -- said Shaun Connolly, vice president of product management at JBoss Inc., and to address them in a way "that these capabilities are just baked into the platform." This would include the ability to get enterprise-grade features without the need to upgrade licenses or products, for example, and the ability to interoperate with existing infrastructure, he said.
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. For instance, tools such as SAP Composite Application Framework make service-enabling an application much easier." SAP CAF is based on the Eclipse 3.2 tools platform.
JBoss' Connolly said the work involved "depends on how the components being service-enabled were architected. For example, were they designed for distributed multi-threaded access? One of the things we always recommend to our customers is that they put in place an SOA governance structure so they spend the time on service-enabling the components/functionality that will actually drive business value. Just service-enabling everything, without keeping an eye towards the business goals, misses the entire point of why SOA has the ears of the CIOs."
Reaching beyond the platform
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."
BEA's SOA 360º platform spans the three BEA product families – Tuxedo, WebLogic and AquaLogic – and is supported by the BEA WorkSpace 360º collaborative tooling environment. "With SOA 360 º, Java EE 5 is only a small piece," said Bill Roth, vice president of the BEA Workshop Business Unit at BEA Systems Inc.
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."
Richard Monson-Haefel, a senior analyst at Burton Group Inc., points to the slew of technologies from Java vendors "that aren't related to Java EE at all. They have a large investment in those platforms and a large client base, so the majority will want to upgrade [to Java EE 5], but not because it's superior to everything else."
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."
"SAP is heavily engaged with IBM, BEA, Oracle [and others], in building SCA," said SAP's Bechauf. "It's certainly true the larger application server vendors have come together and said, 'let's see if can use Java EE as a stable Java platform, but have more rapid release cycles for particular SOA technologies.' People want a stable Java platform, but they also want rapid innovation when it comes to SOA techniques. The way we're working in SCA is very rapidly; it's technology that uses EE 5 and rapidly develops innovation on top of that."
Bechauf continued, "Java EE 5 takes certain measures to reduce API-centric nature; for example, it adopts the POJO [Plain Old Java Object] model for EJBs. However, further simplification of the JEE model is possible, specifically in regards to creating enterprise-class composite applications involving existing and new assets." He said efforts like SCA and Service Data Objects (SDO) are more metadata driven and less API-centric. "Based on our recent implementation experience of JEE 5, we are currently defining how JEE can evolve to support the SCA and SDO technologies," he said.
Transition or stepping stone?
Monson-Haefel said Java EE is in transition. "Look at the focus of Java EE, it was almost entirely focused on simplifying the platform. That wouldn't be a major objective if they didn't sense that was the direction IT was going. The grassroots development community wants platforms that solve problems easier."
Nick Kassem, technology director for Web services at Sun Microsystems Inc., said rather than a transition, Java EE 5 is a "stepping stone" to SOA. "Java EE 5 offers a rich infrastructure; it's an enabler to SOA as opposed to a transition platform."
In fact, Kassem said, the story is still unfolding for what he calls "transactional Web services" and the intersection of the Enterprise Java Beans environment and the Web services environment. The recent release of NetBeans 5.5 -- an open source IDE that extends existing Java EE features, including Java Persistence support, EJB 3.0 and JAX-WS -- is a step toward bringing those environments together, he said.
"We're getting away from the notion that you have EJB developers and Web services developers. The investment our customers are making in EJB 3.0 will be preserved and brought into the SOA world. EJB developers are developing mission-critical applications. You have to bring that into the SOA-centric world."
Part 3 of this series will look at the role of the Java Community Process in the wake of the Java EE 5 release. What are its current priorities? What has been learned from the initial half-year of Java EE 5? And what may lie ahead?