Book Review: Understanding SCA
Four years after the publication of the first SCA specification draft, SCA remains a technology that is not well known or even understood. Yet, two major middleware vendors, IBM and Oracle/BEA have built key product suites on this technology. Pat Shepherd just released a white paper on how Oracle SOA Suite 11g leverages SCA. There are also a couple of open source projects implementing the SCA specifications: Tuscany and Fabric3.
At its core, SCA offers an assembly mechanism, based on the Dependency Injection Pattern, that let you assemble disparate software agents to perform a unit of work. SCA relies on the modern views that distributed component's interfaces are bidirectional, that orchestration languages are a core implementation model of some types of distributed component and that distributed components need to publish and subscribe to message events (an event is the occurrence of a state, which is communicated by a message event). As such, SCA acts as a distributed CLR supporting a variety of languages and runtimes in the same assembly. It also supports assembling orchestrated components with standard Java, Python or C++ components, seamlessly adding orchestration semantics to these languages.
Today, because of its history and leadership, SCA remains fairly Java centric technology bound to specific vendors. An interoperable assembly mechanism would have certainly transformed (and greatly simplified) the way we build distributed systems.
The bottom line is that if you want to understand how to build modern distributed systems, SCA is probably one of the most advanced blueprint you can look at, even if you will never use the technology itself.
Two key authors of the SCA set of specifications, Jim Marino and Michael Rowley, published a book this summer titled "Understanding SCA". Jim Marino is a Principal at Metform Systems Ltd. and has been involved with SCA since its inception and is one of the leads for the open source Fabric3 SCA runtime. Michael Rowley is the Director of Technology and Strategy at Active Endpoints, Inc and has been involved in the development of SCA from very early in its development and has contributed to 12 of the 15 SCA specifications that were published as part of the Open Service Oriented Architecture (OSOA) collaboration.
For Jim and Michael, when building distributed systems:
SCA addresses two key issues with existing approaches: complexity and reuse.
Service Component Architecture, or SCA, is a technology for creating services and assembling them into composite applications. SCA addresses the perennial question of how to build systems from a series of interconnected parts. In SCA, these parts interact by providing services that perform a specific function. Services may be implemented using different technologies and programming languages. For example, a service can be implemented in Java, C++, or in a specialized language such as Business Process Execution Language (BPEL). Services may also be collocated in the same operating system process or distributed across multiple processes running on different machines. SCA provides a framework for building these services, describing how they communicate and tying them together.
The book starts with a general introduction to the SCA programming model from "Assembling and Deploying a Composite", "Service-Based Development Using Java" and "Conversational Interactions Using Java".
Having explored the SCA programming model in depth, the following chapters cover the main SCA concepts: composition, policy, wires, bindings, and the domain. In these chapters, the authors explain how to develop modular applications, use transactions, configure cross-application policies such as security and reliability, integrate with external systems, deploy applications, and structure corporate architectures using SCA.
The final three chapters complete the SCA programming model: "Service-Based Development Using BPEL", "Persistence" and "The Presentation Tier".
SCA is built on four key concepts: services, components, composites, and the domain:
Applications are organized into a set of services that perform particular tasks such as accepting a loan application, performing a credit check, or executing an inventory lookup. The term service has been used in the industry to denote a variety of things. In SCA, a service has two primary attributes: a contract and an address.
A component is configured code that provides one or more services. A client connects to a service via an address and invokes operations on it. Components may be implemented in a variety of languages
The second step in creating a component is to configure it. Components are configured using an XML configuration file called a composite. Composites provide mechanisms for making SCA services available to clients outside of a domain and for accessing services outside the domain.
Composites are deployed into an environment running SCA middleware termed a domain. A domain consists of one or more cooperating SCA servers, or SCA runtimes, that host components in containers.
The chapter on "Service-Based Development Using Java" provides a distinct perspective on how service based implementation differ from prior distributed object technologies. In particular the authors insist on versioning as a fundamental difference:
Remotable service contracts take versioning into account— Remotable service contracts should be evolvable. Rarely do APIs "get it right" in the first iteration. Furthermore, new requirements often arise after an application has gone into production. Barring fundamental changes, it should be possible to version services without breaking compatibility with existing clients.
They also emphasize the mediation capabilities of SCA:
In SCA, the decision to introduce mediation can be deferred until after an application has gone into production
The following chapters provide a detailed view of all aspects of the SCA set of specifications, illustrated with a Loan Application example.
Chapter 10 has been kindly provided by the authors and the publisher. It deals with "Service-Based Development Using BPEL". The authors take a courageous position on explaining where BPEL fit in relation to services:
Ignore, for the time being, the concept of business processes. If you were going to design a language from scratch that was designed for use with asynchronous web services, there is a good chance you would design something very similar to BPEL. The asynchronous qualifier in that statement is critical, but before dealing with that, the features that make it a language for web services include the following:
- Variables and parameters typed by XML Schema
- Operation signatures specified by WSDL
- Expressions and conditionals specified using XPath
- An XML syntax for the language itself
And they continue:
BPEL fits very well into the world of SCA. A BPEL process definition can be used as the implementation of an SCA component. The BPEL partner links become services and references (more on this later), and the interfaces of those services and references are specified using the WSDL port types that make up the BPEL partner link types. SCA's conversational interfaces provide what BPEL refers to as engine-managed correlation, which removes the need for developers to specify correlating information explicitly.
Chapter 11 explains how Java Persistence APIs can be used in an SCA implementation. The last chapter, Chapter 12, introduces an innovative and recent aspect of SCA which completes its programming model: The Presentation Tier.
SCA does not offer an alternative presentation-tier technology. When it comes to user interfaces, SCA's mantra is integration. Service tiers built with SCA can be integrated with a variety of client technologies, including Swing and rich-clients built using Adobe Flex, AJAX, and web frameworks, such as Struts and Java Server Faces (JSFs).
SCA has introduced the notion of a Web Component which enables:
servlets and JSPs [to] be wired to SCA services
Throughout the book, the authors provide their take on a number of important questions such as:
- Is SCA a SOA Technology?
- SCA and Java EE—Embrace and Extend, Replace, or Just Confusion?
- Interoperability and Portability
- Spring and SCA: Wiring in the Small Versus Large
- Services Without WSDL?
- EJB and the Myth of Location Transparency
- How Loosely Coupled Should Services Be?
- Which Data Binding Should You Choose?
- The Performance Implications of Composition
- Declarative Policy Versus API
- Why SCA Did Not Use UML?
- Should WSDL Be Used When Specifying Service Contracts?
- Why Not Use JMS Directly?
- Architecting for Portability
Overall the book provides a complete introduction to SCA. If you are not familiar with the technology and you are building an SOA, it is certainly worth investing some of your time either to adopt the technology or implement some of its patterns.
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014