Service-Component Architectures

Service-Component Architectures (SCA) provide a programming model for implementing Service-Oriented Architectures (SOA).


August 02, 2007
URL:http://www.drdobbs.com/database/service-component-architectures/architecture-and-design/service-component-architectures/201202701

Arunava is a manager at BearingPoint working on SOA and Java Enterprise Architectures. He holds a Ph.D. in Physics from Florida State University and can be contacted at [email protected].


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.

[Click image to view at full size]

Figure 1: SCA Model as it relates to implementation details.

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:

Building Services: The Assembly Model

The Assembly Model describes how services are defined and configured.

Components are at the core of the SCA Model, and can be implemented in any language that supports SCA. Once defined, Components can be configured declaratively using Properties, which map to accessors and mutators in the underlying implementation. Figure 2 is a digram of a component. Example 1(a) is a declaration of a component in XML.

(a)
<component name="AddServiceComponent">
  <implementation.java class="calculator.AddServiceImpl"/>
</component>

(b)
  <component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl"/>
  <reference name="addService">AddServiceComponent</reference>
  </component>

Example 1: Component declaration.

Figure 2: Component.

References let Components invoke other services. References are resolved at deploy time or runtime. Example 1(b) shows an example reference.

Composites are groupings of Components. Depending on the declaration, a Composite can be used as a service or new Component. Thus, the SCA model supports recursive assembly.

[Click image to view at full size]

Figure 3: Composite that is a Service

Services are essentially Composites that you promote to Services by including the service element in the Composite declarations. Like Components, Composites and Services can be configured declaratively through Properties. As you can see from the description of the elements of an SCA assembly, existing applications can be incorporated into the architecture by modeling the application as a Component, Composite, or providing a Reference to a callable interface of the application.

Wiring

Component connectivity is handled through "Wiring," which implies defining source/target information between Components. As with other SCA elements, the details of Wiring can be set declaratively. SCA Wiring does not require the source and targets to be of the same type (Java interfaces to WSDL is acceptable, for instance) as long as compatibility concerns such as remoteability, callback support, Fault, and Exception handling are addressed. Example 3(a) is a simple wiring example.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
           name="CalculatorComposite">
    <service name="CalculatorService">
        <interface.java interface="calculator.CalculatorService"/>
        <reference>CalculatorServiceComponent</reference>
    </service>
    <component name="CalculatorServiceComponent">
      <implementation.java class="calculator.CalculatorServiceImpl"/>
      <reference name="addService">AddServiceComponent</reference>
      ...
    </component>
    <component name="AddServiceComponent">
        <implementation.java class="calculator.AddServiceImpl"/>
    </component>
    ...
</composite>

Example 2: Reference declaration.

(a)
<reference name="stockQuoteService"
target="StockQuoteMediatorComponent"/>

(b)
    <reference name="HelloWorldService"> 
      <interface.java interface="helloworld.HelloWorldService"
         callbackInterface="helloworld.HelloWorldCallback"/>
<interface.wsdl xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance" interface="http://helloworld#wsdl.interface(HelloWorld)" 
callbackInterface="http://helloworld#wsdl.interface(HelloWorldCallback)"
      wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" />
      <binding.ws endpoint=
"http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort)" location="wsdl/helloworld.wsdl" />
    </reference>

Example 3: (a) Explicit wiring in a reference; (b) reference bound to a web service.

To simplify development, SCA supports "Autowiring." As long as References are unambiguous, the container should be capable of wiring components at runtime.

Binding

The SCA Model supports communication between Services via Bindings, which exist for a number of technologies. To comply with the specification, all implementations must support an SCA Service Binding and Web Service Binding. Bindings are used by Services and References. Services use Bindings to define how they can be called; References use them to declare how they intend to call a Service. Example 3(b) is a Binding using web services.

Quality of Service: The Policy Framework

To address Quality-of-Service (QoS) and nonfunctional requirements, the SCA Model provides a Policy Framework. Policies can be used to define security, availability, and transactionality, among other requirements. Policies can be associated with each Component. Services and References can have multiple policies to allow alternate means of access. The main elements of the Policy Framework are Intents, Profiles, and Policy Sets.

