Scenario overview

Our scenario describes the evolution of two separate company policy systems to a consolidated acquisitions and mergers (eMerge) policy system that handles the request and acceptance of car insurance quotes. The scenario is based on the merger of two fictitious insurance companies.

• Lord General Insurance (LGI), a general insurance company, is a large enterprise with more than five-million policy holders, looking to boost its auto insurance business and requiring a quick entry to the e-business direct insurance market. LGI has a large legacy IT infrastructure based on IBM® S/390® and IBM CICS® systems.
• DirectCar.com (DC) is a modern dot-com auto insurance company that sells insurance through the Internet and has fewer than one-million policy holders. It has an e-business-focused infrastructure based on WebSphere Application Server and Oracle databases.

The scenario focuses on the merger and has the following requirements:

• Improve the company's profitability by reducing overall administration costs, with an immediate focus on claims administration for existing products.
• Create an automated claims system for the joint customer base that connects the existing external services.
• Satisfy service-level agreements as defined in customer requirements (performance and security guidelines, for example).

Part 3 in the series describes the design approach for an extension to the consolidated claims system that automates an existing manual activity in an auto insurance claims process. This article describes how to integrate a WebSphere MQ Simple Object Access Protocol (SOAP) and Java Message Service (JMS)-based external claims assessor into the LGI assessor automation scenario to achieve part of the scenario's automation.

The two companies consolidated their individual claims systems into one automated claims handling system. A subset of the claims handling system is the automated external assessor solution, as detailed in Part 3.

Real-world insurance assessors visit damaged cars to assess claims being submitted. The insurance company selects the assessors automatically and seeks their availability. When an individual assessor has been selected, they are given the job. The assessor then performs the assessment of the vehicle, entering the findings into a handheld computer or laptop. At the end of each day, the assessor logs on to a network and uploads these reports in batches.

In this scenario, assessors are automated. Fictitious reports are generated and immediately passed to a report handler that collects all the reports and returns them in batches. Similarly, decisions made by the assessors are returned instantly.

The basic assessor automation process is:

1. Potential assessors are identified by querying the assessor management system.
2. Identified assessors are polled to ask for their availability to perform the assessment (by a Web service request).
3. The assessor management system selection rules are used to select the assessor to perform the assessment.
4. The preferred assessor is requested to perform the assessment.
5. The assessment is completed and the assessment report filed, completing the automated assessment subprocess.

The process flow is shown, and numbered, in Figure 1. Throughout this article, Flow 2 is used as an example. Flow 4 is essentially the same as Flow 2 and to avoid duplication, is not examined further. The return call by the assessor following a Flow 2 (Flow 4) is referred to as Flow 2a (Flow4a).

Most of the process shown in Figure 1 is internal to the newly merged LGI assessor automation system. The external assessors are involved in steps 2, 4, and 5.

The products used in this system are:

• IBM WebSphere Business Integration Message Broker (Message Broker)
• IBM WebSphere Business Integration Server Foundation (WebSphere Process Choreographer component)
• IBM WebSphere MQ Workflow
• IBM WebSphere MQ

Assessors communicate using Web services. Web services send messages using the SOAP protocol. These messages can be carried over many different media, such as HTTP or JMS. In this scenario, the primary medium is JMS, provided by WebSphere MQ. WebSphere MQ now supports SOAP directly with the introduction of the WebSphere MQ Transport for SOAP. See Fundamental concepts for more detail.

Back to top

Fundamental concepts

This section delves further into the solution and explains fundamental concepts. We cover Web services and its technologies. We also briefly introduce WebSphere MQ and discuss the interactions of the WebSphere MQ assessor.

Web services

Web services can entail the following:

Web service

A procedure exposed to be called remotely by a SOAP message (The client and server can, in theory, be on any operating system or platform.) In general, there are two parts to a Web service.

• The requester, or client, which issues a request to a server
• The server (This can be an external Web server such as WebSphere Application Server, but it need not be. Bespoke service code running on the server executes the requested procedure on behalf of the client and typically sends a reply to the client.)

The Web request has two parts:

• The Uniform Resource Identifier (URI) of a service
• A stream of data that the remote server processes and responds to (This is often a SOAP or other Web service request and response in XML.)

SOAP

A lightweight protocol for the exchange of structured information in a decentralized, distributed environment.

Based on XML, this protocol is made up of three parts:

• An envelope that defines a framework for describing what a message is composed of and how to process it
• A set of encoding rules for expressing instances of application-defined data types
• A convention for representing remote procedure calls and responses

