SOA / Web Services / Java

A Technology Blog

Archive for the ‘integration’ Category

Deploying BAR (Broker Archive) using ANT

Posted by Vivek on July 7, 2014

This is not very straight-forward. WMB provide mqsideploy script to deploy the BAR file but before invoking the script, you need to source the mqsiprofile batch file. mqsiprofile is not a perl script and cannot be invoked directly. On windows platform, it is present in MQSI_Home/bin folder as a batch command file (.bat). This batch file has to run before mqsideploy.exe within the same script. Create a new batch command file (deploywmb.cmd) and add the following lines:


CALL “C:\Program Files\IBM\MQSI\7.0\bin\mqsiprofile.cmd”

CALL C:\Progra~1\IBM\MQSI\7.0\bin\mqsideploy.exe -i %1 -p %2 -q %3 -b %4 -e%5 -a %6



%1 corresponds to ipaddress, %2 corresponds to port and so on and are passed from Ant script.

The batch file is called and arguments are passed from Ant script as follows:

<target name=”deploy-bar”>

<property file=”${basedir}/build-properties/config/${Env}/”/>

<property name=”bar-location” value=”${basedir}//bars//${Env}_${bar.file}.bar”/>

<echo message=”MQSI Deploy “></echo>

<exec executable=”C:\utilities\wmbbuild\deploywmb.cmd”






<arg value=”${ipaddress}” />

<arg value=”${port}” />

<arg value=”${queuemgr}” />

<arg value=”${broker}” />

<arg value=”${exegroup}” />

<arg path=”${bar-location}” />


<echo message=”Deploying Broker Archive file – ${} ” />



${Env} is the environment for which BAR is created. Example – Dev, test, UAT file is the file for storing environment specific properties. The following properties are read from file:

${ipaddress} is the name of the host of the Queue Manager

${port} is the port number of the listener

${queuemgr} is the Queue Manager name of the broker

${broker} is the broker name whose execution group is to be used for deployment

${exegroup} is the name of the execution group

${bar-location} is the location of BAR file which needs to get deployed


Posted in IBM Websphere Message Broker, IBM Websphere MQ, integration | Tagged: , , , , | Leave a Comment »

MQOPEN options while reading/browsing MQ messages

Posted by Vivek on July 7, 2014

When using MQI, it is almost a possibility to read and browse messages. MQOPEN call precedes before accessing the messages and it is important to provide correct options before you do something with the messages.
For the options of the MQOPEN call:
v At least one of the following must be specified:
v Only one of the following is allowed:
v Only one of the following is allowed:

Posted in IBM Websphere MQ, integration | Tagged: | Leave a Comment »

3 reasons not to use REST

Posted by Vivek on January 17, 2013

Here are a few reasons why RESTful services can be avoided:

1. REST is not a good choice when the way client application use service require high degree of control.

2. It is required to use vendor based tools to generate client stubs or server skeletons.

3. There is a need for coarser granularity to reduce the number of network calls.

In addition, advanced security controls and standards cannot be used. Exposing data can be dangerous sometimes.

Posted in integration, Java/J2EE, SOA | Leave a Comment »

3 reasons to use REST

Posted by Vivek on January 17, 2013

Here are a few reasons why REST is gaining popularity:

1. Need for speed – REST can take advantage of HTTP caching and proxy to provide improved speed. Example – cacheable map tiles in Google maps  

2. Efficient parsing – It is easy to parse JSON, plain old XML (POX) than the verbose SOAP

3. Reduce network traffic – SOAP messages generally require compression when passed over network. Passing lighter JSON, POX messages will consume less bandwidth.

REST is the backbone of web 2.0. It is now supported by all major vendors like IBM, Oracle and Microsoft. With cloud, adoption of REST has also increased. REST retains advantages of XML such as platform and language independence. Languages like Perl, python and javascript also support REST. Deployment of a REST based service is easy. Also, RESTful services are scalable.

Posted in integration, Java/J2EE, SOA | 1 Comment »

Determining Complexity of Service in SOA

Posted by Vivek on May 13, 2012

Every unit of logic in a SOA is treated as a service. Before embarking on the SOA journey, it is important to go through a service identification process. Once services are identified, they are categorized as per the level of complexity. Determining the complexity is a key step in providing estimation. The following guidelines can be used to gauge the complexity of a service:

Simple Service:

· Exposed using a standard based interface and no adapters are required.
· There is minimal (simple) or no data validation required.
· There is minimal (simple) or no data transformation required.
· Does not require any security implementation. (Mostly public services)
· Simple logging framework. Does not require a separate error handling mechanism.
· Can be easily searched in UDDI. Taxonomies clearly defined. Simple end-point look.
· Does not require WS-* Standards like WS-RM, WS-A etc.
· Does not require any guaranteed delivery messaging mechanism to be in place
· Mostly utility services with simple read/ update operations.

Medium Service:

