Introduction

Service-Oriented Architecture makes some bold claims in reducing cost and improving business flexibility. In recent months, IBM has made a number of product announcements around Service-Oriented Architecture (SOA).

So you may be wondering if it is possible to deploy a Service-Oriented Architecture today. The SOA development and deployment lifecycle provided by IBM WebSphere software describes an approach to building IT systems by modelling business processes. The approach comprises these simple steps:

1. Business analysts model the business process in WebSphere Business Modeler
2. Integration developers implement the business process in WebSphere Integration Developer; assembling the process to new or existing IT functions.
3. Developers or administrators deploy the business process to WebSphere Process Server.
4. Business analysts receive feedback on key performance indicators and business events defined in the model, provided by the WebSphere Business Monitor.

The WebSphere software portfolio provides tools for each stage of the lifecycle as outlined in Figure 1:

This looks great in theory, but you may be asking:

Can I really deploy a business process defined by business analysts to an IT infrastructure?

IBM WebSphere software provides the foundation to enable you to achieve this goal. There are, however, some useful experiences, tips and techniques that you can benefit from as you move towards the SOA lifecycle, which we’ll describe in this article.

Where business analysts and technical architects meet

Specifically, we are going to take a look at moving the business process model from WebSphere Business Modeler to WebSphere Integration Developer and addressing some areas that will facilitate deployment to the runtime environment.

The whole idea behind this methodology is that it is model driven, that is, the 'master copy' of the model is always retained in WebSphere Business Modeler.

The export from WebSphere Business Modeler into WebSphere Integration Developer provides a good template process in Integration Developer. However, WebSphere Business Modeler does not have all the information required to completely implement the process. Therefore, you can assume that you will always need to do a degree of work in WebSphere Integration Developer before you can deploy it. This lifecycle will be iterative and, for every change to the model, it will have to be re-imported into WebSphere Integration Developer, requiring similar implementation steps each time.

This article is not really a tutorial but aims to provide principles, hints and tips for the model-driven development lifecycle provided by WebSphere Business Modeler and WebSphere Integration Developer. The areas discussed in the article fit into these categories, and are shown in Figure 2.

1. Where to start with WebSphere Business Modeler
2. What to bear in mind when developing the model
3. What needs to be done when you export the model to WebSphere Integration Developer
4. How to make life easier when iteratively making changes to the model in WebSphere Business Modeler and reflecting the change in WebSphere Integration Developer

Prerequisite knowledge

This article assumes a working knowledge of the two products involved in this part of the SOA development lifecycle:

• WebSphere Business Modeler v6.0.0
• WebSphere Integration Developer v6.0.1

A practical understanding of using the Service Component Architecture (SCA) standard in WebSphere Integration Developer will also be of value, although an in-depth knowledge is not required. For more information about SCA and these products, see the Resources.

WebSphere Business Modeler: Starting assumptions

Responsibility: Business Analyst

To make your life easier later on, address the following steps and decisions at the start of the modelling process in WebSphere Business Modeler.

Switch to "WebSphere Process Server" mode in Modeler right from the start.

The WebSphere Business Modeler product provides an extensive variety of modelling artefacts that are not supported in the BPEL standard. They therefore do not exist in WebSphere Integration Developer. Switching to this mode disables the artefacts that are not supported in WebSphere Integration Developer and removes most of the reworking required when moving to WebSphere Integration Developer.

Before you start modelling your business process, switch to "WebSphere Process Server" mode using the mode button, as shown in Figure 3:

Define common interfaces and data types as WSDL and Business Objects (XSD) in Integration Developer, and import into Modeler

Part of moving to a Service-Oriented Architecture is defining common interfaces and data types that can be reused by many applications and processes. How these interfaces are developed will depend on a number of factors and information available at the time. The following steps describe how to build well-defined interfaces to provide a strong basis from which to model business processes.

