SlideShare una empresa de Scribd logo
1 de 50
Descargar para leer sin conexión
SOAP-based Web Services

Web Technology
2II25

Dr. Katrien Verbert
Dr. ir. Natasha Stash
Dr. George Fletcher
Contents

•  Big Web Services
    •  SOAP, WSDL and UDDI
    •  Comparison RESTful Web Services
•  Next lecture
    •  JAX-WS: Building SOAP-based services in Java
    •  JAXB: SOAP and XML processing
    •  JAX-RS: Building RESTful services in Java
What Are Web Services?
Web Services, Web Applications and
APIs (Application Programming Interface)
•  Web Applications == Web Services == Web APIs ?
Web Services, Web Applications and
APIs (Application Programming Interface)
•  Web Applications are designed to be accessed by end
   users through Web client software
•  Web Services are intended to be used by other software
   applications


•  Web APIs ≈ Web Services
Example Mashup: Last on AM/FM




http://people.cs.kuleuven.be/~sten.govaerts/lastonamfm/
http://www.programmableweb.com/mashup/last-on-am-fm
Example web client application




   http://ariadne.cs.kuleuven.be/alocom/alocom_plugin/alocom_plugin.swf
Disaggregation service
What Are Web Services?

•  W3C definition:
•  A software system designed to support interoperable
   machine-to-machine interaction over a network...
Web Services Use

•  Connect existing software
•  Reusable application components
Terminology

•  Major classes of Web Services:
      •  Big Web Services
      •  (L. Richardson and S. Ruby)
      •  RESTful (REST-compliant) Web Services
•  Service-Oriented Architecture (SOA)
•  The Competing Web Service Architectures:
•  (L. Richardson and S. Ruby):
      •  RPC-Style Architectures (Remote Procedure Calls)
      •  RESTful, Resource-Oriented Architectures (ROA)
      •  REST-RPC Hybrid Architectures
Web Service Technologies
•  Basic Web Services platform:
      •  XML+HTTP
•  Related to Big Web Services:
      •  SOAP (Simple Object Access Protocol)
      •  WSDL (Web Services Description Language)
      •  UDDI (Universal Description, Discovery, and
         Integration)
Roles and Operations in a
Service-Oriented Architecture (SOA)


                    Service
                    Broker


            Find              Publish



        Service                  Service
       Requester                 Provider
                     Bind
Goals of SOA

•    separation of concerns
•    loose coupling among interacting software applications
•    reusability of services
•    interoperability
The Standards, Components and Relationships for
Big Web Service Implementation

                                  Service Broker
        2) Find                   (UDDI registry)
        Web Service

 Service
Requester   3) Download
  (Web      WSDL
 Service
 client)                               1) Publish
                                       Web Service

                   4) Invoke           Service
                   Web Service      Provider (Web
                                       Service)
What is SOAP

•    SOAP used to stand for Simple Object Access Protocol
•    SOAP is a communication protocol
•    SOAP is designed to communicate via Internet
•    SOAP is based on XML
•    SOAP is simple and extensible
•    SOAP is platform and language independent
•    SOAP is a W3C standard
SOAP Message Structure


                  <?xml version='1.0' ?><env:Envelope
                  xmlns:env="
 SOAP Envelope    http://www.w3.org/2003/05/soap-envelope">
  SOAP Header     <env:Header>
                  ...
  header block    </env:Header>

                  <env:Body>
   SOAP Body      ...
                  <env:Fault>
   body block     ...
                  </env:Fault>
                  </env:Body>
                  </env:Envelope>
SOAP Example: RPC-Style Request Message
<?xml version='1.0' ?>                                                      Request
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <ts:getPrice xmlns:ts="http://travelagency.example.org/wsdl/trips"
   s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">
   <ts:departing>Amsterdam (Schiphol)</ts:departing>
   <ts:arriving>Saint-Petersburg (Pulkovo)</ts:arriving>
   <ts:departureDate>01-05-2010</ts:departureDate>
  <ts:/getPrice>
 </env:Body>
</env:Envelope>
<?xml version='1.0' ?><env:Envelope xmlns:env="                              Response
   http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <ts:getPriceResponse xmlns:ts="http://travelagency.example.org/wsdl/trips"
       s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding" >
       <ts:price>180.00</ts:price>
     </ts:getPriceResponse>
  </env:Body>
</env:Envelope>
RPC-Style Architectures

•  Envelopes exchange between Web Service and its
   client
•  Kinds of envelopes:
      •  HTTP
      •  SOAP
SOAP Example:
     Conversational Message Exchanges
<?xml version='1.0' ?>                                                  Response
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
 ...
 <ts:arriving>
  <ts:arrivingChoices>airport1 airport2 airport3</ts:arrivingChoices>
 </ts:arriving>
 ...
 </env:Body>
</env:Envelope>

<?xml version='1.0' ?><env:Envelope xmlns:env="                          Request
    http://www.w3.org/2003/05/soap-envelope"> <env:Body>
 ...
 <ts:arriving>airport1</ts:arriving>
 ... </env:Body>
</env:Envelope>
Fault Scenarios
<?xml version='1.0' ?>
  <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
   xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'>
    <env:Body>
      <env:Fault>                                                     x
        <env:Code>
          <env:Value>env:Sender</env:Value>
          <env:Subcode>
            <env:Value>rpc:BadArguments</env:Value>
          </env:Subcode>
       </env:Code>
       <env:Reason>
          <env:Text xml:lang="en-US">Processing error</env:Text>
       </env:Reason>
     </env:Fault>
   </env:Body>
 </env:Envelope>
SOAP HTTP Binding:
SOAP HTTP Post Usage
POST /pricesService/getPrice HTTP/1.1
Host: http://travelagency.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <ts:getPrice xmlns:ts="http://travelagency.example.org/wsdl/trips">
   <ts:departing>Amsterdam (Schiphol)</ts:departing>
   <ts:arriving>Saint-Petersburg (Pulkovo)</ts:arriving>
   <ts:departureDate>21-04-2010</ts:departureDate>
  <ts:/getPrice>
 </env:Body>
</env:Envelope>
SOAP HTTP Binding:
    SOAP Response
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <ts:getPriceResponse xmlns:ts="http://travelagency.example.org/wsdl/trips">
   <ts:price>180.00</ts:price>
  </ts:getPriceResponse>
 </env:Body>
</env:Envelope>
What is WSDL

•    WSDL stands for Web Services Description Language
•    WSDL is used to describe and locate Web Services
•    WSDL is based on XML
•    WSDL is a W3C standard
WSDL

Describes three fundamental properties
•  What a service does
   •  Operations (methods) provided by the service
•  How a service is accessed
   •  Data format and protocol details
•  Where a service is located
   •  Address (URL) details
WSDL Document Structure

