SOA / Web Services / Java

A Technology Blog

Archive for the ‘Java/J2EE’ Category

Purge messages from queue using Groovy/ Java

Posted by Vivek on July 8, 2014

Purging messages is one of the common operations when working with queues.

MQI (Message Queue Interface) allows browsing/ reading the message by providing various calls (MQGET, MQOPEN etc) and options alongwith. Below is a sample code to traverse the messages in a queue and perform destructive read.


// Set the Get Message Options


MQGetMessageOptions gmo1 = new MQGetMessageOptions();


boolean msgPresent = true



                def getMsg1 = new MQMessage();                     

                getQ1.get(getMsg1, gmo1);

                gmo1.options = MQC.MQGMO_MSG_UNDER_CURSOR    

                getQ1.get(getMsg1, gmo1);



   catch(MQException e){

if (e.completionCode == 1 && e.reasonCode == MQException.MQRC_TRUNCATED_MSG_ACCEPTED)


                 // Same as expected




               msgPresent = false;




Posted in Groovy, IBM Websphere MQ, Java/J2EE | Tagged: , , | 1 Comment »

Membrane SOAP Client – A beginner’s web service testing tool

Posted by Vivek on February 10, 2013

Those who are new to testing web services often complain about lack of a free tool that provides UI. Though SOAPUI has great capabilities, it requires you to have some understanding of XML. Even though XML is not a complex language to understand but it is sometimes hard for a beginner to find syntax errors or modify it. I find Membrane’s SOAP Client tool useful in such cases. All you need is to import the WSDL file and it generates a form containing text boxes for request parameters.

You can view the HTTP headers too like SOAPUI. The biggest disadvantage is that it only supports username authentication token for secutity. It is not a tool if you want support for WS-* standards. Anyways, you can edit the header details in the XML view of tool.

This tool can be downloaded from


Posted in Java/J2EE, SOA Testing, Web Services | Leave a Comment »

Using CURL to invoke web service

Posted by Vivek on February 10, 2013

CURL  is an interesting tool that provides command line option to send requests over HTTP/ HTTPS. It is a handy tool when there is a requirement to send requests in bulk or through a scheduled job using scripts.

To invoke a service using CURL, you just need to create web service request, place it in a directory and run curl command as a client. For example, to send binary data using CURL:

curl –data-binary @MySOAPRequest.xml http://<host>:<port>/MyService

There are various command line options. A comprehensive list and exit codes can be found here:

You can download CURL binaries from –

After downloading, make sure that you add CURL to the PATH environment variable.

If there is a need to execute some security functiona, download OpenSSL and place libssl32.dll file into the CURL directory.

Posted in Java/J2EE, Web Services | 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 »

Why Contract First Approach?

Posted by Vivek on January 13, 2013

I have been asked a lot of questions in the past about why we should use the contract-first or WSDL first approach of developing web services. This article very well answers the question:

Posted in Java/J2EE, SOA, Web Services | Tagged: , , | 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 »


Posted by Vivek on January 8, 2012

One distinctive feature of REST web service is that it supports message formats other than XML or SOAP.  In a REST based web service, resources are identified by a unique URI and can support formats such as XML, JSON, HTML, CSV etc. However, XML and JSON (JavaScript Object Notation) have gained more visibility and are widely used formats. While XML is still the preferred choice, JSON is not far behind than XML.

1. XML is verbose and causes performance bottlenecks. The primary objective behind adoption of REST is to increase the performance of services and XML does not provide good support here.

2. Those using Java can easily parse JSON as it is well supported by javascript clients. Nowadays, all browsers support javascript and browsers like firefox 4 and IE8 also provide special support for parsing JSON. Afterall, JSON is a subset of javascript. Note that not all browsers support encoding and decoding of JSON.

3. There is support in leading XML editors like XML Spy for JSON. Other editors will soon follow the same. However, this will take some time. JSON schema is not widely accepted and is still evolving.

4. Processing JSON requires less effort and is not memory intensive. Fewer lines of code without any dependency on external JARs reduces overhead.

5. JSON can pose several security problems if the processing program contains insecure scripts. There is no standard security mechanism that can be used. JSON is a preferred approach only when the data and parsers are from a trusted source.

6. A variety of XML processors are available in the market. Also, there are techniques to compress XML or accelerate XML processing. JSON has a limted playing field.


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

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 »

Dynamically upload files using JQuery

Posted by Vivek on April 10, 2011

If you developing a web page and you have a requirement that multiple files need to selected and uploaded, then conventional file upload mechanisms do not work. You might see a lot of web applications which allow you to upload files but the file upload limit is pre-determined. In cases, where the number of files to be selected is not known, these solutions do not work or adds more complexity to the code. JQuery is one way to achieve the desired result and the advantage is that it is an advanced form of Javascript and is easy to understand and allows writing less code.   

The following example demonstrates how JQuery can be used to upload files dynamically. You just need to import some javascript files and that’s it.

<!DOCTYPE html PUBLIC ‘-//W3C//DTD XHTML 1.0 Transitional//EN’ ‘’&gt;

<html xmlns=”; xml:lang=”en” lang=”en”>


<title>Imporing XSDs</title>

<script src=’; type=”text/javascript”></script>

<script src=’; type=”text/javascript”></script>

<link href=’; type=”text/css” rel=”stylesheet”/>

<script type=”text/javaScript” src=””></script&gt;

 <script type=”text/javascript”>try{ChiliBook.recipeFolder=”/jquery/project/chili/”}catch(e){}</script>

<script src=’; type=”text/javascript” language=”javascript”></script>

<script src=’; type=”text/javascript” language=”javascript”></script>

<script src=’; type=”text/javascript” language=”javascript”></script>

<script src=’; type=”text/javascript” language=”javascript”></script></head>


Import Files


<form action=”upload.jsp” method=”post” enctype=”multipart/form-data” name=”form1″ id=”form1″>

<input type=”file”/>

<br /><br />

<input type=”submit” name=”Submit” value=”Submit” />


 Learn more about JQuery at


Posted in Java/J2EE | 1 Comment »