WebSphere MQ Transport for SOAP

A SupportPac (MA0R) is available for WebSphere MQ V5.3 that enables SOAP functions for WebSphere MQ. In WebSphere MQ V6.0, this SupportPac is improved and incorporated into the product. It allows Java classes to expose their methods to clients using SOAP/JMS. It also enables stand-alone Java applications to call other SOAP/JMS services more easily and uses the Apache Axis classes. It is possible to create the proxies using Axis alone, but the new SOAP functions of WebSphere MQ modify the generated code automatically to send the SOAP envelope over JMS, and not HTTP, as is the default.

WebSphere MQ Transport for SOAP lets you send SOAP-formatted messages, used in conjunction with Web services, over WebSphere MQ. It is implemented for either Apache Axis or Microsoft® .NET host environments. Apache Axis is available on UNIX® or Windows® platforms, and .NET on Windows only. WebSphere MQ Transport for SOAP allows interoperation with WebSphere Application Server and IBM CICS® systems.

A traditional way of offering Web services over JMS is to use an application server, such as WebSphere Application Server 6.0. However, this is an enterprise product aimed at large businesses and requires high-powered hardware. WebSphere MQ Transport for SOAP offers a more lightweight solution and is ideally suited to work in conjunction with a company's existing WebSphere MQ infrastructure.

Apache Axis

You can create interoperable, distributed Web service applications using Apache Axis. This is an open source Java and XML-based Web service framework. It includes a SOAP implementation, and utilities and application programming interfaces for generating and deploying Web service applications.

WebSphere MQ: a good choice of transport

WebSphere MQ V6.0 incorporates SOAP functions and makes an ideal transport for adding reliability and traceability to SOAP interactions between Web services, especially as part of a service-oriented architecture (SOA). WebSphere MQ is a more reliable transport than HTTP, the traditional protocol of Web services, and should be used where assured delivery is critical or when synchronicity is not required. Legacy and batch applications that are Web services-enabled can benefit from using WebSphere MQ in its asynchronous mode as a buffering mechanism to regulate the flow of requests made to these systems.

WebSphere MQ V6.0 incorporates the SOAP functions previously available only as an unsupported SupportPac. Since Version 5.3, it has included JMS support and is now fully capable of providing SOAP/JMS functions to a Java command-line application or .NET service.

Interactions of the WebSphere MQ assessor

At the center of the assessor automation solution is WebSphere Business Integration Server Foundation (Server Foundation). The business process choreographer component of this server is used as a workflow management server. Message Broker is used by Process Choreographer for transformation, aggregation, and routing. The assessor is never directly accessed by Server Foundation, but through a message broker (WebSphere Business Integration Message Broker, in this case).

An assessor's availability method is called by the message broker and immediately returns a simple receipt. Following this, the assessor initiates a call to the message broker's return method with the actual availability information. The message broker returns a receipt. These two synchronous calls combine to imitate one asynchronous call.

In this case, we didn't use a single asynchronous call because when the assessor automation system was created, not all of the middleware supported asynchronous Web services. This simple model is repeated for the message broker's request to perform an assessment (Flow 2 and Flow 4 in Figure 1). In the case of Flow 4, when the system requests an assessment as well as making the return call, the assessor also sends a simple message to the report handler (Flow 5), triggering it to create a report and send it to the assessor system.

To better emulate the behavior of asynchronous Web services, threading is used to remove the need for the return call-back to the message broker to be completed before the receipt is returned. There are three java.lang.Runnable classes, one for each call the assessor makes. The first is for Flow 2a; the second for Flow 4a; and the third for Flow 5 in Figure 1.

When one of the assessor's methods is called, it creates an instance of the required thread and starts it. The method then creates the receipt object and returns it. Meanwhile, the client thread calls the broker's return method. As these two tasks run as two separate threads, the Java Virtual Machine (JVM) runs them both concurrently, and the completion of one is independent of the other.

Back to top

Creating the solution

In this section, you configure WebSphere MQ to use SOAP and you write Java code to call and create a SOAP/JMS Web service. Specifically, you learn how to:

• Set up WebSphere MQ Transport for SOAP
• Generate Java proxies to the broker's Web services
• Develop the assessor class
• Generate the WebSphere MQ Web service

Set up WebSphere MQ Transport for SOAP