WSDL Specification   Main structure of WSDL document
abstract part
                     <definitions targerNamespace= ... >
       types
                      <types>definition of types...</types>
     messages
                      <message>definition of a message...</message>
     operations

     port types       <portType>definition of a port</portType>


concrete part         <binding>definition of a binding...</binding>

      bindings
                      <service>
      service           <port>...</port>
                      </service>
        port
                     </definitions>
WSDL Document Example:
Abstract Part
<message name="itineraryMsg">
 <part name="departing" type="xs:string"/>
 <part name="arriving" type="xs:string"/>
 <part name="departureDate" type="xs:date"/>
</message>


<message name="itineraryRespMsg">
 <part name="price" type="xs:string"/>
</message>


<portType name="pricesPT">
 <operation name="getPrice">
  <input message="itineraryMsg"/>
  <output message="itineraryRespMsg"/>
 </operation>
</portType>
Operation Types

Type             Definition


One-way          The operation can receive a message but will not return
                 a response

Request-         The operation can receive a request and will return a
response         response

Solicit-response The operation can send a request and will wait for a
                 response

Notification     The operation can send a message but will not wait for
                 a response
Example: One-Way Operation

<message name="newPrices">
 <part name="departing" type="xs:string"/>
 <part name="arriving" type="xs:string"/>
 <part name="departureDate" type="xs:date"/>
 <part name="price" type="xs:string"/>
</message>


<portType name="pricesPT">
 ...
 <operation name="setPrice">
   <input message="newPrices"/>
 </operation>
</portType >
WSDL Document Example:
 Concrete Part
 <service name="pricesService">
   <port name="getPriceRPCPort" binding="ts:b1">
     <soap:address
      location="http://travelagency.example.org/pricesService">
   </port>
 </service>


xmlns:ts='http://travelagency.example.org/wsdl/trips'
WSDL Document Example:
   Concrete Part
   <binding name="b1" type="ts:getPriceRPCPort">
    <soap:binding style="rpc"
     transport="http://schemas.xmlsoap.org/soap/http" />
     <operation name="ts:getPrice">
      <input>
       <soap:body use="encoded"
        namespace="http://travelagency.example.org/wsdl/trips"
        encodingStyle="http://schemas.xmlsoap.org/soap/encoding" />
      </input>
      <output>
       <soap:body use="encoded"
        namespace="http://travelagency.example.org/wsdl/trips"
        encodingStyle="http://schemas.xmlsoap.org/soap/encoding" />
      </output>
    </operation>
    ...
   </binding>

xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
What is UDDI

•  UDDI stands for Universal Description, Discovery and Integration
•  UDDI a standard for publishing and discovering Web services
•  UDDI is a specification for a distributed registry of Web services
•  UDDI is built upon standards such as HTTP, XML, XML Schema,
   SOAP, WSDL
•  UDDI can communicate via SOAP, CORBA, Java RMI Protocol
•  UDDI uses WSDL to describe interfaces to Web Services
Ways to Use UDDI Registry

•  White pages
–  name, address, contact person, Web site
•  Yellow pages
–  types of business, locations, products, services,
   categorizations
•  Green pages
–  technical information about business services, pointers to
   WSDL descriptions of the services
UDDI Data Model:
    UDDI Core Data Types




Example: http://www.tutorialspoint.com/uddi/uddi_data_model.htm
UDDI Data Model:
tModel example
<?xml version="1.0"?>
 <tModel tModelKey="”>
            <name>http://www.getquote.com/StockQuoteService-interface</name>
            <description xml:lang="en">…</description>
            <overviewDoc>
                 <description xml:lang="en”>WSDL Service Interface Document </description>
                 <overviewURL>
                        http://www.getquote.com/services/SQSinterface.wsdl#SingleSymbolBinding
                  </overviewURL>
            </overviewDoc>
            <categoryBag>
                  <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4”
                        keyName="uddi-org:types" keyValue="wsdlSpec"/>
                  <keyedReference tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384”
                        keyName="Stock market trading services”
                        keyValue="84121801"/>
            </categoryBag>
</tModel>
UDDI: Programmatic Interfaces

•  UDDI Inquiry Interface:
–  find_business, find_service, find_tModel, find_binding,
   find_relatedBusiness
–  get_businessDetail, get_serviceDetail, get_bindingDetail,
   get_tModelDetail
•  UDDI Publisher Interface:
–  save_business, save_service, save_binding, save_tModel
–  delete_business, delete_service, delete_binding,
   delete_tModel
–  ...
Big Web Services Examples

•  http://www.xmethods.com
•  http://www.programmableweb.com/
Web services enable
1.  data exchange between various applications and different platforms
2.  to resolve interoperability issues
3.  applications to function between two different operating systems server
4.  all of the above
Coding and decoding, and transporting the data is
  performed by
1.  XML and UDDI respectively
2.  XML and SOAP respectively
3.  HTML and HTTP respectively
4.  HTML and SOAP respectively
Which of the following is used to locate and
  describe web services?
1.  SOAP
2.  Web page
3.  WSDL
4.  UDDI
Why SOAP is used as a protocol for accessing a
  web service?
1.  SOAP platform and language independent, allows to get around firewalls
2.  SOAP is based on HTML
3.  SOAP is designed to communicate through LAN
4.  All of the above
Big Web Service Operations vs
    RESTful Web Service URIs

Big WS operations                 RESTful WS URIs

getAllUsers()                     http://example.com/users/
                                  "
getUserById()                     http://example.com/users/id/<user-id>

getUserByName(), addUser()        http://example.com/users/name/<user-name>
removeUser(), updateUser()




                       03/28/11
Big Web Services versus REST


A SOAP service has a single endpoint
•  that handles all the operations
•  therefore it has to have an application-specific interface.

A RESTful service has a number of resources
•  so the operations can be distributed onto the resources
•  and mapped to a small uniform set of operations.




                   03/28/11
Comparison:
Big Web Services vs RESTful Web Services
•  How the client conveys its intentions to the server?
   Where method information is kept?

–  Big Web Services: in HTTP header and entity body
–  RESTful Web Services: in HTTP header

•  How the client tells the server which part of the data set
   to operate on? Where is scoping information kept?

–  Big Web Services: in the entity body
–  RESTful Web Services: in the URI path
Comparison:
  Big Web Services vs RESTful Web Services
•  Big Web Services pros:
   –  protocol transparency and independence
   –  existence of tools to hide the complexity
   –  security


•  Big Web Services cons:
   –    rudimentary processing protocol
   –    complexity
   –    heavyweight architecture
   –    do not get the benefits of resource-oriented services
   –    opaqueness
Comparison:
Big Web Services vs RESTful Web Services
•  Big Web Services are the preferred option for enterprise
   application integration
•  RESTful Web services are well suited for basic, ad hoc
   integration scenarios over Web (Mashup)