1. The business analyst should define these interfaces and data types, as far as possible, prior to modelling the business process.
2. As these interfaces often require awareness of IT variables as well as business data, export these artefacts to WebSphere Integration Developer, so that the service definitions can be fully defined as WSDL interfaces by the integration developer.
3. Import the interfaces and data types back into WebSphere Business Modeler. They will import as a Global service in Modeler (At the time of this writing, with Modeler v6.0 this feature was a technical preview and therefore not supported, although it worked when we tested with our sample interfaces.)

The rationale behind these steps is:

• The technical implementations of the services will reside in the WebSphere Integration Developer environment. These steps ensure that WebSphere Business Modeler is working from interfaces that will transform correctly back to WebSphere Integration Developer (All technical attributes, namespaces, operation names, types will be correctly defined.)
• Importing WSDL definitions into WebSphere Business Modeler correctly sets ‘implementation type’ of the imported service for when it is exported to WebSphere Integration Developer.(This is actually different to setting the implementation type manually. You currently can’t select a ‘Web Service’ implementation type in WebSphere Business Modeler.)

It is expected that, over time, these interfaces will mature and be made available in a services repository or UDDI.

Implement the model as fully as possible with technical details

When modelling in WebSphere Business Modeller, you should aim to fill in as many technical details of the model as possible prior to exporting. This will noticeably reduce the implementation work in WebSphere Integration Developer.

In particular, the types of the services can be selected in the model from the ‘Technical Specification’ tab of the service editor (see Figure 4).

The type you select here will specify the SCA component type of the service in WebSphere Integration Developer. This could be particularly useful when defining human tasks, as you can export the staff settings into WebSphere Integration Developer.

Back to top

WebSphere Business Modeler: What to bear in mind whilst modelling

Responsibility: Business Analyst

While it doesn’t make sense for a business analyst to also be an expert in WebSphere Integration Developer, it certainly makes sense for them to be aware of the consequences of their modelling decisions and approaches.

Be aware of the mappings between WebSphere Business Modeler artefacts and WebSphere Integration Developer artefacts

This is common sense really, but keep in mind that a business process in WebSphere Business Modeler effectively has to be translated from its diverse modelling functionality to the slightly more prescribed world of standard BPEL. It is useful for the business analysts to have an idea of what you can and can’t do in BPEL and therefore what cannot be mapped in WebSphere Business Modeler to WebSphere Integration Developer.

Fortunately, many of the unsupported mappings are intuitive in WebSphere Business Modeler when using it in ‘WebSphere Process Server’ mode because they are disabled, but a good awareness of that table will help developing ‘BPEL-ready’ models. A full listing of the mappings is found in the InfoCenter (See Resources).

Decision logic

By default, the decision branches in WebSphere Business Modeler transform to a condition branch in WebSphere Integration Developer, with the logic on the branch (see Figure 5).

However, this may not be the preferred way of expressing decisions in WebSphere Integration Developer. You can change this to a BPEL switch activity (Figure 6) by selecting the check box on the Technical Attributes view of the decision activity, as shown in Figure 7.

This option implements the decision as a BPEL switch. If the Technical Attributes View is not visible, you can access it by selecting Window->Show View-> Other… from the Business Modeler Views (see Figure 8).

There isn’t any logical difference, so it’s personal preference which you use. However, the BPEL switch activity can make the logic decisions clearer to read.

Creating a service with multiple operations

Usually a service with multiple operations will be modelled in WebSphere Business Modeler. First, let’s clarify by using an example. If you’re creating a service (global task) that manages an employee profile, then it might have the operations from Figure 9 related to it:

This service could be transformed into WebSphere Integration Developer in one of two ways; multiple WSDL interfaces, each defining one operation, or a single WSDL interface containing multiple operations, as shown from WebSphere Integration Developer in Figure 10. The latter is clearly the preferred approach from the point of view of the integration developer, although it is not as straight forward in WebSphere Business Modeler.

There are two ways to define the global service in WebSphere Business Modeler with multiple operations:

• Take the recommendation from the previous section and import the WSDL predefined in WebSphere Integration Developer into WebSphere Business Modeler.
• • If the interface doesn’t exist in WebSphere Integration Developer, you need to create it in WebSphere Business Modeler using the following steps.