· Exposed using a standard based interface.
· There is simple/ medium data validation required.
· There is simple/ medium data transformation required.
· Simple logging framework. Requires a separate simple error handling mechanism.
· Require simple security implementation. Eg WS-security for authentication/ authorization, tool based encryption and decryption, SSL etc
· Can be easily searched in UDDI. Taxonomies clearly defined. Simple end-point look.
· Can include simple WS-* standards such as WS-Addressing, WS-reliable messaging.
· Requires some guaranteed delivery messaging mechanism to be in place
· Services returning/ adding medium to large amount of information and interacting with 1 application or system.

Complex Service:

· Exposed using a standard based interface.
· There is complex data validation required. (eg, data & timezone validation etc)
· There is complex data transformation required. (eg. One message standard to another)
· Complex logging framework. Implementation of Correlation sets. Requires a separate complex error handling mechanism with retry/ reprocessing logic and fault notification.
· Require medium to complex security implementation. Eg Digital Signature, encryption & decryption, SAML etc
· Multiple versions exist in UDDI. Standards such as WS-Policy, WS-trust need to be enforced.
· Can include WS-* standards such as WS-Coordination etc.
· Requires guaranteed delivery messaging mechanism to be in place
· Services adding/ updating and returning large and complex information and interacting with multiple systems.

Posted in integration, Java/J2EE, Miscellaneous, SOA, SOA Governance, Web Services | Tagged: , | 1 Comment »

Why IBM is not a best choice for SOA?

Posted by Vivek on May 5, 2012

SOA offers great benefits by simplifying the architecture by virtue of its priniciples and helps in making an enterprise more agile. But implementing SOA is not easy and it takes a well-defined strategy. It is a long-term investment and if the first step taken is in wrong direction, then integration costs and complexity can increase exponentially.

For example, consider an organization which is in Retail domain and wants to integrate its 2 channels – Store and E-Commerce. This can be done by choosing any of ESB available in the market which supports the protocols, message formats etc of the requesting and providing applications. However, integration might not stop here. There can be another legacy system which the organization has acquired and wants to integrate. Also, management wants to increase agility by defining worflows and dynamically changing rules according to business needs in a faster changing market. It needs to be understood that SOA is a journey and it is business to decide which mode of transport they take to embark on this journey.

IBM is one of the leaders in middlware but does its products make a better choice when implenting SOA?

1. IBM has a wide array of products. Deciding which product suits which requirement is a not an easy task. If there is an ESB requirement then IBM offers the following products: Websphere ESB, Websphere Message Broker and Datapower. Not all products offer the same benefits and each one has its own strength and pitfalls.
2. These ESBs alone may not suffice. If complex transformations are required, then you might also need a Websphere Transformation Extender. If a legacy application needs to be integrated and a third-party or customized adapter is required, then providing a seamless integration will be a challenge.
3. As SOA evolves and business grows, it almost becomes a necessity to have a BPM tool to facilitate agility. IBM provides Websphere Process Server as a BPM tool for process based integration.
4. Websphere Process Server is mounted on top of Websphere Application Server. It also comes with a Business Rule engine to enrich process workflows. However, there is another powerful product, websphere ILOG, which also offers business rule management.
5. ILog JRules is installed separately and has its own development and runtime environments. While you already have a Rational Application Developer, an eclipse based IDE, you will be using another IDE for rule authoring. Not only this, you are also using an IDE for designing and developing ESB flows. For example, if you are using websphere message broker, then you will be using a message broker toolkit as IDE.

Posted in IBM Websphere Message Broker, IBM Websphere MQ, integration | Tagged: , | Leave a Comment »

Download Free SOA Knowledge Kit

Posted by Vivek on January 8, 2012

PushToTest is offering free SOA knowledge kit that includes comparison of top middleware vendor products. Follow this link:

Registration Link –



Posted in integration, Middleware, SOA | Tagged: , | Leave a Comment »

Checklist for a new interface in integration

Posted by Vivek on January 8, 2012

While integrating several systems, interfaces are created based on the technical requirements. The interface is defined by a set of parameters, which form building blocks of any interface design.

1. Name: This involves name of the requesting application as well as the service provider or name of the systems involved in the conversational process. Ex. ABCProvider_WeatherService
2. Integration Style: This includes information such as Batch or Real-Time.
3. Integration Technology Framework: This includes information such as ETL (eg Datastage, Ab Initio, Informatica), Web Services, EAI, B2B
4. Invocation Style: It includes the way in which the integration application will be invoked. Invocation could be through Database trigger or Change Data Capture, Manual or through sequencer (in case of ETL).
5. Message Exchange Pattern: It includes information about the way in which messages are exchanged such as Request-Reply, Fire and forget, Pub-Sub topology
6. Message Domain: It includes details such as HL7 for Healthcare, ACORD for Insurance etc
7. Message Format: It includes details such as XML, CSV, Pipe delimited messages, SOAP including web service standards such as WS-Addressing, WS-RM, WS-BaseNotification
8. Messaging Style: Messages could be transported using HTTP, SMTP, MQ etc.
9. Service Contract: It can be WSDL for SOAP based web services, WADL for REST
10. Security: It includes non-functional requirements such as Authentication, Authorizarion, Confidentiality, Integrity and Non-Repudiation.
11. Security level: This can be Message level or Transport level.
12. Security Implementation: It can be WS-Security username token for authentication, SSL, Canonicalization algorithm for encryption/ descryption etc.

