SOAP--Simple Object Access Protocol

Editor's Notes

• #2: Introduce yourself Today, I am going to talk about SOAP
• #3: We know two types of SOAP so far. However, in this talk I would focus on a different type of SOAP This is a communication protocol. So SOAP stands for Simple Object Access Protocol It’s a protocol for web service.
• #4: Now before, we jump into the talk, you will probably hear these terms frequently– Web application which means a client-server application where the client runs in a web browser. Web Service: A software system which is designed to support machine-to-machine communication over the network. Web service can be a part of a large web application. WSDL: Web Service Description Language. It is the XML-based specification for the web service. That means the functions/parameters the service provides. Then comes SOAP: Simple Object Access Protocol, it’s the protocol for web service. That means this protocol is followed during web service consumption. Interoperability: It’s a property of a system that ensures that the system has clear interfaces for communication with other systems.
• #5: This is the outline of my talk: Quite a big talk, so, please get ready  Our talk will have a hierarchical structure. First, we focus on web service as logical fist step. We will touch its overview and evolution history, and then we will explore the architecture. Right now, there exist two dominant architecture– SOAP based and REST based. We will basically explore the SOAP, REST will be done by another speaker. In the SOAP, we will focus on its history, evolution, specification, security and finally a working example (like a tutorial) We will also contrast between REST and SOAP.
• #6: Web service is a component of web application It can be also considered as an API over the internet using HTTP/SMTP But, it targets machine-2-machine communication. There are two flavors of web service—XML based SOAP, and JSON/XML based REST REST based services are also called Web API nowadays. Services are listed by UDDI directory using WSDL or WADL descriptions.
• #7: Now lets look at the history of the web service By 1997: HTTP, TCP/IP were widely accepted by the major companies all over the world as standard communication protocol. Now they need a message passing protocol which came at 1998. XML 1.0 was standardized by W3 Consortium. By this time Dave Winer and colleagues developed XML-RPC, remote procedure call is a hot topic then. However, XML-RPC is standardized as SOAP. SOAP 1.0 came at 1999, although developed at 1998. Due to internal politics of Microsoft, it was postponed. Anyway, MSFT quickly demoed to IBM, IBM liked it and started cooperating. Soon SOAP 1.1 came out, and later accepted by W3C. MSFT also worked with IBM, and announced WSDL at 2000 Later, they worked with Arriba, and announced UDDI 1.0 (Universal Description, Discovery and Integration) More interestingly, five giants came to a contract to promote web services. Not sure, if that still exist or not.
• #8: This is evolution from MSFT’s perspective. First, Microsoft used COM for talking among different applications from different languages. Then comes DCOM, that enables RMI with DCOM. Then comes DotNet Remoting which proves SAAS using TcpChannels. Very useful for legacy business machines. Then comes Web service, it is more generic, and provides method call service using existing protocols such HTTP, TCP/IP and SOAP. Then comes WCF, it improves web service to next level. It targets Service Oriented Architecture (SOA), and also provides JSON support+ others.
• #9: Now we will see the sequence of their operations: Once the service provider is done with service development, it can contact the Discovery agency for service listing and publishing. The provider basically sends the WSDL file that describes the specification of the service. The UDDI directory keeps the WSDL file, and the service requestor requests for a service. The discovery agency then sends the WSDL file. The requestor then develops a client that can consume the service. In this stage, the client directly communicates with service provider for the service, and here comes the SOAP. The client follows SOAP for communication with the provider.
• #10: Now we will see the sequence of their operations: Once the service provider is done with service development, it can contact the Discovery agency for service listing and publishing. The provider basically sends the WSDL file that describes the specification of the service. The UDDI directory keeps the WSDL file, and the service requestor requests for a service. The discovery agency then sends the WSDL file. The requestor then develops a client that can consume the service. In this stage, the client directly communicates with service provider for the service, and here comes the SOAP. The client follows SOAP for communication with the provider.
• #11: These are the tools available for publishing and finding services from the UDDI, the public service registry for web services. Also, big generations have their private UDDI directories for publishing and consuming services. Different languages created tools for UDDI.
• #12: So far, we were discussing web service in general. Now, lets get into SOAP, the messaging protocol for web service.
• #13: SOAP stands for Simple Object Access Protocol– as we said. Although its basically XML based RPC, but probably borrow idea from COM or DCOM, the earlier technologies from Microsoft. So, its an XML based messaging protocol for the web applications. Mostly targeted for machine-to-machine communication. It defines a set of rules for message passing. Not tied to any OS, programming language or protocol. By due wide adoption of HTTP/SMTP, it is implemented over those protocols. SOAP got W3C recommendation on 2003 It was created by Dave Winer from Userland Soft. & Microsoft.
• #14: Now lets see a quick example for the use-case of SOAP. Suppose, a large organization wants to provide a service that offers employee’s contact information within the organization, and a large database contains such info. Now, service module is developed with a listener attached to it. Now if a client application wants to get that service, it has to communicate using SOAP. The client will encapsulate the request contact for an employee as a SOAP request. The listener will decode that request, and forwards the request to the service provider. The service provider accesses the database, and returns the contact info. Then the result will be encoded as a SOAP response, and sent back to the client. So, SOAP is basically a messaging protocol like other protocols.
• #15: Now, we check the evolution history, and then we go to the detailed architecture. As discussed earlier SOAP came out at 1999 although its development started on 1998. But it was not published XML was not standardized. In 1998, XML 1.0 came out from W3C consortium. Then SOAP 1.0 appeared, but it was quite preliminary at that stage. However, IBM liked the idea from Microsoft, and worked together to bring out SOAP 1.1. Then eventually came other technologies like WSDL, UDDI. Still SOAP 1.1 is still popular and widely used probably. Then in 2007, XML Protocol working group provided SOAP 1.2. It’s a major improvement over SOAP 1.1. For example, it provides better support for interoperability, extensibility. It makes SOAP as protocol independent, and provides better support for web standard such as internationalization.
• #16: Now SOAP message is developed based on the information on the available WSDL file. It contains also four sections: Types, message, portType, and binding. Types section describes the XML data types for all input/output parameters used in the web service. Message section defines each of the input/output message items to be communicated with. PortType enlists the available functions offered by the service. Binding defines the protocol and data format for each operation offered.
• #17: An WSDL file looks like this. Looks quite scary, right? Very unreadable. Originally, web service is targeted for machine-to-machine communication. So, machine can read this file pretty well, which we will se later.
• #18: Anyway, if we get the Tree View of the file, we can easily identify the elements. For example, we can see the types that defines the data types for the messages. Then the message section that defines the messages. Then here is the portType that shows the operation allowed. Then the binding section that binds the operations with protocol– HTTP/SMTP Then the service name, service end points.
• #19: This is the skeleton of a SOAP message in general. For both SOAP request or response, it will have these four elements. The whole message is encapsulated in an Envelope element. The envelop must contain the encoding information, and it has to be SOAP-encoding. The comes the optional header, it will contain SOAP message-specific information such as authentication, payment etc. It must be the first element in the message. Then comes the body. It will contain web service function name and Fault section. The Fault section contains info about the fault occurred.
• #20: This is an Example SOAP request. This is the optional header. Here we can see the method name + parameters which we are calling from the client. For example, we are asking for the factorial of 8.
• #21: This is the SOAP response from the server. Here we see the message name GetFactorialResult. It contains our result, factorial of 8.
• #22: Now, we know SOAP sits on top of HTTP. So, when SOAP call made using HTTP post, the whole request looks like this. This is the HTTP method and headers. And, then this is the SOAP request. This whole message is sent over the protocol. This is useful, because SOAP can use the popular protocol. And 100% of the machines support HTTP nowadays, even the firewalls. So, SOAP is truly platform-independent.
• #23: Now, lets focus on the security. Secure operation can be done using SOAP. HTTP provides transport layer security using SSL, but web service security ensures application layer security. Basically it has three focuses– message integrity, confidentiality and user identity. Message integrity checks if the sent message is not tampered– using XML signature. Message confidentiality encrypts the message—using XML encryption. User identity checked using hashed credentials.
• #24: For example, here we can see the user credentials are added into the SOAP header. So that the identity of the user can checked in the application layer. For example, in the banking transaction. However, this additioanl security payload increases message size, and reduces the performance. So, people worked to optimize the message size.
• #25: One such mechanism is message transmission optimization mechanism MTOM. Especially targeted for sending attachments using web service. By default, an Image will be converted to XML data type base64Binary string, a long string. This optimization do not send the attachment directly rather sends the reference to the image. Thus, message size reduced.
• #26: There are also significant improvements on web services as a whole. For example, WS-addressing is found to enable SOAP message routing. In the case of data exchange, WS-Policy and resource frameworks are introduced. In the case of security, key management + trust mechanisms are introduced.
• #27: Now, comes the important part. Which one to choose? SOAP or REST. First of all, SOAP is a protocol and REST is a architectural style. However, we always get some metrics to compare. For example….
• #28: Now, these are the tools available for SOAP-based web service implementation. Several from Apache, some from Mircosoft, and some from PHP community. Many of them support both SOAP and REST. Many use both XML and JSON, to make them useful. However, we used to of these Apache Axis, and Microsoft WCF.
• #30: Now lets go to the demo..
• #33: Thanks!
• #34: Thanks for your time. Questions!!