Understanding SOAP Encoding

Understanding Encoding:

I had an interesting discussion with one of my friends recently on this topic regarding use cases he is a serious Web Services guy and knows the most of the Web Service specifications too. After the talk I realized that though we developers tend to write code for encoded WSDLs we normally tend to ignore or try to understand what exactly is encoding because for most portion of the same is taken care of by the runtime server. I just thought that let me share how I understood the concept.

Encoding is the process of transformation of Message/information from one said form(at) to another said form(at). Any External system has a message/datatype representation in its proprietary way, any other system if it wants to understand in its own way has to transform this message to the one it understand. This is what the Database drivers do for us while we extract the data from the native sql/db format to the Java format.

Apart from that we can understand encoding from several perspectives. Some of those are listed below:

  • Character encoding is a code that pairs a set of natural language characters (such as an alphabet or syllabary) with a set of something else, such as numbers or electrical pulses.

What is SOAP Encoding?

Transforming the messages of other Language(s) into the SOAP type format. The SOAP encoding style is based on a simple type system that is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. Section 5 of SOAP 1.1 specification lays the rules for the SOAP vendors the rules for serialization of a graph of typed objects. If the client and server confirm to the Encoded WSDL both will talk in terms of SOAP Encoding.

SOAP Encoding as per specification does the following things:

  • Given a schema in any notation consistent with the type system described, a schema for an XML grammar may be constructed

  • Given a type-system schema and a particular graph of values conforming to that schema, an XML instance may be constructed. In reverse, given an XML instance produced in accordance with these rules, and given also the original schema, a copy of the original value graph may be constructed.

The SOAP Encoding also provides mappings from programmatic data types (The native data types) to the data types found in XML Schema Part 2: Datatypes. Given a programmatic data structure, the name and type of each element in the serialized XML can be determined.

Having said that where is the use of SOAP:Enc?

If we have the WSDL as the starting point for the Web Service implementation we have the data types involved in the types section either in the in-line schema or as imported XSDs. However we have several instances the services are already running with proprietary data types and there is need for us to expose already running processes as Web Service. We do not have a choice here to implement right from scratch by defining type system in XSDs import them in the exposed WSDL and use them rather we need to start with some programmatic data structure. Ideally we need to expose this also in the WSDL since the client for the WSDL needs to know what is the data structure involved in the message exchange. Obviously transforming the programmatic data types to XML is the only choice. SOAP Encoding as said lays rules for mapping compound data structures, array types, and reference types and construction of the Object graphs for these structures.

Issues in transforming Programmatic Data Types into XML in SOAP Encoding:

  • The legacy system might have declared a variable with a name that might confirm to its own type system but non XML conforming name, Appendix A of the spec provides a mapping algorithm.

  • Mapping of reference types: It involves serializing the instance and marking it with an unqualified attribute whose local name isid. All other references to that instance are then serialized as empty elements with an unqualified attribute whose local name ishref. The value of thehrefis a URI that references the relevant serialized instance via itsidattribute. This mechanism provides a way to serialize graphs, including cyclic graphs in XML.

  • Type Casting: It is worth noting that the foregoing message carries enough information for the receiver to figure out the type of all the elements. This is because the type is tied to the element name. Both sender and receiver know what the names of the elements are. And they also know the names and types of the fields in the programmatic data type. Given that the element name is so closely tied to the field name, the type of the element can also be determined.

  • Run Time Type Identification(RTTI): In some cases where exact type information may not be known until runtime. Incase of the data types, CORBAany, COMVARIANT, or JavaObject theweb service specifies nothing about the type of the data at design time and the type information is only available at runtime. The SOAP Encoding rules allow the use of thetypeattribute from the http://www.w3.org/2001/XMLSchema-instance namespace to be used to specify that a particular type is being passed at runtime.

For example Address is defined with 2 fields street1 and street2 and USAddress extends from Address and has the 3 rd field zip too in a proprietary type system. In Java the same will be represented as

public class Address{

String street1;
String street2;


public class USAddress extends Address{

String zip;


The same is represented as follows:

<address xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:type="USAddress" >



In the above example though the Address in the Message looks like above during the runtime the same would be replaced by the USAddress. All such services in reality “ do not accept” absolutely any type but work on a reasonably small subset of types, generating errors when unknown types are encountered.

Thexsi:typeattribute is of typeQname so, the above example refers to an unqualifiedUSAddresstype. In fact a namespace should be assigned to types to avoid name clashes. Observation says that thexsi:typeis only needed when the exact type is not known until runtime. In cases where both sides know the types in advance,xsi:type, is redundant, and in most of the cases in such WSDLs the expected types are known.


Post a Comment:
Comments are closed for this entry.

I was part of Sun R&D in Java CAPS and later Glassfish ESB. I moved from R&D to Consulting. I am currently working as a Solution Architect in Oracle Consulting Services (India). I was sharing my experience w.r.t. Java CAPS and other technologies during Sun period. Now in Oracle world I share my experiences with Oracle FMW product line as well as other Oracle Technologies and products.


« April 2014