The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: March 21, 2007.
News: Cover StoriesPrevious News ItemNext News Item

Open SOA Collaboration Vendors Advance SCA and SDO Specs for Standardization.

Contents

Update 2007-07: OASIS published six (6) Proposed Charter documents for new Technical Committees to be created within the Open Composite Services Architecture (Open CSA) Member Section: SCA-Assembly, SCA-Policy, SCA-Bindings, SCA-J, SCA-BPEL, SCA-C. The TC Charters as proposed identify deliverables that build upon the existing Service Component Architecture Version 1.0 Specifications produced within the Open Service Oriented Architecture Collaboration (OSOA). Service Component Architecture (SCA) models business solutions as compositions of groups of service components, wired together in a configuration that satisfies the business goals. See "Six Technical Committees Proposed for the OASIS Open CSA Member Section."

[March 21, 2007] The OSOA Collaboration represented by "eighteen leading technology vendors" announced that key Service Component Architecture (SCA) and Service Data Objects (SDO) specifications have completed incubation and will be submitted to OASIS and the Java Community Process for advancement through formal standardization processes. The vendors include BEA Systems, Cape Clear, IBM Corporation, Interface21, IONA, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG, Siemens AG, Software AG, Sun Microsystems, Sybase, TIBCO Software, Xcalia, and Zend.

The Service Component Architecture (SCA) specifications have been in development since 2005, and are now considered mature; the industry partners intend to turn over their standardization process to OASIS. Additionally, the partners have completed work on the SDO specifications, designed to enable uniform access to data residing in multiple locations and formats, and will turn over stewardship of SDO/Java work to the Java Community Process, and non-Java (C++) work to OASIS.

The OSOA industry partners will continue to incubate and drive technology initiatives focused on simplifying SOA application development. Additionally, the group's vendor-neutral Web site (www.OSOA.org) will continue to serve as an information resource for access to draft specifications and white papers, and provide a forum for industry input and feedback.

According to OSOA overview documents, "Service Component Architecture (SCA) provides a programming model for building applications and solutions based on a Service Oriented Architecture. It is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA composites.

SCA is a model that aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, Messaging systems, and Remote Procedure Call (RPC).

SDO provides a set of capabilities for handling business data in a form that is independent of the source or the target of the data. Handling data is key to any business application, but in solutions using SOA, data may have a range of underlying formats. There is data held in relational databases (RDB), and there is data in XML format transmitted via Web services, for example.

SDO first aims to relieve the programmer of the need to understand multiple different data formats and the multiple different programming interfaces that are needed to handle them (e.g., JDBC for relational data, JAX-P for XML data). Secondly, SDO supports a disconnected, optimistic-update style of programming, where data is read from some location, is manipulated by a client program and then updated data sent back to the original location, without needing to lock the original data while the client does its work. SDO also aims to support a wide range of different programming languages, so that services may be written in any language and yet still be able to benefit from the capabilities of SDO."

The Open Service Oriented Architecture (OSOA) Collaboration was created to define a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits. This set of vendors seeks to innovate rapidly in the development of this programming model and to deliver Specifications to the community for implementation. These specifications are made available to the community on a Royalty Free basis for the creation of compatible implementations.

Final SCA and SDO Specifications

On March 21, 2007, the Open SOA Collaboration published ten "Final Version 1.0 Specifications" for SCA; Final Version 2.1 Specifications for SDO were published in November/December 2006. The complete title listing is provided below, followed by excerpts from four of the SCA documents (Assembly Model, Policy Framework, BPEL Client and Implementation Model, Web Services Binding). See the References section for canonical Final Version Specification URIs.

