CP RSS Channel
About Our Sponsors
Articles & Papers
Technology and Society
|IT Vendors Promote Service Component Architecture (SCA).|
Update 2007-03: On 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 had completed incubation and would be submitted to OASIS and the Java Community Process for advancement through formal standardization processes. 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. See: "Open SOA Collaboration Vendors Advance SCA and SDO Specs for Standardization."
[December 07, 2005] BEA Systems, IBM, IONA, Oracle, SAP AG, Siebel Systems, and Sybase have published a version 0.9 release of royalty-free specifications defining a Service Component Architecture (SCA). Xcalia and Zend Technologies have participated in the joint announcement with reference to their contributions on the companion Service Data Objects (SDO) specification.
The SCA/SDO announcement describes a broad industry effort to "develop specifications and resulting collaborative technologies that simplify how organizations create and implement applications in a Service Oriented Architecture. Service Component Architecture (SCA) aims to simplify the development of creating business services, while the Service Data Objects (SDO) specification provides for accessing data residing in multiple locations and formats."
The Service Component Architecture "provides an open, technology neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Its Assembly Model describes (1) a model for the assembly of tightly coupled services and (2) a model for the assembly of loosely coupled service-oriented systems."
SCA "divides up the steps in the building of a Service Oriented Application into two major parts: first, the implementation of components which provide services and which consume other services; second, the assembly of components to build the business application through the wiring of service references to services."
SCA "provides the capability to build coarse-grained service components as assemblies of fine-grained components. 'Coarse-grained' means the use of interfaces with relatively few methods and where parameters and return values are typically document-oriented. 'Fine grained' means that the interfaces may use a larger number of service methods, involving simpler parameter type.
The SCA approach "aims to reduce or eliminate the incidental complexity to which application developers are exposed when they deal directly with middleware APIs. While it allows developers to focus on writing business logic, SCA also complies with existing standards under the covers to preserve existing investment in standards, middleware and tools.
SCA also supports a variety of component implementation and interface types as first class citizens. For example, the implementation of an SCA component may be a BPEL process, and its interface may be defined in WSDL, or the component may be a Java class with an interface defined as a Java interface. This gives businesses the flexibility to incorporate a wide-range of existing and future assets into an SCA-based system with little or no bridging code required.
According to the announcement, SDO "complements SCA by providing a common way to access many different kinds of data. The specification reduces the skill levels and time required to access and manipulate business data. Today, a multitude of APIs are used to manipulate data. These APIs tend to tightly couple the source and target of the data making their use error-prone and subject to breaking as business requirements evolve. SDO makes it easier to use and realize the value of these APIs without having to code directly to them."
An IBM companion white paper on The Business Value of the Service Component Architecture (SCA) and Service Data Objects describes the role of SCA and SDO as elements in the SOA programming model, which "defines the key elements of the SOA solution, how those elements are created, how those elements are linked together to form a cohesive solution, and how the solution is deployed into an appropriate operating environment. In this model, Service Data Objects (SDO) is the 'Information' element, providing a uniform way of representing data; SCA is a 'Business Components' element, in which "relevant units of business logic built as components with interfaces that are independent of the underlying implementation details." SCA also serves a role in Invocation and Composition.
SCA: Service Component Architecture. Assembly Model Specification. SCA Version 0.9, November 2005. Copyright (c) BEA Systems, Inc., International Business Machines Corp, IONA Technologies, Oracle USA Inc, SAP AG., Siebel Systems, Inc., Sybase, Inc. 99 pages. [source]
Technical Contacts: Michael Beisiegel (IBM Corporation), Henning Blohm (SAP AG), Dave Booz (IBM Corporation), Jean-Jacques Dubray (SAP AG), Mike Edwards (IBM Corporation), Bill Flood (Sybase, Inc.), Bruce Ge (Siebel Systems, Inc.), Oisin Hurley (IONA Technologies plc.), Dan Kearns (Siebel Systems, Inc.), Mike Lehmann (Oracle Corporation), Jim Marino (BEA Systems, Inc.), Martin Nally (IBM Corporation), Greg Pavlik (Oracle Corporation), Michael Rowley (BEA Systems, Inc.), Adi Sakala (IONA Technologies plc.), Chris Sharp (IBM Corporation), and Ken Tam (BEA Systems, Inc).
Service Component Architecture: Building Systems Using a Service Oriented Architecture.
A Joint Whitepaper by BEA, IBM, Interface21, IONA, Oracle, SAP, Siebel, and Sybase. Version 0.9. November 2005. 31 pages.
Authors: Michael Beisiegel (IBM Corporation Henning Blohm (SAP AG), Dave Booz (IBM Corporation), Jean-Jacques (Dubray SAP AG), Adrian Colyer (Interface21), Mike Edwards (IBM Corporation), Don Ferguson (IBM Corporation), Bill Flood (Sybase, Inc.), Mike Greenberg (IONA Technologies plc.), Dan Kearns (Siebel Systems), Jim Marino (BEA Systems, Inc), Jeff Mischkinsky (Oracle Corporation), Martin Nally (IBM Corporation), Greg Pavlik (Oracle Corporation), Mike Rowley (BEA Systems, Inc.), Ken Tam (BEA Systems, Inc.), and Carl Trieloff (IONA Technologies plc).
SCA: Service Component Architecture. Building Your First Application — Simplified BigBankSCA Version 0.9, November 2005. 38 pages.
Technical Contacts: Michael Beisiegel (IBM Corporation), Henning Blohm (SAP AG), Dave Booz (IBM Corporation), Jean-Jacques (Dubray SAP AG), Mike Edwards (IBM Corporation), Anish Karmarkar (Oracle Corporation), Jim Marino (BEA Systems, Inc.), Martin Nally (IBM Corporation), Greg Pavlik (Oracle Corporation), Michael Rowley (BEA Systems, Inc.), Ken Tam (BEA Systems, Inc.), and Lance Waterman (Sybase, Inc.)
Next-Generation Data Programming: Service Data Objects. A Joint Whitepaper with IBM and BEA. November 2003 Authors: John Beatty (BEA Systems), Stephen Brodsky (IBM Corp.), Martin Nally (IBM Corp.), and Rahul Patel (BEA Systems). 15 pages.
From "Service Component Architecture: Build Systems Using SOA":
Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA divides up the steps in building a service-oriented application into two major parts: (1) The implementation of components which provide services and consume other services; (2) The assembly of sets of components to build business applications, through the wiring of service references to services.
SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware APIs.
Service Component Architecture
SCA supports service implementations written using any one of many programming languages, both including conventional object-oriented and procedural languages such as Java, PHP, C++, COBOL, XML-centric languages such as BPEL and XSLT, and also declarative languages such as SQL and XQuery. SCA also supports a range of programming styles, including asynchronous and message-oriented styles, in addition to the synchronous call-and-return style.
SCA supports bindings to a wide range of access mechanisms used to invoke services. These include Web services, Messaging systems and CORBA IIOP. Bindings are handled declaratively and are independent of the implementation code. Infrastructure capabilities, such as Security, Transactions and the use of Reliable Messaging are also handled declaratively and are separated from the implementation code. SCA defines the usage of infrastructure capabilities through the use of Policies, which are designed to simplify the mechanism by which the capabilities are applied to business systems.
SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself.
The SCA specification is divided into a number of documents, each dealing with a different aspect of SCA. The Assembly Model deals with the linking of components through wiring. The Assembly Model is independent of implementation language. The Client and Implementation specification deals with the implementation of services and of service clients -- each implementation language has its own Client and Implementation specification, which describes the SCA model for that language..."
From the SCA: Service Component Architecture. Assembly Model Specification:
The SCA Assembly Model consists of a series of artifacts, which are defined by elements
contained in XML files. An SCA runtime may have other non-standard representations of the
artifacts represented by these XML files, and may allow for the configuration of systems to be
modified dynamically. However, the XML files define the portable representation of the SCA
The basic artifact is the Module, which is the unit of deployment for SCA and which holds
Services which can be accessed remotely. A module contains one or more Components, which
contain the business function provided by the module. Components offer their function as
services, which can either be used by other components within the same module or which can be
made available for use outside the module through Entry Points. Components may also depend
on services provided by other components — these dependencies are called References.
References can either be linked to services provided by other components in the same module,
or references can be linked to services provided outside the module, which can be provided by
other modules. References to services provided outside the module, including services provided
by other modules, are defined by External Services in the module. Also contained in the module
are the linkages between references and services, represented by Wires.
A Component consists of a configured Implementation, where an implementation is the piece of
program code implementing business functions. The component configures the implementation
with specific values for settable Properties declared by the implementation. The component can
also configure the implementation with wiring of references declared by the implementation to
specific target services.
Modules are deployed within an SCA System. An SCA System 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 System might cover all financial related function,
and it might contain a series of modules dealing with specific areas of
accounting, with one for customer accounts, another dealing with accounts payable. To help build
and configure the SCA System, Subsystems are used to group and configure related modules.
Subsystems contain Module Components, which are configured instances of modules.
Subsystems, like modules, also have Entry Points and External Services which declare external
services and references which exist outside the system. Subsystems can also contain Wires
which connect together the module components, entry points and external services..."
BEA Systems, IBM Corporation, IONA Technologies, Oracle, SAP AG, Siebel Systems, Sybase, Xcalia, and Zend Technologies today announced an effort to develop specifications and resulting collaborative technologies that simplify how organizations create and implement applications in a Service Oriented Architecture. Using the SOA Programming Model specifications, organizations can more easily create new and transform existing IT assets into reusable services that may be rapidly adapted to meet changing business requirements. Further, the specifications greatly reduce complexity associated with developing applications by providing a way to unify services regardless of programming language and deployment platform.
The specifications take advantage of an emerging trend called Service Oriented Architecture (SOA), which structures IT assets as a series of reusable services that perform business functions. By structuring applications as a series of services, IT assets become more agile and organizations are better able to align their investments in dynamic business environments. For example, using the specifications a mortgage lender can significantly reduce the complexity of automating the loan approval process by developing a set of interconnected "services" based on existing applications tying data on new home owners including credit reports to processes for ordering home appraisals and rate locking. As a result, the lender services more customers while providing more value. In addition, by adopting these specifications organizations gain a higher degree of investment protection, because they can deploy services with a variety of middleware technologies.
The SOA Programming Model specifications include the Service Component Architecture (SCA) to simplify the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats.
SCA provides an open, technology neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Vendors working to create SCA include BEA Systems, IBM, IONA, Oracle, SAP, Siebel and Sybase.
SDO complements SCA by providing a common way to access many different kinds of data. The specification reduces the skill levels and time required to access and manipulate business data. Today, a multitude of APIs are used to manipulate data. These APIs tend to tightly couple the source and target of the data making their use error-prone and subject to breaking as business requirements evolve. SDO makes it easier to use and realize the value of these APIs without having to code directly to them. Vendors working to create SDO include BEA Systems, IBM, Oracle, SAP, Siebel, Sybase, Xcalia and Zend Technologies.
SCA and SDO will be available royalty free and the authors are soliciting industry feedback. Together they offer:
A Language Neutral Assembly Model specification to simplify the development and usage of Business Services called: "Service Component Architecture"
A Java Language specification for implementing SCA service components
A C++ Language specification for implementing SCA service components
A Java Language Service Data Objects specification describing a common rendering methodology for data exchange between clients and services
A C++ Language Service Data Objects specification describing a common rendering methodology for data exchange between clients and services
"Service Infrastructure is a new category of software required for widespread adoption of SOA, It needs a rich ecosystem of technologies, standards, processes and partnerships to make it a reality. These new specifications — the first of their kind — represent significant progress in helping the industry achieve that goal," said Edward Cobb, vice president, architecture and standards, BEA Systems. " As an SOA leader, BEA will continue to drive standards in this area to ensure that the solid infrastructure we are providing supports composite applications from services developed on multiple platforms, using whatever technologies our customer choose. Specifications such as SCA and SDO help developers spend less time on deployment and maintenance and more on solving business problems.
"Standards have become a critical component of today's technology infrastructure," said Karla Norsworthy, vice president, software standards, IBM Software. "The rapid explosion of data and services has created challenges for developers to use all the new types of information. The collection of companies joining forces to create SCA and SDO will help ease developer pain and increase business results."
"Because the SCA specification addresses significant marketplace and user requirements for SOA development and deployment infrastructure, it has the potential to unify service runtime and tooling initiatives such as ESBs and Eclipse," said Eric Newcomer, CTO, IONA. "Our involvement as a co-author of the SCA specification is as a natural fit with IONA's ongoing participation in standards-based and open source distributed computing initiatives. Organizations adopting SOA need appropriate, efficient and cost-effective solutions. Supporting industry standards such as SCA is one of the ways we are helping our customers accomplish this."
"Open standards and specifications such as Java Enterprise Edition, Web services and WS-BPEL play a crucial role in the development of Service-Oriented Architectures," said Steven G. Harris, vice president, Java Platform Group, Oracle. "Through our work in standards organizations and now in unifying those efforts in the SCA and SDO specifications, Oracle is making it easier for organizations to realize the concrete benefits a standards based Service-Oriented Architecture can deliver today and in the future."
"We are dedicated to working with other leading companies to establish standards that allow customers to compose applications from service and data components," said Michael Bechauf, Vice President of SAP NetWeaver Industry Standards at SAP. "Today's announcement is another step forward in our commitment to help customers harness the power of Web services by leveraging the Enterprise Services Architecture (ESA), to optimize business processes and drive innovation through composite applications."
"Data value increases exponentially when business deployments extend to the true point-of-action. Services based on open standards such as SCA and SDO, accelerate management's ability to accurately reflect information-rich processes throughout their enterprise. Enabling this capability is at the heart of Sybase's Unwired Enterprise vision," said Kathleen Schaub, vice president of product marketing, Sybase, Inc. "Just as Sybase has taken a leadership role in the Eclipse Foundation, we are equally eager to contribute to this important effort."
|Receive daily news updates from Managing Editor, Robin Cover.|