Comparison:
 Big Web Services vs RESTful Web Services
•  RESTful Web Services pros:
  –    simplicity
  –    lightweight infrastructure
  –    addressability
  –    uniform interface
  –    scalability of stateless RESTful Web Service
  –    improved performance using JSON

•  RESTful Web Services cons:
  –    bound to one protocol: HTTP
  –    only POST and GET can be used in XHTML form
  –    dealing with large input data - malformed URI
  –    security issues
Recommended reading

Cesare Pautasso,Olaf Zimmermann,Frank Leymann
  (2008) RESTful Web Services vs. Big Web Services:
  Making the Right Architectural Decision. Proc. of the
  17th International World Wide Web Conference
  (WWW2008), Bejing, China, April 2008.
k.verbert@tue.nl
n.v.stash@tue.nl
g.h.l.fletcher@tue.nl




          03/28/11

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

SOAP - Simple Object Access Protocol
SOAP - Simple Object Access ProtocolSOAP - Simple Object Access Protocol
SOAP - Simple Object Access Protocol
 
Web services
Web servicesWeb services
Web services
 
Rest web services
Rest web servicesRest web services
Rest web services
 
Java/Servlet/JSP/JDBC
Java/Servlet/JSP/JDBCJava/Servlet/JSP/JDBC
Java/Servlet/JSP/JDBC
 
Soap UI and postman
Soap UI and postmanSoap UI and postman
Soap UI and postman
 
SOAP vs REST
SOAP vs RESTSOAP vs REST
SOAP vs REST
 
Introduction to Web Services
Introduction to Web ServicesIntroduction to Web Services
Introduction to Web Services
 
Spring boot Introduction
Spring boot IntroductionSpring boot Introduction
Spring boot Introduction
 
Web Servers: Architecture and Security
Web Servers: Architecture and SecurityWeb Servers: Architecture and Security
Web Servers: Architecture and Security
 
JDBC: java DataBase connectivity
JDBC: java DataBase connectivityJDBC: java DataBase connectivity
JDBC: java DataBase connectivity
 
Introduction to java beans
Introduction to java beansIntroduction to java beans
Introduction to java beans
 
Uddi
UddiUddi
Uddi
 
Spring annotation
Spring annotationSpring annotation
Spring annotation
 
Introduction to REST - API
Introduction to REST - APIIntroduction to REST - API
Introduction to REST - API
 
Intro to web services
Intro to web servicesIntro to web services
Intro to web services
 
Http Introduction
Http IntroductionHttp Introduction
Http Introduction
 
Soap web service
Soap web serviceSoap web service
Soap web service
 
Soap and restful webservice
Soap and restful webserviceSoap and restful webservice
Soap and restful webservice
 
Soap Vs Rest
Soap Vs RestSoap Vs Rest
Soap Vs Rest
 
Ajax ppt
Ajax pptAjax ppt
Ajax ppt
 

Destacado

Web Service Presentation
Web Service PresentationWeb Service Presentation
Web Service Presentationguest0df6b0
 
Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)Martin Necasky
 
Introduction to SOAP/WSDL Web Services and RESTful Web Services
Introduction to SOAP/WSDL Web Services and RESTful Web ServicesIntroduction to SOAP/WSDL Web Services and RESTful Web Services
Introduction to SOAP/WSDL Web Services and RESTful Web Servicesecosio GmbH
 
Java web services using JAX-WS
Java web services using JAX-WSJava web services using JAX-WS
Java web services using JAX-WSIndicThreads
 
Restful Web Services
Restful Web ServicesRestful Web Services
Restful Web ServicesAngelin R
 
Using Java to implement RESTful Web Services: JAX-RS
Using Java to implement RESTful Web Services: JAX-RSUsing Java to implement RESTful Web Services: JAX-RS
Using Java to implement RESTful Web Services: JAX-RSKatrien Verbert
 

Destacado (20)

Web Service Presentation
Web Service PresentationWeb Service Presentation
Web Service Presentation
 
Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)
 
Webservices
WebservicesWebservices
Webservices
 
Web Services Tutorial
Web Services TutorialWeb Services Tutorial
Web Services Tutorial
 
Web service introduction
Web service introductionWeb service introduction
Web service introduction
 
RESTful Web Services
RESTful Web ServicesRESTful Web Services
RESTful Web Services
 
Web services
Web servicesWeb services
Web services
 
Introduction to SOAP/WSDL Web Services and RESTful Web Services
Introduction to SOAP/WSDL Web Services and RESTful Web ServicesIntroduction to SOAP/WSDL Web Services and RESTful Web Services
Introduction to SOAP/WSDL Web Services and RESTful Web Services
 
Java web services using JAX-WS
Java web services using JAX-WSJava web services using JAX-WS
Java web services using JAX-WS
 
Restful Web Services
Restful Web ServicesRestful Web Services
Restful Web Services
 
Web Services
Web ServicesWeb Services
Web Services
 
WSDL 2.0 and Apache Woden
WSDL 2.0 and Apache WodenWSDL 2.0 and Apache Woden
WSDL 2.0 and Apache Woden
 
Web service
Web serviceWeb service
Web service
 
Web services wsdl
Web services wsdlWeb services wsdl
Web services wsdl
 
Snmp protocol
Snmp protocolSnmp protocol
Snmp protocol
 
Overview of web services
Overview of web servicesOverview of web services
Overview of web services
 
SNMP
SNMPSNMP
SNMP
 
Web services uddi
Web services uddiWeb services uddi
Web services uddi
 
Web Services
Web ServicesWeb Services
Web Services
 
Using Java to implement RESTful Web Services: JAX-RS
Using Java to implement RESTful Web Services: JAX-RSUsing Java to implement RESTful Web Services: JAX-RS
Using Java to implement RESTful Web Services: JAX-RS
 

Similar a SOAP-based Web Services

Similar a SOAP-based Web Services (20)

Steps india technologies
Steps india technologiesSteps india technologies
Steps india technologies
 
Steps india technologies .com
Steps india technologies .comSteps india technologies .com
Steps india technologies .com
 
Web services overview
Web services overviewWeb services overview
Web services overview
 
Web-Services!.pptx
Web-Services!.pptxWeb-Services!.pptx
Web-Services!.pptx
 
Web services
Web servicesWeb services
Web services
 
Developmeant and deployment of webservice
Developmeant and deployment of webserviceDevelopmeant and deployment of webservice
Developmeant and deployment of webservice
 
Web Services
Web ServicesWeb Services
Web Services
 
Web service- Guest Lecture at National Wokshop
Web service- Guest Lecture at National WokshopWeb service- Guest Lecture at National Wokshop
Web service- Guest Lecture at National Wokshop
 
Web services - A Practical Approach
Web services - A Practical ApproachWeb services - A Practical Approach
Web services - A Practical Approach
 