Selected Specification Excerpts

  • SCA Service Component Architecture: Assembly Model Specification. SCA Version 1.00. March 15, 2007. 91 pages. Appendix 1 presents eleven (11) XML schemas (sca-binding-ejb.xsd, sca-binding-sca.xsd, sca-binding-webservice.xsd, sca-core.xsd, sca-definitions.xsd, sca-implementation-composite.xsd, sca-implementation-java.xsd, sca-interface-java.xsd, sca-interface-wsdl.xsd, sca-policy.xsd, sca.xsd - here in a ZIP archive); these may be located online by dereferencing the NS URI http://www.osoa.org/xmlns/sca/1.0. Copyright (©) 2005, 2007 BEA Systems, Inc., Cape Clear Software, International Business Machines Corp, Interface21, IONA Technologies, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG., Siemens AG., Software AG., Sun Microsystems, Inc., Sybase Inc., TIBCO Software Inc. [source PDF]

    Technical Contacts: Michael Beisiegel (IBM Corporation), Henning Blohm (SAP AG), Dave Booz (IBM Corporation), Mike Edwards (IBM Corporation), Oisin Hurley (IONA Technologies plc), Sabin Ielceanu (TIBCO Software Inc), Alex Miller (BEA Systems, Inc), Anish Karmarkar (Oracle), Ashok Malhotra (Oracle), Jim Marino (BEA Systems, Inc), Martin Nally (IBM Corporation), Eric Newcomer (IONA Technologies plc), Sanjay Patil (SAP AG), Greg Pavlik (Oracle), Martin Raepple (SAP AG), Michael Rowley (BEA Systems, Inc), Ken Tam (BEA Systems, Inc), Scott Vorthmann (TIBCO Software Inc), Peter Walker (Sun Microsystems Inc), Lance Waterman (Sybase, Inc).

    SCA Assembly Model "covers (1) A model for the assembly of services, both tightly coupled and loosely coupled, and (2) A model for applying infrastructure capabilities to services and to service interactions, including Security and Transactions. The SCA Assembly Model consists of a series of artifacts which define the configuration of an SCA domain in terms of composites which contain assemblies of service components and the connections and related artifacts which describe how they are linked together.

    One basic artifact of SCA is the component, which is the unit of construction for SCA. A component consists of a configured instance of an implementation, where an implementation is the piece of program code providing business functions. The business function is offered for use by other components as services. Implementations may depend on services provided by other components — these dependencies are called references. Implementations can have settable properties, which are data values which influence the operation of the business function. The component configures the implementation by providing values for the properties and by wiring the references to services provided by other components.

    SCA allows for a wide variety of implementation technologies, including "traditional" programming languages such as Java, C++, and BPEL, but also scripting languages such as PHP and JavaScript and declarative languages such as XQuery and SQL.

    SCA describes the content and linkage of an application in assemblies called composites. Composites can contain components, services, references, property declarations, plus the wiring that describes the connections between these elements. Composites can group and link components built from different implementation technologies, allowing appropriate technologies to be used for each business task. In turn, composites can be used as complete component implementations: providing services, depending on references and with settable property values. Such composite implementations can be used in components within other composites, allowing for a hierarchical construction of business solutions, where high-level services are implemented internally by sets of lower-level services. The content of composites can also be used as groupings of elements which are contributed by inclusion into higher-level compositions.

    Composites are deployed within an SCA Domain. An SCA Domain typically represents a set of services providing an area of business functionality that is controlled by a single organization. As an example, for the accounts department in a business, the SCA Domain might cover all financial related function, and it might contain a series of composites dealing with specific areas of accounting, with one for customer accounts, another dealing with accounts payable. To help build and configure the SCA Domain, composites can be used to group and configure related artifacts.

    SCA defines an XML file format for its artifacts. These XML files define the portable representation of the SCA artifacts. An SCA runtime may have other representations of the artifacts represented by these XML files. In particular, component implementations in some programming languages may have attributes or properties or annotations which can specify some of the elements of the SCA Assembly model. The XML files define a static format for the configuration of an SCA Domain. An SCA runtime may also allow for the configuration of the domain to be modified dynamically...

  • SCA Policy Framework. SCA Version 1.00. March 2007. 46 pages. Copyright (©) 2005, 2007 BEA Systems, Inc., Cape Clear Software, International Business Machines Corp, Interface21, IONA Technologies, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG., Siemens AG., Software AG., Sun Microsystems, Inc., Sybase Inc., TIBCO Software Inc. [source PDF]

    Technical Contacts: Michael Beisiegel (IBM), Dave Booz (IBM), Ching-Yun Chao (IBM), Mike Edwards (IBM), Sabin Ielceanu (TIBCO Software Inc), Anish Karmarkar (Oracle), Ashok Malhotra (Oracle), Eric Newcomer (IONA), Sanjay Patil (SAP), Michael Rowley (BEA), Chris Sharp (IBM), Ümit Yalçinalp (SAP).

    "The capture and expression of non-functional requirements is an important aspect of service definition and has an impact on SCA throughout the lifecycle of components and compositions. SCA provides a framework to support specification of constraints, capabilities and QoS expectations from component design through to concrete deployment. This specification describes the framework and its usage. Specifically, this section describes the SCA policy association framework that allows policies and policy subjects specified using WS-Policy and WS-PolicyAttachment, as well as with other policy languages, to be associated with SCA components. This document should be read in conjunction with the SCA Assembly Specification.

    The term Policy is used to describe some capability or constraint that can be applied to service components or to the interactions between service components represented by services and references. An example of a policy is that messages exchanged between a service client and a service provider be encrypted, so that the exchange is confidential and cannot be read by someone who intercepts the conversation.

    In SCA, services and references can have policies applied to them that affect the form of the interaction that takes place at runtime. These are called interaction policies. Service components can also have other policies applied to them which affect how the components themselves behave within their runtime container. These are called implementation policies. How particular policies are provided varies depending on the type of runtime container for implementation policies and on the binding type for interaction policies. Some policies may be provided as an inherent part of the container or of the binding — for example a binding using the https protocol will always provide encryption of the messages flowing between a reference and a service. Other policies may be provided by a container or by a binding. It is also possible that some kinds of container or kinds of binding may be incapable of providing a particular policy at all. In SCA, policies are held in policySets, which may contain one or many policies, expressed in some concrete form, such as WS-Policy assertions. Each policySet targets a specific binding type or a specific implementation type.

    PolicySets are used to apply particular policies to a component or to the binding of a service or reference, through configuration information attached to a component or attached to a composite. For example, a service can have a policy applied that requires all interactions (messages) with the service to be encrypted A reference which is wired to that service must be able to support sending and receiving messages using the specified encryption technology if it is going to use the service successfully.

    In summary, a service presents a set of interaction policies which it requires the references to use. In turn, each reference has a set of policies which define how it is capable of interacting with any service to which it is wired. An implementation or component can describe its requirements through a set of attached implementation policies..."

  • SCA Service Component Architecture: Client and Implementation Model Specification for WS-BPEL. SCA Version 1.00. March 21, 2007. 15 pages. Technical Contacts: Martin Chapman (Oracle), Sabin Ielceanu (TIBCO Software Inc), Dieter Koenig (IBM Corporation), Michael Rowley (BEA Systems, Inc), Ivana Trickovic (SAP AG), Alex Yiu (Oracle). Copyright (©) 2005, 2007 BEA Systems, Inc., Cape Clear Software, International Business Machines Corp, Interface21, IONA Technologies, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG., Siemens AG., Software AG., Sun Microsystems, Inc., Sybase Inc., TIBCO Software Inc. [source PDF]

    1.1. Goals: "The SCA WS-BPEL Client and Implementation model specifies how WS-BPEL 2.0 can be used with SCA. The goal of the specification is to address the following scenarios:

    • Start from WS-BPEL process. It should be possible to use any valid WS-BPEL process definition as the implementation of a component within SCA. In particular, it should be possible to generate an SCA Component Type from any WS-BPEL process definition and use that type within an SCA assembly. Most BPEL4WS 1.1 process definitions may also be used with SCA by using the backward compatibility approach described in section 1.5.
    • Start from SCA Component Type. It should be possible to use WS-BPEL to implement any SCA Component Type that uses only WSDL interfaces to define services and references, possibly with some SCA specific extensions used in process definition.
    • Start from WS-BPEL with SCA extensions. It should be possible to create a WS-BPEL process definition that uses SCA extensions and generate an SCA Component Type and use that type within an SCA assembly. Some SCA capabilities (such as properties and multi-party references) can only be used by WS-BPEL process definitions that use SCA extensions..."

    [According to the SCA BPEL White Paper 'Introduction':

    "Executable WS-BPEL is a first class implementation language in SCA. It allows a component to be written in WS-BPEL and then deployed and assembled with other components written in WS-BPEL or written in other SCA implementation languages. By its very nature, a WS-BPEL implementation interacts with other components via WSDL interfaces. Therefore, WS-BPEL components can be assembled with other components whose services are exposed via WSDL.

    SCA and WS-BPEL are complementary with one another. WS-BPEL is a language for defining a business process, which can be invoked by clients and can itself invoke other services. These external interactions, together with the activities that may occur inside the process, provide a business orchestration view of a component. SCA, on the other hand, provides a compositional view of interconnection among service components. SCA does not in itself allow one to define business or application logic. This is left to the implementation languages. SCA does support the aggregation of business services without relying on application states. It models a birds-eye-view of the system that includes WS-BPEL processes and other components with which they interact. This overall view provides a convenient tool to manage the deployment and configuration of a system.

    The WS-BPEL Client and Implementation (C+I) Model is designed to allow any WS-BPEL 2.0 and 1.1 process to be used without them needing any knowledge of SCA. It allows any executable WS-BPEL process to be deployed into the SCA runtime without change. The SCA runtime provides features not defined by the WS-BPEL specification such as initialization of endpoint references of partnerLinks via wiring in SCA and initialization of WS-BPEL variable via SCA properties. Without SCA, such features are provided by vendor dependent mechanisms..."

  • SCA Service Component Architecture: Web Service Binding Specification. SCA Version 1.00. March 21, 2007. 14 pages. Technical Contacts: Simon Holdsworth (IBM Corporation), Sabin Ielceanu (TIBCO Software Inc), Anish Karmarkar (Oracle), Mark Little (Red Hat), Sanjay Patil (SAP AG), Michael Rowley (BEA). Copyright (©) 2005, 2007 BEA Systems, Inc., Cape Clear Software, International Business Machines Corp, Interface21, IONA Technologies, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG., Siemens AG., Software AG., Sun Microsystems, Inc., Sybase Inc., TIBCO Software Inc. [source PDF]

    1.1 Introduction: "The SCA Web Service binding specified in this document applies to the services and references of composites. It defines the manner in which a service can be made available as a web service, and in which a reference can invoke a web service.

    This binding is a WSDL-based binding; that means it either references an existing WSDL binding or allows one to specify enough information to generate one. When an existing WSDL binding is not referenced, rules defined in this document allow one to generate a WSDL binding.

    The Web Service binding can point to an existing WSDL document, separately authored, that specifies the details of the WSDL binding and portType schema to be used to provide or invoke the web service. In this case the SCA web services binding allows anything that is valid in a WSDL binding, including rpc-encoded style and binding extensions. It is the responsibility of the SCA system provider to ensure support for all options specified in the binding. Interoperation of such services is not guaranteed.

    The SCA Web Service binding also provides attributes that can be used to provide the details of a WSDL SOAP binding. This allows a WSDL document to be synthesized in the case that one does not already exist. In this case only WS-I compliant mapping is supported.

    In most cases it is expected that a binding applied to a composite's reference will point to an existing WSDL document that describes the web service to be invoked. The binding applied to a composite's service may use either approach.

    The SCA Web Service binding can be further customized through the use of SCA Policy Sets. For example, a requirement to conform to a WS-I profile could be represented with a policy set.

From the OSOA Announcement

Excerpts from the announcement of March 21, 2007: "Leading Technology Vendors Announce Completion of Specifications Designed to Simplify SOA Application Development. Open SOA Collaboration Chooses OASIS to Advance SCA and SDO Specifications."

Eighteen leading technology vendors focused on driving technology initiatives supporting the creation of industry standards around service oriented architectures (SOA), today announced that key Service Component Architecture (SCA) and Service Data Objects (SDO) specifications have completed incubation and will be formally submitted to OASIS for advancement through its open standards process. The SCA specifications are designed to help simplify the creation and composition of services, critical to building applications using services based on an SOA approach. With these SCA specifications now mature, the partners intend to turn over their standardization process to OASIS. Additionally, the partners have completed work on the SDO specifications, designed to enable uniform access to data residing in multiple locations and formats, and will turn over stewardship of SDO/Java work to the Java Community Process and non-Java (C++) work to OASIS.

The SCA and SDO specifications can help organizations to more easily create new and transform existing IT assets, enabling reusable services that may be rapidly assembled to meet changing business requirements. These specifications greatly reduce complexity associated with developing applications by providing a way to unify services regardless of programming language and deployment platform. Both are technologies designed to simplify the representation of business logic and business data. Early customers are already implementing and gaining value.

"We applaud the Open SOA Collaboration for reaching this milestone and for choosing to take the next step and advance this important work through an open standards process," said Patrick Gannon, president and CEO of OASIS. "We look forward to furthering the evolution of SCA from specifications to standards and to promoting the broadest possible industry adoption through education and implementation efforts."

Since November 2005, 18 companies have joined the effort to work on new industry specifications aimed at simplifying SOA application development. Partner companies include BEA Systems, Cape Clear, IBM Corporation, Interface21, IONA, Oracle, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG, Siemens AG, Software AG, Sun Microsystems, Sybase, TIBCO Software, and Xcalia. Together, these companies have achieved significant progress around SCA and SDO specifications.

The partners will continue to incubate and drive technology initiatives focused on simplifying SOA application development. Additionally, the group's vendor-neutral Web site (www.OSOA.org) will continue to serve as an information resource for access to draft specifications and white papers, and provide a forum for industry input and feedback.

Vendor Endorsements

BEA Systems

"BEA has been a consistent leader in SOA, and continues to be at the forefront of supporting and driving standards in this emerging and evolving area of infrastructure. We are pleased to announce this major milestone today, and couldn't be happier about the stewardship that OASIS will be providing SOA and SCA specifications moving forward," said Edward Cobb, vice president, architecture and standards, BEA Systems.

Cape Clear

"The submission of SCA to OASIS is a significant milestone for this important technology," said Jim Rivera, vice president of product management, Cape Clear Software Inc. "SCA addresses the need for a comprehensive, cross-platform component model for SOA. We look forward to collaborating with other partners through OASIS to shape the SCA specification and ensure that our customers can realize the full benefits of SOA."

IBM Corporation

"IBM is excited about submission of SCA and SDO to OASIS since it further accelerates SOA's adoption," said Karla Norsworthy, vice president, IBM Software Standards. "Customers are telling us that SCA and SDO enhance the value of SOA, simplifying implementation and encouraging reuse while saving time and money in building and managing composite applications."

Interface21

"Interface21 welcomes the move of the SCA specifications into the stewardship of a mature standards body. We believe that this will help SCA gain wider adoption. We are committed to making Spring applications SOA ready with SCA, to assist our customers in better managing their software assets while retaining their preferred development model," said Rod Johnson, CEO, Interface21.

IONA

"SCA is very important to IONA in our capacity as leaders of the SOA Tools Platform project at Eclipse, especially the assembly and policy specifications. We are also seeing an uptake in the interest around OSGi and view the combination of Eclipse, OSGi, and SCA as very powerful. SCA complements IONA's distributed approach to SOA and its capabilities are important to our current and future plans for Artix and Celtix," said Eric Newcomer, CTO, IONA Technologies.

Oracle

"As a founding partner in the SCA/SDO collaboration, Oracle is pleased at how quickly we have reached our goal of maturing these specifications and that OASIS has agreed to move them forward into industry standards," said Don Deutsch, vice president, Standards Strategy and Architecture, Oracle. "Oracle's commitment to driving industry standards, that are crucial to our customers' SOA environments, and to adopting these standards in Oracle products is demonstrated by our SCA/SDO collaboration and by the support of open standards throughout the Oracle Fusion Middleware product family."

Primeton Technologies

"SOA starts with components. The official release of SCA/SDO standards has paved the way for broad acceptance of component-oriented approach to SOA," said Larry Huang, CTO of Primeton Technologies. "Primeton will fully support SCA/SDO standards in the coming release of our flagship product EOS."

Progress Software

"Progress Software is pleased to be a part of the SCA effort and to have the opportunity to help form what will become a driving force for the next generation of SOA developers," said Gordon Van Huizen, vice president and general manager of the Enterprise Infrastructure Division, Progress Software. "This effort dovetails nicely with our world-class integration, management, and mediation technologies and we look forward to bringing significant advantages to SCA developers in our upcoming product releases. We applaud bringing these important new specifications to an even broader audience via OASIS."

Red Hat

"SCA 1.0 represents a real step toward the standardization of a service-oriented composite application development model. The fact that ubiquitous Java EE skills and components along with technologies like Web Services and Business Process Definition Language (BPEL) are supported in the first version of SCA means an enterprise developer can embrace the otherwise abstract concepts of SOA," said Mark Little, director of standards, JBoss Division, Red Hat. "We believe that this effort will be a valuable addition to Java EE and Java Business Integration (JBI) in the SOA arena and will gain support through an open standards approach."

Rogue Wave Software

"Rogue Wave Software uses SCA to bring concurrent computing to existing applications without requiring expensive upgrades or the removal of existing technologies," said Patrick Leonard, vice president, product development, Rogue Wave Software. "Next month, Rogue Wave Software is slated to launch the first product commercially available for deploying high-performance SOA applications based on SCA - allowing users to increase performance and scalability, take advantage of multicore technologies and maximize IT investments."

SAP AG

"Customers are working closely with SAP and its open ecosystem to gain business agility and IT flexibility leveraging SOA today. Industry standards play a crucial role to further simplify application development in a service-oriented architecture, and the OSOA partners have reached a key milestone in meeting this customer demand with the submission of key SCA and SDO specifications to OASIS," said Michael Bechauf, vice president, industry standards, SAP. "As a founding member of the partnership, it is exciting to see the cross-industry efforts and hard work of the partners come to fruition."

Siemens AG

"A growing number of Siemens products are based on Service Oriented Architecture (SOA) platforms and product lines. Service composition via workflows and service integration into heterogeneous customer environments is extremely important for us," said Dr. Lothar Borrmann, director, Siemens AG. "The technology independent standard SCA provides our developers and our customers with a simple and powerful way to construct SOA applications. Examples for the usage of SCA inside Siemens include the integration of Enterprise Service Buses into service container, the bridging between Java EE and .Net services, and the combination of SCA and OSGi."

Software AG

"We are delighted to support the Open SOA Collaboration in promoting open industry standards and that they have reached this significant milestone," said Dr. Peter Kuerpick, Member of the Board at Software AG. "Standards, openness and collaboration are the principals of both our Crossvision SOA Suite and the CentraSite Community, the standards based SOA forum we launched with Fujitsu. This is an important step for our industry, sends a clear signal to enterprises thinking of adopting SOA and of course makes implementation easier."

Sun Microsystems

"Sun is pleased that the Service Component Architecture (SCA) specifications have been submitted to OASIS for stewardship through the standardization process. As more and more applications are being built on a Service Oriented Architecture (SOA), the challenge of composing services is growing. Richer, standardized metadata supporting such composition will benefit developers building applications on an SOA," said Mark Hapner, Chief Web Services Strategist, and Sun Distinguished Engineer, Sun Microsystems.

Sybase

"OASIS' guidance brings SCA and SDO one major step closer to becoming the industry standard for service-oriented architectures. Sybase is proud to have been a part of achieving this milestone. The advantage customers will gain from SOA affords Sybase the extraordinary opportunity to provide intelligent data and mobility services," said Kathleen Schaub, vice president of product management and marketing, Sybase, Inc. "SCA and SDO help open the door to a rich, more adaptive future for information technology."

TIBCO Software

"The submission of SCA to OASIS brings us one step closer to simplifying SOA development across disparate vendors and technologies such as Java, .NET and BPEL," said Matt Quinn, senior vice president, Product Strategy, TIBCO Software Inc. "Businesses globally are already seeing the value of the group's commitment and collaboration, and we look forward to working on future industry initiatives that help deliver a transformative business impact to customers."

Xcalia

"As an independent software vendor focused on Enterprise Data Access and Services, SDO is a critical standard, which is why we have been involved with developing the standard from the beginning. Having SDO within OASIS will increase its visibility and thus broaden its adoption and improve interoperability with other major standards for SOA such as WS-*, helping make SOA easier and more scalable for our customers," said Eric Samson, CTO, Xcalia, "In addition to working with OASIS on ongoing management of the SDO standards, Xcalia will remain involved with the Open SOA committee to support the development and introduction of new innovative standards for SOA."

SCA/SDO: Technical Papers and Articles

Selected Commentary

  • "SOA Specs SCA and SDO headed for OASIS and the JCP." By Rich Seeley. From SearchWebServices.com (March 21, 2007)."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 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, [Jeff Mischkinsky] 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.

  • "SCA and SDO Become SOA Essentials for Banking System." By Rich Seeley. From SearchWebServices.com (April 03, 2007). "How useful are the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications? Alan Walters, CTO at Cachet Solutions LLC., says his bank processing system couldn't run without them. Vendors in the Open SOA group that developed SCA and SDO, and submitted them to the OASIS and JCP standards bodies late last month, have argued the specs are already mature enough to be implemented in service-oriented architecture (SOA) applications. Walters has done just that. Cachet Solutions is a startup application service provider (ASP) that is betting its future on the implementations of SCA and SDO by Rogue Wave Software, a division of Quovadx, Inc., in its HydraSCA and HydraSDO products. Walters recalled showing his initial design for a bank processing system to Cory Isaacson, president of Rogue Wave, who suggested adding the SCA and SDO technology... The ability of Rogue Wave's SDO-based tool to handle multiple data formats is important because bank and customer data comes in an unpredictable mix of old and new standards, he said. 'There's lots of different formats,' Walters said. 'That's where we talk about SDOs. You've got the old BAI (Banking Administration Institute) format, you've got custom formats that are like BAI but aren't BAI, and then you've got EDI (Electronic Data Interchange). The newer systems use XML as well...'"

  • "SCA/SDO goes to OASIS, could be to SOA what Java EE was to n-tier computing." By Dana Gardner. ZDNet Blog (March 21, 2007). "By seeking to elevate the SCA/SDO duo to industry standard status under OASIS, these architectural approaches could join the accepted Web services standards (UDDI, WSDL, SOAP, WS-*) to form an agree-upon architectural foundation for both vendor products, as well as compliance-enforced reference implementations and use best practices. OASIS is already driving the development, convergence and adoption of e-business and Web service standards.

    The new OASIS-backed approaches could provide a common, accepted, widespread common meta data foundation, and the means to broader use of BPEL to write processes that relate to services from across a broad spectrum of platforms. SCA/SDO are designed to provide a common way to alleviate the complexity of adopting SOA across heterogeneity of services types and origins. Such benefits are expected to hasten the adoption of SOA, from its initial popularity on a projects basis to more general means of advancing IT productivity.

    As the adoption of distributed computing and n-tier architectures emerged in the mid-1990s, the 'Java' set of functions (agreed-upon standards, middleware specifications and implementations) helped consolidate vendors and users alike around ways to best integrate and develop applications that consumed various resources from different computing tiers, or infrastructure components and resources. Many of these applications types became the mainstay of enterprise business applications and the foundation for complex Web-facing commerce applications. What became J2EE also forced Microsoft to advance its COM approaches into what became .NET.

    The backers of SCA/SDO, which do not include Microsoft, did not choose to house these technologies inside the Java process or expand their adoption via the Java licensing models, even though they have been close to the major Java vendor community. The choice of OASIS for SCA/SDO forms another indication of Java's waning role in the advancement of modern tools, architectures and reference implementations. Oracle, for example, recently adopted Eclipse as the governing body for its Java EJB persistence runtime.

    Even while the SCA/SDO backers invited Microsoft to join their efforts, and to adopt a programming-level of SOA standardization, rather than a Web services level of interoperability, the members voiced little hope that Microsoft would have a sufficient motivation to move .NET to a programable open standards level. SCA/SDO is nonetheless expected to make interoperability between .NET- and non-.NET-based services a natural and rudimentary aspect of SOAs..."

  • "IT Vendors Hand Over SOA Specs to OASIS." By China Martens. From InfoWorld (March 21, 2007). "Members of the Open SOA Collaboration announced Wednesday that they will hand over their jointly developed SCA (Service Component Architecture) and non-Java C++ SDO (Service Data Objects) specifications to the Oasis standards body for further development. They will turn over their Java SDO specification work to the JCP (Java Community Process), the group that sets Java standards. The Java SDO work originated in JCP in 2003.

    SCA focuses on defining models to create and assemble service components to build SOAs, while SDO aims to provide a consistent method for data handling within SOA applications.

    The SCA specifications include full support for BPEL (business process execution language), the Spring Java development framework, Java, and C++. The specifications also include an assembly model describing how SOA components interact with each other so that the developers, assemblers, and deployers of individual components can deal with a consistent model, according to Michael Bechauf, vice president of industry standards at SAP AG...

    Further specification work is ongoing within the Open SOA Collaboration, according to Jeff Mischkinsky, director of Oracle Fusion middleware and Web services standards at Oracle. The work due to take place over the coming year includes adding an event module to SCA and support in SDO for the C and Cobol programming languages..."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2007-03-21-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org