Previous articles in this series have addressed the ways in which Rational SOMA 2.9 (henceforth, "Rational SOMA") and IBM Rational Software Architect for WebSphere Software, Version 7.5.4 and higher (henceforth, "Rational Software Architect") support the discipline of service solution design. So – you've used this method content and this tool to create a well-specified and organized service solution design. What, next, do you do with the service models?
This article illustrates some of the support that Rational Software Architect 8.0.2 provides for automating the creation of software service artifacts from service models. In particular, we'll illustrate Rational Software Architect's capabilities for creating Service Component Architecture (SCA) artifacts. Other articles, such as the previous 4-part developerWorks series Transformation to SOA, describe how to use Rational Software Architect to create other types of service and software development artifacts.
We will begin this discussion with an overview of SCA. We'll then describe some mappings between SoaML service model elements and SCA elements. Once this background has been established, we'll describe Rational Software Architect's support for transforming from service models to SCA artifacts. We'll finish the article with an example that illustrates the SCA output that is generated from a slightly-modified version of the sample service design model that ships with Rational Software Architect.
Service Component Architecture overview
The Open SCA specifications describe a model for building reusable software services. The suite of specifications includes an Assembly Model specification, which outlines the basic SCA concepts and describes how SCA configuration files are structured. Several specifications are provided that define how SCA components are constructed using specific implementation technologies and frameworks, such as Java, C++, BPEL, PHP, and Spring. The following sub-sections briefly describe the SCA elements that are most relevant to this article, those being:
The SCA component
SCA's basic building block is the component. As Figure 1 illustrates, a component can provide one or more services and it can have one or more references, through which it can use services that are provided by other software elements, including other SCA components, conventional Web services, and Enterprise Java Beans. An SCA component can be implemented using numerous development technologies. It can communicate with other components using a wide range of communication protocols, from least-common-denominator (and poorest-performing) SOAP to high-performance native protocols that are unique to the run-time application server that implements the SCA container. Further, SCA components support dependency injection, with which configurable properties can be defined at deployment time to specify, for example, specific implementations of policies that the component supports.
Figure 1. SCA Component
Component implementations are concrete implementations of business function which provide services and/or which make references to services provided elsewhere. In addition, an implementation may have some settable property values. An SCA component may be implemented using programming languages such as Java, C++, or COBOL. One also may be implemented by using the services that are exposed by an SCA composite (composites are described later).
An SCA interface defines one or more business functions. These business functions are provided by SCA services and are used by SCA references. An SCA service offers the business functionality of exactly one interface for use by other components.
Interface type systems
The open SCA specifications currently support the following interface type systems for describing SCA interfaces:
- Java interfaces
- WSDL 1.1 portTypes
- WSDL 2.0 interfaces
SCA is extensible with respect to interface types. As an example, the IBM implementation of SCA that supports CICS (Customer Information Control System) on IBM mainframes supports defining interfaces using CICS Channels and Commareas, as well as WSDL.
Remotable and local interfaces
SCA interfaces can be either remotable or local. A remotable service is one which may be called by a client that is running in an operating system address space different from that of the service itself (this also applies to clients running on different machines from the service). Whether or not a service of an SCA component is remotable is defined by the interface of the service. In the case of Java, this is defined by adding a @Remotable annotation to the Java interface. WSDL-defined interfaces are always remotable.
SCA supports bidirectional communication between service providers and consumers. This is accomplished by supporting the notion of a callback interface. If an interface element includes a callback, the interface as a whole is referred to as a "bidirectional interface".
If an SCA service is defined using a bidirectional interface element, then a component that provides the service implements the interface and uses the callback interface to converse with the service consumer.
If an SCA reference is defined using a bidirectional interface element, a component that uses the reference converses with the referenced service using the interface – that is, it uses the interface. The component that uses the reference implements the callback interface.
As is illustrated in Figure 2, an SCA service on one component (the illustrated "Provider") and an SCA reference on another component (the illustrated "Consumer") can be defined using the same bidirectional interface element. In modeling terms, they have the same type. These two components could communicate with each other, across this type-compatible service/reference pair. However, the sense of the provided and the required interfaces for the consumer is the mirror image of the sense of the provided and the required interfaces for the provider. We say that the reference is the "conjugate" of the service.
Figure 2. SCA service and reference defined using the same bidirectional interface element
The SCA Composite
The SCA specifications provide the composite concept as a means to assemble SCA elements into logical groupings. An SCA composite contains a set of components, services, references, and the wires that interconnect them. A composite also can contain a set of properties which can be used to configure components. Figure 3 illustrates a conceptual SCA composite
Figure 3. SCA Composite
The assembled components are connected within the composite using "wires" (communication channels) between pairs of services and references that are defined using compatible interface elements. SCA provides the ability to "autowire" components. If autowire is selected, the SCA runtime into which the composite is deployed will introspect the elements within the composite and automatically wire together compatible services and references that it identifies.
Composites can communicate with external elements using SCA services and references. These services and references are defined using "promotion". Promotion involves wiring the composite's services and references to compatible services and references on assembled components. The composite in essence delegates its services and references to its components' compatible services and references.
As Figure 3 illustrates, a lower-level composite may be used to implement a component that is itself assembled into a higher-level composite. The using component can only connect wires to the services and references of the used composite and set values for any properties of the composite. The internal construction of the composite is invisible to the using component.
Mapping SoaML to SCA
The astute reader who examines either Jim Amsden's Modeling with SoaML developerWorks articles or the sample SoaML model that ships with Rational Software Architect will observe a remarkable similarity between many SoaML and SCA concepts. As an example, consider the SoaML Participant, shown in Figure 4. The Participant offers Services and makes Requests, analogously to SCA components and composites, which define services and references. SoaML Services and Requests are typed by ServiceInterfaces, which can realize and/or use simple UML interfaces. The ServiceInterface maps cleanly to the SCA interface element, which defines interfaces and callback interfaces. Further, SoaML Requests conjugate their ServiceInterfaces, similarly to how SCA interface elements are conjugated when they are applied to SCA references. Conjugation of SoaML Requests is indicated in Figure 4 by applying a tilde (~) appended to the name of a Request.
Figure 4. A SoaML Participant in Rational Software Architect
An SCA component can define its implementation, intents, policy sets, and other details. Those aspects are modeled in Rational Software Architect by applying the SCA Transformation profile to the service model, applying the «SCA» stereotype to the Participant, and defining the stereotype's attributes. SCA attribute values for the Participant in Figure 4 are visible, being shown within Rational Software Architect via the Participant’s Attributes compartment.
Figure 5 reveals other similarities between a SoaML service model and certain aspects of SCA. Here we see a structure diagram for a SoaML Participant. The figure illustrates how internal parts that are owned by the Participant are connected in order to realize the operations that are offered by the Participant’s Service. The Participant delegates its Service to the Service of one of its owned parts.
The mapping between SoaML and SCA is fairly clear. In this case, the Manufacturer Participant is analogous to an SCA composite. Its internal parts map to SCA components that are assembled by the composite. The connectors (SoaML ServiceChannels) between the parts and between the composite and its delegated part map to SCA wires.
Figure 5. A SoaML Participant structure diagram
Rational Software Architect uses these illustrated mappings and others to transform SoaML-based service models into SCA artifacts. All pertinent mappings are documented in the online help for Rational Software Architect Version 8.0.
Transforming SoaML service models to SCA
In addition to being a modeling environment, Rational Software Architect provides powerful capabilities to transform content from one level of abstraction to another. For example, the tool includes a suite of productized transformations that can be used as-is to support model-driven development – transform work products from model to model, from model to text (Java, WSDL, etc.), and from text to model. Rational Software Architect also provides tooling to enable users to either extend existing transformations or create their own.
This article focuses on using the provided UML-to-SCA transform to accelerate service solution development. Transforming from SoaML to SCA follows these high-level steps:
- Create the SoaML service model
- Mark up the service model with appropriate stereotypes from the SCA Transformation profile
- Create and configure a new UML-to-SCA transformation configuration
- Run the transformation
The following sub-sections will address the final three of the above steps.
Marking up the service model using the SCA Transformation profile
Rational Software Architect provides an SCA Transformation profile that enables designers to add SCA-specific markup to service models. The profile includes four stereotypes and some stereotype attributes. They are used by the UML-to-SCA transformation to control its processing. Details can be found in the Rational Software Architect Version 8.0 online help.
Briefly, SCA Transformation stereotypes can be applied to UML Interface and UML Component elements to direct transformation processing. Three stereotypes – «Java», «Remote», and «WSDL» – can be applied to Interface elements to specify what type of interface description files are to be generated by the UML-to-SCA transformation, and to cause the invocation of appropriate secondary transforms (UML-to-Java or UML-to-WSDL, specifically). As was illustrated in Figure 4, applying the «SCA» stereotype to a UML Component adds stereotype attributes to it. The transform reads the attribute values to determine whether the resulting SCA element (either an SCA composite or an SCA component) has its auto-wiring property set, to set the policy sets and intents of the SCA element, and to determine what type of implementation the SCA element is configured to have. In one case – when the implementationType attribute of the SCA stereotype is set to "Java" – the UML-to-SCA transformation will invoke the UML-to-Java transformation to generate a skeleton Java implementation file for the created SCA component.
Creating and configuring a UML-to-SCA transformation configuration
Rational Software Architect provides wizard-based support to create and configure transformation configuration files. The approach is described in detail in Rational Software Architect online help. The procedure can be summarized briefly, as follows:
- Select the Modeling > Transform > New Configuration menu item to invoke the transformation configuration wizard.
- On the first page of the wizard, define a name for the new configuration file, where in your workspace it is to be created and the type of transform you are configuring – in this case, a UML to SCA transform
- On the second page of the wizard, select the source for the transformation's input and its target. The source commonly is a service model or selected elements of a service model. The target either is an existing SCA project or one that is created interactively using the wizard.
- Select "Finish".
Once the configuration has been created, you can use the configuration editor to set optional properties. For the UML-to-SCA transform, you can set a property to generate implementations for each of your SCA components, and another to generate Java code for any WSDLs that are found in the transformation source. These WSDLs that are “found in the transformation source” include:
- WSDLs that are generated by the UML-to-SCA transform from UML interfaces that are defined in the service model; and
- Pre-existing WSDLs that are referenced by UML elements in the service model.
As an example of the latter, consider Figure 6, which illustrates a SoaML ServiceInterface specification. The ServiceInterface realizes a UML Interface to which the «WSDL» stereotype of the SCA Transformation has been applied. The ServiceInterface uses an interface that is defined using an existing WSDL document. The representation of the WSDL was created simply by dragging and dropping the WSDL document onto the UML diagram. If the transformation property for generating Java code from WSDL documents is set to “true”, the UML-to-SCA transform first will generate a WSDL file for the "Invoicing" UML interface, then it will generate Java interface code for both the Invoicing and the InvoiceProcessing WSDL documents.
Figure 6. SoaML ServiceInterface that uses an interface defined by a WSDL document
Running a UML-to-SCA transformation configuration
Transformations can be initiated using one of several means, including:
- Invoking the transformation configuration from a menu
- Running the transformation from a command line
- Invoking the transformation API programmatically (such as from a user-built transform)
- Running from an Ant script
Details can be found in Rational Software Architect online help.
Example: generating SCA content from a SoaML service model
We illustrate the results obtained using the UML-to-SCA transformation using a simple work-along example.
Begin by making the following modifications to the sample Purchase Order Process service model that is included with Rational Software Architect 8.0.2:
- Apply the SCA Transformation profile to the model. This prepares the model for domain-specific SCA markup.
- Apply the «WSDL» stereotype to each UML interface in the "com" and "org" packages of the service model.
- Apply the «SCA» stereotype to each SoaML Participant in the "com" and "org" packages.
- For each Participant, navigate to its Properties View, then to the Stereotypes drawer of that view. For each Participant other than Manufacturer, set its implementationType stereotype property to "Java". For Manufacturer, set its implementationType stereotype property to "Composite".
Figure 7 illustrates the Property View for the Invoicer Participant, with the «SCA» stereotype applied and the implementationType stereotype property set to "Java".
Figure 7. A Participant's Property View with settings to generate a Java implementation
Next, create and configure a new UML-to-SCA transformation configuration.
- For the configuration's source, select the "com" and "org" packages of the Purchase Order Process service model. For its target, create a new SCA project.
- Once you have defined the source and target, select Finish, which causes the transformation configuration wizard to create your configuration and terminate.
- The transformation configuration editor remains open. Select the Properties tab at the bottom of the editor.
- Ensure that both of the transformation configuration properties – to generate implementations for components and to generate Java code for WSDL documents – are set to "true".
Now, run the transform.
- Select the "Main" tab of the transformation configuration editor, and then select the Run button.
As a result of running the transform, the SCA project will be populated with Java code, WSDLs, XSDs, and SCA content. Java, complete with SCA-related annotations, is created for numerous system elements, including the interfaces, the components (skeletal implementations are created for these), and data objects. This content can be further manipulated using the WSDL, XSD, SCA, and Java editing tools that are included with Rational Software Architect.
Navigate into the SCA project's SCA Content > Composites folder structure and expand the contents under the http://Manufacturer/ entry (this defines the namespace for the Manufacturer composite). Double-clicking on the Manufacturer item results in opening Rational Software Architect’s graphical SCA editor and revealing a diagram similar to what is shown in Figure 8. Here, we see a graphical depiction of the Manufacturer composite, with its exposed Service being realized by four wired-together SCA components. The correspondence to the source SoaML content – which is shown in Figure 5 – is clear.
Figure 8. Manufacturer composite in an SCA graphical editor
In Figure 8, the "J" for each of the components signifies that the component is based upon a Java implementation. Double-clicking any of the components will open a Java editor that contains the skeleton code that was generated for the implementation.
Things left for the SCA developer to do
Rational Software Architect's UML-to-SCA transform enables teams to get extra value from their service solution designs by automating the construction of SCA components, composites, and related WSDLs, XSDs, and Java code from service models. However, once the UML-to-SCA transform is run, there usually still are some details that need to be addressed using the Rational Software Architect graphical editors for SCA and other supporting editors and wizards.
For example, Rational Software Architect currently generates SCA configuration code for the web service and the default (SCA) bindings. Further, the transform generates one binding for a given service or reference, while the SCA specifications support assigning multiple bindings to a given service or reference. Additional bindings can be added by selecting a service or reference in the SCA graphical editor, then using the Binding tab of a service's or reference's Property View to add and define the bindings.
Further, the current transform generates (skeleton) source code for Java implementations of SCA components. The transform is able to use the implementationType property of the SCA stereotype to determine what type of implementation (EJB, JEE, etc.) is to be used for a component, and to configure an SCA component accordingly, but non-Java implementations must be separately coded. The productized transform can be extended to generate non-Java implementation code, should a user wish to do so.
- The Transformation to SOA 4-part developerWorks article series describes how to use Rational Software Architect to create service artifacts (WSDLs, XSDs, BPEL, service component definitions, etc.) that can be consumed by WebSphere Integration Developer for use in business process choreography.
- Visit the OASIS Open CSA website to learn more about Service Component Architecture (SCA) and the other initiatives of the Open CSA group.
- SoaML (Service Oriented Architecture Modeling Language) is a specification of the Object Management Group. SoaML defines a notation and a meta-model for describing and specifying service-oriented systems.
- Rational SOMA 2.9 borrows much of its approach to service modeling using SoaML from Jim Amsden's 5-part IBM developerWorks series, "Modeling with SoaML, the Service-Oriented Architecture Modeling Language".