Integrate Java and. NET technologies in business processes

Note: You should be familiar with the WebSphere Studio application Developer integration Edition Version 5.1.1 Web Service development environment, ASP. NET Web Services, and understanding of building BPEL processes of knowledge. This article also contains sample code for the BPEL business process.

Introduction

Because XML and WEB services need to use BPEL, it quickly becomes the foundation for service-oriented architecture (SOA), and BPEL also provides WebSphere application Server Enterprise Process choreographer (Pro Open standards for cess choreographer). Over the years, many enterprise applications have been developed and deployed independently and in parallel on the Java EE and. NET platforms. These business applications are designed with fine-grained business functions. For example, in Java EE, use entity beans to implement information persistence and use session beans to implement business logic. These business applications also provide an integrated framework for the integration of back-end or legacy enterprise applications in limited business domains. For example, the Java Connector Architecture (JCA) and Java Messaging Service (JMS) are typical application integration frameworks for EE.

With the advent of WEB services, back-end enterprise applications are exposed as business services that can be discovered and callable by using WSDL. WSDL defines the service semantics for the Web service interface, such as operations, protocol bindings, and message types. The BPEL layer, above WSDL, specifies the behavior of the composite WEB service that participates in the flow of the process. Therefore, it enables business analysts and architects to define the logic of the business process flow and can use BPEL to support long-running sessions with the Java EE Web service and the. NET Web Service.

In fact, the success of a BPEL process flow depends largely on the XML service semantics defined in each WEB service's WSDL document. XML schemas differentiate XML from other file formats, which are XML Schema definitions and are comprehensive and complex data type definition systems. Simply put, XSD defines the shape of an XML document. Using XSD to design simple and strongly typed (strongly-typed) objects is the foundation of WEB Service interoperability. "Improving the interoperability between Java and. NET" (part 1th of this series) points out that many Web service programmers ignore the importance of XSD schema design. In other words, they use their favorite programming language to write code for a Web service implementation, and then use the vendor's tools to derive Web service semantics from the implementation. This bottom-up approach creates problems with interoperability.

Interoperability issues between. NET and Java EE often originate from XML namespaces and complex data types, such as arrays of nested complex types and dates and times (parts 2nd and 3rd of this series). The techniques described in this article will show how to safely and correctly pass nested arrays, complex types, and dates among two platforms in BPEL process integration. But this requires you to carefully design the XSD schema for these complex types.

Start to prepare

To build the process, you need to install IBM WebSphere Studio application Developer V5.1.1 and Microsoft. NET framwork 1.1 in Windows. For this article, both of these products are installed and running on the same machine.. NET Visual Studio is an integration tool for building. NET Web services that is not used in this technique.

The document root directory for IIS is C:\Inetpub\wwwroot by default. I will use this directory to publish. NET Web Services. Also, the. NET Framework 1.1 is installed in the C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 directory, and the SDK is C:\Program files\microsoft.net\sdk\ The v1.1 directory.

Add the following directory to the system PATH variable:

c:\Windows\Microsoft.NET\Framework\v1.1.4322

C:\Program Files\microsoft.net\sdk\v1.1\bin

Sample code for the BPEL business process is in the downloads section.

Typical interoperability Business scenarios

Imagine a purchase scenario where the purchaser performs an order request through a cargo agent. Cargo agents have a number of suppliers to provide sourcing, each participant is an independent subscriber and has its own product inventory management system. That is, a vendor might run the Java EE Web Service to manage its inventory and other vendors might use the. NET Web service for the same operation.

The purchase process begins with a request for a product quote from a different vendor. Before the buyer submits the order, the agent contacts each vendor to obtain a quotation for the corresponding product, and each vendor returns the details of the product. The purchaser then browses the information and continues with the next order process. Figure 1 shows the flowchart of the two vendor (Supplier A and Supplier B) quote request. The purchaser requests the agent to provide the quotation, the agent passes the request to the supplier, and then returns the information provided by the supplier to the purchaser.

Figure 1. Flowchart of Quotation Request

In the diagram:

Buyer is the client who made the purchase request.

An Agent is a business process that requests a vendor to provide product information and process a purchaser's order.

Supplier A is a Java Web service that manages vendor A's inventory.

Supplier b is a. NET Web service that manages the inventory of Vendor B.

For purchase requests made by the purchaser, the agent process will first construct the product quotation request for each supplier. Each supplier responds and provides product information, including price, quantity and other product information. The agent then returns the product information to the purchaser for browsing and ordering.

In the following sections, we will build the agent process, build a Java Web service for Supplier A, and build a. NET Web service for Supplier B.