BizTalk

Digg This!

Page 1 of 3   next page »

If you need to integrate Microsoft BizTalk Server (BTS) 2004 with other applications and data sources, you're going to need some kind of adapter. BTS 2004 ships with a few, including the file adapter and the Web services adapter. Other adaptors, especially ones used to integrate BTS with popular enterprise software, are available from third-party vendors. However, if you need a JMS (Java Messaging Service) adapter, or one that supports J2EE facilities such as JNDI (Java Naming and Directory Interface), JAAS (Java Authentication and Authorization Service), and EJBs (Enterprise Java Beans), you're probably going to have to build one. This article shows you how to construct a custom adapter that allows BTS to integrate with JMS. You can also use these techniques to construct other kinds of adapters, including ones for Java APIs that come with custom applications, or simply call Java libraries from BizTalk Server orchestrations.

The example in this article shows how to create a JMS adapter for BizTalk Server using JNBridgePro, a Java/.NET interoperability tool. We'll start with a discussion of adapter architecture, run through an example orchestration, build the adapter, then deploy and run it. The creation and deployment of adapters can seem like an involved process, but once you get past the details inherent in the creation of any BizTalk Server adapter, creating an adapter that bridges between BizTalk Server and J2EE is quite straightforward.

Background
This article assumes you have passing familiarity with both BizTalk Server and JMS. It will also help if you have some knowledge of how BTS adapters are used, but you don't need a deep knowledge of how they're constructed because the necessary information will be presented below.

The BTS orchestration used in this example comes from the first orchestration example in the excellent book Microsoft BizTalk Server 2004 Unleashed (Sams, 2005), by Scott Woodgate, Stephen Mohr, and Brian Loesgen. I recommend reading the example in the book and performing the actions to create the orchestration, but I'm supplying the code for those who are not inclined to do so.

Required Software
If you want to follow the instructions in this article and use the associated sample code, you'll need to install the following software:

• A working development copy of Microsoft BizTalk Server 2004 or 2006, including Visual Studio .NET 2003 or 2005 with the appropriate extensions.
• BizTalk Server 2004 SDK Refresh, which can be downloaded at www.microsoft.com/downloads/details.aspx? FamilyID=8A1CA3AF-790C-4261-838A-9F0661C72887&displaylang=en .
• BizTalk Server 2004 Adapter Wizard, which can be downloaded at www.gotdotnet.com/Community/UserSamples/Details.aspx? SampleGuid=c95217fc-4f9f-4fec-9d68-1aa9456b6ca0.
• J2SE SDK (J2SDK), version 1.3.1 or later.
• JNBridgePro, which can be downloaded from www.jnbridge.com. It comes with a 30-day free, full-featured evaluation.
• A J2EE application server or special-purpose JMS messaging server. This example uses BEA's WebLogic 8.1 application server, although it's easy to adapt this example to any other application server or JMS server.
• Download and unpack the sample code, www.jnbridge.com/biztalk/JMSAdapterSample.zip. There are three folders: jmsAdapter, MyFirstIntegration, and Java clients. You may place these folders anywhere on your machine.

Adapter Architecture
Figure 1 shows the architecture of the adapter. BizTalk Server interacts with the adapter via adapter framework code. The adapter framework code calls .NET-side proxy classes, which are proxies of the JMS classes in this example. We're using the JNBridgePro proxy generation tool to create a .NET-side proxy class that has an equivalent signature to the corresponding Java class. From there control flows through the .NET-side runtime components, across a remoting connection, and eventually to the appropriate Java-based JMS client class, which functions as an ordinary JMS client that communicates with the server via RMI or other chosen protocol.

Figure 2 shows how JNBridgePro supports calls from .NET to Java. For each Java class, the JNBridgePro proxy generation tool generates a .NET-side proxy class with an equivalent signature. The proxies are then used in the resultant application, where the .NET code calls a Java class by calling the equivalent proxy class. The proxy class directs the call through the JNBridgePro .NET-side runtime component, which performs marshalling and serialization. The serialized request is then sent across a remoting connection, where it is received by the Java-side runtime component, which unmarshals and deserializes the request and dispatches it to the proper object. Return values and thrown exceptions come back in the opposite direction by the same pathway. The .NET-side code runs inside a .NET CLR (Common Language Runtime), and the Java-side code runs inside a JVM (Java Virtual Machine).

