SOA / Web Services / Java

A Technology Blog

Archive for the ‘Web Services’ Category

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 »

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 »

SOA testing tools – A comparitive study

Posted by Vivek on January 5, 2013

This is my attempt to compare the various SOA testing tools in the market. Please feel free to provide your suggestions or comments.

Sr No

Features Crosscheck Networks SOAPSonar 3.0.5 iTKO LISA 3.6e Mindreef SOAPscope (Progress Actional) Parasoft SOAtest 5.1 Rational Service Tester Greenhat (Rational Test Workbench) SOAP UI Pro


 Learning curve Medium Medium Simple Medium Simple Medium Simple


Simple Navigation Y Y Y Y Y Y Y


Dynamic Data Population Y Y Y Y Y Supported in GH Performance (Rational Performance Test Server) Y


Project Save, Merge, Import, and Export (allows Team Project Sharing) Y Y Y Y Y Y Y


WSDL Merge (services, operations, XSD schema) Y X X X X X X


Clone Test Suites, Test Groups, Test Cases, Test Settings Y Y Y Y Y Y Y


Run Test Suites from HP Quality Center Y Y X Y X Y X


WSDL Operation Response/Request Chaining Y Y Y Y Y Y Y


WS-Security and Identity Management Digital Signature, Encryption, Username, X509, SAML, Kerberos Y Y Y Y Y Y


SOAP with Attachments (DIME and MIME) Y Y   Y Y   Y


WS-Addressing Y Y X Y Y Y Y


XSL Transformation Y X   X X X X


Design Time WSI-BP 1.1 Compliance Y Y Y Y X Y Y


Report generation PDF, XML, CSV formats PDF, HTML, CSV, Excel PDF Y CSV, HTML, RTF Y PDF, HTML, RTF, Word, Excel


Data Source Support CSV, Excel, SQL Server 2000/2005, Oracle SQL, ODBC, JDBC, Excel, Raw file SQL Server
Apache Derby
CSV, Excel, relational databases X via JDBC via JDBC


Regression Testing Suite Y Y Y Y Y Y Y


Record and Playback X Y Y X Y Y Records HTTP traffic


Extensible Y Java support Limited Y Y Y Supports Groovy and JavaScript


Performance Testing Support Y Y Y Y Using Rational Performance Tester Y Y


MQ Support Y Y X Y Y Tibco EMS, IBM MQ, Sonic MQ X


REST Service Support Y Y Y Y X Y Y


JMS Support Y Y Y Y Y Y Y


Stub Generation Y Y Y Y Y Y Y


SMTP Support Y     Y X Y  


SOAP 1.2 Support Y Y Y NA NA NA Y


OS Platforms Windows. SOAPSonar can be run on MAC and UNIX based systems through the use of a Virtual Machine running a Windows OS Windows (XP/Vista/Me/2000), Linux, Unix, Solaris, Mac OSX Microsoft Windows
Red Hat Linux,
Enterprise Linux,
Solaris (including
the x86 series)
SUSE Linux
Windows, Linux, Solaris, Mac windows and linux AIX, Linux, Solaris, Windows Windows, Linux, Mac


UDDI Support   Y X Y Y Y X


Policy Enforcement Y Y Y Y Y WS-Policy X


Mock Service Y Y Y Y Y Y Y


Asynchronous Service Testing   Y   Y asynchronous using WS-Notification Y X


UI Support Y Y Y Y X Y X


Industry Specific Data Formats X Out of the box support X X X HL7, MLLP, SWIFT, FIX, IATA, AMQP X


ESB Support IBM, Tibco, Oracle IBM, TIBCO , Software AG / webMethods, Oracle , Progress, Cordys, SAP, Microsoft Oracle, IBM, Jboss, SAP NA NA IBM, Tibco, Software AG, Oracle, SAP NetWeaver NA


Variants Personal Edition, Standard Edition, Automation Edition, Platinum Edition. (Personal Edition lacks features such as WS-Security validation, performance testing, and vulnerability testing) NA NA NA Rational Service Tester, Rational Performance Tester GH tester, GH Performance, GH VIE SOAPUI, SOAPUI Pro


License Commercial (Free – Personal Edition) Commercial Commercial Commercial Commercial Commercial Commercial (Free – SOAPUi)

Posted in SOA, SOA Testing, Web Services | 6 Comments »

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 »

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 »

Identifying services in SOA

Posted by Vivek on January 8, 2012

