SOA / Web Services / Java

A Technology Blog

Posts Tagged ‘SOAP’

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 »

Is your web-service conforming to WSI-Basic Profile?

Posted by Vivek on January 23, 2010

Though there are various ways to design a service and since webservices are XML based and XML is tagged as platform independent, different programming languages and different application server have their own set of rules while defining a web service. WSI-Basic Profile helps address some interoperability issues that might arise because of the proprietary nature of majority of tools and languages. Listed out below are some of the guidelines that can be useful while defining a service:

XML version is 1.0

Encoding must be UTF-8 or UTF-16

Namespace for WSDL is defined as

Namespace for SOAP binding is defined as

Namespace for SOAP encoding is defined as

Namespace should not be as

Custom Data types used in WSDL should conform to XML Schema version 1.0

Data Type that causes interoperability issues should not be used. For ex. wsdl:arrayType, arrayOfStrings etc. should not be used.

All the xsd:import elements should be used within the xsd:schema element of the types section

The attribute wsdl:required=”true” should not be used by any element.

wsdl:import URIs should be absolute and not relative.

wsdl:import should precede all other wsdl types , except wsdl:documentation. Similarly, wsdl:types should precede all other elements, except wsdl:documentation and wsdl:import

targetNamespace value of WSDL that is being imported should have the same value as wsdl:import.

All the imported schemas should have a root element defined with namespace

Part attribute, if any, in a document literal style of web service should be defined within binding or operation.

In Document Literal style, wsdl:part elements that are used in soapbind:body should have ‘element’ attribute defined.

In a wsdl:message/wsdl:part element, the ‘element’ attribute should refer to a global element declaration and not to any xsd types.

In an RPC Literal style, envelope should not have xsi:nil attribute value = “1” or “true”.

In an RPC Literal style, wsdl:part elements that are used in soapbind:body should have ‘type’ attribute defined.

In a wsdl:portType definition, Solicit-Response/Notification type operations should not be used.

A wsdl:message element should not have both type and element attributes defined.

The values for name attribute of wsdl:portType elements should be distinct.

In soap:binding element, the transport attribute should be defined and the value should be

In a soap:operation, the value of style attribute should be either “rpc” or “document”.

In a soap:operation, the soap:bodyelement should have use attribute set to “literal” ?

If soap:header/soap:headerfault/soap:fault elements are defined, the use attribute should be set to “literal”

The location attribute should have distinct value for different ports wsdl:port.

A soap:fault should be defined for each fault defined and it should contain name attribute. If use attribute is defined, it should contain a value ‘literal’

Similarly, a soap:headerfault should exist for each header fault defined.

If SOAP Action is defined within operation, it should be set in the HTTP header of the request otherwise, it should be set to empty quoted string.

SOAP envelope should contain namespace whereas SOAP encoding namespace should be SOAP message should also use UTF-8 or UTF-16 encoding.

Intermediaries, if present while transmitting SOAP message, should modify the header only if the must-understand attribute is set to true. Intermediaries should not modify the payload or elements with the SOAP Body.

A must understand faultcode must be generated in case receiver is unable to process the mandatory header of the SOAP message.

In case of a fault, soap:Fault must not have childrens other than faultcode, faultstring, faultactor and detail. In case of fault,  children of the soap:Fault element must be unqualified. There can be zero or more child elements of the detail element, which can be either qualified or unqualified.

Values of the faultcode element are defined by SOAP specification and preferably should not be modified.


Posted in Web Services | Tagged: , , , , | 8 Comments »

Preserve white spaces in a SOAP message

Posted by Vivek on January 30, 2009

Sometimes, the business requirement mandates that a SOAP request/response should maintain leading or trailing spaces that are present in a variable. By default, this does not happen. For example, you may expect ” ABC” or “ABC “, but you get “ABC”. The spaces are removed. Also, you may encounter issues if you use a binding mechanism like JAXB to marshal/ unmarshal xml fragments.  This requires modifying the default marshalling or unmarshalling behavior. This is how you can still maintain any whitespaces:

Before marshalling call

marshaller.setPropertyMarshaller.JAXB_ENCODING, “UTF-8”)

 which informs MarshallerImpl#createWriter(…) to create a UTF8XmlOutput instead of SAXOutput. 

UTF8XmlOutput escapes line-break into “ ”, which will be preserved when unmarshalling is performed by any xml parser.

Posted in Web Services | Tagged: , , | Leave a Comment »

RPC-style vs Document-Style Web Service

Posted by Vivek on September 12, 2008

There has been lot of confusion on which style of web service is used but It is always recommended to use a Document-style webservice to realize SOA.

RPC style web service:
These web services are easier to create and are usually synchronous in nature.
The responsibility of marshalling and de marshalling lays with SOAP engine, This leads to significant performance degradations when message passed to an operation is large or complex.
Since large sized messages lead to performance degradation in RPC style web service, they are not suitable for implementing coarse grained functionality requiring information messages having more number of fields.
However fine grained functionalities is better implemented by RPC style web services.
Document style web service:
Document style web services are more time consuming to create, as it is the onus of the service to create the required objects from XML document.
These web services can consume large sized documents without any significant drop in performance as there are no overheads of marshalling and de marshalling associated with SOAP engine.
Document style web services are ideal for representing coarse rained functionality as a single large sized  document can be used to transfer information required to implement a business functionality.
Document style web service are primarily used for implementing asynchronous service.

RPC encoded web services are easiest  create but offers least control in terms of usage of custom data types, validation and interoperability.
RPC encoded web service are slower in performance because of added overheads of marshalling and un marshalling.
Document literal web services are harder to create but scores higher in all the above metrics and this is one of the reasons WS –I basic profile encourages the usage of document literal web services.

Document style web services are better suited for defining custom data types as they are not constrained by the usage of a particular encoding style. Document –literal web services offers the best performance and RPC –encoded web services offers the least performance as in document-literal web service overheads of marshalling and un marshalling no longer lies with SOAP engine. In a document –literal web service alternative techniques such as  SAX based parsing or custom data binding tool like XML beans, castor can be used.In case SOAP engine does not maintain state a document –literal web service can be used to carry state related data in the document. While using RPC –encoded web service often platform specific data structures are exposed in WSDL, which might not be supported by other platforms.

Posted in Web Services | Tagged: , , , , , | 10 Comments »