Lecture 16 - Web Services
Lecture 16 - Web ServicesLecture 16 - Web Services
Lecture 16 - Web Services
 
Web services101
Web services101Web services101
Web services101
 
Web services
Web servicesWeb services
Web services
 
Ws rest
Ws restWs rest
Ws rest
 
Web service architecture
Web service architectureWeb service architecture
Web service architecture
 
Introduction to SOAP
Introduction to SOAPIntroduction to SOAP
Introduction to SOAP
 
Ntg web services
Ntg   web servicesNtg   web services
Ntg web services
 
jkljklj
jkljkljjkljklj
jkljklj
 
WebServices introduction in Mule
WebServices introduction in MuleWebServices introduction in Mule
WebServices introduction in Mule
 
WebServices SOAP WSDL and UDDI
WebServices SOAP WSDL and UDDIWebServices SOAP WSDL and UDDI
WebServices SOAP WSDL and UDDI
 
SOAP, WSDL and UDDI
SOAP, WSDL and UDDISOAP, WSDL and UDDI
SOAP, WSDL and UDDI
 

Más de Katrien Verbert

Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Katrien Verbert
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Katrien Verbert
 
Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?Katrien Verbert
 
Explaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspectiveExplaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspectiveKatrien Verbert
 
Explaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learnedExplaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learnedKatrien Verbert
 
Designing Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons LearnedDesigning Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons LearnedKatrien Verbert
 
Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...Katrien Verbert
 
Explainable AI for non-expert users
Explainable AI for non-expert usersExplainable AI for non-expert users
Explainable AI for non-expert usersKatrien Verbert
 
Towards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methodsTowards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methodsKatrien Verbert
 
Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...Katrien Verbert
 
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...Katrien Verbert
 
Learning analytics for feedback at scale
Learning analytics for feedback at scaleLearning analytics for feedback at scale
Learning analytics for feedback at scaleKatrien Verbert
 
Interactive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learningInteractive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learningKatrien Verbert
 
Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”Katrien Verbert
 
Interactive Recommender Systems
Interactive Recommender SystemsInteractive Recommender Systems
Interactive Recommender SystemsKatrien Verbert
 
Web Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTMLWeb Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTMLKatrien Verbert
 
Information Visualisation: perception and principles
Information Visualisation: perception and principlesInformation Visualisation: perception and principles
Information Visualisation: perception and principlesKatrien Verbert
 
Web Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: IntroductionWeb Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: IntroductionKatrien Verbert
 
Information Visualisation: Introduction
Information Visualisation: IntroductionInformation Visualisation: Introduction
Information Visualisation: IntroductionKatrien Verbert
 

Más de Katrien Verbert (20)

Explainability methods
Explainability methodsExplainability methods
Explainability methods
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
 
Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?
 
Explaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspectiveExplaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspective
 
Explaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learnedExplaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learned
 
Designing Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons LearnedDesigning Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons Learned
 
Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...
 
Explainable AI for non-expert users
Explainable AI for non-expert usersExplainable AI for non-expert users
Explainable AI for non-expert users
 
Towards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methodsTowards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methods
 
Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...
 
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
 
Learning analytics for feedback at scale
Learning analytics for feedback at scaleLearning analytics for feedback at scale
Learning analytics for feedback at scale
 
Interactive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learningInteractive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learning
 
Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”
 
Interactive Recommender Systems
Interactive Recommender SystemsInteractive Recommender Systems
Interactive Recommender Systems
 
Web Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTMLWeb Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTML
 
Information Visualisation: perception and principles
Information Visualisation: perception and principlesInformation Visualisation: perception and principles
Information Visualisation: perception and principles
 
Web Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: IntroductionWeb Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: Introduction
 
Information Visualisation: Introduction
Information Visualisation: IntroductionInformation Visualisation: Introduction
Information Visualisation: Introduction
 