Perhaps the most critical task before embarking on a SOA journey is to identify and build the right set of services. This exercise requires not only technical knowledge but also functional knowledge as the services might span across business and techical domain of the enterprise. Based on the business and technical requirements, services can be classified into one of the four major categories.

1. Infrastructure or Utility services: Services falling under this category and mostly techical and discrete in nature and provide reusable functionalities and are internal to an enterprise. If there is a need to execute a piece of logic which is difficult to be rewritten and/ or is readily available on the other side of the firewall or business domain or is offered by a third party, then building a wrapper or client or choreographing the service with ESB provide easy access to the information saving a considerable amount of effort and cost. For example- a credit check service can be used by billing, HR or insurance domain within an enterprise. Similarly, authentication or authorization services can be reused across an organization.

2. Application services: These services are designed and developed to address a sepecific set of requirements. They can be composite and encompass the domain or functional logic within. These services are not generally accessed directly by the user. example: a packaging application service that packages and ships order.

3. Business Services: These services are exposed to the consumer and is composed by choreographing one or more application services. Example: An order service that takes an order, sends it for approval, confirms payment mode, processes transaction and triggers shipment.

4. Process Services: These services are used mostly by management and business analyst to make the business more agile. Process services involve orchestration of services and other components and typically take the form of a workflow. Example: A loan processing service which spans across HR, Finance, Insurance departments. Loan interest rate might change from time to time and a rule engine can serve the pupose for management.

Posted in SOA, Web Services | Leave a Comment »

Adapter and Façade – The Design Patterns of SOA

Posted by Vivek on August 6, 2011


This design pattern helps to take advantage of the existing technology or aplications. One of the principles of SOA is reuse. Adapter fosters reusability by integrating legacy or packaged applications with your ecosystem. Application built using mainframe technologies like CICS, COBOL etc still have a place in today’s IT infrastructure. Capabilities and usage of packaged applications like Siebel CRM, Peoplesoft HRM, Portal billing, SAP CRM etc are not limited because of technical implementations. One of the well known adapters is JCA (Java Connector Architecture) adapter.


A right level of granularity is essential when designing services. Services, in context of SOA, can be considered as a unit of logic. SOA recommeds use of coarse granular services. Reason is simple – It avoids making multiple calls to service and hence increases network throughput. But sometimes it is difficult to avoid designing and developing low-level services (mostly utility services). Façade helps in providing coarse granurality by encapsulating low level services. Façade pattern also abstracts client from the implementation details of a service. Most of the times, changes in a service does not impact client because of usage of Façade pattern.



Posted in SOA, Web Services | Tagged: , , | 1 Comment »

Access User-Defined SOAP Header Elements in Service

Posted by Vivek on February 13, 2010

There could always be a requirement that some data be sent only in SOAP Header. Usually SOAP Header contains data that is system specific and is dissimilar to the message payload that is contained in the SOAP Body. The information that a SOAP Header carries could be user-defined and generally used for tracking and logging. This data could be required by your service but is lost when a SOAP engine unmarshals the SOAP Request and provides just payload to the service i.e., applies the binding mechanism to convert an XML into a VO for the service to access elements using accessors and mutators.  To make this user-defined data available to the service, use of ThreadLocal can be advocated.

ThreadLocal allows you to have copy of variable per thread, which are subject to garbage collection when the thread goes away. Before the binding framework of SOAP engine performs any logic, a SOAP Handler can be placed to access the original SOAP request message and let the handler set the data in a threadlocal variable and use this data, which remains alive till the thread is active.

Here is the sample code which allows a bean injection and makes it available for setting values in the handler class.

<bean id=”myUserDefinedInfoBean”
<property name=”targetSource” ref=”threadLocalUserInfo” />

<bean id=”threadLocalUserInfo”
<property name=”targetBeanName” value=”userInfoVO” />
<bean id=”userInfoVO”
class=”mypackage.vo.UserInfoVO” scope=”prototype” />

UserInfoVO defines setters and getters for the user defined elements . The values can be set in the handler class and can be obtained anytime till the thread remains active.

For ex, the following code snippet will set the values in SOAP Handler

private UserInfoVO userInfoBean;


public UserInfoVO getUserInfoBean() {
return userInfoBean;

public void setUserInfoBean(UserInfoVO userInfoBean) {
this.userInfoBean = userInfoBean;




Once the above code is executed, value set in myVal can be accessed anywhere using getUserInfoBean()

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