Introduction to SOAP

11,509 views
11,236 views

Published on

the presentation that i made for my soa class. summer, 2009

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
  • As html tutorial i used http://phpforms.net/tutorial.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
11,509
On SlideShare
0
From Embeds
0
Number of Embeds
82
Actions
Shares
0
Downloads
514
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Introduction to SOAP

  1. 1. Introduction to SOAP by H. Fırat Güvence Simple Object Access Protocol
  2. 2. What is SOAP? • SOAP stands for Simple Object Access Protocol • Simply; ▫ XML formatted message in order to exchange information among applications or services. • SOAP is a standard that defines the Web Services protocol. While HTTP is the low-level protocol, also used by the Internet, SOAP is the specific format for exchanging Web Services data over this protocol
  3. 3. What is SOAP? • SOAP is a communication protocol • SOAP is for communication between applications • SOAP is a format for sending messages • SOAP communicates via Internet • SOAP is platform independent • SOAP is language independent • SOAP is based on XML • SOAP is simple and extensible • SOAP allows you to get around firewalls • SOAP is a W3C recommendation
  4. 4. A little bit about its history • SOAP was originally designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998, with backing from Microsoft (where Atkinson worked at the time), as an object- access protocol. • The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium. • SOAP is now recommonded by W3C
  5. 5. Advantages • Using SOAP over HTTP allows for easier communication through proxies and firewalls than previous remote execution technology (but not required!). • SOAP is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols are also usable (e.g. SMTP, RSS). • SOAP is platform independent. • SOAP is language independent. • SOAP is simple and extensible.
  6. 6. Disadvantages • SOAP can be considerably slower than competing middleware technologies. • When relying on HTTP as a transport protocol and not using WS- Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases. • Most uses of HTTP as a transport protocol are done in ignorance of how the operation would be modeled in HTTP. This is by design (with analogy to how different protocols sit on top of each other in the IP stack), but the analogy is imperfect (because the application protocols used as transport protocols are not really transport protocols). Because of this, there is no way to know if the method used is appropriate to the operation. This makes good analysis of the operation at the application-protocol level problematic at best with results that are sub-optimal (if the POST-based binding is used for an application which in HTTP would be more naturally modeled as a GET operation). • Although SOAP is an open standard, not all languages offer appropriate support. Java, .NET and Flex offer excellent SOAP integration and/or IDE support. Python and PHP support is much weaker.
  7. 7. Mutual Relations • WSDL is to list available services • SOAP is a protocol in order to exchange information through defined services by WSDL (is not always true) … <binding name="CustomerSOAPBinding“ interface="tns:CustomerInterface“ type=http://www.w3.org/2006/01/wsdl/soap wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <operation ref="tns:getCustomerAddress“ wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> <service name="CustomerService“ interface="tns:CustomerInterface"> <endpoint name="CustomerEndpoint“ binding="tns:CustomerSOAPBinding" address=http://soa-in-practice.com/customer20 /> </service> …
  8. 8. Some Technical Specifications • Syntax ▫ A SOAP message MUST be encoded using XML ▫ A SOAP message MUST use the SOAP Envelope namespace ▫ A SOAP message MUST use the SOAP Encoding namespace ▫ A SOAP message must NOT contain a DTD reference ▫ A SOAP message must NOT contain XML Processing Instructions
  9. 9. Some Technical Specifications <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope>
  10. 10. Some Technical Specifications • The xmlns:soap should always have the value of: "http://www.w3.org/2001/12/soap-envelope". • The namespace defines the Envelope as a SOAP Envelope. • If a different namespace is used, the application generates an error and discards the message. • The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents and all child elements. • A SOAP message has no default encoding. soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
  11. 11. Some Technical Specifications • The SOAP Header Element ▫ The optional SOAP Header element contains application-specific information (like authentication, payment, etc) about the message. ▫ If the Header element is present, it must be the first child element of the Envelope element. ▫ The mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. ▫ The SOAP actor attribute is used to address the Header element to a specific endpoint.
  12. 12. Some Technical Specifications • The SOAP Header Element cont. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/">234 </m:Trans> </soap:Header> ... ... </soap:Envelope>
  13. 13. Some Technical Specifications • The SOAP Body Element ▫ The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message. ▫ Immediate child elements of the SOAP Body element may be namespace-qualified.
  14. 14. Some Technical Specifications • The SOAP Body Element cont. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope>
  15. 15. Some Technical Specifications • The SOAP Body Element cont. ▫ Possible response <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>
  16. 16. Some Technical Specifications • The SOAP Body Element cont. ▫ The SOAP Fault Element ▫ The optional SOAP Fault element is used to indicate error messages. ▫ If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.
  17. 17. Some Technical Specifications • The SOAP Body Element cont. ▫ The SOAP Fault Element Sub Element Description <faultcode> A code for identifying the fault <faultstring> A human readable explanation of the fault <faultactor> Information about who caused the fault to happen <detail> Holds application specific error information related to the Body element
  18. 18. Some Technical Specifications • HTTP protocol ▫ HTTP communicates over TCP/IP. An HTTP client connects to an HTTP server using TCP. After establishing a connection, the client can send an HTTP request message to the server: POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 250 ...
  19. 19. Some Technical Specifications • HTTP protocol cont. POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>
  20. 20. Some Technical Specifications • HTTP protocol cont. ▫ Response HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope>
  21. 21. Some Technical Specifications • Manner of speaking…  service is defined as Price getStockPrice(StockName)  We call the service and return the Price as a type of int
  22. 22. Vendors • Sun, Java, .NET and Flex offer excellent SOAP integration. • Python and PHP support for SOAP is poor. • Java TM API for XML Web Services, JAX-WS https://jax-ws.dev.java.net/nonav/jax-ws-21- ea3/docs/index.html
  23. 23. Examples, Glassfish, java • Deploying Web Services in Glassfish …. @WebService public class CustomerWS { … @WebMethod public boolean checkCustomer(String email) {…} … } • Generation of WSDL will be automated. • The conversation of SOAP will take place without notice.
  24. 24. Examples, JAX-WS, java • wsimport : The tool reads a WSDL and generates all the required artifacts for web service development, deployment, and invocation. ▫ After deploying at one point, this tool will read the WSDL and will generate classes for the client in order to use the service. • Usage: CustomerWSService service = new CustomerWSService(); CustomerWS customerWS = service.getCustomerWSPort(); boolean doesHave = customerWS.checkCustomer(“hguvence@gmail.com”);
  25. 25. Examples, Glassfish, java
  26. 26. Examples, .NET • http://www.west- wind.com/presentations/dotnetwebservices/Dot NetWebServices.asp • http://www.15seconds.com/Issue/010430.htm
  27. 27. Alternatives • REST (Representational state transfer) ▫ An Architectural Style, Not a Standard • RPC (Remote Procedure Call), middleware technologies such as CORBA
  28. 28. Conclusion • Even though it is important to know the format of SOAP, why and when we use it is more important. • We use it for integrity with the world. It is like using a single language for benefits! Except cultural values :) • No need to develop tools to send or to parse SOAP messages, big vendors already did it. And they work efficiently. Many people are using. So, you- use it! Don’t loose time! • Tools will help you in developing services and connecting to them in order for you to design your services well. So you don’t have to worry about SOAP format at all!
  29. 29. References, Resources • http://www.w3.org/TR/soap/ • specs: http://www.w3.org/TR/soap12-part1/ • http://www.w3schools.com/SOAP/soap_intro.asp • http://searchsoa.techtarget.com/generic/0,295582, sid26_gci1049566,00.html • SOA in Practice, The Art of Distributed System Design, August 2007, p.234-235 • http://www.xfront.com/REST-Web-Services.html • http://en.wikipedia.org/wiki/SOAP
  30. 30. ?
  31. 31. Thank You • H. Fırat Güvence ▫ hguvence@gmail.com

×