If these parameters are clearly defined, then it is possible to build the interfaceand use this information as metadata in governing the services in future.

Posted in integration, SOA, Web Services | Tagged: , | 2 Comments »

Execution Group properties of a local/remote WMB

Posted by Vivek on September 10, 2011

Those using IBM WMB sometimes face issues when they have to connect to a remote broker and deploy their code to an execution group.  The utility (mqsireportproperties) provided by IBM Websphere Message Broker does not allow to read the properties of a remote broker and it is sometimes not possible to log on to a remote broker machine to execute the mqsireportproperties command. Common problems faced by users in such situation are –

1. User requires MB toolkit/ MQ Explorer 7 to connect to broker and see EG details. It is difficult for a user who does not have these tools on his/her machine.

2. User cannot see/ set the properties like debug port, HTTP port on an execution group.

Most user do not know that they can leverage the ConfiguarionManagerProxy APIs as a workaround mainly because WMB users are not generally java savvy. Here is a utility (Simple Java Program) which will help to set and report the properties on a local or remote broker. It is easy to alter and run from command line.


1. Java 6

2. Following jars are added in  classpath – ConfigManagerProxy.jar (located at ../MQSI/7.0/classes), (located at ../Websphere MQ/Java/lib) and (located at …/Websphere MQ/Java/lib)

import java.util.Enumeration;









 * This utility connect to a broker and reports the properties on an execution

 * group.


 * @author vivek



public class EGStatusReport {

      public static void main(String args[]) {

            try {

                  BrokerConnectionParameters bcp = new MQBrokerConnectionParameters(

                              “localhost”, 1425, “MYQMGR”);

                  BrokerProxy b = BrokerProxy.getInstance(bcp);

                  Enumeration<ExecutionGroupProxy> listEG = b


                  while (listEG.hasMoreElements()) {

                        ExecutionGroupProxy egIter = listEG.nextElement();

                        // Get Execution Group Name


                                    .println(“Execution Group Name – ” + egIter.getName());


                        System.out.println(“Debug Port of EG – ”

                                    + egIter.getDebugPort());


                        System.out.println(“HTTP port enabled on EG – ”

                                    + egIter.getRuntimeProperty(“HTTPConnector/port”));

                        // Get List of Message Flows and their details

                        Enumeration<MessageFlowProxy> listMsgFlow = egIter


while (listMsgFlow.hasMoreElements()) {

                              MessageFlowProxy msgFlow = listMsgFlow.nextElement();

                              // Get name of message flow

                              System.out.println(“Messsage Flow Name – ”

                                          + msgFlow.getName());

                              // Get BAR File Name

                              System.out.println(“BAR File Name – ”

                                          + msgFlow.getBARFileName());

                              // Get time of deployment

                              System.out.println(“Deployed at – ”

                                          + msgFlow.getDeployTime());

                              // Get run status of Message Flow

                              System.out.println(“Is run enabled? – ”

                                          + msgFlow.isRunEnabled());


                        // Get number of deployed objects

                        System.out.println(“No of deployed objects – ”

                                    + egIter.getDeployedObjectsCount(null));


            } catch (ConfigManagerProxyLoggedException e) {


            } catch (ConfigManagerProxyPropertyNotInitializedException e) {





Refer to the following URL for complete list of methods:

Posted in IBM Websphere Message Broker, integration, Java/J2EE | 1 Comment »

MQMON – MQ Tool for Admins and Testers

Posted by Vivek on May 7, 2011

You might have come across many tools which allow you to communicate with message queues. Reading a message from queue and writing a message to queue are very common operations especially in projects where guaranteed messaging is extremely important. However, handling messages in queue is sometimes cumbersome.

Some of the tedious operations are reading a message which is somewhere in the middle (as queue operates in LIFO fashion). Putting messages in bulk into the queue and getting/ browsing multiple messages at a time are handy. Indexing is also important to identify the position of message in queue. It is imperative that an MQ tool should support all these features.

Those who install IBM MQ use MQ explorer wizard but it does not offer features mentioned above. Nor does it allow to view the message properly.

One can use RFHUtil to read/ write/ browse messages but it does not allow bulk insertion/ retrieval of messages. RFHUtil can be download from IBM site:

Performance testing cannot be performed unless messages can be published in bulk. Also, it is always better to save the Queue Manager settings to save some time and effort. These are some of the benefits that are offered by MQ Monitor tool (Also known as MO71) It can be downloaded from IBM site

It provides a simplified GUI and is a very useful tool for Administrators and testers. Here is how it can be used and has an edge over other tools.

1. A freeware, this tool allows you to create connections to queue managers and save them for future use.

2. Allows you to index the messages and export them to a file.

3. Able to read the file and insert messages in queue based on index. This makes it simpler to modify any message in file and put it back in queue.

4. Searching an element/ word/ value  in message is easy when the message is written to a file.

5. Easy to navigate through all the queues. (List of queues can be seen using Queue List option. Search and filter options can be used)

6. Statistics can be easily calculated. Channel administration is supported.

Download MQMON from here –

Posted in integration, Middleware | Tagged: | Leave a Comment »