Our adapter architecture example has the .NET and Java sides operating inside the same process and communicating via a shared-memory channel. The remoting infrastructure used in JNBridgePro also supports other communication channels, including TCP/binary and HTTP/SOAP. Therefore, it is equally possible to set up the adapter so that the .NET and Java sides operate in different processes or on different machines and communicate through a socket-based mechanism.

Example Orchestration
The example orchestration (Figure 3) is taken from Microsoft BizTalk Server 2004 Unleashed. It represents a simple human resources orchestration in which XML-based employee records are taken from one HR application. A test is performed on the value of the employee's grade. If it's 6 or below (ordinary employee), the record is forwarded to another HR application. If it's 7 or above (executive), the record is transformed to a different format and sent to a third HR application, and then the original version of the record is forwarded to the same (second) HR application as the records of other employees.

As described in Woodgate's book, the orchestration is set up so that the employee records are files, and the orchestration's send and receive ports that connect it to the other applications are really folders. Once we get the JMS adapter built and installed, we will connect the orchestration to an instance of the adapter at each of the send and receive ports. Each instance of the adapter will connect to a message queue on a particular JMS server (see Figure 4).

Building and Deploying the Adapter from the Sample Code
Using Visual Studio .NET, open the jmsAdapter solution file located in the jmsAdapter folder. You should be able to build the project without error.

To deploy the adapter, first edit the file jmsAdapter.reg. In particular, edit the lines for OutboundAssemblyPath, InboundAssemblyPath, and AdapterMgmtAssemblyPath so that these paths are valid for your machine. Then, launch jmsAdapter.reg by double-clicking on the icon. This will install the relevant entries in the registry. Then launch the BizTalk Server Administration tool, navigate to the Adapters folder, right-click on it, and select New Adapter. Name the adapter JMS and select JMS from the pulldown.

Next, edit the file jnbproxy.config that can be found in the jmsAdapter folder. This file configures the communications mechanism that governs the bridging between the .NET and Java sides of the adapter. We will be using the shared-memory mechanism. Edit the paths for the jvm, jnbcore, bcel, and classpath items so that they are valid for your machine. (If you are using JNBridgePro v3.0 with BizTalk Server 2004, edit the "Version" attribute of the shared-memory channel to read "2.3.0.0" - it is originally "2.2.0.0"; if you are using BizTalk Server 2006 and .NET Framework 2.0, set the "Version" attribute to "3.0.0.0.") Save jnbproxy.config and copy it to the root folder of the drive on which your system is installed (typically, but not always, C:\).

Finish deploying the adapter by installing the files jmsProxies.dll (from the jmsAdapter folder), jnbshare.dll, and jnbsharedmem.dll (both from the JNBridgePro installation folder) in the Global Assembly Cache (GAC). The simplest way to do this is to copy them into the C:\Windows\Assembly folder, although you can also do this using the gacutil.exe program that comes with the .NET SDK.

The Proxy Classes
Note that it is not necessary for you to generate the proxy classes for this example, since they have already been generated. However, if you want to generate them, or simply want to know how it's done, the information is below.

To create the JMS proxy classes, launch the GUI-based JNBridgePro proxy generation tool. Add C:\bea\weblogic81\server\lib\wljmsclient.jar (the actual path may be different on your machine. Generate load the proxies for the following classes and all supporting classes:

• java.util.Hashtable
• javax.naming.Context
• javax.naming.InitialContext
• javax.jms.QueueConnectionFactory
• javax.jms.QueueConnection
• javax.jms.QueueSession
• javax.jms.Session
• javax.jms.Queue
• javax.jms.QueueReceiver
• javax.jms.QueueSender
• javax.jms.TextMessage

These are the classes that will be accessed from the Java code.

Page 1 of 3   next page »