To create the WebSphere MQ assessor, you need to set up and configure WebSphere MQ. Select Java Messaging and SOAP Transport at install time (from the custom install), or add it later by rerunning the installation procedure. This installs the necessary files, but there are still a few steps you need to complete and additional prerequisites before you can create services.

WebSphere MQ Transport for SOAP has the following prerequisites:

• IBM Java 2 Platform SDK and Runtime Environment, V1.4.2
• Apache Axis V1.1
• On Windows: Microsoft .NET Framework redistributable V1.1 with Service Pack 1
• On Windows 2000 only: Microsoft Internet Information Services (IIS)

The IBM Java SDK and Runtime Environment are included in the WebSphere MQ installation media. They are not installed automatically and must be installed from the CD. The setup program is in the prereqs/JDK/ directory. To ensure the tools work with no modification, the JDK's bin directory (for example, C:\Program Files\IBM\Java142\bin) must be added to the system PATH. See the appropriate operating instructions for how to complete this.

It is best to use this exact JVM, since running with alternative versions may cause problems.

The recommended version of Apache Axis is included on the installation media, but is not installed automatically. Copy it from its location on the CD (prereqs/axis/axis.jar) to %install_root%/java/lib/soap (C:/Program Files/IBM/WebSphere MQ/java/lib/soap on Windows, for example).

The Microsoft .NET Framework can be downloaded from Microsoft .NET Framework Version 1.1 Redistributable Package

It is easier to install IIS before installing the .NET framework. On Windows 2000, Microsoft's IIS must be installed at some point before attempting a service deployment. It is not required that it remain installed if no .NET services are to be deployed. If the .NET Framework was installed first, IIS must be registered with it using aspnet_regiis.exe . (See the Transport for SOAP, WebSphere MQ manual for more details.) It is a good idea to do a Windows Update after installing IIS to ensure the safety of your machine. Because IIS is not to be used directly, it can be stopped and set to DISABLED in the services menu.

Finally, the environment variable WMQSOAP_HOME must be set to the installation directory of WebSphere MQ. For example, on Windows this is C:\Program Files\IBM\WebSphere MQ. See the appropriate operating system instructions for how to complete this, and be sure that the variable persists over system restarts. For example, on UNIX place the variable in the .profile.

To ensure that everything has been completed correctly, run amqwsetcp, which sets the classpath for amqwdeployWMQService, the main deployment command, and verifies the existence of the needed files.

You should create a queue manager before you try to deploy any services. To make deployment simpler, this queue manager should be set to default. When deploying a service you must have a SYSTEM.SOAP.RESPONSE.QUEUE queue on the queue manager if a reply queue is not explicitly set or the URI set at runtime. As a system queue, this may not be shown by WebSphere MQ Explorer, depending on the viewing options.

Generate Java proxies to the broker's Web services

At this point, you need to generate Java proxies to make the Web service calls back to the broker. This must be completed now, so that they can be invoked when writing the main class later.

The amqwdeployWMQService command supplied with WebSphere MQ V6.0 is only a sample and as such is not designed for our goals. However, the command can be manipulated to better serve our purposes.

To create the first proxy, for Flow 2a in Figure 1, you need the Web Services Description Language (WSDL) file, which almost certainly refers to WebSphere MQ objects by Java Naming and Directory Interface (JNDI) names. These names must be changed to use WebSphere MQ V6 nojndi class. The nojndi class is used as the initial context factory and creates Java objects representing WebSphere MQ objects from given names, rather than retrieving the object from a directory using JNDI names. This helps to reduce the complexity of the assessor.

The location attribute of the wsdlsoap:address tag should have the format shown in Listing 1.
Listing 1. The location attribute of the wsdlsoap:address tag

jms:/queue?initialContextFactory=com.ibm.mq.jms.Nojndi&connectionFactory=()&
destination=REQUESTQUEUENAME&targetService=TARGETSERVICE&replyDestination=
REPLYQUEUENAME

In the example WSDL, the line shown in Listing 2 must be replaced with that shown in Listing 3.
Listing 2. Replacing this line

<wsdlsoap:address location="jms:/queue?destination=jms/
assessorAvailabilityResponseQueue&amp;connectionFactory=jms/
assessorAvailabilityQCF&amp;targetService=responseAssessorAvailabilityPort&amp;timeToLive=
0&amp;wsif.syncrequest.timeout=120000"/>

