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. CORBA and COM: interoperability. XML and SOAP. WEB services 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. 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. 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. Function Calls in Distributed Systems: The Famous RPC: Remote Procedure Calls (RPC’s): Client Calls Functions Client Server Program Program Stub Marshall unmarshall Transport 1 0 1 0 1 Transport 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. 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. 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. DCOM Clients and Servers: The user should not worry about communication details: Client Server 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. 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. 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. 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. 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 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. 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. 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> 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> Why XML XML is simple Text-based and human readable Open, Standards Based Much like TCP/IP, HTTP, HTML XML makes data more important than code 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 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> 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 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> 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 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 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 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 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 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 HTTP/1.1 200 OK Also 1xx and 3xx codes. Content-Length: 12 Content-Type: text/plain Hello, World Back to SOAP: Now Back to SOAP. 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 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 SOAP HTTP Message Structure SOAP Message The complete SOAP Message HTTP Headers Standard HTTP and SOAP HTTP Headers SOAP Envelope <Envelope> encloses payload SOAP Header <Header> encloses headers Headers Individual headers <Body> contains SOAP SOAP Body Message Name & Data Message Name & Data XML Encoded SOAP Message Name & Data 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 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> 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> 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. 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> SOAP Body Always mandatory This is where the method call and response are encoded Errors can be reported on the response 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> 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> 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 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”. WEB Services: A WEB service is simply a WEB application or method callable across the Internet. The vehicle is of course SOAP. 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. 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. Current web applications Browsers App Code Internet OS, Browsers Core Services and Data Web app developers took Historically, most advantage of these local development efforts have services and used HTML to been directed toward “project” the UI to lots of building apps using rich local clients. services. The Web Services View Vertical and Portal App Code Services OS and Application Specific Local Web Services Internet Services Building Block Web Services Web Services are building blocks that enable developers to build and Browsers Devices aggregate applications and services from local and remote resources for a range of clients. What are Web Services? A web-addressable resource that provide data and functions for programmatic access. WEB Services: UDDI - Client DISCO Server Program Program WSDL Proxy Stub SOAP Transport 1 0 1 0 1 Transport Building Block Standards XML Standard way to represent information Used to build all other protocols HTTP Transport Layer Scalable Web Service Protocols Simple Object Access Protocol (SOAP) Remote Procedure Calls Web Services Description Language (WSDL) Describe Web Services Discovery Protocols DISCO Tied to a particular URL UDDI Universal Description Discovery and Integration Building Web Service catalogs and finding Web Services from central repositories Web Service Infrastructure Reliability Process Security Orchestration Routing (XLANG) Packaging Service Directory (UDDI) SOAP Description (WSDL) Disco (XML Protocols) XML Schemas XML XML HTTP XML Communication Description Discovery What are Web Services? Building blocks for constructing distributed applications Independent of platform, object model and language Based upon open Internet Standards Internet or Intranet Loosely coupled Higher levels of application integration Software as a service The programmable web Web Services Commerce Collaboration Transact Leverage your business experience V A Access data L U Transform the way you E conduct business Publish Integrate the Web with business systems Get your information on the Web Security Business Chasm Chasm Illustrating the Idea: A Simple LookUp Example: Methods: LookUp • FindPerson • GetPersonList Web Service Specifications HTTP – transport XML – packaging SOAP – method/response format WSDL – services and types UDDI and DISCO (Web) Services Description Language Need a way to describe Web Services As documentation for the Web Service For Tools / Platforms to automate the details of communication WSDL 1.0 is a new standard for doing this. A Service Description fragment – Service Description <serviceDescription xmlns:s0="http://tempuri.org/main.xsd" xmlns:s1="" name="WebService1" targetNamespace="" xmlns="urn:schemas-xmlsoap-org:sdl.2000-01-25"> <soap xmlns="urn:schemas-xmlsoap-org:soap-sdl-2000-01-25"> <service> <addresses> <address uri="http://localhost/websx/webservice1.asmx"/> </addresses> <requestResponse name="FindPerson“ soapAction="http://tempuri.org/FindPerson"> <request ref="s0:FindPerson"/> <response ref="s0:FindPersonResult"/> </service> </soap> A Service Description fragment -- Types <schema targetNamespace="http://tempuri.org/main.xsd" xmlns="http://www.w3.org/1999/XMLSchema"> <import namespace="http://www.w3.org/1999/XMLSchema"/> <element name="FindPerson"> <complexType> <element name="strEmail" type="string" nullable="true"/> </complexType> </element> <element name="FindPersonResult"> <complexType> <element name="result" type="s0:Person"/> </complexType> </element> <complexType name="Person"> <element name="strEmail" type="string" nullable="true"/> <element name="strFirstName" type="string" nullable="true"/> <element name="strLastName" type="string" nullable="true"/> </complexType> Discovery Used to locate a Web Service’s description DISCO is targeted discovery Looking directly at a particular site Web crawlers UDDI is a centralized services directory Geared toward finding standard services from a centralized registry UDDI defines an API executed via SOAP UDDI hold pointers to the details (WSDL or DISCO) Let’s look at DISCO a bit further DISCO in practice HTTP request http://resource <discovery> information about resource </discovery> Sample DISCO Documents <?xml version="1.0" ?> <discovery xmlns="http://schemas.xmlsoap.org/disco/"> <contractRef ref="/calc/Calc.asmx?sdl" docRef="/calc/Calc.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" /> </discovery> <?xml version="1.0" ?>- <discovery xmlns="http://schemas.xmlsoap.org/disco/"> <discoveryRef ref="/CPPWS/CPPWS.disco" /> <discoveryRef ref="/Calc/Calc.disco" /> <discoveryRef ref="/CalcForm/CalcForm.disco" /> <discoveryRef ref="/Calculator/Calculator.disco" /> <discoveryRef ref="/CPPWS/CPPWS.disco" /> <discoveryRef ref="/WA1/WA1.disco" /> <discoveryRef ref="/WS1/WS1.disco" /> <discoveryRef ref="/WS2/WS2.disco" /> </discovery> App Code The SOAP Toolkit SDLASP Vertical and Portal Services Local SOAP ROPE Services SDLASP Application Specific Web Services The Toolkit enables you to: • Expose Web services by generating an SDLASP XML service description from a COM Building Block Web Services component’s type library • Consume Web services automatically in VB by turning the contract into a programmable proxy with a Remote Object Proxy Engine (ROPE) Browsers Devices • Receive SOAP requests from a SOAP client (e.g., the proxy) with an ASP or ISAPI “listener” Thanks Thank you for attending and listening. WaSalamu Alaikum Wa Rahmatu Allah.