The UML-to-SOA transformation tool in IBM®Rational®Software Architect includes an SOA transformation tool that is based on Service Component Architecture (SCA), which uses Service Component Definition Language (SCDL) to express metadata. UML-to-SOA transformation tool produces output that is ready to be imported into IBM® WebSphere® Integration Developer 6.0.2 or later for further development, testing, and deployment. In addition to the common transformation configuration options, the UML-to-SOA transformation tool provides specific configuration properties.

Transformation structure and extensibility

Figure 1 shows the structure of the UML-to-SOA transformation.

The UML-to-SOA transformation tool is extended with UML-to-SCDL transformation, which is responsible for the creation of the SCDL module and library projects.

• Module projects contain SCDL artifacts, such as modules, components, exports, and imports.
• Library projects contain other domain-specific artifacts referenced by various SCDL elements.

The UML-to-SCDL transformation tool included in Rational Software Architect provides four different extensions, and there are two groups of extensions:

• Interface extensions, which are used to process all interfaces in the source model including UML interfaces, referenced WSDL port types and Java™ interfaces. UML-to-WSDL transformation is used by the WSDL interface extension to create WSDL port types referenced by the SCDL components, exports and imports. The Java interface extension is used to copy Java projects containing referenced Java interfaces into the target project.

• Component implementation extensions, which are used to process UML activities and references to the Java classes. The Business Process Execution Language (BPEL) implementation extension uses UML-to-BPEL transformation to create BPEL processes referenced by the SCDL. The Java implementation extension is used to copy Java projects containing referenced Java classes into the target project.

The UML-to-BPEL transformation tool uses UML-to-WSDL transformation and UML-to-XSD transformation to create WSDL (Web Service Description Language) port types and XSD Schema Datatypes. Similarly, UML-to-WSDL transformation uses UML-to-XSD transformation to create XSD Schema Datatypes.

Transformation source

The UML-to-SOA transformation is designed to process UML models of the software services.

The intended source for the UML-to-SOA transformation is an entire UML model, with or without the UML 2.0 Profile for Software Services applied. Alternatively, the transformation can accept one or more UML packages or individual UML components representing service provider as the source. If the UML model or package is selected as a source, the UML-to-SOA transformation navigates to the selected model or package and creates necessary SCDL artifacts for every service provider. Selection of multiple UML elements as the source of the transformation is supported by the UML-to-SOA transformation.

Figure 2 is a fragment of the UML model (on the left), showing the CreditManager service provider and a UML class diagram (on the right) with the external view of the CreditManager service provider.

Transformation output

A UML-to-SOA transformation produces output for importing into IBM WebSphere Integration Developer 6.0.2 and later for further development, testing, and deployment. The transformation can accept any project in the work space as a target.

Tip:
You can create a new target project, if one is required, by clicking Create New Target Container on the Source and Target page in the Transformation Configuration editor.

For every service provider, the transformation creates a module project. In addition to the typical project files, such as manifest.mf, .project, .classpath, and .runtime, the transformation creates an sca.module file, plus files with extensions of component, export, and import that represent various elements of the SCDL module. The module project references one or more library projects that contain definitions for the interfaces and business objects.

Figure 3 shows a typical structure of the module project created by the UML-to-SOA transformation tool. This is an expanded view, showing the com.acme.creditmanagement.CreditManager module project created by the UML-to-SOA transformation.

For every UML interface transformation creates a separate WSDL file. For every UML parameter type (data type), except UML primitive types and built in XSD simple types, transformation creates separate XSD file. WSDL and XSD resources are created in the single Library project or in multiple Library projects depending on the structure of the transformation source. Figure 4 shows the CreditManagement library project created by the UML-to-SOA transformation.

Source-to-output mapping

The following table describes the mapping between the source and output objects.

Transforming a UML service provider component to the SCDL module

The UML-to-SOA transformation produces different types of the SCDL modules, depending on the design of the particular software service. Details about designing software services in UML can be found in the previous article on SOA modeling.

Figure 5 is a fragment of the UML model, showing Customer Order Handling service provider represented by the UML component with the Customer Order Handling UML activity used as owned behavior.

For this design of the service provider, the transformation creates an SCDL module project that contains a single SCDL component with BPEL implementation (see Figure 6). For details about mapping the UML activity to the BPEL process, see the article from the SOA modeling series, cited in Resources, titled "From UML to BPEL."

Figure 7 shows the UML composite structure diagram, which shows the decomposition of the Customer Order Handling service provider.

In this case, the transformation creates an SCDL component for every UML part of the service provider and wires these components, accordingly, to the internal structure of the UML component that represents the service provider (see Figure 8).

All interfaces that are provided through the UML ports by the UML component and represent the service provider become SCDL exports. All required interfaces exposed through the UML ports become SCDL imports. In this example, the provided CustomerOrderHandling interface exposed through the myRole port was used to generate the myRoleExport.export file. The OrderVerification, PaymentHandling, CustomerServiceRepresentative, and AccountManager ports were used to create corresponding import files.

Transforming UML models with references to domain-specific data types and interfaces

Some data type libraries became a recommended or an official standard for a particular industry. For example, Health Level Seven (HL7), which is one of several ANSI-accredited Standards Developing Organizations operating in the healthcare arena, provides clinical and administrative data standards available in XSD format. In many cases, the use of industry-specific types and data sets is one of the key requirements for the software.

