The proxy assembly needs to be placed in the GAC, so you will need to sign it. Before generating the proxy assembly, create a strong name key (or use the MyFirstIntegration.snk strong name key that is supplied with the sample code), and use the Strong Naming menu item in the proxy generation tool to indicate that the assembly will be signed with the indicated strong name key. Also assign a version number to the assembly.

When this is completed, generate proxies for all the classes using the Build menu item in the proxy generation tool.

The Adapter Code
It's worthwhile to examine the code for the JMS adapter. There are three projects: JMSReceiveAdapter (representing the portion of the adapter that receives data from JMS), JMSTransmitAdapter (representing the portion of the adapter that sends data to JMS), and CommonJMSAccess (which contains functionality common to both the receive adapter and the send adapter).

The JMSReceiveAdapter and JMSTransmitAdapter projects were automatically generated by the BizTalk Server adapter wizard. We made modifications to the automatically generated code in the following places:

• JMSReceiveAdapter.JMSReceiverEndpoint.GetRequestMessagesAndSubmit() now contains code to call the JMS client classes and then to submit the received message to BizTalk Server.
• JMSTransmitAdapter.JMSAdapterWorkItem.SendJMSRequest() now contains code to receive the message from BizTalk Server and sent it to the JMS client classes.

CommonJMSAccess contains the portion of the code that actually does the .NET/Java bridging. The project references jmsProxies.dll, which contains .NET proxies for the Java-based JMS client classes. By calling these proxy classes, JNBridgePro bridges the calls across to the Java-based JMS classes. The actual calls to the proxy classes are in the class CommonJMSAccess.JMSSendRecv. Note that we have cached the result of each proxy call so that one does not have to be made each time we attempt to send or receive a message.

Also note that a number of parameters have been hardwired into the code in CommonJMSAccess. In a generally applicable JMS adapter, these values should be specified as adapter properties that can be changed at runtime. In this case, if you are using an application server other than WebLogic Server, or if you are using WebLogic Server with nondefault parameters, you will need to change these values appropriately and rebuild the adapter. The values that need to be changed are:

• In CommonJMSAccess.JMSReceiver, the receive timeout value in receive(). It's currently set to 500ms.
• In both CommonJMSAccess.JMSReceiver and CommonJMS-Access.JMSSender, the format of URI, the URI used by the JMS client classes to contact the JMS server classes. WebLogic uses a protocol called "t3." If you are using a different application server, you may need to use rmi, iiop, or some other protocol.
• In CommonJMSAccess.JMSSendRecv, the JNDI names of the initial context factory and the queue connection factory. Each vendor's application server provides different names for these factories.

Building and Deploying the Adapter Using the Adapter Wizard
The adapter code that we supply was created using the BizTalk Server Adapter Wizard. You can re-create the code using the same wizard, although it is not necessary to do so to make the example work. It's beyond the scope of this article to go into detail on how to use the adapter wizard. Please see the extensive documentation provided with the wizard.

To create an adapter using the adapter wizard, create a new project in Visual Studio .NET 2003 and, under BizTalk Server Projects, select BizTalk Server Adapter Project. Make sure the following options are selected:

• The adapter should be able to both send and receive messages.
• The receive adapter should be a regular (in-process) adapter and should not support request-response.
• The receive adapter should have the following endpoint properties: QueueName (a string), JMSHostName (a string), and JMSPortNr (an integer).
• The transmit adapter should support the alias jms://. It should not have batch support, and it should not support solicit-response.
• The transmit adapter should have the following endpoint properties: QueueName (a string), JMSHostName (a string), and JMSPortNr (an integer).

The wizard will create a code skeleton with the appropriate properties. Add the CommonJMSAccess project and modify the code in the JMSReceiveAdapter and JMSTransmitAdapter projects as described in the previous section.

Trying Out the Adapter
Now that the adapter has been built and deployed, it's time to set up the example and run the orchestration.

Set Up WebLogic Server
Note that this example assumes the use of WebLogic, but it is easy to perform the equivalent actions to set up your favorite J2EE application server to work with the example.

Start up the WebLogic Server. Assuming that you've installed the WebLogic Server examples along with the server itself, the simplest way to do this is to launch it from the Start menu: Start->All Programs->BEA WebLogic Platform 8.1->Examples->WebLogic Server Examples->Launch WebLogic Server Examples. Once it has started and the Examples index page comes up, click on the Administration console link to bring up the Administration console. Log in with the administrator user ID and password you have specified. Using the tree view on the left side of the Administration console, navigate to Examples->Services->JMS->Servers ->examplesJMSServer->Destinations. Click on Configure a new JMS Queue and enter the queue name and the JNDI name as queue1, leaving all the other default settings the same. Repeat the process to create queue2 and queue3. You may log out of the administration console, but leave WebLogic running.

Build and Deploy the Orchestration
To build and deploy the orchestration, you can either build the orchestration from scratch by following the instructions starting on page 53 of Microsoft BizTalk Server 2004 Unleashed ("Your First Integration Project"), or just deploy the orchestration from the sample code as described below by opening the solution file MyFirstIntegration.sln found in the MyFirstIntegration folder.

After building the orchestration, deploy it selecting the Build->Deploy menu item in Visual Studio .NET, or use the BizTalk Deployment Wizard.

Configure the Adapter and Bind It to the Orchestration
If you are using the supplied orchestration, everything is configured. If you are creating the orchestration from scratch, create the following send and receive ports in the BizTalk Server Explorer:

• Send port jmsToExecQueue: Create a static one-way port. Set Transport Type to JMS, and set Address (URI) to jms://queue2/localhost/7001 (or explicitly set JMSHostName to localhost, QueueName to queue2, and JMSPortNr to 7001). Set the Send Pipeline to Microsoft.BizTalk.DefaultPipelines.XMLTransmit.
• Send port jmsToHRQueue: Create a static one-way port. Set Transport Type to JMS, and set Address (URI) to jms://queue3/localhost/7001 (or explicitly set JMSHostName to localhost, QueueName to queue3, and JMSPortNr to 7001). Set the Send Pipeline to Microsoft.BizTalk.DefaultPipelines.XMLTransmit.
• Receive port jmsFromInputQueue: Create a one-way port. Inside this port, add a new receive location locJmsFromInputQueue. Set the Transport Type to JMS, and set the Address (URI) to jms://queue1/localhost/7001 (or explicitly set JMSHostName to localhost, QueueName to queue1, and JMSPortNr to 7001). Set the Receive Handler to BizTalkServerApplication, and set the Receive Pipeline to Microsoft.BizTalk.DefaultPipelines.XMLReceive.

Now, bind the ports to the orchestration as follows:

• Under Orchestrations in the BizTalk Server Explorer, right click on MyFirstOrchestration and select Bind
• Bind RecvEmpPort to jmsFromInputQueue
• Bind SendExecPort to jmsToExecQueue
• Bind SendEmpPort to jmsToHRQueue
• Set the BizTalk Host to BizTalkServerApplication
• Click on the OK button

Enlist and start the orchestration.