SOA specs SCA and SDO headed for OASIS and the JCP |
 |
By Rich Seeley, News Writer
21 Mar 2007 | SearchWebServices.com |
|
|
The long-anticipated announcement of standards homes for Service Component Architecture (SCA) and Service Data Objects (SDO) was made today with both specifications headed to OASIS and the Java implementation of SDO headed back into the Java Community Process (JCP), where it languished after its first entry in 2003.
|
|
|
|
|
The broader issue of industry adoption is always a tricky thing to anticipate. Many good specifications have never been implemented.
Eric Newcomer
Chief Technology Officer, Iona Technologies Inc.
|
|
|
|
|
|
|
|
|
|
The long-anticipated announcement was made today in a conference call hosted by the Open SOA (OSOA) vendor group, led by IBM, Oracle Corp., SAP AG and BEA Systems Inc., which has been developing the two standards since 2005. SCA and SDO are designed to provide programming models developers could use in creating Web services. SCA creates neutral interfaces, implementations and references that can be bound to different technology implementations. SDO provides a standard way of accessing data residing in multiple locations and formats.
The specifications are divided into functions within the specifications and OASIS will form technical committees to work on each area, explained Jeff Mischkinsky, director of Oracle Fusion middleware and his company's lead representative at Open SOA. He listed these sub-specifications as including:
- The service assembly specification, which describes the architecture that is "the lynchpin of SCA"
- Service creation for BPEL, Spring, Java and C++
- The general policy framework for security and reliable messaging
- Declarative bindings, which describe how services are actually used, including the Web services binding, which is key for interoperability among heterogeneous systems.
- Service Data Objects specifications for Java and C++
Open SOA will continue work on related specifications including an event model for SCA, more Java EE integration, and C and COBOL language support, he said.
Concurrently, the JCP work will continue on Java SDO. Open SOA has continued to work on SDO for Java and it is now mature enough move ahead in JCP, according to Mischkinsky. "We will be taking that work and putting it back into the JSR that already exists," he said. "The Java work will be completed in the Java Community Process where it started." He said there would not be a conflict between the Java effort in JCP and the rest of the specifications being worked on in OASIS.
Work on SCA will begin in the next month with the formation of technical committees to work on its components, said Patrick Gannon, president and CEO of OASIS. The charters will be written and committees are expected to begin work on preparing the standards for adoption beginning in June, he said.
The news that SCA is moving forward in OASIS is a good start, although vendor adoption remains tricky, said Eric Newcomer, chief technology officer at Iona Technologies Inc., one of the Open SOA members.
"It's always a good sign when specifications originally developed via private consortium end up in an open consortia," he said, "and I think it's great the SCA/SDO specs have finally reached that milestone."
But the road beyond that milestone is still uncertain, he added.
"The broader issue of industry adoption is always a tricky thing to anticipate," Newcomer said. "Many good specifications have never been implemented. Others have not been implemented widely enough. At IONA we are primarily interested in the assembly and policy specifications, because we believe these represent the strongest value in the SCA set. We are also very interested in the role of these specifications in the Eclipse SOA Tools Platform project."
In December while SCA was still waiting to find a standards body home, Ted Farrell, chief architect and vice president of tools and middleware at Oracle, told SearchWebServices that it was already usable. It is included in Oracle WebCenter Suite, designed for developers working on SOA and Web 2.0 projects, he said. While a standards body blessing would be a plus, Farrell said SCA was already a de facto standard.
Farrell said the most important thing is that the standard needs to work in practical applications and have wide-ranging industry support.
Tracing its history, he said, "SCA really came about as more ad hoc. IBM and BEA were frustrated with some of the standards processes, so they started OSOA. Oracle jumped in and other vendors jump in. While it's not in a traditional standards body, it's very much growing and evolving, but, at the end of the day, we as enterprise software vendors really just want to get these specs into the software and do the right thing."
|
|
|
|
