XML Messaging: Simple Object Access Protocol (SOAP)

XML Messaging: Simple Object Access Protocol (SOAP) Authors Gabriel Toma-Tumbãr: GabrielToma-Tumbar@ucvro Dan-Ovidiu Andrei: DanAndrei@ucvro University of Craiova Faculty of Automation, Computers and Electronics Computer and Communications Engineering Department Lapusului Street, nr 5 Abstract In the past, communications between software systems, especially those between two or more different organizations, has often been cobbled together with a variety of ad-hoc methods and proprietary protocols This approach to integrating software is often difficult, expensive and time-consuming, especially when the number of connections the organizations have to support increase Over the past years, there has been enormous work in the area of interoperability between different systems This article presents an emerging technique that gains more and more supporters from the IT world: XML messaging Keywords XML messages, SOAP (Simple Object Access Protocol), SOAP-RPC, systems interoperability, WSDL 1 Overview Messaging systems came into being with the first networks, and a variety of messages are exchanged over computer networks Naturally, one thinks first of the ubiquitous e-mail; however, many other types of valuable data are moved over networks, making messaging systems very important in enterprise-level computing, even without e-mail There has been a recent trend to recognize messaging systems as a separate class of application, frequently called Message- Oriented Middleware (MOM) A MOM system takes responsibility for transmitting application messages over a network and provides support for load balancing, fault tolerance, and transactions Basically, there are two models for messaging: point-to-point and publish/subscribe However, there has been a great deal in trying to standardize the messaging protocols used The XML messaging technology appeared as a normal improvement over all proprietary messaging protocols 2 XML as a Data Representation and Messaging Standard XML is one of the key technologies that is driving enterprise Web development today XML promises a standard data format that can be shared easily across applications and especially by different organizations that need to share data XML is shaping up as a key technology in distributed applications One couldn't have missed it in the hype happening in the trade papers But unlike other overhyped technologies XML has been rapidly accepted because it solves very specific technical problems by using a standard protocol/data representation The simple act of agreeing to a common data format for data is making data exchange drastically easier than it ever was before Even in its simplest form XML as a standard has lots of potential as a data representation and messaging mechanism Data representation typically involves translating the data from a native format into XML, and then back into the same format or even a completely different one on the other end of a connection Another huge benefit of XML as a data representation mechanism is that XML can combine multiple pieces of data into a single document The markup language has support for stacked and hierarchical data representation XML documents can combine several separate entities (be it tables, objects, messages or metadata) into a single XML document For example, one can send the actual data of say a table, as well as a message header that describes the data or maybe contains any error conditions that might have occurred in obtaining that data One could also combine multiple tables (as an example) into a single document Or a table and an object both parsed into XML 3 SOAP Messages Most people tend to think of SOAP as nothing more than a protocol for Remote Procedure Calls (RPC) over Hypertext Transfer Protocol (HTTP) However, this is only one implementation of SOAP, which is defined as a lightweight protocol for passing structured and typed data between two peers using XML The specification doesn t require the use of HTTP or even a request/response type of conversation Instead, SOAP can be used with any protocol that supports the transmission of XML data from a sender to a receiver In fact, both Microsoft and IBM have implemented