SOAP-based Web Services

  • 1. SOAP-based Web Services Web Technology 2II25 Dr. Katrien Verbert Dr. ir. Natasha Stash Dr. George Fletcher
  • 2. Contents •  Big Web Services •  SOAP, WSDL and UDDI •  Comparison RESTful Web Services •  Next lecture •  JAX-WS: Building SOAP-based services in Java •  JAXB: SOAP and XML processing •  JAX-RS: Building RESTful services in Java
  • 3. What Are Web Services?
  • 4. Web Services, Web Applications and APIs (Application Programming Interface) •  Web Applications == Web Services == Web APIs ?
  • 5. Web Services, Web Applications and APIs (Application Programming Interface) •  Web Applications are designed to be accessed by end users through Web client software •  Web Services are intended to be used by other software applications •  Web APIs ≈ Web Services
  • 6. Example Mashup: Last on AM/FM http://people.cs.kuleuven.be/~sten.govaerts/lastonamfm/ http://www.programmableweb.com/mashup/last-on-am-fm
  • 7. Example web client application http://ariadne.cs.kuleuven.be/alocom/alocom_plugin/alocom_plugin.swf
  • 8.
  • 10. What Are Web Services? •  W3C definition: •  A software system designed to support interoperable machine-to-machine interaction over a network...
  • 11. Web Services Use •  Connect existing software •  Reusable application components
  • 12. Terminology •  Major classes of Web Services: •  Big Web Services •  (L. Richardson and S. Ruby) •  RESTful (REST-compliant) Web Services •  Service-Oriented Architecture (SOA) •  The Competing Web Service Architectures: •  (L. Richardson and S. Ruby): •  RPC-Style Architectures (Remote Procedure Calls) •  RESTful, Resource-Oriented Architectures (ROA) •  REST-RPC Hybrid Architectures
  • 13. Web Service Technologies •  Basic Web Services platform: •  XML+HTTP •  Related to Big Web Services: •  SOAP (Simple Object Access Protocol) •  WSDL (Web Services Description Language) •  UDDI (Universal Description, Discovery, and Integration)
  • 14. Roles and Operations in a Service-Oriented Architecture (SOA) Service Broker Find Publish Service Service Requester Provider Bind
  • 15. Goals of SOA •  separation of concerns •  loose coupling among interacting software applications •  reusability of services •  interoperability
  • 16. The Standards, Components and Relationships for Big Web Service Implementation Service Broker 2) Find (UDDI registry) Web Service Service Requester 3) Download (Web WSDL Service client) 1) Publish Web Service 4) Invoke Service Web Service Provider (Web Service)
  • 17. What is SOAP •  SOAP used to stand for Simple Object Access Protocol •  SOAP is a communication protocol •  SOAP is designed to communicate via Internet •  SOAP is based on XML •  SOAP is simple and extensible •  SOAP is platform and language independent •  SOAP is a W3C standard
  • 18. SOAP Message Structure <?xml version='1.0' ?><env:Envelope xmlns:env=" SOAP Envelope http://www.w3.org/2003/05/soap-envelope"> SOAP Header <env:Header> ... header block </env:Header> <env:Body> SOAP Body ... <env:Fault> body block ... </env:Fault> </env:Body> </env:Envelope>
  • 19. SOAP Example: RPC-Style Request Message <?xml version='1.0' ?> Request <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <ts:getPrice xmlns:ts="http://travelagency.example.org/wsdl/trips" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding"> <ts:departing>Amsterdam (Schiphol)</ts:departing> <ts:arriving>Saint-Petersburg (Pulkovo)</ts:arriving> <ts:departureDate>01-05-2010</ts:departureDate> <ts:/getPrice> </env:Body> </env:Envelope> <?xml version='1.0' ?><env:Envelope xmlns:env=" Response http://www.w3.org/2003/05/soap-envelope"> <env:Body> <ts:getPriceResponse xmlns:ts="http://travelagency.example.org/wsdl/trips" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding" > <ts:price>180.00</ts:price> </ts:getPriceResponse> </env:Body> </env:Envelope>
  • 20. RPC-Style Architectures •  Envelopes exchange between Web Service and its client •  Kinds of envelopes: •  HTTP •  SOAP
  • 21. SOAP Example: Conversational Message Exchanges <?xml version='1.0' ?> Response <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> ... <ts:arriving> <ts:arrivingChoices>airport1 airport2 airport3</ts:arrivingChoices> </ts:arriving> ... </env:Body> </env:Envelope> <?xml version='1.0' ?><env:Envelope xmlns:env=" Request http://www.w3.org/2003/05/soap-envelope"> <env:Body> ... <ts:arriving>airport1</ts:arriving> ... </env:Body> </env:Envelope>
  • 22. Fault Scenarios <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'> <env:Body> <env:Fault> x <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>rpc:BadArguments</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en-US">Processing error</env:Text> </env:Reason> </env:Fault> </env:Body> </env:Envelope>
  • 23. SOAP HTTP Binding: SOAP HTTP Post Usage POST /pricesService/getPrice HTTP/1.1 Host: http://travelagency.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <ts:getPrice xmlns:ts="http://travelagency.example.org/wsdl/trips"> <ts:departing>Amsterdam (Schiphol)</ts:departing> <ts:arriving>Saint-Petersburg (Pulkovo)</ts:arriving> <ts:departureDate>21-04-2010</ts:departureDate> <ts:/getPrice> </env:Body> </env:Envelope>
  • 24. SOAP HTTP Binding: SOAP Response HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <ts:getPriceResponse xmlns:ts="http://travelagency.example.org/wsdl/trips"> <ts:price>180.00</ts:price> </ts:getPriceResponse> </env:Body> </env:Envelope>
  • 25. What is WSDL •  WSDL stands for Web Services Description Language •  WSDL is used to describe and locate Web Services •  WSDL is based on XML •  WSDL is a W3C standard
  • 26. WSDL Describes three fundamental properties •  What a service does •  Operations (methods) provided by the service •  How a service is accessed •  Data format and protocol details •  Where a service is located •  Address (URL) details
  • 27. WSDL Document Structure WSDL Specification Main structure of WSDL document abstract part <definitions targerNamespace= ... > types <types>definition of types...</types> messages <message>definition of a message...</message> operations port types <portType>definition of a port</portType> concrete part <binding>definition of a binding...</binding> bindings <service> service <port>...</port> </service> port </definitions>
  • 28. WSDL Document Example: Abstract Part <message name="itineraryMsg"> <part name="departing" type="xs:string"/> <part name="arriving" type="xs:string"/> <part name="departureDate" type="xs:date"/> </message> <message name="itineraryRespMsg"> <part name="price" type="xs:string"/> </message> <portType name="pricesPT"> <operation name="getPrice"> <input message="itineraryMsg"/> <output message="itineraryRespMsg"/> </operation> </portType>
  • 29. Operation Types Type Definition One-way The operation can receive a message but will not return a response Request- The operation can receive a request and will return a response response Solicit-response The operation can send a request and will wait for a response Notification The operation can send a message but will not wait for a response
  • 30. Example: One-Way Operation <message name="newPrices"> <part name="departing" type="xs:string"/> <part name="arriving" type="xs:string"/> <part name="departureDate" type="xs:date"/> <part name="price" type="xs:string"/> </message> <portType name="pricesPT"> ... <operation name="setPrice"> <input message="newPrices"/> </operation> </portType >
  • 31. WSDL Document Example: Concrete Part <service name="pricesService"> <port name="getPriceRPCPort" binding="ts:b1"> <soap:address location="http://travelagency.example.org/pricesService"> </port> </service> xmlns:ts='http://travelagency.example.org/wsdl/trips'
  • 32. WSDL Document Example: Concrete Part <binding name="b1" type="ts:getPriceRPCPort"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="ts:getPrice"> <input> <soap:body use="encoded" namespace="http://travelagency.example.org/wsdl/trips" encodingStyle="http://schemas.xmlsoap.org/soap/encoding" /> </input> <output> <soap:body use="encoded" namespace="http://travelagency.example.org/wsdl/trips" encodingStyle="http://schemas.xmlsoap.org/soap/encoding" /> </output> </operation> ... </binding> xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
  • 33. What is UDDI •  UDDI stands for Universal Description, Discovery and Integration •  UDDI a standard for publishing and discovering Web services •  UDDI is a specification for a distributed registry of Web services •  UDDI is built upon standards such as HTTP, XML, XML Schema, SOAP, WSDL •  UDDI can communicate via SOAP, CORBA, Java RMI Protocol •  UDDI uses WSDL to describe interfaces to Web Services
  • 34. Ways to Use UDDI Registry •  White pages –  name, address, contact person, Web site •  Yellow pages –  types of business, locations, products, services, categorizations •  Green pages –  technical information about business services, pointers to WSDL descriptions of the services
  • 35. UDDI Data Model: UDDI Core Data Types Example: http://www.tutorialspoint.com/uddi/uddi_data_model.htm
  • 36. UDDI Data Model: tModel example <?xml version="1.0"?> <tModel tModelKey="”> <name>http://www.getquote.com/StockQuoteService-interface</name> <description xml:lang="en">…</description> <overviewDoc> <description xml:lang="en”>WSDL Service Interface Document </description> <overviewURL> http://www.getquote.com/services/SQSinterface.wsdl#SingleSymbolBinding </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4” keyName="uddi-org:types" keyValue="wsdlSpec"/> <keyedReference tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384” keyName="Stock market trading services” keyValue="84121801"/> </categoryBag> </tModel>
  • 37. UDDI: Programmatic Interfaces •  UDDI Inquiry Interface: –  find_business, find_service, find_tModel, find_binding, find_relatedBusiness –  get_businessDetail, get_serviceDetail, get_bindingDetail, get_tModelDetail •  UDDI Publisher Interface: –  save_business, save_service, save_binding, save_tModel –  delete_business, delete_service, delete_binding, delete_tModel –  ...
  • 38. Big Web Services Examples •  http://www.xmethods.com •  http://www.programmableweb.com/
  • 39. Web services enable 1.  data exchange between various applications and different platforms 2.  to resolve interoperability issues 3.  applications to function between two different operating systems server 4.  all of the above
  • 40. Coding and decoding, and transporting the data is performed by 1.  XML and UDDI respectively 2.  XML and SOAP respectively 3.  HTML and HTTP respectively 4.  HTML and SOAP respectively
  • 41. Which of the following is used to locate and describe web services? 1.  SOAP 2.  Web page 3.  WSDL 4.  UDDI
  • 42. Why SOAP is used as a protocol for accessing a web service? 1.  SOAP platform and language independent, allows to get around firewalls 2.  SOAP is based on HTML 3.  SOAP is designed to communicate through LAN 4.  All of the above
  • 43. Big Web Service Operations vs RESTful Web Service URIs Big WS operations RESTful WS URIs getAllUsers() http://example.com/users/ " getUserById() http://example.com/users/id/<user-id> getUserByName(), addUser() http://example.com/users/name/<user-name> removeUser(), updateUser() 03/28/11
  • 44. Big Web Services versus REST A SOAP service has a single endpoint •  that handles all the operations •  therefore it has to have an application-specific interface. A RESTful service has a number of resources •  so the operations can be distributed onto the resources •  and mapped to a small uniform set of operations. 03/28/11
  • 45. Comparison: Big Web Services vs RESTful Web Services •  How the client conveys its intentions to the server? Where method information is kept? –  Big Web Services: in HTTP header and entity body –  RESTful Web Services: in HTTP header •  How the client tells the server which part of the data set to operate on? Where is scoping information kept? –  Big Web Services: in the entity body –  RESTful Web Services: in the URI path
  • 46. Comparison: Big Web Services vs RESTful Web Services •  Big Web Services pros: –  protocol transparency and independence –  existence of tools to hide the complexity –  security •  Big Web Services cons: –  rudimentary processing protocol –  complexity –  heavyweight architecture –  do not get the benefits of resource-oriented services –  opaqueness
  • 47. Comparison: Big Web Services vs RESTful Web Services •  Big Web Services are the preferred option for enterprise application integration •  RESTful Web services are well suited for basic, ad hoc integration scenarios over Web (Mashup)
  • 48. Comparison: Big Web Services vs RESTful Web Services •  RESTful Web Services pros: –  simplicity –  lightweight infrastructure –  addressability –  uniform interface –  scalability of stateless RESTful Web Service –  improved performance using JSON •  RESTful Web Services cons: –  bound to one protocol: HTTP –  only POST and GET can be used in XHTML form –  dealing with large input data - malformed URI –  security issues
  • 49. Recommended reading Cesare Pautasso,Olaf Zimmermann,Frank Leymann (2008) RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision. Proc. of the 17th International World Wide Web Conference (WWW2008), Bejing, China, April 2008.

Notas del editor

  1. To describe in simple words what Web services are sometimes a LEGO example is being used. Conceptually think about a child who gets his first box of LEGO and throws the little blocks on the floor. He gets little bits and builds something out of them, then he breaks it and makes something new. Every time he rebuilds something of a different shape with a different set of characteristics. Those small building blocks are the Web services and where they come from are the existing Web applications. Think of Web applications that fit into the client-server paradigm, except that the clients are not people but other Web applications.
  2. Web services are software systems that are also designed to be accessed using web protocols, but that are intended to be used by other software applications rather than directly by end users (machine-to-machine interaction). The API allows programmers to use predefined functions to interact with the software system, instead of writing them from scratch. Think about a Java class which might be viewed as providing services (instance variables and methods) for use by other software in a program. APIs in general can use any means of communication they wish (not necessarily over network). Web APIs are used in the context of Web development, they are available over Internet. They can be virtually considered as a synonym to Web Services. By using Web Services your Web-application can publish its function or message to the rest of the world.
  3. Following the learning from comparison approach let&apos;s see how web services, web applications and APIs are related to each other. We have learned about Web applications which are software systems that are designed to be accessed by end users through browsers or other web client software. Web services are software systems that are also designed to be accessed using web protocols, but that are intended to be used by other software applications rather than directly by end users (machine-to-machine interaction). The API allows programmers to use predefined functions to interact with the software system, instead of writing them from scratch. Think about a Java class which might be viewed as providing services (instance variables and methods) for use by other software in a program. APIs in general can use any means of communication they wish (not necessarily over network). Web APIs are used in the context of Web development, they are available over Internet. They can be virtually considered as a synonym to Web Services. By using Web Services your Web-application can publish its function or message to the rest of the world. http://e-culture.multimedian.nl/demo/session/api/search?query=gogh&amp;view=exhibit&amp;http%3A%2F%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23source=http%3a%2f%2fe-culture.multimedian.nl%2fns%2frijksmuseum%2f&amp;indent=true&amp;display=thumbnail&amp;display=label&amp;display=http%3A%2F%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23creator&amp;display=http%3A%2F%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23location.creationSite&amp;searchPath=abstract show CHIP example of how the data is displayed
  4. It is possible to build completely new applications by combining Web services. These applications are called mashups. Example of a mashup: Wikipediavision, a site that shows in semi-realtime where anonymous edits to Wikipedia are originating from. It combines Google Maps and a Wikipedia API.
  5. Machine-to-machine interaction - Web services are used to provide services to software applications. The data they provide is intended as input to a software program that does something amazing with this data - Interaction is happening over a network - because these services are intended to be accessed using Web protocols and technologies, they are called Web services. - Another keyword in this definition is interoperable.
  6. Connect existing software – The focus of Web services is on simplifying the integration of heterogeneous applications on different platforms, implemented in different languages and residing within the same organization or across multiple organizations. Thus the driving factor for the Web services is the interoperability between all these systems. Reusable application-components – Web services can offer application-components that can be included in other applications like: currency conversion, weather reports, or language translation as services.
  7. The name Big Web Services is given by Richardson and Ruby, the authors of the first book on the alternative solution - RESTful Web services. RESTful or REST-compliant Web services (those conforming to the REST constraints) look like the Web. Their purpose is to create, retrieve, update, and delete information resources. Big Web Services allow for arbitrary complex set of operations on resources but they typically don&apos;t work like Web though some Big Web Services can be compliant with REST. SOA is an architectural style or pattern for building distributed systems that deliver application functionality as services to either end-user applications or other services. Web service is a kind of SOA implementation.
  8. Technologies that enable distributed computer systems to communicate with one another have been around for a long time. e.g. CORBA Common Object Request Broker Architecture, DCOM Distributed Component Object Model, Java RMI Remote Method Invocation, RMI over IIOP Java RMI style programming using CORBA IIOP for communication. But Web services are easiest to implement than many other approaches because they are based on commonly used existing standards (protocols and data formats), in particular, HTTP and XML. At their lowest levels Web services are typically based on transmitting XML documents between clients and servers via HTTP. XML is used to format data into a document that all interacting application know how to process. HTTP clients and servers are available for all major programming languages and operating system/hardware platforms, and the default HTTP port 80 is commonly left open by default in most firewall configurations. This communication mechanism provided by sending XML documents over HTTP connections allows for interoperability. Big Web Services have three basic platform elements:SOAP to transport data, WSDL to describe Web services, UDDI to publish and find Web services.RESTful Web services rely upon the concept of the URI. Often as an alternative to XML, they use a lightweight JSON (JavaScript Object Notation) format for messages exchange between client and server. It is possible to provide WADL file describing every resource by RESTful service. RESTful services have simpler interfaces thus WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.
  9. SOA can be conceptualized as containing 3 roles and 3 operations (publish, find and bind). Service provider – develops the service interface and implementation and deploys the service so that it is available to be invoked over a network. The service provider also creates a service description and publishes that service description with one or more service brokers (publish operation). The service description describes everything that a service requester must know to invoke the service made available by the service provider. This information typically includes the format for the request message, the format for the response message (if any) and where to send the request message. Service broker – accepts requests from service providers to publish information about the services they want to make available. The information published includes the type of the service, a description of the service, and the location where the service can be invoked. The service requester can then query the service broker to find a particular service (find operation). An analogy to the service broker is a phone book. A company publishes information on a particular service they are providing in a phone book. In turn, people look in the phone book to find companies providing that same service. People find the company that published their service and use the contact information to request the service from that company. Service Requester – uses the service broker to find services that match some set of criteria. The service requester can then use the service description to connect to the service and invoke it (bind operation).
  10. This type of architecture allows to achieve the following properties: separation of concerns - each functional unit is then exposed as a separate service which achieves a separation of concerns. Each service handles a specific concern (task). In SOA applications are integrated via the service interface not the service implementation. The separation of interface from implementation is intended to allow service consumer applications the ability to interoperate with service provider applications regardless of whether their underlying implementations are compatible (interoperability). As a result the applications are loosely coupled. loose coupling among interacting software applications - the benefit of loosely coupled applications lies in their ability to survive evolutionary changes in their structure and implementation. reusability of services - these services can then be orchestrated together to form any number of different business processes. If a company finds that it is more cost-effective to use a service provided by a different company than maintain their own, they can quickly swap out that service. The system can also be designed to dynamically choose among different service providers (if they have the same service interface) based on price or even some other policy such as performance or reliability.
  11. The interaction illustrated is accomplished through the exchange of XML documents. The publish and find operations of the UDDI registry and the Web service are invoked using the exchange of SOAP messages. SOAP messages and WSDL documents are both instances of XML documents and the data SOAP messages contain is also XML.
  12. A SOAP message is an ordinary XML document that consists of an envelope that describes a message and how to process it, data encoding rules for describing data types (based on XML Schema) and a set of rules for how to make remote calls (remote procedure calls RPC or messages) and get responses. The main elements of the SOAP message are:an envelope that identifies the XML document as a SOAP message (notice the xmlns:env namespace in the example). It should always have the value of: &quot;http://www.w3.org/2001/12/soap-envelope&quot;. The namespace defines the Envelope as a SOAP Envelope. If a different namespace is used, the application generates an error and discards the message. SOAP envelope contains two main parts:a(n optional) header (the metadata) that provides (application-specific) information about the message. The actual contents of the header are not specified by the SOAP standard but the basic idea is that the header may be available to SOAP intermediaries that may process the message as it goes from the sender to the receiver, as well as being available to the actual receiver. Headers are typically used to transmit authentication or session management data. body contains the message itself (the data). A Body element contains call and response information – the mandatory element within SOAP Envelope. The optional SOAP Fault element contains errors and status information for a SOAP message. Both the header and the body contain application specific XML content. The contents of Header and Body elements are application defined and not a part of the SOAP specifications.
  13. RPC is very much like making a standard HTTP request to a Web application, where the client makes a call to the service and then waits for the response. An example shows an RPC-style SOAP request message and the response message from the method: request for a ticket price on a particular date and a corresponding result. An example uses a method getPrice which encapsulates a number of parameters: departing, arriving, departureDate. The corresponding method and parameter tags are namespaced by the service name. In the response message there is only ever one parameter tag representing the return value of the method getPriceResponse.
  14. The examples above represent an implementation of the RPC-Style Architecture according to the classification by Richardson and Ruby. An RPC-style Web service accepts an envelope full of data from its client, and sends a similar envelope back. What kind of envelope e.g. HTTP or SOAP is not important to classification. Just about every SOAP service is an example of an RPC-style.
  15. In contrast to RPC messaging is asynchronous. A message is sent but the client does not wait for the response (similar to the asynchronous XMLHttpRequest in Ajax systems). The more interesting scenarios typically involve multiple messages exchange between SOAP sender and ultimate SOAP receiver following request-response pattern. Continuing with the travel scenario an example shows another type of SOAP message returned in response about prices. This response seeks to refine some information in the request, namely the choice of airports, giving a list of alternatives.
  16. SOAP provides a model for handling faults in processing of message. Faults are reported within env:Fault element which has two mandatory sub-elements env:Code which places the fault in an appropriate category and a human-readable explanation of the fault env:Reason. Example shows that it is an env:Sender fault which indicates that is is related to some syntactical or inappropriate information in the message. In this case it is expected that the sender has to take a corrective action.
  17. SOAP messages may be exchanged using a variety of underlying protocols (e.g. HTTP or email). However in most cases they use HTTP as the underlying transfer protocol. HTTP binding makes use of GET and POST Web methods: HTTP POST is used for conveying SOAP messages in the bodies of HTTP request and response messages (SOAP-specific aspect is that a SOAP message in the request body has to be processed); and HTTP GET is used in HTTP request to return a SOAP message in the body of response (no SOAP message in the request body). As the slide shows our RPC example is carried in an HTTP Post Request. The destination URL is split between the request line which contains the argument /priceService/getPrice identifying the procedure to be invoked and the host address. Since a SOAP message is being sent the content-type field is set to application/soap+xml.
  18. RPC return in the example embedded in an HTTP response indicates a successful completion . If an error occurs processing the request, the HTTP binding specification requires that a HTTP 500 “ Internal server error ” be used with an embedded SOAP message containing a SOAP fault indicating the server-side processing error.
  19. &lt;portType&gt; A set of operations supported by one or more endpoints &lt;binding&gt; A protocol and data format specification for a particular port type concrete level - specifies how the abstract level is implemented. Concrete level gives a Web address at which the operations of a port type can be invoked and specifies how the messages that are exchanged through that address are bound to a specific transport protocol (e.x. HTTP) . Binding describes concrete communication protocol and data format specification for a particular port type . Port is a combination of a binding and network address. A WSDL document defines services as collections of ports.
  20. The slide shows a simplified fraction of a WSDL document. It shows an abstract definition of a request and response message for our travel example and the definition of a port type. The &lt;message&gt; element defines the data elements of an operation. Each message can consist of one or more parts and the associated data types. The parts can be compared to the parameters of a function call in a traditional programming language.The &lt;portType&gt; element defines &quot;pricesPT&quot; as the name of a port, and &quot;getPrice&quot; as the name of an operation.The &quot;getPrice&quot; operation has an input message called &quot;intineraryMsg&quot; and an output message &quot;intineraryRespMsg&quot;.Compared to traditional programming, getPricePT is a function library, &quot;getPrice&quot; is a function with &quot;intineraryMsg&quot; as the input parameter, and intineraryRespMsg as the return parameter.
  21. In the example, the port &quot;prices&quot; defines a one-way operation called &quot;setPrice&quot;. The &quot;setPrice&quot; operation allows input of new price message using a &quot;newPrices&quot; message with 4 input parameters. No output is defined for the operation.
  22. A service gives a name to a set of ports. Each port specifies the address at which the operations of a particular port can be invoked together with the binding to be used. Taken together the ports of a service host a set of related operations that are offered to customers. The port getPricesRPCPort identifies a particular binding b1 and the Web address at which messages that use that binding are to be sent.
  23. WSDL bindings defines the message format and protocol details for a Web service. Suppose in our travel scenario we want all operations of port type &apos;pricesPT&apos; to be invoked with RPC-style SOAP messages sent using HTTP. Then we might declare the binding b1 as shown in the slide. The binding element has two attributes: name - defines the name of the binding and type - points to the port for the binding. The child soap:binding is an example of an extension of WSDL that provides information specific to that binding. The soap:binding element has two attributes - style and transport. The style attribute can be &quot;rpc&quot; or &quot;document&quot;. For our travel example we use rpc. Transport is SOAP messages on top of HTTP protocol.The operation element defines each operation that the port exposes. Attribute “ name ” gives the name of the operation. It is important to keep in mind that the elements input and output inside the binding element are not themselves SOAP messages. Instead these are descriptions from which the actual SOAP messages are constructed. You must also specify how the input and output are encoded. In this case we use &quot;encoded&quot;. A fault child should describe the fault message but it is omitted.
  24. Key functional concepts for working with UDDI are UDDI Registry, UDDI data model and programmatic interfaces.
  25. White pages: Basic information about the Company Basic contact information A unique identifiers for the company tax IDs (2) Yellow pages: This has more details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want. (3) Green pages: This category contains technical information about a web service. This is what allows someone to bind to a Web service after it&apos;s been found. This includes: The various interfaces The URL locations Discovery information and similar data required to find and run the Web service. NOTE: UDDI is not restricted to describing web services based on SOAP. Rather, UDDI can be used to describe any service, from a single web page or email address all the way up to SOAP, CORBA, and Java RMI services.
  26. The UDDI specification defines core data types. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:A description of a service ’ s business function (called the businessService) Information about the organization that published the service (businessEntity) The service ’ s technical details (bindingTemplate), including a reference to the service ’ s programmatic interface or API, and The binding template represents the actual implementation of the web service. Various other attributes or metadata such as taxonomy, transports and protocol definitions, digital signatures, etc. (tModels). Value sets including identifier systems, categorization systems and namespaces. Structured categorizations using multiple value sets called &quot;categorization groups ” . tModel stands for technical model. tModels can be used to represent classification information which can then be added into interface tModels to make search easier, and finally,
  27. The UDDI specification defines core data types. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:A description of a service ’ s business function (called the businessService) Information about the organization that published the service (businessEntity) The service ’ s technical details (bindingTemplate), including a reference to the service ’ s programmatic interface or API, and The binding template represents the actual implementation of the web service. Various other attributes or metadata such as taxonomy, transports and protocol definitions, digital signatures, etc. (tModels). Value sets including identifier systems, categorization systems and namespaces. Structured categorizations using multiple value sets called &quot;categorization groups ” . tModel stands for technical model. tModels can be used to represent classification information which can then be added into interface tModels to make search easier, and finally,
  28. These are query and update languages. Requestors can use Inquiry Interface to find and retrieve information from the registry. Providers (businesses) can use Publisher Interfaces to enter information into the registry, to store and update it.Inquiry and publishing functions represent the core data management tools of a UDDI registry.
  29. In RESTful approach we use the following (example) URIs as the destination of the corresponding standard HTTP methods: http://example.com/users/ (HTTP method GET) http://example.com/users/id/ &lt;user-id&gt; (HTTP method GET) http://example.com/users/name/ &lt;user-name&gt; (HTTP methods GET, PUT, DELETE, POST)
  30. - transparency and independence - using SOAP the same message in the same format can be transported across a variety of middleware systems which may rely on HTTP but also on many other transports (These may change along the way). - existence of tools to hide the complexity - mature SOAP engines and WSDL tools effectively hide the perceived complexity from the application programmer and integrator - security - security concepts are much better specified and deployed in SOAP-based protocols than in native HTTP protocols. Weaknesses Big Services - rudimentary processing protocol . HTTP protocol is used just as a tunneling protocol to enable remote communication through firewalls, but it is not used to convey the semantics of the service interaction. - complexity - too often Big Web Services are used for a job that HTTP could handle just fine. The effect is that HTTP is reduced to a transport protocol for an enormous XML payload. - heavyweight architecture for distributed object access - do not get the benefits of resource-oriented services . They are not addressable, well connected, don&apos;t respect uniform interface. Many of them are stateless though. - opaqueness - understanding one does not help you to understand the next one.
  31. Strengths RESTful Web Services considered simple because REST leverages existing well-known W3C standards (HTTP, XML, URI). such lightweight infrastructure where services can be built with minimal tooling is inexpensive to acquire. No need to develop custom-client software since the developers can begin testing using ordinary Web browser. addressability - no need for a registration to a (centralized) repository, URIs can be bookmarked. it is known how to scale a stateless RESTful Web service to serve a very large number of clients, thanks to the support for caching, clustering and load balancing built into REST. using lightweight message formats, e.g. JSON allows to optimize the performance of a Web service. Weaknesses RESTful Web Services bound to one protocol: HTTP POST and GET are the only two verbs that can be used in the method attribute of an XHTML form. for idempotent requests having large amounts of input data it is not possible to encode such data in the resource URI, as the server will reject such “ malformed ” URI (request-URI too long). POST method does not suffer from these limitations. security issues: REST doesn&apos;t cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,