Burton cautiously optimistic about SCA for SOA |
 |
By Rich Seeley, News Writer
17 Oct 2007 | SearchWebServices.com |
|
|
The analysts who cover service-oriented architecture (SOA) for Burton Group Inc. have some reservations about the Service Component Architecture (SCA) specification, but have concluded the vendor backing is so strong "adoption may be inevitable."
|
|
|
|
|
It does sound like it's CORBA all over again, but for the most part we're optimistic.
Anne Thomas Manes
Vice President and Research Director, Burton Group Inc.
|
|
|
|
|
|
|
|
|
|
Touted as "a new programming model for SOA" by its vendor sponsors led by IBM and now making its way through the OASIS standards process, SCA is not yet baked into many products beyond IBM's WebSphere, but Burton analysts expect adoption to pick up in 2008. Given its apparent inevitability as a vendor supported standard, Anne Thomas Manes, vice president and research director at Burton, spent more than an hour Tuesday in a Web seminar explaining SCA's potential promise and problems to clients.
She said the concerns about SCA at Burton Group include the fact that SCA is made up of more than 14 specifications. Analysts are skeptical that the various technical committees working on those specifications can reach the goal of creating an overall standard to "simplify" service creation and composition. This leads to concern that SCA could suffer the same fate as Common Object Request Broker Architecture (CORBA), which failed to achieve its promise in the 1990s because, as one analyst put it, "too many cooks spoiled the broth."
"There is some concern that SCA can hide all the complexities," she said.
The good news is that SCA has potential, yet unproven, to be a language-and protocol-independent programming model for SOA. Languages that will be supported in SCA cover most of those a non-Microsoft coder would be working on today, ranging from COBOL to Ruby. Support is planned for Java, including Plan Old Java Objects (POJO), Spring, Enterprise Java Beans, C, C++, BPEL and PHP.
Programmers familiar with the Spring framework will find that SCA looks and feels a lot like Spring, Manes said.
"So we have this 'new programming model for SOA,'" she said. "It's an interesting model. It defines a mechanism to create service components, to wire them together to create composites. It defines an abstract policy framework to specify quality of service requirements on components and interactions. It is completely language and technology neutral."
Another potential plus for SCA is that it has "strong vendor endorsement," Manes said, including IBM and BEA Systems Inc., the two companies that worked up the initial spec, as well as Oracle Corp., SAP AG, Software AG and Sun Microsystems Inc. The only major vendor not on the SCA bandwagon is Microsoft.
Asked during the question and answer period why Microsoft is not involved, Manes answered: "Because they don't think they need to be. From their perspective they don't necessarily think it's valuable to have a single standard when it comes to the actual development model. I don't think they necessarily oppose it, they just don't have a strong impetus to join in." She said Microsoft is sticking with Windows Communications Foundation (WCF) for its vision of service-oriented development.
Of the vendors supporting it, there are implementations by IBM in its WebSphere ESB, and Rogue Wave Software, a division of Quovadx Inc., in its Rogue Wave HydraSCA, Manes said. BEA, Oracle, Progress Software Inc., SAP and Software AG are among vendors with plans to implement SCA, she said, but the levels of compliance with the standard are not clear yet.
Another Burton concern with SCA is the extent to which the vendors will customize their implementations of it. The specification allows proprietary vendor extensions and proprietary annotations, which raises interoperability concerns, Manes said.
In terms of Burton recommendations, she said: "I think you need to keep an eye on SCA. The technology is very new, but it has a lot of potential to make life much easier for developers who are trying to build services. But there are some significant issues still to be worked out."
Manes noted that most ESB vendors plan support for SCA and that may be one of the first product categories where there is significant adoption of the specification.
She ended her presentation with a cautiously optimistic assessment wrapped in a caveat: "Keep in mind this is a vendor-driven effort and you have to sit back and ask if we really need another component model. Do we really need 14 specifications to simplify SOA development? It does sound scary. It does sound like it's CORBA all over again, but for the most part we're optimistic. And we're also looking at it and saying even if it isn't ideal, we probably don't have a whole lot of choice because adoption is probably going to be inevitable given the level of vendor support."
|
|
|
|