SOAP messages over SMTP, which means SOAP messages can be routed through e-mail servers One of the key goals of the Web services movement has been to develop a set of universally-supported protocols that enable "snap-together" system-to-system communication on a much larger scale than in the past SOAP is one such protocol; it defines an XML-based encoding and enveloping standard for system-to-system communication The fact that SOAP can be used over SMTP (instead of HTTP) means that SOAP can be used as an asynchronous method of remote procedure calling SOAP requests are emailed via SMTP to a mailbox on a server SOAP over SMTP contains a process for picking up those emails and executing the SOAP request and then emailing the SOAP response back to the sender Both the client and the server can pick and respond to the SOAP emails at any point in time This asynchronous methodology may prove useful for applications executed over long time intervals, or run over short connection times on low bandwidth modems Figure 2 - The SOAP Message Process The SOAP envelope is analogous to the envelope of an actual letter It supplies information about the message that is being encoded in a SOAP payload, including data relating to the recipient and sender, as well as details about the message itself For example, the header of the SOAP envelope can specify exactly how a message must be processed Before an application goes forward with processing a message, the application can determine information about a message, including whether it will even be able to process the message SOAP Envelope SOAP Header Figure 1 SOAP Messaging The bottom line is SOAP is nothing more than a lightweight messaging protocol, which can be used to send messages between peers The main goals of SOAP are focused on providing a common way to package message data and define encoding rules used to serialize and deserialize the data during transmission Another goal was to provide a model that can be used to implement RPC operations using SOAP All these goals are considered orthogonal in the specification, which means they are independent, but related For example: A SOAP message should define encoding rules, but these rules needn t be the same rules defined in the specification There are three basic components to the SOAP specification: the SOAP envelope, a set of encoding rules, and a means of interaction between request and response SOAP Body Figure 3 - SOAP Message Structure Below are given some examples of SOAP messages over HTTP, the most used method of transporting SOAP messages It can be easily seen that it does not differ too much from the HTTP protocol There can be found, as a plus, only the SOAPAction header field The response, however, does conform with all the rules of the HTTP standard POST http://wwwexamplecom /HelloApplication HTTP/10 Content-Type: text/xml; charset="utf-8" Content-Length: 587 SOAPAction: "http://wwwexamplecom/helloapplication# sayhelloto" xmlns:soap- ENV="http://schemasxmlsoaporg/soap/enve lope/"

xmlns:xsi="http://wwww3org/1999/xmlsche ma-instance" xmlns:xsd="http://wwww3org/1999/xmlsche ma" <SOAP-ENV:Header </SOAP-ENV:Header <SOAP-ENV:Body <ns1:sayhelloto xmlns:ns1="hello" SOAP- ENV:encodingStyle="http://schemasxmlsoap org/soap/encoding/" <name xsi:type="xsd:string"hello World!</name </ns1:sayhelloto </SOAP-ENV:Body </SOAP-ENV:Envelope Example 1 - SOAP Request HTTP/10 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 615 xmlns:soap-env=" http://schemasxmlsoaporg/soap/envelope/ " xmlns:xsi="http://wwww3org/1999/xmlsche ma-instance" xmlns:xsd="http://wwww3org/1999/xmlsche ma" <SOAP-ENV:Body <ns1:sayhellotoresponse xmlns:ns1="hello" SOAP- ENV:encodingStyle="http://schemasxmlsoap org/soap/encoding/" <return xsi:type="xsd:string"hello There, How are you doing?</return </ns1:sayhellotoresponse </SOAP-ENV:Body </SOAP-ENV:Envelope Example 2 - SOAP Response Message 4 RPC or Messaging? The first task is actually not code-related but designrelated One needs to determine if an RPC service or a messaging one is wanted A client invokes a remote procedure on a server somewhere, and then gets some sort of response In this scenario, SOAP is simply acting as a more extensible XML-RPC system, allowing better error handling and passing of complex types across the network This is a concept one should already understand, and because it turns out that RPC systems are simple to write in SOAP The second style of SOAP processing is message-based Instead of invoking remote procedures, it provides for transfer of information As one can imagine, this is pretty powerful, and doesn't depend on a client knowing about a particular method on some server It also models distributed systems more closely, allowing packets of data (packet in the figurative sense, not in the network sense) to be passed around, keeping various systems aware of what other systems are doing It is also more complicated than the simpler RPC-style programming Like most design issues, the actual process of making this decision is left up to you Look at your application and determine exactly what you want SOAP to do for you If you have a server and a set of clients that just need to perform tasks remotely, then RPC is probably well suited for your needs However, in larger systems that are exchanging data rather than performing specific business functions on request, SOAP's messaging capabilities may be a better match 5 Handling Attachments with SOAP Web services will require the ability to send more than just text messages between services in a process Often it will involve complex data types such as language structures, multimedia files, and even other embedded messages A SOAP message may need to be transmitted together with attachments of various sorts, ranging from facsimile images of legal documents to engineering drawings Such data are often in some binary format For example, most images on the Internet are transmitted using either GIF or JPEG data formats This kind of SOAP Messages are called SOAP message package A "SOAP message package" contains a primary SOAP 11 message It may also contain additional entities that are not lexically within the SOAP message but are related in some manner These entities may contain data in formats other than XML The primary SOAP 11 message in a message package may reference the additional entities Such additional entities are often informally referred to as "attachments" This section describes how to construct SOAP message packages and how SOAP processors will process them A SOAP message package is constructed using the Multipart/Related media type, which is defined in RFC 2387 The rules for the construction of SOAP message packages are as follows: 1 The primary SOAP 11 message must be carried in the root body part of the Multipart/Related structure Consequently the type parameter of the Multipart/Related media header will always equal the Content-Type header for the primary SOAP 11 message, ie, text/xml 2 Referenced MIME parts must contain either a Content-ID MIME header structured in accordance with RFC 2045, or a Content-Location MIME header structured in accordance with RFC 2557 POST /insuranceclaims HTTP/11 Host: wwwexamplecom Content-Type: Multipart/Related; boundary=mime_boundary; type=text/xml; start="<claim061400axml@examplecom" Content-Length: XXXX