To create the new global task (service) in WebSphere Business Modeler:

1. Create the new global task, using the name of the service as shown in Figure 11:

   
   Figure 11: Creating a new service
   
   

2. Under Inputs, add all the input parameters that will be needed by all of the operations:

   
   Figure 12: Creating input parameters
   
   

   Add the input parameters for each operation. If different operations use the same parameters, you still need to add them individually for each operation. In the example in Figure 12, three of the operations take the same parameter of type Employee, but the parameter is added three times, usefully named so that it can be identified as the parameter for a given operation.

3. Under Input logicI, add all the operation names that you want to have on the service. For each operation, check the parameter inputs (entered above) that apply to the operation, as shown in Figure 13.

   
   Figure 13: Creating input operations and assigning input parameters
   
   

4. Under Outputs, add the return parameters for all the operations in a similar fashion to the input parameters.

   
   Figure 14: Creating output parameters
   
   

5. Under Output logic, add a return output criteria (a response) for each operation that returns a result. Correlate it against the parameter that it returns.

   
   Figure 15: Creating output responses and assigning output parameters
   
   

6. Under Advanced output logic, ensure that each output criteria matches the correct input criteria (operation). You simply match the input request with the output response.

   
   Figure 16: Correlating input operations to correct output responses
   
   

To use the global task (service) with multiple operations:

1. Add the global task to the model as many times as required.

   
   Figure 17: Using the global service in a WebSphere Business Modeler model
   
   

2. To wire up the desired operation, wire up the input of the operation that is required, and its corresponding output. When using the multiple inputs/outputs in the model, be careful to select both the correct input, and the correct output.

Wiring tips:

• Use "hover over" to identify the correct parameter for a given operation as shown.
• The little left/right scrollers select the appropriate input/output criteria (these correlate to the operation). Use the scrollers to select the correct criteria.
• Wire up the correct input/output connector (parameter) within the criteria. These are highlighted for each criteria.
• Modeler will give warnings if you’re not using all inputs, but this is not a problem.
• If the model doesn't appear correctly in Integration Developer from the output of this service onwards, then it is likely that you've selected the wrong input/output combination.

Managing data flow

Data returned from an early task in the model can be used later on in the model by storing it in a local repository. WebSphere Business Modeler transforms the local repository to a BPEL variable in WebSphere Integration Developer.

Back to top

WebSphere Integration Developer: What will need changing

Responsibility: Technical Architect

As described at the start, the aim of this document is to minimize the number of changes required in WebSphere Integration Developer by maximizing the model development done in WebSphere Business Modeler. However there will always need to be some implementation steps performed in WebSphere Integration Developer as part of the import process. The following sections give an outline of this implementation.

Layout

Since you can’t move layout information from Modeler to Integration Developer, Integration Developer makes a best guess. Sometimes the process can initially look little like the exported model, so expect to do a little rearranging.

Although this has no effect on implementation, it may be worth trying a few different ways of designing the model to make the initial process easier to work with in WebSphere Integration Developer. Some ideas that change the way the process is rendered are:

• Whether decision modules are implemented as conditional branches or BPEL switch activities, the former being more structured.
• The use of scoping and local processes to make the model more modular.

Java snippets

A model from WebSphere Business Modeler also cannot contain any implementation information. Anything that needs implementation details within the process, such as a mapping, or data handling, gets transformed from WebSphere Business Modeler as a Java snippet.

You will need to implement these snippets each time the model is brought into WebSphere Integration Developer. See Making changes to the model for ways to minimize this.

Module assembly

Module assembly is the process of binding the service calls to actual implementations. See the resources section for more information about the Service Component Architecture (SCA) if required. If the services are created and defined in WebSphere Business Modeler (as opposed to importing them as WSDL from WebSphere Integration Developer), then all of the task/service implementations are defined as SCA components in the same module as the BPEL process.

By default, each component doesn’t have an implementation type. So, as part of module assembly (Figure 19), each component would need:

