SOAP

This article is about the Internet Protocol. For further meanings see soap .

SOAP in the TCP / IP protocol stack :

application	SOAP
	HTTP		HTTPS		...
transport	TCP
Internet	IP ( IPv4 , IPv6 )
Network access	Ethernet	Token bus	Token ring	FDDI	...

SOAP (originally for Simple Object Access Protocol ) is a network protocol with the help of which data can be exchanged between systems and remote procedure calls can be carried out. SOAP is an industrial standard of the World Wide Web Consortium (W3C).

SOAP is based on XML to represent the data and on Internet protocols of the transport and application layer (cf. TCP / IP reference model ) to transmit the messages . The most common combination is SOAP over HTTP and TCP . SOAP can also be used over SMTP or JMS , for example. The user data transmitted with the message do not necessarily have to be sent in XML; other formats such as Base64 or CSV are also possible. The abbreviation SOAP is no longer officially version 1.2 as acronym used since it first, (subjectively) by no means simple (Simple) , and secondly, not only access to objects (Object Access) is used.

history

Dave Winer (the "father" of RSS 2.0) and Microsoft developed the specification for XML-RPC in 1998 . As a further development from this, SOAP emerged, which was published in version 0.9 at the end of 1999. However, the reaction of the developers was still very cautious. Version 1.0 was released later in 1999. That was when the development found more support. This can be seen mainly from the fact that IBM joined the development of SOAP in 2000, which led to IBM, Microsoft, DevelopMentor (Don Box) and UserLand Software (Dave Winer) adopting the SOAP 1.1 specification on the World Wide Web Consortium (W3C) submitted. The aim was to initiate a working group to develop SOAP further. The result of this working group is SOAP Version 1.2, the recommendations (in June 2003 English recommendation ) was recognized. An important change was that SOAP is no longer an acronym , since all interpretations for SOAP , such as Simple Object Access Protocol or Service Oriented Architecture Protocol , do not meet the full meaning of SOAP. The fact that SOAP is no longer understood as a common abbreviation made it possible to register SOAP as a brand name in the USA.

Working method

SOAP is a protocol for the exchange of XML information set- based messages over a computer network and has the status of a W3C recommendation. It lays down rules for message design. It regulates how data is to be mapped and interpreted in the message, and provides a convention for remote procedure calls using SOAP messages. SOAP makes no provisions for the semantics of application-specific data to be sent, but provides a framework ( framework ) is available which allows any application-specific information can be transmitted. SOAP is used for remote procedure calls as well as for simple message systems or for data exchange . Any transport protocol can be used to send messages , for example FTP , SMTP , HTTP or JMS . In practice, due to its compatibility with common network architectures (such as firewalls), HTTP is usually used. The encrypted transmission of SOAP messages is also possible using HTTPS . However, this does not allow end-to-end encryption. This is made possible by WS-Security , which starts at the message level and not at the level of the underlying transport protocol. When using HTTP (S), the XML information set of the SOAP request is sent as XML to a given URL in the body of an HTTP POST request .

SOAP is regularly used where direct access from external systems to a source of information does not make sense. This can be due to compatibility problems between different application architectures, but also to security aspects. This enables (partial) access to a database without the user program having to be granted direct access. The number of executable methods can be regulated and defined via the SOAP interface.

Communication with SOAP enables the coupling of systems, but the open design of SOAP only allows the construction of weakly coupled systems. The flexibility of the concept is bought at the cost of disadvantages in terms of transmission volume and computing effort . The XML document must first be set up at the sender and then validated. The concept pursues the goal of a lightweight protocol, but due to the flexible area of ​​application, the file to be transferred carries a series of metadata that is added when the XML document is constructed. For example, simply sending “true” or “false” leads to a data volume of several hundred bytes, although theoretically one bit would be sufficient in a strongly coupled system. Due to the possibility of the flexible structure of the document, however, complex transactions can be combined atomically in one request , while in strongly coupled systems often several requests have to be made for this purpose. This improves the payload ratio (payload to metadata) and the communication effort (for setting up a connection, only one send / receive).

SOAP distinguishes between the ultimate recipient and intermediate recipients. This makes it possible to send a message via different "hops", in which even different transport protocols are used. For example, the message can be sent to the first hop using the Java Message Service , then via e-mail and finally to the recipient using HTTP. The sender does not have to have any information about the intermediate hops, but the middleware does.

Structure of SOAP messages

SOAP structure

A minimal SOAP message consists of an element called an envelope to which a local name must be assigned. This element references by means of a namespace attribute http://www.w3.org/2003/05/soap-envelope. The child of this element must be a body element. A header element can optionally be added beforehand . Meta information, for example on routing, encryption or transaction identification, can be accommodated in this. The actual user data is housed in the body element.

Structure of a SOAP message:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

The body element can contain both information on data exchange and instructions for a remote procedure call. This is to be interpreted accordingly by the recipient.

The next hop (intermediary) and the final recipient (ultimate recipient) are specified in the header. For example, an intermediary can encrypt the message, log it or split the message. The former means that the application logic does not have to worry about the security of the message, but that the middleware takes over. The possibility that intermediaries can do anything is made possible by enterprise application integration, for example with the EAI patterns from Gregor Hohpe and Bobby Woolf.