SOAPAction: http://schemasriskystuffcom/auto-claim Content-Description: This is the optional message description Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: 8bit <claim061400axml@examplecom <?xml version='10'? xmlns:soap- ENV="http://schemasxmlsoaporg/soap/enve lope/" <SOAP-ENV:Body <claim:insurance_claim_auto id="insurance_claim_document_id" xmlns:claim="http://schemasriskystuffcom/auto-claim" <thesignedform href="cid:claim061400atiff@examplecom"/ <thecrashphoto href="cid:claim061400ajpeg@examplecom"/ <!-- more claim details go here -- </claim:insurance_claim_auto </SOAP-ENV:Body </SOAP-ENV:Envelope Content-Type: image/tiff Content-Transfer-Encoding: base64 <claim061400atiff@examplecom Base64 encoded TIFF image Content-Type: image/jpeg Content-Transfer-Encoding: binary <claim061400ajpeg@examplecom Raw JPEG image -- Example 3 SOAP/HTTP message with an attached facsimile image 6 WSDL and SOAP Applications Web Services Description Language (WSDL) is a new specification to describe networked XML-based services It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as Simple Object Access Protocol or XML) or encoding (such as Multipurpose Internet Messaging Extensions) WSDL is a key part of the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business Definition: WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint Related concrete endpoints are combined into abstract endpoints (services) WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 11, HTTP GET/POST, and MIME [3] As communication protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication A WSDL document defines services as collections of network endpoints, or ports In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations The concrete protocol and data format specifications for a particular port type constitutes a reusable binding A port is defined by associating a network address with a reusable binding, and a collection of ports define a service Hence, a WSDL document uses the following elements in the definition of network services: Types a container for data type definitions using some type system (such as XSD) Message an abstract, typed definition of the data being communicated Operation an abstract description of an action supported by the service Port Type an abstract set of operations supported by one or more endpoints Binding a concrete protocol and data format specification for a particular port type Port a single endpoint defined as a combination of a binding and a network address Service a collection of related endpoints [3] In addition, WSDL defines a common binding mechanism This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint It allows the reuse of abstract definitions <?xml version="10" encoding="utf-8"? <definitions? <types

<schema targetnamespace="somenamespace" xmlns:typens="somenamespace" <xsd:complextype name="person" <xsd:sequence <xsd:element name="firstname" type="xsd:string"/ <xsd:element name="lastname" type="xsd:string"/ <xsd:element name="ageinyears" type="xsd:int"/ <xsd:element name="weightinlbs" type="xsd:float"/ <xsd:element name="heightininches" type="xsd:float"/ </xsd:sequence </xsd:complextype </schema </types <message name="addperson" <part type="typens:person"/ </message name="person" <message name="addpersonresponse" <part name="result" type="xsd:int"/ </message </definitions 8 References Example 4 - WSDL File [3] 1 W3C Web site: http://wwww3org/tr/soap 2 SOAP With Attachments: http://wwww3org/tr/2000/note-soapattachments-20001211 3 WSDL: http://wwww3org/tr/2001/note-wsdl- 20010315 4 Bill Brogden SOAP Programming with Java 5 Joshy Joseph Transferring foreign objects with Apache SOAP 22 6 Jurvis, J Evolution of Mobile Web Services 7 Stahl, R Building distributed applications with XML messaging 8 Tapang, Carlos Web Services Description Language (WSDL) Explained 9 Tony Hong Advancing SOAP Interoperability 10 Uche Ogbuji Using WSDL in SOAP Applications