![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article is the second in a series for developers migrating from WebSphere InterChange Server (hereafter InterChange Server) to WebSphere Process Server (hereafter Process Server). In Part 1, you learned about the BPEL artifacts created when you migrate InterChange Server collaboration templates to Process Server. One InterChange Server collaboration object file (.cwc) translates into a number of service component architecture (SCA) components. This article describes these SCA components and their functions.
Note that a collaboration object specifies the collaboration template that it uses. The SCA components that result from migration differ depending on the collaboration template that is specified. Therefore, you should read about collaboration templates in Part 1 of this series, before reading this article. It's also assumed that you know how to run the migration tools and understand the purpose of the artifacts generated in Process Server Version 6, as covered in the following two articles:
- Migrating WebSphere InterChange Server solutions to WebSphere Process Server V6: A simple migration example -- Part 1
- Migrate WebSphere InterChange Server solutions to WebSphere Process Server V6: Artifacts generated by migration -- Part 2
To view the example repository, refer to Migrate WebSphere InterChange Server solutions to WebSphere Process Server V6, Part 2: Artifacts generated by migration.
In this article, we'll take a closer look at the PIP example from that article, and specifically the CustomerSyncInst module that is created, which has a BPEL associated with it. You can use the WebSphere Integration Developer's assembly editor to view all of the sca artifacts that are created and how they are wired (To view the Assembly Diagram double click on the sca.module file):
Figure 1. WebSphere Integration Developer SCA artifacts in the assembly diagram
Figures 2 and 3 show the Business Integration and Java™ perspectives in Integration Developer after migrating a repository:
Figure 2. PIP example Business Integration view
Figure 3. PIP example Java view
It's easier to see the extensions of the SCA components in the Java perspective, which may help you understand what to expect from migration.
The artifacts covered in this article are specific to the collaboration object's needs. The following sections describe in detail the artifacts that are created to give you a better understanding of why only one collaboration object results in so many new artifacts.
Certain naming conventions were used for the SCA components that were created during migration that are particular to the collaboration object being migrated. These conventions, as well as examples that relate to the PIP example, are presented in Table 1 and described in the following sections:
| SCA artifact | Naming convention | Example |
|---|---|---|
| Export | <trigPortName>.export | Input.export |
| Export to bpel mediation | <trigPortName>_To_<bpelName>.ifm <trigPortName>_To_<bpelName>.component | Input_To_CustomerSync_Input.ifm Input_To_CustomerSync_Input.component |
| Bpel component | <CollabObjectName>_<trigPortName>.component | CustomerSyncInst_Input.component |
| Bpel to Import Mediation | <bpelName>_To_<portName>.ifm .component | CustomerSync_Input_To_Input.ifm CustomerSync_Input_To_Input.component |
| Import | <ConnectorName>_<BOName>BG.import | ClarifyConnector_CustomerBG.import |
| Java Selector (if present) | JavaSelector | JavaSelector.java |
Asynchronous in and correlation sets
Currently, migration supports all collaboration objects that referenced collaboration templates with following specifications:
- One or more triggering ports, no correlation sets and no asynchronous in calls
- Exactly one triggering port, correlation sets and asynchronous in calls
Migration doesn't support the case of one or more triggering ports, correlation sets and asynchronous in calls. In that situation, the resulting artifacts are equivalent to the case where there are one or more triggering ports with no correlation sets and no asynchronous calls. The developer has to manually go in and create the missing SCA components and wire them together appropriately.
In this article, we'll define the default SCA components and wiring first. If there is a discrepancy when correlation sets and asynchronous in calls are present, we'll describe that difference.
An export is created for every triggering port for the collaboration template associated with the collaboration object. The export name is trigPortName.export. Figure 4 shows an export in the assembly editor:
Figure 4. Export in assembly editor
An export is also created for every other port that is defined in the collaboration template that the collaboration object references. If there is no asynchronous in call, no export is created for other non-triggering ports.
In order to send the information from the export to the BPEL, you need an interface map that says exactly how the data is to be transferred. For every interface map, there is a corresponding component file that describes how to write the map. Right-click the .component file associated with an .ifm file, you'll see the interface, reference, and implementation that are used. The implementation defines the .ifm file that a particular .component file is associated with.
Figure 5 shows an interface map in the assembly editor:
Figure 5. Export to BPEL interface map
If you double-click the component or right-click the .ifm file in the Package Explorer view on the right and open it with Interface Mapping editor, you'll see something similar to Figure 6:
Figure 6. Interface map editor
In this example, the export has both Async and Sync port types. These map to the Async and Sync port types on the BPEL.
Note: Currently, having a collaboration template that is triggering and has asynchronous in is not supported. Therefore, it's not necessary to broadcast the information to both the asynchronous input and the execute asynchronous input on the BPEL. This means that the BPEL will only be wired to the asynchronous input or the execute asynchronous input.
If you right-click the .ifm file and open it with a text editor, you can see the xml that makes this mapping happen.
When there is exactly one triggering port and the collaboration template has an asynchronous in call, the SCA components that are created are a little different than the above situation. Now, instead of having just one mediation, the migration results in two mediations: one for synchronous calls, and one for asynchronous calls. A Java component is used to decide which of these two mediations to followl, as shown in Figure 7. The Java component selects based on the operation the information came in on.
Figure 7. Interface map for asyncIn
Double-click the JavaSelector component or open the JavaSelector.java file to see the code that is called to send all of the synchronous information through the Sync interface map and all of the asynchronous information through the Async interface map. If you open either of the maps in the Interface Mapping editor, you'll see something similar to Figure 5. Figure 5 is the Async interface map. It doesn't map the Synchronous calls to anything.
As mentioned in the Exports section, an export is created when there is an asynchronous in call for every other port. Interface map and component files are also needed in this case to map the port's export to the BPEL.
For every triggering port, the export will be wired to an interface map, as described in the previous section, and that interface map will map to an instance of the .bpel file. Figure 8 shows how the BPEL instance looks in the assembly editor:
Figure 8. BPEL in assembly editor
For information on the BPEL itself, refer to Part 1, which covers migration of collaboration templates. Note that all of the BPELs that are created for the triggering ports will refer to the same wsdl file.
- The name of the wsdl file is the name of the collaboration template.
- The name of each of the BPELs is collabTemplateName_trigPortName.bpel.
- The name of the BPEL instances is CollabObjectName_trigPortName.component.
All of the components to the right of the BPEL are independent of asynchronous in operations and any other combination, which means that they'll always be the same. Every port, triggering and non-triggering, has a set of .ifm and .component files. Figure 9 shows the .ifm mapping that connects the BPEL to an import as seen in the assembly diagram.
Figure 9. BPEL to import in assembly editor
See the section on Export to import to understand the .ifm and .component files and what their purposes are. These interface maps map the BPEL to an import file. Therefore, for every BPEL operation, a mapping must be in place to decide how to chart the information with the port type of the import.
Figure 10 shows an example of an interface map that maps the BPEL to an import:
Figure 10. BPEL to import mapping in Interface Mapping editor
The map tells the process how the different operations correlate with one another. For example, all of the asynchronous operations from the BPEL are handled by sending them through the interface map's Async operation. Without this mapping, the process would have no way of knowing which operations are intended for the operations that are waiting for them. For more information on maps and their functionality, refer to the WebSphere Process Server Information Center.
Finally, a .import file is created to tell everyone that the information is now available for use. Figure 11 shows an import in the assembly editor:
Figure 11. Import in assembly editor
The naming convention for the import is <ConnectorName>_<BOName>BG
The .import and .export files don't need a .component file associated with them, as they aprovide the wiring information themselves.
Custom collaboration properties
In InterChange Server, you could generate a collaboration object that was similar to that shown in Figure 12:
Figure 12. Collaboration object defined in InterChange Server
In the New Collaboration Object dialog, you could select the collaboration template to associate with the collaboration object and give it a name, as shown in Figure 13:
Figure 13. InterChange Server New Collaboration Object dialog
In the Properties dialog, you could specify a custom property and assign a value, as shown in Figure 14:
Figure 14. Collaboration properties in Interchange Server
When a custom property was defined in the selected collaboration template, it showed up in this view. You could then specify a value for the property. You could also view custom properties in InterChange Server by right-clicking on the collaboration object and selecting Properties.
We're describing the custom property details here, rather than in Part 1 because if you specify a value in the collaboration object, it will overwrite the value of the custom property in the collaboration template. In this example, suppose that the collaboration template gave the property myProperty a value of world and the collaboration object gave it a value of hello. After migration, the myProperty property will have the hello value.
You can find the new custom property in the BPEL by clicking the Properties tab and clicking Environment on the right, as shown in Figure 15:
Figure 15. Collaboration properties defined in Integration Developer
It may be hard to fathom why one collaboration object results in so many SCA artifacts after migration, but after reading this article, you should have a better understanding of why these SCA artifacts are present and how they function in Process Server. As mentioned in Part 1, the best way to truly understand the resulting migrated artifacts is to migrate as many repository jar files as possible.
-
Migrating WebSphere InterChange Server solutions to WebSphere Process Server V6: A simple migration example -- Part 1 (developerWorks November, 2005): Describes a simple InterChange Server to WebSphere Process Server migration scenario.
-
Migrate WebSphere InterChange Server solutions to WebSphere Process Server V6: Artifacts generated by migration -- Part 2 (developerWorks December, 2005): Describes the source artifact migration capabilities provided in WebSphere Process Server V6 to support migration from WebSphere InterChange Server.
-
WebSphere Process Server and WebSphere Integration Developer Version 6 Information Center: Product documentation, including installation and migration instructions for the server, as well as the tools.
-
WebSphere Business Integration zone: Get the technical resources you need for WebSphere Business Integration products.
-
IBM WebSphere Business Integration: Product information for all of IBM's business integration offerings.
-
New to WebSphere Business Integration: A brief introduction to the WebSphere Business Integration family of products and links to resources available to help you learn more.
Lisa Seacat is a Software Engineer at the IBM Austin Lab in Austin, Texas. She is a part of a team of developers working on migration support in WebSphere Process Server for WebSphere InterChange Server. Specifically, she has been the principal technical developer on the migration of InterChange Server collaboration templates into WebSphere Process Server BPELs and InterChange Server collaboration objects into Process Server SCA components. She received her B.S. degree in Computer Science from Carnegie Mellon University.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
