Component Contracts in Service-Oriented Architectures Francisco Curbera
IBM T.J. Watson Research Center
For SOAs to reach their full potential, the basic interoperable framework must accommodate meaningful quality-of-service contracts.Work on both industry-specific standards and semantic Web services is still needed to fully meet that goal.
A
t the core of service-oriented architectures (SOAs) are distributed software components provided or accessed by independent third parties. Because access is not limited to a specific organization, explicit component contracts and universally adopted standards must support third-party access. Although such contracts could cover any technical or business aspect of service interaction, the current focus is on quality-of-service (QoS) policies. From an SOA point of view, we must consider two separate aspects of the use of QoS policies: interoperability between components, which is the subject of the Web services specifications stack; and composition, which composition models, such as the service component architecture (SCA), specify (www.osoa.org/display/Main/ Service+Component+Architecture+Specifications). As the “Components, Services, and Contracts” sidebar describes, a service contract covers both functional and nonfunctional aspects of a service component’s visible behavior. Functional aspects are the component operations’ business semantics, including the business interface and protocol the component follows. Nonfunctional aspects include the interaction’s technical features, such as data serialization and QoS protocols (reliable messaging and confidentiality, for example). They can also include higher business-level characteristics that are not intrinsic to the service interaction, such as legal requirements. Standards and infrastructure are widely available to support the most basic form of SOA contracts: Functional interfaces are encoded using descriptions in
74
Computer
the Web Services Description Language, which was also designed to support the inclusion of policies and semantic information. Policies encode QoS properties such as security, reliable delivery, and transactional behavior. SOA contracts based on these Web services standards are already becoming commonplace in enterprise and scientific computing. However, basic support is not enough. If the SOA concept is to achieve its full potential, the SOA framework must evolve toward richer and more meaningful contracts. To meet this objective, work is under way on industry-specific standards to provide shared business semantic definitions across industries, and there is significant growth in semantic Web services research to provide a more flexible support environment for such contracts. These two developments—one to standardize industryspecific semantics and the other to incorporate semantic capabilities into the basic infrastructure—are complementary and could revolutionize the practice of SOA and enterprise computing. Central to these developments is the understanding of how the Web services specification stack supports nonfunctional contracts as policies and how policies in turn affect service composition.
WEB SERVICES STACK
Web services provide an XML-based interoperability stack that supports the SOA paradigm. The core Web services specifications provide basic standards for interoperable protocols and service descriptions. Figure 1 shows a simplified view of the core specification stack.1
Published by the IEEE Computer Society
0018-9162/07/$25.00 © 2007 IEEE
Components, Services, and Contracts An SOA is a system of distributed software components, and SOA policies are declarative statements of a component’s relevant behavioral aspects. A serviceoriented model is founded on the idea that designers can represent an organization’s computing environment as a set of distributed software components. A component is a software building block that exposes one or more services to potential requesters. These definitions are consistent with the service component model underlying the Web Services Business Process Execution Language (WS-BPEL, or BPEL; http://docs. oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html) and the Service Component Architecture (SCA) specifications (www.osoa. org/display/Main/Service+ Component+Architecture+Specifications), the two Web services specifications that define the mechanisms for assembling SOA components into new services. A component’s full specification requires internal and external definitions. The internal specification determines the component’s implementation and execution environment. A component might be a BPEL script executing on a compliant BPEL engine, for example. From an SOA point of view, the external definition is the component’s most critical part because it determines its interaction capabilities with other components and is thus the basis for the component’s composability. This external specification is the component’s contract. In general, SOA policy refers to the component contract’s nonfunctional aspects, but is typically restricted to the technical aspects that guide component interac-
The Web services stack builds on the Simple Object Access Protocol (SOAP; www.w3.org/TR/soap), an extensible message-oriented interaction protocol that can be supported on top of multiple transport protocols such as HTTP, raw TCP/IP, or proprietary messaging. QoS protocols such as message-level security or reliable delivery are extensions of SOAP. The SOAP message can include QoS headers, such as a transaction context header, to support specific QoS properties. SOAP’s extensibility is a central feature of the Web services stack and key to supporting runtime QoS. Services describe their support for or the requirement of QoS protocols by attaching a Web services policy to their WSDL descriptions, thus extending their functional contract with nonfunctional attributes. Service clients that intend to access
tion. Depending on the interaction context, a component’s contract can include different sets of functional or nonfunctional aspects. In some cases, it is possible to infer from the environment required information that might be missing from the contract. Contracts support two major goals of serviceoriented systems. The first is the principle of thirdparty use, which requires that an SOA component be accessible from different management and organizational domains. Explicit contracts enable third-party access because they help component users understand the technical and business requirements of the service they access. The second goal is automatic integration between service components, a goal not yet attained but core to the SOA vision. The challenge of automatic integration motivates the intense focus on service discovery and automatic composition technologies. Because of the focus on automating the integration process, SOA contracts have been defined in machinereadable formats, even at the expense of humanreadable documentation. For this reason, the main specifications defining component contracts are encoded as XML documents, geared toward their use in code-generation tools, repositories that can be queried, and the like. The Web Services Description Language and Web Services 1.5 Policy (www.w3.org/ TR/2007/REC-ws-policy-20070904) are the two main XML formats used today to encode service descriptions for functional and nonfunctional service contracts, respectively.
WS-BPEL
Composition
WSDL, WS-Policy
Description
Security
Reliable messaging
SOAP (Logical messaging) XML encoding
Transactions
Quality of service
Other protocols Other services
Interaction
Figure 1. A simplified view of a Web services stack. Including service composition specifications like the Business Process Execution Language takes the core stack a step beyond strict interoperability and into SOA-centric implementation. November 2007
75
the service include the right QoS headers according to the policies in the service description.
Quality-of-service specifications
(http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-specos.pdf). These protocols relax traditional ACID properties to support long-running transactions in which resources might not be locked as the ACID model requires, making it possible to see intermediate results. Instead of automatic rollback recovery, which ACID transactions use, the business activity assumes that a compensation operation defined at the business level will carry out error recovery.
The number of QoS concerns is large and open by nature, but some QoS properties are absolute requirements for business interactions. Among the most critical are security, reliability, and the ability to recover from errors. A family of Web Services Security specifications deals with providing security to service interactions. Web services security is message-based, which means that it Web services policy can support end-to-end or multihop WSDL provides the basis for Web security beyond the single-hop secuservice descriptions, focusing on a Web Services Policy 1.5 rity that transport protocols like service behavior’s functional aspects, HTTPS provide. The core specificaparticularly the business-level interprovides a flexible tion—SOAP Message Security 1.1 faces. A WSDL description identifies framework for aggregating (www.oasis-open.org/committees/ the messages to be exchanged with and attaching download. php/16790/wss-v1.1-specthe service, the operations that the os-SOAPMessageSecurity.pdf)— service makes available, and the end QoS attributes to defines SOAP headers and processing points for service access. However, a service description. models for providing message inWSDL also includes binding infortegrity (digital signatures) and confimation that conveys the data repredentiality (encryption), as well as a way sentation to be used during the to associate security tokens (carrying proof of identity). interaction (typically XML serializations) as well as Additional specifications define how to establish a shared communication protocol details. Although both are typsecurity context, specify mechanisms for issuing identity ically nonfunctional aspects, they are central to the intertokens, and support the exchange of identity credentials action and thus must be in every complete WSDL across enterprise boundaries. description. In fact, the WSDL design lets service authors The Web Services Reliable Messaging 1.1 specification attach multiple bindings to the same business interface, (http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1. highlighting the information’s nonfunctional nature. 1-spec-os-01.pdf) defines a protocol for reliably exchangExpressing nonfunctional characteristics requires a ing SOAP messages in the presence of software, system, separate specification. The Web Services Policy 1.5 or network failures. Reliable message exchange is a specification (www.w3.org/TR/2007/REC-ws-policywell-known feature of message-oriented middleware. 20070904) provides a flexible framework for aggregatThis specification, combined with systems-level reliabil- ing and attaching QoS attributes to a service description. ity guarantees such as persistent, transactional queues, The policy comprises a series of policy alternatives, each supports reliable execution in loosely coupled, interop- of which represents a set of behaviors that must be folerable environments. lowed during service interaction. A typical “behavior” The Web services stack also supports traditional atomic, is a QoS protocol, which a policy assertion represents consistent, isolated, and durable (ACID) transactions within a policy alternative. The presence of a QoS asserthrough the protocol that the Web Services Atomic tion in the policy alternative indicates the need to follow Transaction 1.1 specification (http://docs.oasis-open.org/ the corresponding QoS protocol. A service might indiws-tx/wstx-wsat-1.1-spec-os.pdf) defines. This protocol cate that several policy alternatives are possible; the seris defined using a general-purpose protocol definition vice requester is then free to select and follow one of them framework introduced by the Web Services Coordination as it accesses the service. 1.1 specification (http://docs.oasis-open.org/ws-tx/wstxPolicy assertions can represent both requirements on wscoor-1.1-spec-os.pdf). Distributed ACID transactions service requesters and the capabilities of the service are not particularly well suited to the SOA environment, itself. Requirements represent a demand on service however, because they assume tight coupling between requesters to follow a particular behavior; capabilities participants—an unlikely scenario in service-oriented are the service provider’s promises of behavior. The use applications. Still, the Web Services Atomic Transaction of a mechanism to protect message integrity, such as a Protocol supports transaction interoperability between digital signature, is a requirement that a service can platforms that otherwise cannot easily interoperate, such impose on requesters. Adhering to a particular privacy as Enterprise Java (J2EE) and Microsoft’s .NET. policy when manipulating data from a requester is An alternative set of transaction protocols is defined a service capability that requires no specific service by the Web Services Business Activity 1.1 specification requester behavior. 76
Computer
To be correctly interpreted, a policy must be attached to a particuService wsdI:service policy subject lar scope of applicability. A policy can apply to all service interactions, to a specific operation, or to indiwsdI:port vidual messages. By their nature, some policies are scoped to comEnd point plete interactions: A reliable meswsdI:binding policy subject saging session, for example, applies to all messages sent to (or received wsdI:portType from, or both) a service. Transactional protocols are often limited to a specific operation’s execution, wsdI:operation while message data protection Operation because of its high processing cost policy subject is typically limited to messages that wsdI:operation carry sensitive information. A policy attachment specification (www.w3.org/TR/2007/REC-wswsdI:input policy-attach-20070904) indicates the scope of a policy’s applicability. Message wsdI:input policy As Figure 2 shows, such a specificasubject tion associates the policy to a particular point of the WSDL service wsdI:message description: end point, operation, message. When policies are attached to overlapping scopes, the policy that applies to a particular subject (a Figure 2. Possible policy subjects appear on the left side, paired to the right with their message, for example) is the aggre- corresponding WSDL attachment points. gate of policies from all the scopes containing the subject. This aggregated policy is the sub- the policies cover all interactions with this interface. ject’s effective policy. For example, the reliable messaging protocol covers Figure 3 shows the attachment of QoS properties to a all messages exchanged. The subject of the ReliableWSDL binding. This example is a simplified version of Assertion is the end point policy subject shown in Figure one given in the Web Services Policy 1.5 specification. 2, which means that a policy containing this assertion Figure 3 defines three policies. RmPolicy supports the can be attached to the WSDL port, binding, or portType reliable messaging protocol by including the assertion. Nested information in this asserThe WSDL binding also indicates properties of indition configures the protocol’s timing parameters. vidual operations and messages through the , , and capabilities: X509EndpointPolicy contains the assertion to indicate the use of GetLastTradePrice operation’s input and output indiasymmetric key technology for securing the SOAP cates the need to secure those particular messages. (In message. Protocol configuration details, omitted for the context of Figure 2, SecureMessagePolicy is an assersimplicity, are nested inside the assertion. Secure- tion with a message policy subject.) The ability to attach MessagePolicy contains assertions to identify what parts policies to specific messages means that service providers of the SOAP message to secure. In the example, the can avoid unnecessary processing expense, saving policy indicates that only the message body, not SOAP encryption and digital signatures for messages that headers, is to be encrypted and signed. absolutely require them. The rest of the document contains a WSDL binding for a stock quote retrieval interface, which references SERVICE COMPOSITION the business interface being bound (fab:Quote) and There are two models of service composition in SOAs. indicates the need to use SOAP 1.2 for service access. Process-oriented composition combines services using The binding then attaches the reliable messaging and a workflow model to define a new service component. asymmetric key policies using . The Business Process Execution Language (BPEL) specBecause the attachment occurs at the level, ification (http://docs.oasis-open.org/wsbpel/2.0/OS/ November 2007
77
Figure 3. Defining and attaching QoS policies to a WSDL binding to configure the protocol requirements of a service end point.
wsbpel-v2.0-OS.html) is the prototype for this composition model. Structural composition focuses on identifying the participating components and the component connections that represent component interac78
Computer
tion channels. To date, the SCA specification is the most complete specification of a structural composition model for SOA. Unlike BPEL, SCA explicitly addresses the policy aspects of service composition. As of September
2007, the SCA specification is under OASIS review for standardization.
Service component architecture
Properties Composite A
Property setting
An SCA implementation represents a reusable service component that encapsuComponent Component Service Reference lates the business logic that supports one A B or more services. Implementations can be in a variety of languages, including Java, Promote Wire Promote BPEL4WS, C, and Cobol. Implementations also define the references—dependencies on other components’ services that the implementation must invoke during Figure 4. A graphical representation of an SCA composite. Services, references, normal operation—as well as configura- and properties of internal components can be exposed as services, references, tion properties. Interface types (typically and properties of a composite. WSDL portTypes) describe both services and references. Services and references use SCA bindImplementation policies are QoS directives to the conings to configure the interaction protocol used for pro- tainer hosting the implementation. An example is the viding or using a service. Examples of bindings are the requirement to execute the component’s code within a Web services binding (the Web services protocol stack) local transaction, a behavior that need not be externally or a messaging backbone. visible or affect component interoperation. This policy is Services, references, and properties define an SCA part of the contract between the implementation and the implementation’s configurable aspects (its points of vari- hosting environment, as opposed to the standard SOA ability). An SCA component is a configured SCA imple- contract, which binds a service to an external user or mentation that sets property values and resolves the another component. Implementation policy is relevant references to other SCA components by specifying the when considering SOA composition because composicomponent wires (interconnections). An SCA compos- tion is essentially a form of implementation and introite (or SCA assembly) is a packaged set of components duces QoS aspects that implementers must address. and wires that define the structural composition. The idea of policy intents is parallel to the idea of As Figure 4 shows, the SCA composite can provide abstract interfaces in WSDL and is rooted in the assumpfor the interaction between internal components and tion that each platform or interaction medium can manexternal applications by defining composite services, ref- ifest the same QoS capability as a different protocol. For erences, and properties. This means that an SCA com- example, service users and providers can ensure mesposite can be an SCA component within another SCA sage confidentiality through XML encryption or a secure composition, with the first SCA composite providing transport; an SCA developer is concerned with protectthat component’s implementation. In SCA, this is called ing confidential data, independent of the technology recursive service composition. used to achieve that goal. Just as WSDL abstract interfaces must be bound to Role of policies in the Service concrete access bindings and a network end point, polComponent Architecture icy intents must be bound to concrete policies repreThe SCA specification lets component assemblers senting specific protocols. In most cases, a policy intent specify policies on the wires between components by will map to a Web services policy that represents the realassociating QoS properties with the binding attached to ization of that intent (or set of intents) on a particular the wire. These policies govern the interaction across communication protocol, such as SOAP. The mapping component boundaries, and their use is a direct appli- between abstract intents and concrete policies is achieved cation of the Web services interoperability stack’s policy using the policy set and intent map SCA constructs. model. The service provider can specify SCA policy at develSCA extends the Web services policy model in two sig- opment time (during composition creation) using nificant ways, by introducing abstract policy intents. Selecting the concrete policy is done at deployment by inspecting the available policy ! implementation policies—policies that represent sets and intent maps. In this way, an SOA application implementation behaviors, policies not necessarily provider can use the same SCA assembly in different related to component interaction—and deployment environments with consistent policy config! policy intents—abstract policy features that repre- urations. SCA also makes it possible to specify concrete sent QoS capabilities independent of a particular Web services policies directly within the SCA composite protocol. by attaching a policy map to the composite’s elements. November 2007
79
SCA provides a complete policy model that extends the Web services policy model beyond providerrequester service interoperability to multicomponent environments in the same way that functional service composition extends functional contracts.
Policy composition
Service composition, whether process-oriented or structural, centers on the services’ functional characteristics. Both BPEL and SCA build their composition models on WSDL business interfaces. However, as an SCA developer assembles services and components into new composites, the QoS properties of components and wires are also implicitly composed in ways that are usually hard to understand or predict. A major challenge when composing policy-rich SOA components is to determine a composite’s QoS properties—to understand how the QoS properties of individual services aggregate during composition. Methods for meeting this challenge are either bottom up or top down. In a bottom-up approach, assemblers use a set of policy intents to configure the composite’s components and wires. The problem then becomes how to derive the composite’s QoS properties. A classic problem is how to determine a process-oriented composition’s (a workflow) performance properties from performance models of the composed services.2 In general, this problem remains open because no well-defined rules exist for composing most QoS properties and because composition rules depend heavily on the QoS property being considered. In a top-down scenario, assemblers define the composite’s desired QoS behavior and use that definition to
IEEE Computer Society members
SAVE
25%
on all confer ences sponsor ed by the IEEE Computer Society
w w w. c o m p u t e r. o r g / j o i n 80
Computer
drive component configuration. A common strategy is to encode well-known QoS configuration patterns that guarantee the desired composite properties. The patterns capture established practices for configuring the policy intents of composites and wires. However, even a simple model is surprisingly complex to configure. Consider the typical authentication and authorization pattern in which services authenticate the credentials of distributed application users at a single point, and ensuing service interactions transmit credentials and perform authorization checks to control access to enterprise resources. This extremely common model requires configuring all the services that compose the application in a simple but perfectly correlated manner, including such aspects as propagating security tokens, specifying their format, and converting among formats as required. Capturing this pattern generically and providing ways to map it onto SCA assemblies ensures the correctness of the overall configuration and radically simplifies the overall configuration task. Clearly, policy composition remains one of the most challenging aspects of service-oriented computing research, and continues to be one of the least understood.
E
stablishing contracts for service composition remains one of the most challenging research areas in SOA and will require significant attention to individual policy domains. Conducting extensive domainspecific research is a first step in addressing this problem. As knowledge develops, new industry standards in each policy domain are likely to provide guidelines and patterns that will guide practitioners in various policy composition scenarios. Finally, semantic reasoning techniques hold the prospect of supporting automated, policy-rich service composition based on more meaningful service contracts. ■
References 1. S. Weerawarana et al., Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WSReliable Messaging, and More, Prentice Hall, 2005. 2. J. Cardoso, “Modeling Quality of Service for Workflows and Web Service Processes,” Web Semantics J.: Science, Services and Agents on the World Wide Web J., vol. 1, no. 3, 2004, pp. 281-308.
Francisco Curbera is a research staff member at IBM’s T.J. Watson Research Center. His research interests are in component and composition models in Web-centric, loosely coupled runtimes. He helped define the Web services stack and write the WSDL, Web Services Policy, and BPEL specifications. Curbera received a PhD in computer science from Columbia University. Contact him at
[email protected].
