IBM has long spoken of the values of Service Oriented Architecture (SOA). One of the key principles of a living SOA is that business processes (comprised of business services) are modeled, decomposed into services which are assembled from various existing and new services, deployed into a run time execution environment, and then managed from not only an IT perspective, but also from a business performance perspective.
Figure 1 depicts the SOA lifecycle. The cycle repeats as the processes change due to external business pressures and internal improvements that are made by observing the process in action. The symbiotic nature of business and IT coming together to engineer an enterprise SOA delivers agile, business relevant applications that solve tangible business-relevant problems.
Figure 1. SOA lifecycle
In many enterprises, the catalog of coarse-grained business services that exist in an SOA are actually hosted by a myriad of technologies, from COBOL CICS® applications, WebSphere Application Server J2EE™ applications, SAP, .NET®, and so on. In fact, even in smaller businesses, the "business catalog" includes services that are hosted by third parties and made ubiquitous by the Web. In an agile SOA, the enterprise needs to be able to connect and compose these services together as the business application evolves; however, the number of technologies that a given business programmer can cope with is finite. An enterprise needs a better way to incorporate critical business assets wherever they may be hosted and include them in new business services; it also needs to reduce the number of technologies with which a business programmer must contend.
Enterprises are looking for a way to detangle the knowledge that must be acquired to use a service, and developers are looking for a way to compose coarse-grained services without needing to know the details of the service implementation. Service Component Architecture (SCA) was designed to provide these capabilities. SCA extracts details of service connectivity away from developers, captures the relevant service design (such as interfaces and semantic contracts) in an open and portable metadata form that any number of vendors can understand, and insulates the business logic from the eventual infrastructure changes that happen to all applications.
Several interesting things happen when you can factor out these details from the application in a consumable metadata form:
- The service interfaces and their semantics are brought forefront where they belong in an SOA: an application declares what services it provides, what services it consumes, and the semantics on which it depends in a way that is not entangled with its own implementation technology (and it doesnât get entangled in details of other implementations).
- The business logic is insulated from changes in service composition, and the pathways are isolated between services and their consumers.
- You are able to view the relationships between services using a circuit board paradigm, making a visual representation of the service design extremely intuitive.
A brief history of SCA
You might be surprised to learn that SCA is not new; IBM WebSphere Process Server pioneered SCA, delivering a precursor to the open version in the Version 6.0 release. This pioneering technology, which we'll call "classic SCA," was used by IBM to seed the open SCA specifications endorsed by several vendors at the Open Service Oriented Architecture (OSOA) organization. SCA represents the SOA programming model of the IBM SOA Foundation and is a strategic technology of the IBM application server and business process management software portfolios.
The OSOA organization's charter is to define a core set of specifications that describe a language-neutral model for building applications and systems using a Service Oriented Architecture. OSOA also defined a set of programming language specific specifications that extend and complement other approaches to implementing services, such as Java™, BPEL, C++, and Java EE technologies such as EJB™ components. SCA also builds on other open standards, such as Web services.
SCA is not a competitor to the other fine-grained service implementation languages and frameworks, but rather a complementary and inclusive technology.
In parallel to the specification work, there are several open source communities cropping up that have developed implementations of the specifications. WebSphere Application Sever V7 applies the open source Apache project Tuscany for providing the core of the SCA runtime, and integrates that support with the world-class enterprise application server functions inherent in WebSphere Application Server.
In late 2007, the vendors at OSOA took their specifications, knowledge, and passion to OASIS, where SCA will be enriched through a formal standardization process and the creation of a publicly available compliance test suite. The standardization effort is expected to complete in 2009.
SCA technology overview
The SCA composite
As the name implies, Service Component Architecture is a component model. Service-oriented coarse-grained building blocks are represented as components. Components describe the services they provide and the services they depend on or reference. Components also point at the chunk of code that provides the implementation of the service. Components are connected together through wires. Components can tailor their behavior by exposing configurable properties. Policy and quality of service intents are used to decorate services or references (called interaction intents) and components (called implementation intents) in order to configure additional semantics that are provided by the SCA runtime.
Figure 2. The SCA composite
Assemblies of components are formally composed into composites. A composite is the set of components and wires; the assembly of services. The composite provides a scoping mechanism that defines a local boundary for components, but further can hide services provided in components that are not intended for other SOA applications. Once defined, a composite can be reused to provide the implementation for other components in a nested fashion. The components, assemblies, internal wires, and service and reference definitions are written in an open XML language called Service Component Definition Language (SCDL). Services and references are bound to specific protocols (such as Web services) through the usage of bindings. The bindings are part of the SCDL definition so that the business logic (implementation) does not need to be polluted with this detail.
Be aware that SCA encompasses a set of language-neutral specifications that enable SCA to be realized in a variety of application environments. Each application environment will offer the set of implementation, binding, and policy features that make sense in that environment. For example, the WebSphere Application Server Feature Pack for Service Component Architecture V1.0 offers support for components whose implementations are Java or other SCA composites, and specifically does not support the deployment of C or C++ implementations.
The SCA contribution
Once a composite is defined, it needs to be deployed along with the related component implementation artifacts into a runtime. An SCA contribution is a package that contains all these artifacts. A special XML document called a contribution document (sca-contribution.xml) describes how composites should be deployed, and defines dependencies (that is, other contributions) that contain artifacts which a contribution needs to execute (such as, shared XML schemas or Java utility classes).
Figure 3. The SCA contribution
Contributions are deployed into an SCA domain. The SCA domain is an administration scoping mechanism, but it also provides a service catalog that can used by the SCA runtime to simplify the wiring of SCA components. Services deployed in the SCA domain are available over the SCA default binding, which enables reference targets to be specified by a logical domain scoped name without having to specify the particulars of the endpoint configuration -- as is the case with other bindings -- deferring to the SCA runtime to find the best possible path to the service. For the purposes of the Feature Pack for SCA, the SCA domain and cell have the same scope, and services deployed in the SCA domain are available throughout the WebSphere cell over the default binding.
The SCA Java programming model
SCA adopts the ease of use improvements provided by Java EE 5 annotations and the modern container design supporting inversion of control or dependency injection. SCA Java implementations have the benefit of declaring component definitions using annotations; having SCA service references, policy, and properties injected into their code by the SCA container. Implementations that use this pattern are not only insulated from the specifics of container or framework APIs, but they are also insulated from endpoint configuration. The SCA architecture enables application assemblers to override annotations provided in the code with formal metadata, which lets you keep things simple during development while giving the enterprise deployment the stringent control over service policy and configuration.
The primary use cases for the SCA programming model revolve around the ability to abstract business function into loosely coupled services that are implemented by coarse-grained components, compositions of fine-grained components, and compositions of coarse-grained components. SCA provides composition on two axes: composition by reference and composition by implementation. SCA components can compose services by orchestrating the invocation pattern of those services through a single invocation programming model that's independent of where and how the services are deployed. SCA can also provide composition by implementating the use of an assembly of finer-grained components as the implementation of a coarse-grained component. Fine-grained components are found at the leaves of composition by implementation; coarse-grained components are found at the root.
Table 1 generally categorizes the various component technologies in terms of their usage as fine- or coarse-grained component models. This table concentrates on the aspects that have the largest effect on granularity; namely abstraction, data format, transport independence, interaction pattern, and mediation.
Table 1. Component model comparison
|EJB 2.0 or later stateless session bean|
|Java API for XML Web services (JAX-WS)|
Value to WebSphere Application Server
SCA contribution deployment is integrated with WebSphere Application Server application administration, taking advantage of a new V7 feature called business level application support, which enables SCA contributions to be deployed without the need for Java EE packaging. Services deployed in these contributions can be added to the WebSphere Application Server cell-level SCA domain that enables the SCA default binding to be used by other SCA applications within the cell, simplifying the wiring of SCA components.
Quality of service intents and policy for SCA contributions are integrated with WebSphere Application Server security, transaction, and Web services policy set management, providing SCA applications with enterprise-class qualities of service.
SCA services deployed in WebSphere Application Server are available through Network Deployment high availability configurations, enabling SCA contributions to leverage the clustering technology that youâve come to expect for WebSphere applications.
SCA as a technology is also an enabling technology for middleware products, providing flexible component and assembly support that is directly related to their particular functional missions. For example, WebSphere Application Server will use SCA to focus on providing a robust, enterprise-wide solution for composing services and building business logic for SOA applications, whereas WebSphere Enterprise Service Bus, for example, uses SCA to provide a first-class mediation framework, exposing virtual service endpoints and giving you complete flexibility to connect disparate technology. Even though the products use a common technology, the way the tools are used will help you determine which product is best suited for developing specific SOA solutions.
The Feature Pack for SCA brings a simplified SOA programming experience to WebSphere Application Server V7. This initial delivery of SCA technology provides the framework for composing coarse-grained services via an agile, flexible, open metadata-driven mechanism. This feature pack:
- Provides a service-oriented, circuit-board assembly paradigm for composing SOA applications that focuses on what the services are versus how the services are implemented.
- Provides a proper separation of concerns for SOA business logic developers by insulating them from the specifics about the services that are consumed, or from the pathways for which a service might be made available.
- Lets you embrace your existing services by providing connectivity to your existing assets via Web services and EJB components.
- Provides simple coarse-grained service creation through the use of dependency injection and an easy to use SCA binding that simplifies wiring.
- Reuse coarse-grained services without specific knowledge of their implementation or host environment.
This article is the first in a series that looks into various aspects of this new and exciting technology.
- More in this series
- OSOA: Open Service Oriented Architecture
- OASIS: Open CSA technical committees for SCA
- WebSphere Application Server Information Center
- Apache Tuscany
- IBM developerWorks WebSphere
- Introducing SCA, David Chappell and Associates (PDF)
- Wikipedia" Service component architecture definitioin
- Software components: Coarse-grained versus fine-grained
- IBM SOA Foundation: An architectural introduction and overview
- Software components: Coarse-grained versus fine-grained
- Roadmap for WebSphere Application Server V7.0 Feature Pack for Service Component Architecture V1.0