<wsdlsoap:address location="jms:/queue?initialContextFactory=com.ibm.mq.jms.
Nojndi&amp;connectionFactory=()&amp;destination=LGI.FLOW2A.REQUEST&amp;targetService=
responseAssessorAvailabilityPort&amp;replyDestination=FLOW2AREPLY"/>

amqwdeployWMQService has a mandatory parameter, -f, which is the filename of the Java source file that is to be used to create a service. This parameter is required even when you are only generating a proxy for an existing Web service and there is no Java source file. There is no way to pass the name of the WSDL file we have for our service. However, the file name passed with -f doesn't have to actually exist, but it does affect the name of the WSDL file looked for. Where name.class is passed with -f, the WSDL looked for is generated/name_Wmq.wsdl. By renaming the WSDL and placing it in a directory called "generated" and then passing the appropriate values to amqwdeployWMQService, the command can be used for our purposes.

amqwdeployWMQService should be called using amqwdeployWMQService –f FILENAME.java –c genProxiestoAxis where FILENAME is the name of a nonexistent file. The WSDL file for the service to be called is named FILENAME_Wmq.wsdl and exists in a directory called generated. For example, Flow 2a's WSDL is called Flow2a.wsdl, so it is renamed to Flow2a_Wmq.wsdl and moved into a directory called generated. The command is called (from within the directory containing generated) using amqwdeployWMQService -f Flow2a.java -c genProxiestoAxis.

At this point, be sure you've completed the steps in Set up WebSphere MQ Transport for SOAP and run amqwsetcp in your current command prompt window to correctly set up all environment variables.

If everything works correctly, nothing is outputted to the command prompt, and the program returns control. Two directories are created in generated: server and client. In this instance, only a proxy is generated and the server directory is empty. Client contains a .cs and a .vb file that are Visual C# and Visual Basic files, respectively. (These are not covered in this article and can be deleted.) The client directory also contains another directory called remote, which contains the generated client code. The client code is then in a directory named the same as the target namespace from the WSDL. Using our example, Flow2a.wsdl in the DefaultNamespace directory has the following files:

RequestAck.java

A Java class representing the RequestAck complex type returned by Flow2a

AssessorAvailability.java

The Service Definition Interface (SDI) is the interface derived from a WSDL's portType (This is the interface you use to access the operations on the service.)

ResponseAssessorAvailabilityPortSoapBindingStub.java