Processing references to existing XSD data types

To fulfill this requirement, UML models of the software services might use references to an existing XSD type. In this case, the UML-to-SCDL transformation creates a library project and copies the XSD resource that contains the referenced XSD data type from its parent project into the library project, including the folder structure and all XSD schemas referenced with XSD include or XSD import. The name of the created library project is the same as the name of the project that contains the originally referenced XSD schema. If the included or imported XSD schemas are in a different project, the transformation creates a corresponding library project and adds project dependencies where they are required.

Processing references to existing WSDL port types

In a manner similar to existing XSD data types, UML models of the software services may use references to existing WSDL port types. References to the WSDL port types are processed by the transformation the same way as referenced XSD data types. The transformation creates all necessary library projects for the WSDL port types referenced in the UML model and all WSDL files referenced using WSDL import and XSD schemas that are referenced with XSD include or XSD import.

Processing referenced Java interfaces and Java classes

The UML-to-SOA transformation supports UML models of the software services with references to the existing Java interfaces and classes as the source. This enables you to design new services as an aggregation or composition of the existing services that already have Java implementation and are exposed through the Java interfaces. When the transformation encounters a Java interface or class during parsing of the source module, it creates a copy of the Java project. The copy containing the Java source code and all Java projects that it depends on, and these are transferred into the project selected as the transformation target container.

Importing the output of the transformation into IBM WebSphere Integration Developer

To create, complete, and test a Web application, the transformation output must be imported into WebSphere Integration Developer by selecting File > Import > Existing Projects into the Workspace. All projects created by the transformation must be imported into the WebSphere Integration Developer workspace, one by one. Imported projects contain dependencies. If projects are imported in the wrong order, the build may have errors. In this case, simply clean and rebuild all imported projects.

Then, complete these tasks in WebSphere Integration Developer:

1. Add implementation to components with empty implementations.
2. Wire all imports.

Summary

You can find more information about SOA transformation in the final article in this series, Transformation to SOA: Part 4. UML-to-BPEL. Also, for additional information, be sure to check the citations and links in Resources.

Resources

Learn

• Part 1 of this series, Transformation to SOA: Part 1. From business process to service model architecture using IBM WebSphere Business Modeler and IBM Rational Software Architect.
  
  
• Part 2 of this series, Transformation to SOA: Part 2. Creating a custom extension for the Business Process-to-Service Model transformation feature in IBM Rational Software Architect.
  
  

• For additional useful information, read this series of five articles by Jim Amsden about developing software based on service-oriented architecture (SOA):

  • Modeling SOA: Part 1. Service identification shows how to use UML models extended with the IBM Software Service Profile to design an SOA solution that is connected to business requirements, yet independent of the solution implementation. The author describes the business goals and objectives and the business processes implemented to meet those objectives, and then explains how to use the processes to identify business-relevant services necessary to fulfill the requirements that they represent.
  • Modeling SOA: Part 2. Service specification. The author continues defining the SOA solution by modeling the specification of each service in detail. These specifications will define contracts between consumers and producers of the service. These contracts include the provided and required interfaces, the roles those interfaces play in the service specification, and the rules or protocol for how those roles interact.
  • Modeling SOA: Part 3. Service realization. This third article explains how SOA-based Web services are actually implemented. The service realization starts with deciding what component will provide what services. That decision has important implications in service availability, distribution, security, transaction scopes, and coupling. After these decisions have been made, you can model how each service functional capability is implemented and how the required services are actually used. Then you can use the UML to SOA transformation feature included in IBM Rational Software Architect to create a Web services implementation that can be used in IBM WebSphere Integration Developer to implement, test, and deploy the completed solution.
  • Modeling SOA: Part 4. Service composition. This fourth article covers how to assemble and connect the service providers modeled in "Part 3. Service realization" and choreograph their interactions to provide a complete solution to the business requirements. The resulting component will be a service participant that composes the services provided by the Invoicer, Productions, and Shipper components to provide a service capable of processing a purchase order. It also shows how this service participant fulfills the original business requirements.
  • Modeling SOA: Part 5. Service implementation. In this final article in the series, the author describes how to create an actual implementation that is consistent with the architectural and design decisions captured in the services model. We'll generate the platform-specific implementation by exploiting both model-driven development and the IBM Rational Software Architect UML-to-SOA transformation feature to create a Web service from the SOA model.
  
  
• Browse the SOA and Web services area on developerWorks to get the resources you need to advance your skills in service- oriented architecture.
  
  
• Visit the IBM Service-Oriented Architecture (SOA) Solutions area on IBM.com.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
  
  
• Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download trial version of IBM Rational Software Architect, Version 7.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Transformation structure and extensibility
• Transformation source
• Transformation output
• Source-to-output mapping
• Transforming a UML service provider component to the SCDL module
• Transforming UML models with references to domain-specific data types and interfaces
• Importing the output of the transformation into IBM WebSphere Integration Developer
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Software Architect
• Demo: Model Rational RequisitePro requirements in Rational Software Architect
• Webcast: Harnessing the power of enterprise architecture
• Briefing: Architecture, design, and construction using the IBM Rational Software Delivery Platform
• Buy: Rational Software Architect

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers