Web Services – The Evolution of Distributed Applications

Document Sample
Web Services – The Evolution of Distributed Applications Powered By Docstoc
					    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.

				
DOCUMENT INFO