Service Component Architecture

Service Component Architecture

Level: Advanced Contributors: BEA Systems, IBM, IONA, Oracle, SAP AG, Siebel Systems, Sybase In response to requests from customers and Independent Software Vendor (ISV) partners, BEA, IBM, IONA, Oracle, SAP, Siebel Systems, and Sybase are collaborating on specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA. These specifications are published under royalty-free terms. 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: The implementation of components which provide services and consume other services 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. Figure 1. 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. The current SCA specifications are published at a version 0.9 level, indicating that the specifications are not in their final form. The specifications are published with the intent of getting feedback from the community in order to ensure that the eventual version 1.0 level of the specifications more fully meets the needs of developers and businesses.

Advertisement