Short notes on SOAP messaging

SOAP is the fundamental messaging framework for web services. It is the first piece of thing you should learn and understand when starting to deal with web services. I think most of the readers of this blog possess a good understanding of the concepts and techniques of SOAP. However, this blog is not restricted to folks who are working with SOA and web services. QA testers and non-web service specific developers are also a part of target audience.
I thought to describe a set of commonly used terms in SOA and web services in fairly simple and non-technical user oriented manner so that most novice users get benefit from it.

SOAP defines a standard message format based on XML. It provides a mechanism to bind messages to different network protocols. It also defines a processing model to serialize/de-serialize messages.

Structure of a soap message

<Envelope>
 <Header>
<headerBlock1/>
</Header>
 <Body>
 <payload/>
 </Body>
 </Envelope>

SOAP message consists of 3 basic elements.
Soap Envelope

Body

Header

SOAP envelope should have one mandatory body element which contains the message payload.
One soap message can have zero or more header elements. The SOAP header is an extension that provides a way for information to be passed within a SOAP message that is not
part of the business message payload. Soap headers include information that controls QOS (quality of service) such as Security and reliable messaging.

Soap nodes are intended to receive or send soap messages in the message transmission path. If a node transmits a message it is known as a SOAP Sender. If it receives a message, then it is a SOAP Receiver. If a node does both transmitting and receiving of soap messages, then it is called a SOAP Intermediary.

The Soap sender which builds the message initially is said to be initial SOAP sender. The final target of the message is Ultimate Soap receiver. It is expected to process the payload of soap message.

There is an important attribute you may have seen in soap header elements. it is the "mustUnderstand" attribute. If this attribute is set to true, the target node should process the SOAP header block. If this attribute is false or not available, then target SOAP node can ignore processing the block.

SOAP fault is a model to handle exceptions when an error occurs in processing a soap message.
Soap fault is included in the body element of soap message.
Soap fault should have a mandatory fault code element. There are five fault codes defined in SOAP 1.1 specification.

VersionMismatch: message does not comply with the SOAP version
Sender: message was incorrectly generated when receiving node processing it
Receiver: Receiving node cannot process the message
MustUnderstand: The targeted node cannot understand the soap header
DataEncodingUnknown: The target node cannot understand the data encoding mechanism of the message

SOAP bindings allow a SOAP message to be transmitted over different transport protocols such as HTTP and SMTP.
In a web service interaction, the request and response SOAP messages can be sent via two different transports.

If you can understand the commonly used terms I explained above, you should be able to follow and explore more with the detailed reading materials published on various places.

Stay tuned. I will post a set of commonly used terms of WSDL soon.

Comments

Post a Comment

Popular posts from this blog

WSO2 Stratos - Introducing WSO2 middleware Platform as a Service (PaaS)

Image
Yesterday we released our newest integrated cloud middleware platform, WSO2 Stratos . It is now online and ready for use! For the past few years, WSO2 has been doing many releases based on revolutionary Carbon platform , which helped to consistently improve the platform with introducing latest state-of-art technologies. The initial releases of Carbon product platform intended to improve the features of the individual products. For example, a lot of core features were introduced to WSO2 ESB, WSAS, Governance Registry etc.. Then we focused on ease of integration and more component based model. We introduced Equinox based provisioning model to build your SOA platform by picking and choosing the components as and when you need. Then, the core product platform has been enhanced to support multi-tenancy. With the multi-tenant supported architecture at hand, our brilliant development team was able to introduce the first ever comprehensive middleware PaaS. Why is this so important? Now, WSO2 C...
Read more

Common mistakes to avoid in WSO2 ESB - 1 - "org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL"

In the next few weeks, you could expect a series of blog posts from me which explain the remedies to avoid some common mistakes which we do when working with WSO2 ESB . This is the first of many. During the initial rounds of testing your integration solution or even in production systems, you may have come across the following error. org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL .... Some of you may have struggled hours figuring out a solution to address this issue. Let me explain this error in detail and possible causes of this. So, next time when you see this error in your WSO2 ESB setup, you will not have to spend time unnecessarily googling everywhere. There can be many different causes of this error. I have observed  four main reasons. Cause 1 This is the simplest cause. Suppose, you have a proxy service similar to the following. <proxy xmlns="http://ws.apache.org/ns/synapse" name="MistakesTest...
Read more

Working with HTTP multipart requests in soapUI

Image
You can use HTTP request test step in soapUI to submit messages with various Content-Types.  In this post, we will have a quick look into the multipart/form-data requests in soapUI. multipart/form-data requests usually come into action when you do HTML form submissions with file attachments. For example, have a look at the following HTML form post. <form action="http://localhost:8090/CKFileUploadApp/UploadServlet" method="post" enctype="multipart/form-data"> <input type="file" name="file"> <input type="text" name="paramName"> <input type="submit" name="Submit" value="Upload File"> </form> In the forms like above, we have file upload option as a form input where we can upload a file along with the form submission. In that case, the request's HTTP content type will be multipart/form-data. How can we simulate such a request using soapUI...
Read more