• An implementation type, such as human task, process, business rule, etc.
• To be bound to the actual implementation.

In reality, the module gets recreated whenever the model is imported from WebSphere Business Modeler. Therefore you should wire the process component to imports instead. An import is simply a reference to a SCA component implementation that resides somewhere outside the module, as opposed to a SCA component that is implemented in the module itself.

This wiring unfortunately cannot be defined in Modeler. See Making changes to the model for some ideas to make this easier.

Other recommendations

Follow these additional recommendatins when implementing the imported model in WebSphere Integration Developer:

• Do not modify interfaces and business objects in WebSphere Integration Developer. The interfaces and business objects exported from WebSphere Business Modeler are assumed to be reusable interfaces and therefore shouldn’t be changed in WebSphere Integration Developer without consideration for interface versioning. If the actual implementation interfaces and business objects are different to those defined in WebSphere Business Modeler, use Interface and Data maps to map to the actual implementations
• Limit the amount of changes to the BPEL process. The BPEL process should remain, as far as possible, the same as that exported from Modeler. Use custom snippets and invoke activities to other components when you require additional logic.
• Do not modify Event Monitoring settings in a BPEL process. Settings are defined in WebSphere Business Modeler for use in WebSphere Business Monitor and should be left the same.
• Do not change the Valid From date setting. Changes will cause WebSphere Business Monitor to ignore generated events

Back to top

Making changes to the model

Responsibility: Business Analyst

The base assumption with the SOA lifecycle is that all changes to the business process are driven from WebSphere Business Modeler. This is good as it means that all changes to the process are driven directly by business requirements. However, this does have the unfortunate knock-on effect that the BPEL process will need to be ‘re-implemented’ in WebSphere Integration Developer after each change to the process. Practically this means, the steps from the previous section will need repeating for each change.

All is not lost however. This section provides some tips on reducing the number of steps needed to re-deploy the business process to WebSphere Process Server.

Starting each iteration

As there currently isn’t a merge function that can import the deltas from a new model into an existing BPEL process, it is best to recreate the module in WebSphere Integration Developer every time you export the model change from WebSphere Business Modeler.

Java snippets

When you import a model into WebSphere Integration Developer, it is likely that there will be a number of Java snippets in the BPEL process. These are effectively place-holders for performing steps that have no meaning in the modelling stage. The most common example is the map task in WebSphere Business Modeler.

You need to implement the Java snippets in WebSphere Integration Developer as Java, or using the visual editor. For mappings, you could change the activity type to an "assign" and implement it with the visual mapping editor. Unfortunately, you’ll need to do this every time you export the model from WebSphere Business Modeler, because the Java snippets cannot be externalised.

To reduce the amount of re-implementation work, consider one of the following options:

• Implement the Java snippets as Java components in a separate module. Compared with re-implementing a Java snippet, it is trivial to rewire the process to the Java components. This typically won’t make sense for small snippets, but could be quite helpful if the Java snippet work is quite involved
• Use copy and paste! This is the brute-force approach, but a reasonable approach for small snippets. Just store the Java from the snippets in a Java scrapbook page.
• Consider externalising the Java code as a utility service. This is probably the neatest solution if you can externalize a reusable generic function. We’ll discuss this option in the next section.

Prepare a set of utility services in WebSphere Integration Developer

You can reduce re-implementation work by factoring out a number of the common tasks and services that are often needed in the business process. The idea is to create a module in WebSphere Integration Developer with a number of SCA components that provide common services, described by Figure 20.

Consider providing components for the following functionality:

• Mapping: If you commonly require a map between particular variables, you could externalised it as a separate service and invoke it from the process instead of implementing it as a Java snippet or Assign task. The premise is that it’s much easier to rewire the component assembly than re-implement Java snippets each time. You could implement this externalised service in whichever way makes sense, although an interface and data map seems the most logical.
• Tasks not supported by WebSphere Business Modeler: This may be a useful way of leveraging WebSphere Integration Developer functionality which either isn’t supported in WebSphere Business Modeler, or isn’t handled by the transformation. For example, you could build a ‘utility service’ that would perform a ‘wait’ task, which is currently not supported when exporting the model from WebSphere Business Modeler.

