® ibm software group © 2004 ibm corporation using rational software architect to drive application...

®

IBM Software Group

© 2004 IBM Corporation

Using Rational Software Architect to Drive Application Integration Message Definition from Information Models using a Model-Driven Development Approach

Mariangela Orme

Executive IT/Architect

IBM Rational Services

[email protected]

CIM User Group 2010 - Milan

IBM Software Group

Problem StatementIn many industries, there is a growing trend to standardize on information being passed between systems themselves and systems and client applications. Various standards bodies comprised of corporate industry leaders are attempting to define common data that is to be used as a basis for interoperability. In some situations, messages themselves are defined as part of the standard. In most cases an information model is provided as a basis for messaging data. It is often necessary to create new message definitions based on the standard information model.

Therefore, tooling is needed to help create standards-based message definitions.

2

IBM Software Group

Goal

3

The ultimate result of this strategy is to show that Rational Software Architect can be used as a single tool platform

for the creation, maintenance and governance of industry information

model-based message definitions and the implementation code needed to

process the message data.

IBM Software Group | Rational software

4

The Rational Software Architect Solution The following principles apply to the proposed strategy

1. A cursory examination of information models across different industries shows that the models are in various states of maturity. Also, there are various levels of detail in the models with respect to “closeness to implementation”. For example, some information models simply are interested in showing abstraction relationships but do little to further specify that relationship (direction, multiplicity, etc.).

Therefore, there will be a need to augment the model and further specify its contents. However, it is still important to maintain some compliance to the original standard no matter how far from your reality it is.

2. Tooling should be established to help the user maintain and manage their extended information model.

3. It is assumed that the user has a desire to propose changes back to the standards body. Therefore, tooling should help with this effort.


5

The Rational Software Architect Solution

4. There is a conflict in principles between a well formed and normalized data types model (information model) and a messaging strategy that attempts to limit the message payload and the computing resources necessary to process the messages. Therefore a strategy needs to be put in place to allow for the ability to subset the information model. A typical information model used in its pure form for even the simplest of messages would contain tens if not hundreds of types to fully satisfy the enclosure, even if most of the data were optional. A mechanism needs to be provided that allows the user to maintain the integrity of the information model abstractions yet be able to only take the subset of those abstractions needed to satisfy a particular message scenario. It could be debated whether you can then call these resulting messages “compliant” to the standard, yet the reasons for doing so are still valid.

- Categories- Relationships- Normalization

vs.- Light payload- Simpler implementation- De-normalization



6

5. A model-driven approach is also desired that allows you to model your message definitions and have them auto-generated by a model transformation. The reverse is also true in that the ability to reverse transform an existing data definition into a UML model is desirable since some standards bodies publish data definitions (xsd) as part of its content. It is therefore desirable to see what those definitions look like in UML.



7

The following principles apply to the proposed strategy (continued)6. Once you have established your desired data definitions and messages, there is the

obvious task of building any necessary implementation components necessary realize the interoperability. There are numerous options here and many off-the-shelf solutions that provide large-scale solutions.

• Enterprise Service Bus solutions such as WebSphere Message Broker or WebSphere ESB

• Process choreography solutions such as WebSphere Process Server

• Web Service implementations

The data and message definitions as defined by the resulting XSDs can be directly imported into such solutions.

7. Tooling should also be provided to allow a more custom implementation approach, such as building java implementations of web services, the creation of XML data manipulation code via JAXB, or the creation of XSL translations to mediate between data definitions.


Use Case Model

8


Maintain Information Model Use Case

10

Pre-conditions: An information model in RSA format

1. Import the information model into RSA2. Create a diff report to determine what is new with the latest version of the

model. Compare it to the previous version as well as your extensions to determine if anything you added is now part of the standard model.

3. Extend the information as necessary. As you work on the model, the tool needs to prevent you from making changes to the model structure. The tool also needs to automatically mark the model to be able to visually see the additions you have made to the model.

4. Create a report that shows the additions that you have made to the model.


Maintain Information Model Use Case

11


Maintain Message/Service Model Use Case

12

Pre-conditions: An extended information model

1. For a particular message scenario, examine the extended information model for the data types that are deemed necessary. Utilize the RSA Browse diagram feature to understand the enclosure scope of any given information data type (UML class)



13

2. Mark the primary data types in the information model that are necessary to satisfy the message scenario with either a <<Select>> or <<SelectAll>> stereotype. <<SelectAll>> for a class/enumeration indicates that the class and all of its attributes are included. A <<Select>> stereotype for a class simply includes the class itself. You must subsequently provide the <<Select>> stereotype to individual properties for them to be included.

3. Once you have determined the necessary primary data types, execute the transformation that will extract the selected data types into a separate model. If it is determined that more data types are necessary, repeat steps 2 and 3 accordingly.

For each selected class the transformation will bring over the class and its one level closure. I believe this to be a good solution in that it does not force you to have to truly select every class you want yet it doesn’t bring the entire enclosure over either.

The resulting model then represents the information model abstractions that are deemed necessary for the message scenario.



14

4. In order to save the <<Select>> and <<SelectAll>> markings that have captured the chosen abstractions for a message scenario, execute an action that will save these selections to an xml file. This is important for two reasons. One you most likely will have many different message scenarios that will have different information model selections. This allows you to save numerous xml files with different selection criteria. Secondly, when a new version of the information model is brought into use, you will want to be able to restore these selections to the new version.

5. The model that results from the transformation now includes just the information model classes that are necessary for the message scenario. The model can now be manipulated to produce the necessary message and service constructs. Manipulation includes severing relationships to limit complexity. This model is completely editable yet care should be taken to preserve the integrity of the standard types. You will need to add the XSD and SoaML profiles as well as the XSDDataTypes model library to the model. This gives you the necessary stereotypes you need to execute the UML to XSD and UML to WSDL transformations.

6. Generate the XSDs and WSDLs by executing the UML to XSD and/or UML to WSDL transformations.



15


Develop Integration Implementation Use Case

16

Pre-conditions: XSDs and WSDLs

1. Utilize automation tools such as:1. Generating JAXB code to process the XSDs2. Using model mapping to map data between to XSDs (or XML or DTD) to

automatically create a XSLT transformation file. Then auto-generate the necessary XSLT implementation.

3. Create web service implementations and clients from WSDLs2. Import XSDs and WSDLs into middleware development tools (WebSphere

Integration Developer, WebSphere Message Broker, WebSphere ESB, etc.)


Develop Integration Implementation Use CaseXML Development tooling XML editor and validator

XSL schema editor and validator

Simplified XML schema graphical editing options

High performance XML schema validator

XML schema document generator

XML schema inference (XML -> XSD)

XML grammar converters (DTD -> XSD, XSD -> DTD)

XML schema to Java code generation (XSD -> Java via JAXB – JSR222)

DTD editor and validator

XSLT editor and validator

XSLT debugger

XPath wizard

XML-to-XML mapper (also utilizes XSD and DTD as input)

XSLT implementation generator

17


Develop Integration Implementation Use CaseWeb Service tooling Web Services wizards to take you through each step in Web Service

development

Generate Web Service client from WSDL/WSIL

Create Web Services from Java Beans or WSDL/WSIL files using Axis 1.3 Web service runtime

WSDL visual editor

18



19

® ibm software group © 2004 ibm corporation using rational software architect to drive application...

Documents