1 / 65

Soap and the Future of Distributed Processing on the Internet

Soap and the Future of Distributed Processing on the Internet. Mohammed El-Affendi Dept of Computer Science, CCIS, PSU. Topics Covered. What is a distributed application? Evolution of distributed applications. The famous RPC. Architectures of distributed systems and applications.

clark
Télécharger la présentation

Soap and the Future of Distributed Processing on the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Soap and the Future of Distributed Processing on the Internet Mohammed El-Affendi Dept of Computer Science, CCIS, PSU

  2. Topics Covered • What is a distributed application? • Evolution of distributed applications. • The famous RPC. • Architectures of distributed systems and applications. • CORBA and COM: interoperability. • XML and SOAP. • WEB services

  3. What is a distributed application? • A distributed application is an application that runs on several interconnected machines, but appears to its user as if it were running on a single machine. • This is called a true distributed application.

  4. Network Applications? • In network applications, the network is transparent. • The user knows that he is using a network. • Transparency is the major difference between distributed and network applications.

  5. Architecture of distributed systems and applications: • Distributed systems may be based on existing OS’s and protocols or built from scratch. (Distributed Unix versus Amoeba). • They may be based on monolithic or thin kernels.

  6. 1 0 1 0 1 Function Calls in Distributed Systems: The Famous RPC: • Remote Procedure Calls (RPC’s): Client Calls Functions Server Program Client Program Stub Marshall unmarshall Transport Transport

  7. The CORBA Standard and Distributed Objects: • The OMG designed CORBA as a standard for interoperability between distributed objects. • The main motivation is to allow applications to call functions implemented by other distributed applications using a standard interface specification.

  8. COM and DCOM: • Microsoft introduced a similar de facto standard commonly known as COM. • The main motivation behind COM is to allow binaries to interoperate through exported interface specifications, in a manner independent of the programming language and platform.

  9. COM and DCOM: • Another motivation is to allow applications to control each other easily. • COM assumes that the interoperating applications are on the same machine. • DCOM is an extension of COM across networks and the Internet. • DCOM clients may call procedures and functions implemented by DCOM servers on other machines.

  10. DCOM Clients and Servers: • The user should not worry about communication details: Server Client

  11. Problems with COM and CORBA: • One problem with COM and CORBA is that they are competing standards which are not compatible. • Another problem is that in many cases they may not be able to cross firewall boundaries.

  12. Enter SOAP: • Due to the above problems, people have been looking for a more versatile solution acceptable by all. • The answer has been “SOAP”. • SOAP stands for “Simple Object Access Protocol” • In one sentence: SOAP=XML + HTTP.

  13. SOAP: • The main idea behind SOAP is to utilize two widely accepted standards to facilitate interoperability across the Internet. • The first of these is the XML standard for describing data (I will explain shortly). • The other standard is nothing but the widely accepted WEB protocol: the famous HTTP.

  14. SOAP: • In what follows, I will briefly describe XML and the HTTP and then come back to SOAP. • However, one point to remember is that the HTTP is one of the very few protocols that can cross firewalls.

  15. XML: • XML is all about structured, self-describing data • Data which must be structured are the method calls and return data • Many implementations available to process XML

  16. What is XML • XML stands for “eXtensible Markup Language” • XML Language is a text-based format that lets developers describe, deliver and exchange structured data between a range of applications and clients for local display and manipulation. • XML also facilitates the transfer of structured data between servers themselves. • XML resembles and complements HTML. • XML describes data, while HTML defines tags that describe how the data should be displayed.

  17. XML: • XML, however, allows developers to define an unlimited set of tags, bringing great flexibility to authors, who can decide which data to use and determine its appropriate standard or custom tags. • HTML uses a frozen set of tags that are difficult to extend.

  18. XML example: • The following simple example shows how XML is used to describe a weather report: • <weather-report> • <date>16, Sept, 2001</date> • <time>12:45</time> • <area> • <city> Sharjah </city> • <region> North. Reg</region> • <country> UAE </country> • </area>

  19. XML Example: • <measurements> • <skies>partly cloudy</skies> • <temperature>46</temperature> • <wind> • <direction>SW</direction> • <windspeed>6</windspeed> • </wind> • <humidity>40</humidity> • <visibility>10</visibility> • </measurements> • </weather-report>

  20. Why XML • XML is simple • Text-based and human readable • Open, Standards Based • Much like TCP/IP, HTTP, HTML • XML makes data more important thancode and is good for describing data • XML enables powerful Web applications and is available on (almost) all platforms • XML will be the format and the data model for all information flowing across applications, via messages, and through the web

  21. Namespaces • Solves the “naming” and “sharing” problems • Makes XML very extensible • Enables developers to mix data described by multiple schemas in one XML instance • Schema components are reusable in other schemas • Qualifies data elements uniquely • <B:Title>Learning XML</B:Title> • <C:Title>Dr.</C:Title>

  22. Namespaces • URI’s are used for Scoping. • Uniform Resource Identifiers (URIs) • Uniform Resource Name (URN) • Location Independent, need not equate to anything. • Uniform Resource Locator (URL) • Location hints are embedded in identifier

  23. Using Namespaces • To define a namespace for an element: • Define the xmlns attribute and assign it a Uniform Resource Identifier (URI) <root> <bk:BOOK xmlns:bk="urn:BookStore.org:BookInfo" xmlns:money="urn:Finance:Money"> <bk:TITLE>A Suitable Boy</bk:TITLE> <bk:PRICE>22.95</bk:PRICE> </bk:BOOK> </root>

  24. HTTP • Internet’s Request/Response Protocol • Ubiquitous cross-platform/language support • Highly scalable server-side implementations are available • Simple and Extensible protocol • Typically the only thing allowed through firewalls

  25. A basic HTTP scenario • User-Agent establishes TCP connection to Server • Typically over port 80 • User-Agent sends HTTP request message to Server • Server processes request and sends back HTTP response message • An HTTP endpoint is identified by a Uniform Resource Locator (URL): http://www.affendi.net/test/mmm.asp

  26. HTTP operations • HTTP 1.1 supports several built-in methods • GET and POST most common • POST requests typically contain a body used to pass information along with request • GET can only pass information using a Query String

  27. HTTP messages • HTTP request and response messages have headers & optional body • Headers contain method (GET/POST), URL and HTTP version. • Headers are text-based name:value pairs • Headers are CRLF delimited • Body starts after CRLFCRLF sequence • Content-Length/-Type headers indicate size and MIME type

  28. Sample HTTP messages GET /test/mmm.asp HTTP/1.1 Host: WWW.affendi.NET POST /test/display.asp HTTP/1.1 Host: WWW.affendi.NET Content-Length: 12 Content-Type: text/plain Hello, World

  29. HTTP responses • HTTP responses begin with a status line containing a numeric code and description • 2xx: Success • 4xx: User-Agent Error – Request contains bad syntax or cannot be fulfilled • 5xx: Server Error – The server failed to fulfill an apparently valid request • Also 1xx and 3xx codes. HTTP/1.1 200 OK Content-Length: 12 Content-Type: text/plain Hello, World

  30. Back to SOAP: • Now Back to SOAP.

  31. SOAP version 1.1 • Specifies a simple and lightweight XML messaging protocol for exchanging structured and typed information. • Designed as an RPC mechanism • Bindable to many transports • HTTP is currently the primary transport • Extensible • Based upon its envelope structure

  32. SOAP Spec consists of 4 parts • An extensible envelope (XML) expressing • what is the message and what are its features • whether the features are optional or mandatory. • A set of encoding rules for data • Defines how data is represented in XML. • A convention for representing Remote Procedure Calls • Defines how calls and returns are packaged in XML. • A protocol binding to HTTP • What SOAP messages over HTTP look like

  33. The complete SOAP Message SOAP Message Standard HTTP and SOAP HTTP Headers HTTP Headers <Envelope> encloses payload SOAP Envelope SOAP Header <Header> encloses headers Individual headers Headers SOAP Body <Body> contains SOAP Message Name & Data XML Encoded SOAP Message Name & Data Message Name & Data SOAP HTTP Message Structure

  34. A Simple Request Example: • <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Header></SOAP:Header> <SOAP:Body><m:GetSalesTax • xmlns:m="urn:myserver/soap:TaxCalc"><SalesTotal>100</SalesTotal> </m:GetSalesTax> </SOAP:Body></SOAP:Envelope

  35. A Simple Response Example: • <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Header></SOAP:Header> <SOAP:Body> <m:GetSalesTaxResponse • xmlns:m= • "urn:myserver/soap:TaxCalc"> <SalesTax>4</SalesTax> </m:GetSalesTaxResponse> </SOAP:Body></SOAP:Envelope>

  36. Sample SOAP (HTTP) Message POST /sample/soapdemo.asp HTTP/1.1 Host: www.ctmsdev.net Content-type: text/xml Content-length: nnn SOAPAction: Some-uri#MethodName <SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  37. SOAP Headers • Headers are optional • Associate special processing instructions with the request • Open-ended set of header entries • Can be used for security, transactions, etc… • Or any other special information that applies to processing this message • Individual header entry can be optional/mandatory • mustUnderstand=“1” indicates the recipient must understand this instruction and obey it or fail processing.

  38. Sample SOAP Message -- Header <SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <SOAP-ENV:Header> <mynms:CurrIndex xmlns:myns=“My-uri” SOAP-ENV:mustUnderstand=“1”>3</myns:CurrIndex> </SOAP-ENV:Header> <SOAP-ENV:Body> … </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  39. SOAP Body • Always mandatory • This is where the method call and response are encoded • Errors can be reported on the response

  40. Sample SOAP Request <SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <SOAP-ENV:Header> … </SOAP-ENV:Header> <SOAP-ENV:Body> <m:MethodName xmlns:m=“Some-uri”> <x>3</x> <y>4</y> </m:MethodName> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  41. Sample SOAP Response HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnn <SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/> <SOAP-ENV:Body xmlns;m=“Some-uri”> <m:MethodNameResponse> <return>24</return> </m:MethodNameResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  42. SOAP Types • SOAP specification specifies Simple as well as Compound Types • Simple types are defined in the section of “Built-in data types” of “XML Schema Part 2: Datatypes” • String, int, boolean,float, etc… • Compound Types are either Structs or Arrays • In Structs, the element names distinguish the different elements • In Arrays, the Ordinal postion serves to distinguish among the elements

  43. WEB Services: • SOAP made it possible to implement RPC’s across the Internet. • Using SAOP, an application may transparently call a function implemented in server somewhere on the Internet. • Companies are now utilizing this feature to provide “WEB Services”.

  44. WEB Services: • A WEB service is simply a WEB application or method callable across the Internet. • The vehicle is of course SOAP.

  45. What is the Significance of this? • The main significance of this is that the Internet is being transformed from a network system into a huge global distributed system that may host a wide variety of distributed applications. • Users may now build distributed applications that consists of components that reside on other machines and platforms.

  46. What is the Significance of this? • Software may now be provided as a subscription service. • You license an application for a period of time rather than buying it. • Users may be able to control their environments and do a wide range of things that were not possible before. • A huge amount of services will shortly be available across the Internet.

  47. Historically, most development efforts have been directed toward building apps using rich local services. Current web applications Browsers App Code Internet Browsers OS, Core Servicesand Data Web app developers took advantage of these local services and used HTML to “project” the UI to lots of clients.

  48. Web Services are building blocks that enable developers to build and aggregate applications and services from local and remote resources for a range of clients. The Web Services View Vertical and Portal Services App Code Application SpecificWeb Services OS and Local Services Internet Building BlockWeb Services Browsers Devices

  49. What are Web Services? • A web-addressable resource that provide data and functions for programmatic access.

  50. 1 0 1 0 1 WEB Services: UDDI -DISCO Server Program Client Program WSDL Proxy Stub SOAP Transport Transport

More Related