Intents are abstract statements of QoS constraints on a Component implementation. For example, messaging may need to be confidential. An Intent with name "confidentiality" can therefore be defined as in Example 4(a).

(a)
<intent name="confidentiality" constrains="sca:binding">
<description>
Communication through this binding must prevent
unauthorized users from reading the messages.
</description>
</intent>

(b)
<sca:profile intents="sec.confidentiality rel.reliability"/>

Example 4: (a) Intent declaration; (b) Profile declaration.

Profiles are aggregations of Intent names. Intents referenced in a Profile are mapped to implementations in Policy Sets. Example 4(b) is a Profile declaration.

Policy Sets correspond to the implementation of Intents. They declare technology-specific constraints on elements in the Assembly Model. Example 5 is a Policy Set corresponding to the Confidentiality Intent. This example uses the intentMap element, which indicates alternative implementations for a given Intent.

<policySet name="SecureMessagingPolicies"
provides="confidentiality"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<intentMap provides="confidentiality"
default="transport">
<qualifier name="transport">
<wsp:PolicyAttachment>
   <wsp:AppliesTo>
    <wsa:EndpointReference xmlns:myStore="..." >
 <wsa:Address>http://myStore.example.com/acct
</wsa:Address>
 <wsa:PortType>
myStore:myPortType
</wsa:PortType>
 <wsa:ServiceName>
myStore:InventoryService
</wsa:ServiceName>
    </wsa:EndpointReference>
  </wsp:AppliesTo>
  <wsp:PolicyReference
URI="http://myStore.example.com/policies.xml" />
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
 ...
</wsp:PolicyAttachment>
</qualifier>
<qualifier name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject for
"message" alternative" -->
 ...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>

Example 5: Policy Set using an intentMap and WS-PolicyAttachment.

Policy Sets contain the specifics of a technology including details for the bindings, sources, and targets. If a Public Key Infrastructure were required, the Policy Set may contain information such as encryption methods, trust relationships, and key stores. WS-Policy and WS-PolicyAttachment are the de facto syntax for Policy Set declarations. However, support for other languages (such as XACML or proprietary languages) are possible and depend on the container implementation.

Intents are attached to components through the Component metadata. Example 6 is an example of attaching authentication and reliability intents to a Service declaration.

<sca:service name="mySpecialService">
<sca:interface.wsdl portType="..." />
<sca:profile intents="sec.authentication rel.reliabilty"/> 
</sca:service>

Example 6: Profile attached to Service.

At this writing, Policy Sets and Intents are maintained in a global definitions file that is referenced in assembly descriptor files through the Intent or Profile.

Data Access: Service Data Objects

While not part of the SCA Model proper, Service Data Objects (SDO) are the de facto SCA data architecture. SDOs are based on the concept of disconnected data graphs. The SDO architecture maintains a tree or graph of data objects that can be accessed via APIs. The architecture allows both strong-typed and weak-typed data models, thus supporting static and dynamic data access strategies. The SDO architecture makes no assumptions about the query languages involved. Instead it relies on its base API to access nodes. Intended to separate application code and data access code, the architecture encourages the use of Data Access Services (DAS) to manipulate graphs (incubator.apache.org/tuscany/das_index.html). By adding metadata, SDOs also support runtime exploration of the data graphs. Since the architecture was designed with XML in mind, it provides a rich mechanism for manipulating XML. In fact, for practical purposes, the underlying data structure for SDOs may well be XML documents. At this writing, the SDO specification is in Version 2.1.

Conclusion

SCA attempts to create a simple, robust programming model based on SOA concepts. Its value lies in a conceptually simple, declarative approach to assembly and QoS. Through assembly-time and runtime wiring and loosely coupled policies, SCA addresses the issue of creating a service without foreknowledge of the underlying components. This, in turn, lets service component and integration developers act independently. Combined with SDO, a vendor-neutral approach to SOA is possible—the model designers appear to have learned from weaknesses of earlier models—by providing a clean separation between assembly and QoS. If the Apache Tuscany Project is an indication of SCA's viability, then the outlook for a straightforward (though not necessarily simple) way to implement SOA is promising (cwiki.apache.org/confluence/display/TUSCANY/Home).

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.