Building SOA portfolio Business Services, part 2nd

Part 2nd: Migrate business integration projects from WebSphere application Developer-ie v5.1 to WebSphere integration Developer v6.0.1

This article is part of a series that considers developing composite applications. Composite applications integrate existing SOA services and create new services that can be combined in different ways. We initially developed a demo composite application using the WebSphere application Developer IE v5.1, which uses the WebSphere Business integration SF as its runtime (see part 1th of this series). With the release of the WebSphere Process Server V6 and its corresponding development tools, WebSphere Integration Developer V6, a service-based component architecture (services Component A new programming model for ARCHITECTURE,SCA, which requires migrating artifacts from the legacy programming model to the new programming model. Here we share some of the key lessons learned during this migration process.

Introduction

This article describes some of the issues and solutions for migrating a prototype composite application from a WebSphere application Developer-ie v5.1 to a WebSphere integration Developer V6. The main issues we will cover include WSDL bindings, WSDL interfaces, XSD definitions, and Orchestration execution languages (Business Process Execution Language, BPEL) encodings. Although the WebSphere Integration Developer V6 has a powerful Migration wizard, we find that simple projects can be automatically migrated. However, more sophisticated BPEL applications will require a deeper understanding of the migration process. For detailed migration considerations, refer to the WebSphere Integration Developer Help or WebSphere Integration Developer/wps Information Center.

Migration issues for bindings

The first article in this series identifies a number of use cases initiated by a bank customer. The loan application use case invokes a BPEL business process. The business process completes the process of invoking a series of services to handle a loan. Some of the services invoked use Java or EJB bindings.

Java Binding issues

WebSphere Integration Developer V6 does not support the original Java binding type used in the WSDL generated by the WebSphere application Developer-ie. The service/Port definition uses some type of java. As a result, a Java classname is generated in the WSDL instead of an endpoint address. (see Listing 1).

Listing 1. WSDL with Java bindings

<service name= "Loantrackingserviceproxyporttypeservice" >
 

 <port binding= "Tns:loantrackingserviceproxyporttypejavabinding"
 

   Name= "Loantrackingserviceproxyporttypejavaport" >
  

<java:address 

classname= "Loantrackingservice. Loantrackingserviceproxy "/>
  

</port>
</service>

If this type of WSDL is imported directly into the SCA module, the resulting import cannot be successfully bound even if there are no exceptions or errors that are flagged by the WebSphere integration Developer (see Figure 1). In fact, the WebSphere integration Developer V6 only supports Web service imports with soap bindings. As a result, the imported endpoint is left blank, causing a Run-time exception when the module is deployed to WPS and when we try to call it.

Figure 1. WSDL Import with Java bindings