The SOA Gateway and MQ Series. This document is intended to give IT personnel an in depth understanding of the differences between these products.

Transcription

1 The SOA Gateway and MQ Series Version The SOA Gateway and MQ Series This document is intended to give IT personnel an in depth understanding of the differences between these products. This document is distributed for information purposes only and does not form part of or constitute an agreement with Risaris Ltd. Although Risaris Ltd. uses reasonable efforts to include accurate and up-to-date information in this document, Risaris makes no warranties or representations as to its accuracy. Risaris Ltd. may also make improvements and/or changes to this document at any time without notice. The various approaches outlined in this document are put forward in good faith, but it remains possible that individual results may vary. For that reason and in accordance with standard practice, readers are encouraged to test any materials developed on the basis of this paper before putting them into productive use. Risaris Limited Page of 0

2 The SOA Gateway and MQ Series Version. Overview When first introduced to the SOA Gateway, many users of MQ series or organizations evaluating the use of MQ Series believe that both products do the same thing. While they do similar things, they do them in very different ways and are thus completely different solutions to the integration problem. MQ Series enables applications to be connected together using a strong messaging based approach which is required where persistent messaging is desired but which is quite expensive when the goal is to connect systems together in real time. The following table summarized the differences between MQ Series and the SOA Gateway where they can be directly compared: Feature MQ Series SOA Gateway Standards Some standards can be used with external add ons but internally the solution is 00% proprietary. Connectivity Configuration Architecture Performance Availability Uses proprietary MQ messaging based approach on top of transport which requires different organizations (or departments) to both run MQ series if they wish to exchange information. Installation required on the server platform and each client that will communicate using MQ Series. Multi tiered, multiple hop implementation Multi tiered, multiple hop messaging based communication results in increased usage of system resources to service requests. Multiple processes/address spaces (sometimes on multiple platforms) means there are multiple points of failure. Security Proprietary SSL Debugging Multiple processes/address spaces (sometimes on multiple platforms) to check when there are problems. Fully standards based using WSDL, SOAP, REST, XML, HTTP and Uses standard HTTP over transport. Optionally able to use HTTP over MQ or EntireX Communicator as the transport when strong messaging required. Single installation on server platform. Single tier, point to point implementation Point to point, based communication means minimal system resources required to process requests Single process/address space means one single point of failure. One single process/address space to check when there are problems. Risaris Limited Page 2 of 0

3 The SOA Gateway and MQ Series Version Licensing Application Container Standard legacy model based on platform and number of users. No application container meaning significant server side coding still required to offer services to the client. Simple usage or platform based licensing available Apache based container means no server side coding is required In addition, the SOA Gateway has the following capabilities not available with MQ Series: - REST/URL based approach to calling services. This means that SOA Gateway services may be invoked from any technology that can open a URL including MS Excel, MS Word, Internet Explorer and Firefox to name but a few. - XSLT delivery as standard. The SOA Gateway can optionally deliver an XSLT file with an XML file for specific rendering on the client side. - Access to databases out of the box such as ADABAS, VSAM, DB2, Oracle etc. - Access to business logic out of the box such as Natural, PL, CICS, C, Assembler etc. The following sections describe in detail the architectures of the two solutions so that it s clear how they are different in terms of installation, configuration, for the creation of the services and the usage of those services once created. Risaris Limited Page 3 of 0

4 User Written Server WS-Proxy The SOA Gateway and MQ Series Version 2. MQ Series Architecture MQ Series can be configured in various ways, however, in order to make a direct comparison with the SOA Gateway, the configuration required to make COBOL services available with SOAP is used here. This looks as follows: 3 2 Java Host (e.g Windows, Linux 2.. Installation and Configuration Requirements In order to achieve the above configuration, the following steps are required:. The MQ Server must be installed and configured on the host server where your COBOL business logic is running. This will result in two processes, address spaces or partitions being started. 2. A user written server or application container must be built or installed to handle the MQ Series messages and to invoke the COBOL application. This will require another process, address space or partition to be available to run the service. 3. The MQ Series stub must be installed on the Java host where you will be running your JAVA proxy for the service. This will generally run on a different to your host server but can potentially run on the same. Risaris Limited Page 4 of 0

5 User Written Server WS-Proxy The SOA Gateway and MQ Series Version 2.2. Creating a Web Service for your COBOL program In order to make a Web Service available for a COBOL program with the above configuration, it is necessary to proceed as follows: 3 2 Java Host (e.g Windows, Linux. Custom coding must be added to the user written server to handle each COBOL program to be made available. 2. At least 2 queues (one for input and one for output) must be defined to the MQ Series server. 3. The user must create a JAVA proxy for the service and must then deploy this on the Java host. Risaris Limited Page 5 of 0

6 User Written Server WS-Proxy The SOA Gateway and MQ Series Version 2.3. Using the COBOL Web Service The Web Service may now be called from a consumer as follows: Java Host (e.g Windows, Linux The consumer will send the SOAP request to the Java proxy using. 2. The Java proxy will take the SOAP request and transform it to a MQ Series request. 3. The Java proxy will send the MQ request to the input queue defined in the MQ Series server via. 4. The MQ Series server will send the MQ request via to the User Written Server application. 5. The User Written Server will interpret the MQ request and call the COBOL program and get the result. It will then map the result back into a MQ response. 6. The User Written Server will send the MQ response back to the output queue defined on the MQ Series Server. 7. The MQ Series Server will send the MQ response back to the Java proxy. 8. The Java proxy will take the MQ response and transform it to a SOAP response. 9. The Java proxy will send the SOAP response back to the Consumer. Risaris Limited Page 6 of 0

7 The SOA Gateway and MQ Series Version 3. SOA Gateway Architecture The SOA Gateway equivalent configuration to the above is as follows: 3.. Installation and Configuration Requirements In order to achieve the above configuration, the following steps are required:. The SOA Gateway Server is installed on the Host server. This must be started as an individual process, address space or partition. Risaris Limited Page 7 of 0

8 The SOA Gateway and MQ Series Version 3.2. Creating a Web Service for COBOL In order to make a Web Service available for a COBOL program with the above configuration, it is necessary to proceed as follows:. The COBOL program is defined as a service to the SOA Gateway using the Eclipse based Control Centre Risaris Limited Page 8 of 0

9 The SOA Gateway and MQ Series Version 3.3. Using the COBOL Web Service The Web Service may now be called from a consumer as follows:. The consumer will send the SOAP request to the SOA Gateway Server using. 2. The SOA Gateway Server will interpret the SOAP request, call the COBOL program and get the result. It will then map the result back into a SOAP response. 3. The SOA Gateway Server will send the SOAP response back to the Consumer. Risaris Limited Page 9 of 0

10 The SOA Gateway and MQ Series Version 4. Summary This document shows the difference in the architectures between the SOA Gateway and the product and clearly illustrates the benefits that can be achieved by using the SOA Gateway as follows: - Simpler initial installation and configuration - Simple, single step creation of - No installation required on the client systems - Less custom coding to get data and business logic integrated - Less usage of system resources - Easier diagnosis of problems in the system - Ease of use from any other technology Risaris Limited Page 0 of 0