Service Component Architecture (SCA) [1] is a specification which describes a model for building applications and systems using a Service Oriented Architecture (SOA). This white paper discusses the motivation behind SCA, describes the major features of the architecture and presents the areas for future development of the specification. The paper also explains how SCA extends and complements prior approaches to implementing services, and how SCA builds on open standards.

SCA aims to simplify the creation and integration of business applications built using a Service Oriented Architecture (SOA). In an SOA, relatively coarse-grained business components are exposed as services, with well-defined interfaces and contracts. Interfaces are expressed using technology agnostic business terms and concepts. “Coarse grained” here means that the service interfaces use relatively few service methods to achieve a particular business goal, with large document-oriented parameters.

While SOA-based systems can have individual services that are built using object-oriented technology (among other approaches), the overall system design is service-oriented. In particular the service interfaces involve the exchange of business data, not the exchange of objects.

SCA also 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.

SCA builds on emerging best practices of removing or abstracting middleware programming model dependencies from business logic. SCA aims to reduce or eliminate the “incidental” complexity to which application developers are exposed when they deal directly with middleware APIs. SCA allows developers to focus on writing business logic. However, SCA complies with existing standards “under the covers” to preserve existing investment in standards, middleware and tools. Thisapproach is exemplified by a number of existing projects, such as the Spring framework [11].

Download