A stub class implementing the SDI (Its name is the binding name with the suffix "Stub." It contains the code that turns the method invocations into SOAP calls using the Axis Service and Call objects. It stands in as a proxy for the remote service, letting you call it exactly as if it were a local object. In other words, you don't need to deal with the endpoint URL, namespace, or parameter arrays that are involved in dynamic invocation with the Service and Call objects. The stub hides all that work for you.

AssessorAvailabilityService.java and AssessorAvailabilityServiceLocator.java

Normally, a client program does not instantiate a stub directly; instead it instantiates a service locator and calls a get method that returns a stub. This locator is derived from the service clause in the WSDL. WSDL2Java generates two objects from a service clause -- the service interface and the locator that implements this interface.

For a client generated using the WebSphere MQ Transport for SOAP to work, the amqwclientconfig command must be executed to generate the client bindings.

Developing the threads to use the generated proxies

Calling a Web service using the Apache Axis framework always follows the same pattern. The basic method of calling the Flow 2a example is shown in Listing 4.
Listing 4. Basic method of calling the Flow 2a example

AssessorAvailabilityServiceLocator locator = new AssessorAvailabilityServiceLocator();
AssessorAvailability assessorAvailability = locator.getresponseAssessorAvailabilityPort();
RequestAck ack = assessorAvailability.assessorAvailability(claimID, assessor, reqDate, cost);

It is quite likely that the queue names and queue manager names may vary when the application is moved from, for example, a test environment into a production environment. To set the URI at runtime, line 2 is replaced with:

AssessorAvailability assessorAvailability = 
locator.getresponseAssessorAvailabilityPort(new java.net.URL(uri));

jms:/queue?name=value&name=value... 

See Listing 5 for the example for Flow 2a.

jms:/queue?initialContextFactory=com.ibm.mq.jms.Nojndi&connectionFactory=()&

destination=LGI.FLOW2A.REQUEST&targetService=requestAssessorAvailabilityPort&replyDestination=FLOW2AREPLY

Note: When passing the URI as a parameter in Java, ampersands (&) must be used, but when used in a WSDL, the & code must be used.

This URI can be passed into your application from the command prompt or read from a properties file, as required. For more information about the manual setting of this URI, see "Specifying the URI" in WebSphere MQ: Transport for SOAP.

The Flow 2a class, ReturnClientAssessorAvailability, is shown in Listing 6.

		
package hial.hursley.assessors.wmq;

import java.util.Random;

import DefaultNamespace.AssessorAvailability;
import DefaultNamespace.AssessorAvailabilityServiceLocator;
import DefaultNamespace.RequestAck;

import com.ibm.mq.soap.Register;

public class ReturnClientAssessorAvailability implements Runnable
{
  private int claimID;

  private int assessor;

  private String reqDate;

  private static String uri = null;

  public ReturnClientAssessorAvailability(int claimID, int assessor, String reqDate)
	{
		this.claimID = claimID;
      	this.assessor = assessor;
		this.reqDate = reqDate;
	}

	public void run()
	{
		//[Enter]run
		Register.extension();

		if (uri == null)
		{
			try
			{
			//getting properties from file
			initialise();
			}
			catch (Exception e)
			{
			//Error occurred during reading properties for
			  ReturnClientAssessorAvailablity
			return;
			}
		}

		try
		{
		 getting responseAssessorAvailabilityPort from service locator
		 AssessorAvailabilityServiceLocator locator = new
		    AssessorAvailabilityServiceLocator();
		 AssessorAvailability assessorAvailability = locator.
		    getresponseAssessorAvailabilityPort(new java.net.URL(uri));
		 calling remote method
		 Integer cost = new Integer(new Random().nextInt(1000));
		 RequestAck ack = assessorAvailability.assessorAvailability(new 
		    Integer(claimID), new Integer(assessor), reqDate, cost);//do something with the RequestAck
		}
		catch (Exception e)
		{
			Error during calling Flow4a
			return;
		}
		//[Exit]run
	}

	private synchronized void initialise() throws Exception
	{
		//load some properties
	}
}

This code uses a static value for storing the URI of the service, so that it is read from the properties file only once. It then has the call to the Web service in the run() method of a class implementing the java.lang.Runnable interface. Develop the assessor class describes the method of calling the thread.

Register.extension() is required in all client code using the WebSphere MQ Transport for SOAP. It registers the JMS URL type. Error messages about unknown transport type JMS indicate you may have omitted Register.extension().

Because this is not a real-life assessor, a random number is used for the cost of the assessment to test the functions of the assessor.

Develop the assessor class

The assessor is a Web service that must act as a client to another Web service. Having developed the client in Develop the threads to use the generated proxies, you now must develop the Java class that will become the main Web service.

This class must return a simple receipt, or acknowledgement, and trigger the calling of the return Web service hosted on WebSphere Business Integration Message Broker, the same server that called the service initially.

Runnable classes in Java (classes that implement java.lang.Runnable) are started by creating a new instance of a thread (java.lang.Thread) with the target set as a newly created instance of the Runnable class, then calling the thread object's start() method. This causes the Runnable class' run() method to be called, as shown in Listing 7.
Listing 7. Calling the Runnable class of the run() method

ReturnClientAssessorAvailability returnClientAssessorAvailability = new 
   ReturnClientAssessorAvailability(claimID, assessor, reqDate);
new Thread(returnClientAssessorAvailability).start();

When the start() method is called, the run() method of the Runnable class and the code subsequent to the start() call in the calling code are executed concurrently. The actual implementation of concurrent operations is system specific. For most programming needs, the underlying implementation doesn't matter. This threading ensures that the flow of control through the assessor system is correct. In reality, the information about the assessor's availability for the broker could take hours or days, depending on the level of automation implemented by the assessor and its schedule. In this instance, it is not desirable for the Flow 2 acknowledgement to have to wait until after Flow 2a has completed. Our method of threading eliminates this potential problem.

The assessor's main class is shown in Listing 8for Flow 2/2a.

		
package hial.hursley.assessors.wmq;

public class AssessorAvailable
{
  public Flow4RequestAck requestAssessorAvailability(int claimID, int assessor, 
     java.lang.String location, java.lang.String reqDate, CarDetails carDetails) 
        throws Exception
 	{
      //[Enter]requestAssessorAvailability

	Flow4RequestAck ackack = new Flow4RequestAck();
	ackack.setClaimID(new Integer(claimID));
	ackack.setTimeStamp(new java.util.Date().toString());

	ReturnClientAssessorAvailability returnClientAssessorAvailability = new 
	   ReturnClientAssessorAvailability(claimID, assessor, reqDate);

	//starting thread to call return web service"
	new Thread(returnClientAssessorAvailability).start();

	//[Exit]requestAssessorAvailability
	return ackack;
  }
}

In this example, Flow2RequestAck is the Java object representing the receipt returned to the broker acknowledging receipt of the Flow 2 call. CarDetails is a Java object containing all details pertaining to an insured car.

Now you have a Java class, but not a Web service. See the following section Generate the WebSphere MQ Web service to generate the Web service.

Generate the WebSphere MQ Web service

In this instance, amqwdeployWMQService can be used as it is designed. Use the amqwdeployWMQService -f hial\hursley\assessors\wmq\AssessorAvailable.java command to deploy the class as a Web service. At this point, be sure you have completed the steps in Set up the WebSphere MQ Transport for SOAP and run amqwsetcp in the command prompt window you are currently using to ensure all environment variables are set.

For successful generation, all required files must be in the correct locations and several other key criteria must be satisfied. The class AssessorAvailable makes use of several other classes that must be available in the classpath when running the deploy command. For this to work correctly, these classes should be placed in the generated\server directory. For example, the hial.hursley.assessors.wmq.Flow4RequestAck class should be in the generated\server\hial\hursley\assessors\wmq\ directory.

AssessorAvailable, the class to be deployed, must not be in any directory except for those comprising its package. You must have a queue manager started, and, unless specified, the default queue manager is used. (See the manual, WebSphere MQ Transport for SOAP for more details.)

If successful, there is no output to the command prompt and control is returned. The deploy process has automatically created a queue for the service. In this example, it is called SOAPJal.hursley.assessors.wmq.AssessorAvailable, on the specified or default queue manager. In the generated\server directory, you'll find two .cmd files for starting and stopping the listener. When your classes use any additional Java archive (JAR) files, be sure to edit the start listener batch file to add these JARs to the classpath.

In the client directory are files you'll need for creating a Java WebSphere MQ Transport for SOAP client to call Flow 2. These are not required in this instance since Flow 2 is called by the message broker. For more information about these files, see Generate Java proxies to the broker's Web services.

The queue that the Flow 2a server listens on must be available to the queue manager on the assessor server. To do this, cluster the queue managers or create individual channels as required. Similarly, the broker must have access to the Flow 2 queue. In this implementation, we used clustering in the test environment for simplicity, but used separate channels in the production environment for increased security.

The WebSphere MQ SOAP/JMS assessor is now fully integrated with the existing assessor automation system.

Back to top

Summary

In this article, you learned how this scenario:

• Implements an automated assessor system
• Uses a WebSphere MQ Transport for a SOAP-based assessor
• Enables the assessor to interact with the rest of the automated system

You also learned how to:

• Generate a Java proxy to a SOAP/JMS Web service
• Write a Java client using that proxy
• Call the Java client using simple threading
• Deploy a Java class as a SOAP/JMS Web service

Resources

Learn

• Check out the developerWorks series about merging disparate IT systems.
  
  
• Learn more about the mergers and acquisitions business scenario: "Develop an assessor automation solution" and "Coordinate a cross-product infrastructure to develop a mergers and acquisitions solution"
  
  
• Review other lab-tested solutions targeted to solve specific business problems: "Integrating IBM middleware to develop business solutions"
  
  
• Get more information about WebSphere Business Integration Message Broker in Part 12 of the "Merging disparate IT systems" series, "Model Web services with WebSphere Business Integration Message Broker."
  
  
• developerWorks' new Architecture area gives you leading-edge resources to help you more easily develop a Service-Oriented Architecture (SOA).
  
  

Get products and technologies

• IBM WebSphere MQ family SupportPacs provide a wide range of downloadable code and documentation that complements the WebSphere MQ family of products.
  
  

About the author

Stephen Willoughby is on the IBM Software Horizontal Integration Analysis Lab team. He was with IBM in 2000 for 15 months as part of his studies and returned to IBM as a full-time employee following graduation from the University of York in 2002. He has developed servlets, EJBs, Web services, WebSphere Business Integration Message Broker flows and more, and deployed them to the lab's pseudo-production environment. Stephen has also had software published on IBM's alphaWorks site.

Rate this article

Comments

Back to top

Table of contents

• Scenario overview
• Fundamental concepts
• Creating the solution
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere MQ
• Briefing: WebSphere flexible business processes
• Buy: WebSphere MQ