(This article sort of picks up where the What are Sockets article leaves off)
SOAP is a high level protocol that rides over the common lower level HTTP protocol. What's high level and low level? When you call a vendor to order parts, you usually don't ask the receptionist who answers the phone to take the order. The receptionist functions at a lower business level, just taking calls or messages and passing them on. The receptionist doesn't know how the phones work either, that's left to the phone company one level below her. So we can say the phone company works at a low-level, the receptionist at a mid-level, and the order processing people work at a higher-level. HTTP, as it is applied with Web Services, is at the same level as the receptionist, just passing messages along. HTTP runs over the low-level TCP/IP protocols which are the base for most Web communication today. But HTTP doesn't know anything about taking orders for parts.
In keeping with the analogy, let's say you call your vendor and the receptionist connects you with Order Processing. The order taker asks who you are and what you'd like to order, and at the end of the conversation they give you an order number. The exchange is very basic and predictable. You may just as easily be able to Fax your requests in, as long as you put your customer ID in the Fax and you provide the right part numbers. When requests are processed you may get a Fax in return with your order confirmation. You might be able to e-mail your requests in as well, sending and receiving the same data. In these cases, the medium used to transport the request and response are not (or shouldn't be) related to the business function. In the Web Services and .NET article I mentioned that SOAP messages don't need to be sent via HTTP (the receptionist) but they can be sent by SMTP (e-mail) or other custom protocols, as long as both sides agree on lower level protocols which will be accepted.
SOAP is a common format that is used for passing general messages. High level SOAP messages are sent over the lower and more generalized HTTP protocol. When they are received by a remote HTTP server, they are forwarded to processes which understand the syntax of the SOAP request, which is really an XML document. To make this happen, the beginning of a SOAP request identifies the transaction as a SOAP request, rather than a request for a web page which is what HTTP normally processes.
XML tags are used to wrap around the request and data in an "envelope". The SOAP protocol details the specific tags used in the envelope. When the SOAP processor gets the request, it looks in the envelope to see which business process you want to execute. It then extracts all of the data for the business process out of the XML document, passes the data to the business process, and waits for a response. Finally, it wraps the response into an outbound XML envelope and sends it back, much like a web page is sent back to a web browser.
There is nothing in SOAP itself which is specific to a transaction type, SOAP is simply used to wrap requests and data on the way to and from business processes. By definition, it is an Access Protocol, allowing us to access remote processes. There is nothing in the SOAP definition about orders, invoices, etc. These application-specific details are left to the trading partners themselves. How do you know which business process you want to receive your request? This is something your trading partner will tell you. They will also tell you the field names that should be used to pass data in and the details of the responses you may receive back.
For more information about SOAP, Web Services, .NET, and how they all relate to the MultiValue market, see Tony Gravagno's articles which are being published in Spectrum Magazine.
Nebula Research and Development writes SOAP
client and server interfaces for business applications to conduct Web
Service transactions with remote trading partners. Web Services are also
very popular in local environments with disparate applications running
on different OS platforms. If you would like to pursue development of
SOAP interfaces to and from your business applications, please let us
know. See our contact page, or e-mail
© 2009 Nebula Research and Development
for Product and Service inquiries.