Working with SOAP

SOAP is used for database queries via an Internet interface. For example, eBay or Amazon use this technology to process search queries. In the following, an Internet interface should be used to inquire at a central database whether there is a work with the title “DOM, SAX and SOAP”, and if so, this will be returned. This database provides the "TitleInDatabase" method for this purpose, which requires the title as input. A request could then look like this:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Body>
        <m:TitleInDatabase xmlns:m="http://www.lecture-db.de/soap">
            DOM, SAX und SOAP
        </m:TitleInDatabase>
    </s:Body>
</s:Envelope>

This SOAP request does not contain a header element. The "TitleInDatabase" element is not part of the SOAP definition, but application-specific. The server receives the message and evaluates it. Both SAX and DOM can be used to read in the message . In this case, a SAX parser may be recommended that calls a corresponding database query on "startElement (" TitleInDatabase ", [...])", whose input value is read in at the next "character event". In this way, parallelism can be achieved between reading in and evaluating the message. Then, in this example, a SOAP message is returned as a response:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Header>
        <m:RequestID xmlns:m="http://www.lecture-db.de/soap">a3f5c109b</m:RequestID>
    </s:Header>
    <s:Body>
        <m:DbResponse xmlns:m="http://www.lecture-db.de/soap">
            <m:title value="DOM, SAX und SOAP">
                <m:Choice value="1">Arbeitsbericht Informatik</m:Choice>
                <m:Choice value="2">Seminar XML und Datenbanken</m:Choice>
            </m:title>
        </m:DbResponse>
    </s:Body>
</s:Envelope>

The server has attached a header element to its response , which in this example returns the request identifier. The requested information can be found in the body of the message. In this case, two pieces of work were found and sent back to the requesting system. In the following, this leads to mutual communication, a dialog-oriented exchange of XML documents using SOAP, at the end of which the requested element will be transmitted.

Implementations

• Apache CXF (continuation of Codehaus XFire ), Apache Axis ( Java EE ), mSOAP, kSOAP and Java API for XML Web Services API for Java
• AWS Web Development Framework
• Curl package in CURL.XML.SOAP
• cSOAP and gSOAP for C / C ++
• PHP: SOAP, nuSOAP and PEAR SOAP project for PHP
• Python SOAP, ZSI, SOAPpy and SUDS are SOAP libraries for Python
• SOAP :: WSDL open source toolkit for Perl
• SOAP for VisualWorks Smalltalk
• WebMethods GLUE
• SOAP4R and Savon for Ruby
• TCLSOAP for the scripting language Tcl
• 4th dimension
• Qt Soap Part of the Solutions (add-on) of the Qt library
• KDSOAP Qt4 / 5 native library with a converter from WSDL to C ++ / Qt
• FEAST A client-server framework for the Qt library
• wsdl2objc Open source toolkit for Objective-C
• .NET Framework 2.0: For serialization purposes in System.Runtime.Serialization.Formatters.Soap, System.Web.Services
• .NET Framework 3.x / 4.x: WCF , System.Web.Services

Extensions based on SOAP

• WS-Reliability (Web Services Reliability): Security mechanisms, e.g. B. To be able to process transactions reliably
• WS-Security (Web Services Security): Ensuring the integrity and confidentiality of messages
• WSRP (Web Services for Remote Portlets): Integration of presentation logic in portals
• further specifications: WS- *
• TR-069 CPE WAN Management Protocol (CWMP)

See also

• Service Oriented Architecture (SOA) - architecture based on SOAP or similar protocols
• UDDI (based on SOAP; uses SOAP)
• WSDL - description language for SOAP-based interfaces including a message description
• SoapUI - tool for testing SOAP messages
• Hessian , Burlap - alternative protocols
• MTOM - protocol for sending binary data within SOAP messages
• SOAP with Attachments - W3C proposal for the transport of SOAP messages within MIME messages
• DSSP - a SOAP-based protocol for the Microsoft Robotic Developer Studio

Further:

• REST
• CORBA
• Middleware
• Component (software)
• Component-based development
• Internet Communications Engine (ICE)
• Universal Network Objects

Web links

• W3C: SOAP Specifications (English)
• XML protocol activity (English)
• Example for a web service with Java / SOAP step-by-step instructions for the implementation of a web service in Java with SOAP (status: 2008, German)
• Technology report (English; xml.coverpages.org)
• Security for SOAP with Tomcat and AXIS (PDF; German)

Individual evidence

1. ↑ en: SOAP Version 1.2 Email Binding
2. ↑ en: SOAP over Java Message Service 1.0
3. ↑ en: SOAP Message Construct
4. ↑ en: XmlCsvReader Implementation
5. ↑ en: SOAP Processing Model
6. ↑ en: Patterns and Best Practices for Enterprise Integration
7. ↑ TclSOAP
8. ↑ ( Web Services Reliable Messaging TC WS-Reliability 1.1 )
9. ↑ ( Web Services Security ( Memento from September 16, 2012 in the Internet Archive ))
10. ↑ ( Web Services for Remote Portlets Specification )
11. ↑ Decentralized Software Services Protocol - DSSP / 1.0