Service-Oriented Architectures have been in the software limelight for several years now. But even as groups attempt to define best practices and governance strategies, the details of developing a SOA for a particular organization remain somewhat elusive. In this article, I examine Service-Component Architectures (SCA) as a means to implement Service-Oriented Architectures (SOA).
SOA is conceptually about loosely coupled behavior. Business and system functionality is exposed as largely independent services, thus letting them be used in different ways in the composition of business flows. This is a simple description, but implementations can be considerably more complex. Anyone who has worked with EAI and distributed technologies recalls the difficulties of vending business functionality across an enterprise.
SOA principles are abstract and independent of implementation technologies. From a development perspective, it would be helpful to define SOA constructs that let engineers discuss implementations in concrete terms without necessarily resorting to technology specifics. Towards this end, the Open Service-Oriented Architecture (OSOA) has published the Service Component Architecture (SCA) Specification 1.1 (www.osoa.org).
SCA has been under development for several years by IBM, BEA, Sun, Software AG, IONA, SAP, and Oracle, among others. Implementations are currently available from IBM, Rogue Wave, Oracle, Tibco, the Apache Software Foundation (Tuscany), and the Eclipse Foundation (SOA Tools Platform).
The SCA Programming Model
The SCA Programming Model addresses the engineering details of SOA by providing an approach to the development, assembly, and deployment of services. In keeping with SOA principles, SCA supports heterogeneous implementations by being metadata driven, language independent, and container independent. So long as a mapping from the SCA specification to a technology can be defined, SCA can be implemented. Consequently, SCA has been bound to multiple languages and containers; most recently a C-language specification has been drafted. Figure 1 is a high-level conceptual view of SCA as it relates to technologies and Quality-of-Service requirements.
To date, SCA mappings exist for Java, C++, Ruby, Spring, and BPEL, among others. Additionally, SCA bindings exist for web services, JMS, JCA, and other communication mechanisms. The purpose of SCA is to reduce the conceptual principles of SOA to a concrete set of elements that can be discussed in an implementation context.
Among SCA's intended benefits are:
- Simplified SOA implementation using Components and Compositions.
- Use of loosely coupled Components and References to support agility.
- Handling of event-driven behavior through a comprehensive invocation model.
- Separation of development and assembly to allow technology-agnostic composition.
