Web services guru and consultant David Chappell, who has been somewhat skeptical about Service Component Architecture (SCA), says the specification is starting to gain traction. However, there are still nagging issues around the ways vendors are supporting component development within the SCA framework.
Over the past year, David had questioned whether SCA may fall into vendors' separate containers and agendas, and thus not truly be platform independent as all SOA components should be. Still, he had become a booster of SCA since it offered an alternative to older approaches such as EJB and JAX-WS.
David, who moderated a panel on SCA at the recent Java One conference, concludes that the SCA specification has made progress over the past year. "SCA is real, or at least part of it is," he wrote. He is especially impressed with the XML-based language called the Service Component Definition Language (SCDL), part of the SCA specs.
SCDL, which is vendor-neutral, describes how components created in various technologies, such as Java, BPEL, and Spring. "Vendors were showing SCDL in real products on the JavaOne floor—Oracle had an especially nice demo—and so it's clear that this part of SCA is seeing some success," David stated.
However, SCA still has issues that need to be worked out, noting that there is still confusion around how to write SCA components:
"Along with SCDL, the SCA specs define how to create components using several different technologies. Yet the various SCA vendors and open source projects can’t agree on which of these to implement. SCA support for Spring components, for example, is hit or miss: some SCA offerings support it, some don’t. BPEL is much the same—Oracle is a big fan, while the open source Fabric3 currently has no BPEL support."
Plus, David adds, "support for SCA’s new programming model for creating Java components is uneven." This is important, he says, since "it unifies the diverse approaches of Java EE." Some vendors, including SAP, are pursuing an approach using Enterprise Java Beans (EJBs), while others, such as Fabric3, are not supporting EJBs. There needs to be a common approach to component development, not a bewildering assortment of approaches from vendors, David says:
"For SCA to really improve portability, the vendors and open source projects that support it need to agree on how their customers should create components. If they don’t, SCA risks becoming yet another standard that doesn’t provide much benefit to the people who use it."
Widespread support for SCDL is a step in the right direction, and shows a lot of promise, David says. However, vendors still need to come to agreement on how to create SCA components.