Setting up utility services in WebSphere Integration Developer

The following steps provide an outline of how to implement the utility service pattern:

1. Create a module to hold the common services. It can share the same library projects as the process module. It may be helpful to establish a naming convention such as:
   <PROJECT_NAME>>UtilityModule

2. Implement the common services as SCA components in the module in the desired way, for example as Java components, data maps, or additional processes.

3. On the assembly editor of the utility module, provide an export for all the components so that it can be used in our process module. It will probably make sense for these exports to be of type SCA export, because the module will probably be deployed with the main model as opposed to being called via Web services or JMS.

   
   Figure 21: Adding exports to the utility components
   
   

4. The exports appear on the Business Integration project explorer, which makes it easy to drag and drop them onto the process's assembly diagram.

   
   Figure 22: The exports appear in the navigator
   
   

5. Open the assembly diagram of the process module to begin wiring up the utility services. By default the module will have provided a non-typed component for each partner link.

   
   Figure 23: The assembly editor when first importedr
   
   

6. Remove the unneeded components (and the corresponding exports created for them by default).

   
   Figure 24: Without default components and related exports
   
   

7. Drag and drop the exports listed on the utility module onto the process module (one at a time.) The exports from the utility module become imports for the process. For each drag and drop you will be asked if you want to import with the SCA binding. Agree to this.

8. Rename the imports to something meaningful if desired, e.g. <service>Import.

   
   Figure 25: Drag and drop the imports
   
   

9. When you’ve added all the imports to the module, right-click on the process component and select Wire to existing. Integration Developer connects the process component to the appropriate imports.

   
   Figure 26: Wire to existing
   
   

Component wiring in the assembly editor

The SCA component wiring is not retained when the model is re-exported from WebSphere Business Modeler. However, it is not difficult to rewire the component, as WebSphere Integration Developer will do much of this using the ‘Wire to existing’ context menu option. It does this by matching interfaces and types.

Back to top

Conclusion

We started off by asking the question "Can we really implement the SOA development lifecycle with IBM WebSphere?" Although this article exists to make life easier in working to the SOA development lifecycle, it also demonstrates that the power of this development paradigm is available at your fingertips today.

Acknowledgements

• Stuart Foster, IBM WebSphere Technical Sales, Certified IT Specialist, IBM UK. Stuart provided the background and requirement for the work in this document. He also provided assistance with researching the best practices outlined here.
• Raymond Kong, WebSphere Business Modeler Development, IBM Canada. Raymond provided technical assistance and guidance whilst testing a number of transformation scenarios.
• IBM Software Services for WebSphere. A number of the concepts found in this document are brought together from the Intellectual Capital being generated in the Software Services community. Specific thanks to Josh Bock, Joe Pappas, and Michele Chilanti.

Resources

Learn

• Learn more about WebSphere Business Modeler v6.
  
  
• Learn more about WebSphere Integration Developer v6.0.1.
  
  
• Get a Technical Overview of WebSphere Process Server and WebSphere Integration Developer
  
  
• Read an overview of Business integration in developerWorks' New to Business Integration page.
  
  
• Learn more about Service Component Architecture.
  
  
• Visit the WebSphere Integration Developer Info Center for product documentation.
  
  
• Learn more on this topic from the IBM Education Assistant: Modeler to WebSphere Integration Developer.
  
  
• Browse for books on these and other technical topics.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• Download a free trial version of WebSphere Business Modeler Advanced V6.0.1.
  
  
• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Discuss this topic in the WebSphere Integration Developer Forum.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• WebSphere Business Modeler: Starting assumptions
• WebSphere Business Modeler: What to bear in mind whilst modelling
• WebSphere Integration Developer: What will need changing
• Making changes to the model
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Business Modeler Advanced
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Business Modeler Advanced

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers