Docstoc

basic

Document Sample
basic Powered By Docstoc
					Service-Oriented Computing
     Basic Technologies
                         SOC and SOA
 Service-oriented architecture (SOA)
    An architectural approach for software integration
    A coarse grained and loosely coupled approach
    Support better reuse and dynamic adaptivity
    More focused on software services
 Web service
    A set of XML based standards defined to realize SOA
 Service-oriented computing
    A more general concept than SOA, consider any form of services
        Such as services provided by hardware devices or even human
 Semantic web
    Theories and techniques to specify the web
    Can be applied to SOC for service specification and discovery
  Basic Service Infrastructure



                   Service     Registry
                   Broker


        Publish                Discover
       (WSDL)                  (UDDI)



Service           Invocation          Service
Provider           (SOAP)            Requestor
Web Service Stack (W3C)
              Service Oriented Computing
 Topics
    Service specification
        Specifies the service and its I/O (WSDL)
        Is it sufficient?
    Service publication and discovery
        Is UDDI based centralized approach sufficient?
    Service composition and orchestration
        Specification of the composition and process (BPEL, OWL)
        Discovery and adaptation (allow interoperations)
        It is still a very challenging area
    Service invocation
        Invocation protocol (SOAP)
        Is it sufficient? How about continuous interactions?
              Service Oriented Computing
 Topics
    Semantic web
        Achieve better service specification, discovery and composition
    Service mediation
        Solve mismatches (data, protocol, process) among the services in
         different domains
    Quality of service (QoS)
        How to specify QoS, how to satisfy QoS requirements, …?
    Dependability and security issues
        WS-Security, WS-Trust, …
                      Service Invocation
 SOAP (Simple Object Access Protocol)
    Designed on top of HTTP for remote procedure call or simply message
     exchange
    Include three parts
    Envelope: define the message to be a SOAP message
    Encoding rules: for expressing instances of application-defined
     data types
    Body: information for the actual invocation and response
                   SOAP Request Example
POST /temp HTTP/1.1
Host: www.socweather.com                        HTTP header followed by
Content-Type: text/xml; charset="utf-8"         a mandatory blank line
Content-Length: xxx
SOAPAction: "http://www.socweather.com/temp"

<?xml version=“1.0”?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<env:Body>
 <m:GetTemp xmlns:m="http://www.socweather.com/temp.xsd">
  <m:City>Honolulu</m:City>
  <m:When>now</m:When>                                    Web service URL and
 </m:GetTemp>                      Input parameters       method name
</env:Body>
</env:Envelope>
                SOAP Response Example
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
SOAPAction: "http://www.socweather.com/temp"

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
  env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
  <env:Body>
    <m:GetTempResponse
          xmlns:m="http://www.socweather.com/temp.xsd">
      <m:DegreesCelsius>30</m:DegreesCelsius>
    </m:GetTempResponse>
  </env:Body>
</env:Envelope>
                   Service Specification
 WSDL
   Define transmission protocol, services, standard data type
    definition file, etc.
   Define the service name and URL (service)
   Define all publicly available functions (operation)
   For each function, define all message requests and message
    responses
   Example
      <wsdl:service name="HelloWorldService">
       <wsdl:port binding="impl:urn:HelloWorldSoapBinding"
        name="urn:HelloWorld">
       <wsdlsoap:address
        location="http://localhost:8080/axis/services/urn:HelloWorld" />
       </wsdl:port>
      </wsdl:service>              Define service name and location
                  Service Specification
<wsdl:portType name="HelloWorldService">
 <wsdl:operation name="sayHello" parameterOrder="in0 in1">
 <wsdl:input message="impl:sayHelloRequest" name="sayHelloRequest" />
 <wsdl:output message="impl:sayHelloResponse"
   name="sayHelloResponse" />
 </wsdl:operation>
                     Define functions and bind their request/response definitions
</wsdl:portType>

<wsdl:message name="sayHelloRequest">
 <wsdl:part name="in0" type="tns2:string" />
 <wsdl:part name="in1" type="tns2:string" />
 </wsdl:message>
<wsdl:message name="sayHelloResponse">
 <wsdl:part name="sayHelloReturn" type="tns2:string" />
 </wsdl:message>                     Define I/O parameters and types
          Service Publishing and Discovery
 Directory service in distributed systems (Name server)
    For distributed file systems
    Maintain the file names, their locations, …
 UDDI
    Universal Description, Discovery, and Integration
    Provide directory service for web services
    It is a Web service itself (access to UDDI is SOAP based)
 WSDL UDDI
    UDDI register information specified in WSDL
                                  UDDI
 UDDI registry
    Each entry is an XML document composed of:
       businessEntity: A description of the organization that provides the
        service, can be a company, a group, a person, etc.
       businessService: A list of all services offered by the business entity
           o Support projection: reference to services provided by other organizations
           o Include name, description
           o categoryBag: a list of business categories (e.g., which industry, which
             product category, which geographic region)
                - Can be used to help search in terms of category
       bindingTemplate: the specifications of the services being offered
           o bindingKey, serviceKey, description
           o accessPoint: the URL of the service being provided (actually can be
             anything, e.g., an e-mail address or even a phone number)
       tModel (technical model)
                              UDDI
 tModel
   A tModelis is a document with a short description of the technical
    information and a pointer to the actual information
   It contains
       A pointer to the
        WSDL description
       Description of the
        business protocol
        and conversations
       tModelKey, Name,
       overviewDoc (URL)
       categoryBag
       …
                                 UDDI
 Business UDDI
    IBM, Microsoft, SAP, NTT has provided public UDDI registry
     since 2000, and cumulated approximately 50,000 service entries
    But they discontinued in 2006
 Problems with UDDI
    No semantic information
        Can add OWL-S related specifications, but not completely compatible
         with the semantic information
    No structure, difficult to imposed security constraints
        E.g., cannot support role based access (cannot map roles to entries)
    No management protocols
        Difficult to maintain and evolve
                                 AXIS
 Remote procedure call
    From shared memory to message passing to RPC
      Server-side
        Driver
                                                    Client
         Method
                                                  Client-side
      Web Server                                     Stub
                         Network + DNS

 Axis
    Support web service infrastructure
        Tools to generate wrappers for client and server (same as RPC)
        Tools to generate WSDL from methods
        Web server
                                  AXIS
 Problems
    Static binding, client invokes a fixed service
 Some solutions
    Making URL a reference
        Fixed function and syntax in the invocation
        Dynamically bind to the service with matching WSDL
    Data flow model
        Output of one service is linked to input of another service
 Which solution is preferable
 Any other possibilities?
                     Service Composition
 BPEL
   A language for specifying business process based on Web services
   A standard for Web service composition by OASIS
   Specification of partner link
       BPEL describe the business process
       The partner link links a node in the process to a Web service that can
        be invoked
           o Partner Link Type
               - The portTypeof the process and the portTypeof the service
           o Partners: a group of Partner Links (this is an optional element)
               - A partner link can only point to one partner
           o Partner Link: the actual link to the service
                     Service Composition
 BPEL
   Description of basic activities
       <receive> allows the business process to do a blocking wait for a
        matching message to arrive.
       <reply> allows the business process to send a message in reply to a
        message that was received through a <receive>
           o <receive> and <reply> form a request-response operation for the
             composed process
       <invoke> allows the business process to invoke a request-response
        operation offered by a service or process
       <throw> generates a fault in the business process
       <wait> Insert a wait for a given time period or until a certain time
                  Service Composition
 BPEL
   Specification of structured activities
      <sequence>: an ordered sequence of activities
      <switch>: case-statement
      <while>: loop
      <pick>: execute one of several alternative paths
      <flow>: parallel steps
                   Semantic Web Service
 Deficiencies in original web service framework
    WSDL only support syntactical description
    Service discovery capability is limited
    No support to automate service composition
    No specification of interaction with services
 Semantic web
    Support specification of information that contains machine-
     processable and machine-understandable semantics
 Semantic web service
    Semantic web technology
    Semantic and QoS models for web services
    Mediation (WSMO)
                Semantic Web Service
 Semantic Web stack
    Language models

                                  OWL-S (Services)

                                 SWRL (Rules)

                        OWL ([DLP], Light, DL, Full)

                        RDFS (RDF Schema)

              RDF (Resource Description Framework)

            XML (Extensible Markup Language)
                                    RDF
 RDF (resource description framework)
    Data model
        Resources
           o Named by URI (universal resource identifier)
        Properties
           o Define characteristic of a resource
        Value
        Example:
           <rdf:Description rdf:about="http://www.w3schools.com">
               <si:title>W3Schools</si:title>
               <si:author>Jan Egil Refsnes</si:author>
           </rdf:Description>
    RDF statement (triple)
        Specifying facts using subject/predicate/object
                              RDF Schema
 RDF Schema
    Defines new RDF vocabulary
    Light-weight ontology specification
 RDF Schema example:
    rdfs:Class and rdfs:subClassOf
        Specifying a class of resources and the class hierarchy
    rdfs:Resource (all things in RDF are resources)
        All resources are an instances of “class”
    rdfs:Literal
        Literal values such as strings and integers
    rdfs:Property (is also an instance of rdfs:Class)
    rdfs:domain & rdfs:range
        Define restrictions on the resources that have a given property
          (domain) and the set of valid values for that property (range)
                       RDF Schema
 Reasoning                                         Property
 Validation
                                                          type
                                       Fish     range

                                                       owns
                      Class              domain
               type           type            Person

             Person             Fish
      type            type             Or, Wanda can be a person
                                type   and a fish (a mermaid)
   Wendy                Wanda
               owns
                                  OWL
 Web ontology language (OWL)
    Build on top of RDF and RDF Schema
    Add more vocabulary for describing
         Relations between classes (e.g., disjointness)
         Cardinality (e.g., "exactly one")
         Equality
         Richer typing of properties
         Characteristics of properties (e g symmetry)
         Enumerated classes
                                  OWL
 OWL class can be constructed
    Explicitly
    By set operators
        IntersectionOf, unionOf, complementOf
        Example
           <owl:Class rdf:ID='SweetBread'>
           <owl:intersectionOf rdf:parseType='Collection'>
              <owl:Class rdf about '#Bread'/>
              <owl:Class rdf:about='#SweetFood'/>
           </owl:intersectionOf>
           </owl:Class>
                                        OWL
 Restrictions
     A unique feature of description logics
     Key primitives
           someValuesFrom a specified class
           allValuesFrom a specified class
           hasValue equal to a specified individual or data type
           minCardinality and maxCardinality
     Examples
               <owl:Restriction>
                  <owl:onProperty rdf:resource="#hasFather"/>
                  <owl:maxCardinality rdf:datatype="xsd:nonNegativeInteger"> 1
                  </owl:maxCardinality>
               </owl:Restriction>

               <owl:Restriction>
                  <owl:onProperty rdf:resource='#bakes'/>
                  <owl:someValuesFrom rdf:resource='#Bread'/>
               </owl:Restriction>
                                  OWL
 Axioms
    Common primitives
       rdfs:subClassOf
       owl:equivalentClass
    Example
           <ex:Country rdf:ID='Iran'/>
           <ex:Country rdf:ID='Persia'>
              <owl:sameAs rdf:resource='#Iran'/>
           </ex:Country>

 Inference
    Based on restrictions and/or axioms
    Statements from different documents about the same URI are
     automatically conjoined
                            OWL-S
 OWL for services
    An OWL ontology defined for (formally) describing properties and
     capabilities of Web services
 Upper ontology
                                  OWL-S
 Profile
    Capabilities description (functional properties)
        Inputs, outputs, preconditions, effects
        May be a subset of process model IOPRs
    Service descriptors (non-functional properties)
        Provenance
        Quality of Service
            o Response time, quality guarantees, etc.
        Security and policies
        Domain-specific characteristics
            o E.g., geographical region, class of service
        Some do not have adopted standards yet
OWL-S
                               OWL-S
 Process
    Description of service behavior
    Interaction patterns (read/write messages)
        Tells service user how and when to interact
    Include
        Inputs, outputs, preconditions and effects (IOPE)
    Can be
        Atomic processes or composite processes
    Composition processes can be defined by
        Control flow
        Data flow
OWL-S
                                 OWL-S
 Process
    Description of service behavior
    Interaction patterns (read/write messages)
        Tells service user how and when to interact
    Include
        Inputs, outputs, preconditions and effects (IOPE)
    Can be
        Atomic processes or composite processes
    Composition processes can be defined by
        Control flow
            o Loop, condition
            o Sequence, choice, parallel
        Data flow
                               OWL-S
 Grounding
    Information for accessing the service
        Message formatting, transport mechanisms, protocols, serializations
         of types
    Builds upon WSDL
                                OWL-S
 Added capabilities
    Define ontology-based specification frameworks for describing
     Web Services and related aspects (Web Service Description
     Ontologies)
    Support formal specification of the semantic behavior of the web
     services  Facilitate composition
        In service profile, pre-conditions and effects can be defined to specify
         the functional behavior of the service
    Support the definition of service ontology
        Describe the relations among services
    Define ontologies for underlying data models to allow machine
     supported data interpretation (Semantic Web)
   WSMO - Web Service Modeling Ontology
 OWL-S
   An ontology to describe Web services and data
   Facilitates composition, but does not specifically model it
   OWL-S is grounded in WSDL and it has been mapped into UDDI
 WSMO
   Ontology based model for Web services, data, as well as
    composition aspects
         Core elements: Ontologies, Web Services, Goals, Mediators
         Language for semantic element description (WSML)
         Reference implementation (WSMX)
         Popular in Europe
   Mediation as a key element
       Every resource description is based on ontology
       Every data element interchanged is an ontology instance
                                WSMO
 Goals
    Objectives that a client wants to achieve
    Clear separation of requester and provider
    Use ontological relationships & mediators to link goals to web
     services, but there is no good solutions either
 Goal specification
    Ontology based goal specification
        Support goal ontology
        Can reuse an existing goal ontology or build on top of existing ones
    Requested Capability (desired service functionality)
    Requested Interface
        Describes communication behavior supported by the requester
         (Choreography)
        Restrictions/preferences on orchestrations of Web services
                            WSMO
 Mediation
    Resolve mismatches on data, service, and process
                               WSMO
 Data mediation
    Solving terminological mismatches by ontology mapping,
     merging, alignment
 Functional mediation
    Solving functional mismatches between goals and/or web services
    Used during service discovery and semantic matchmaking
        Exact, plug-in, subsumption, intersection, no-match
 Process mediation
    Solving communication
     mismatches
                            WSMO
 OO Mediators
    Data level mediation, resolve mismatch terminologies
 GG Mediators
    Data/Function/Process level mediation
    Goal does not involve the communication mechanisms
 WG Mediators
    Match a Web Service to a Goal and resolve mismatches
    Data/Function/Process level mediation
 WW Mediators:
    Enable interoperability of heterogeneous Web Services
    Data/Function/Process level mediation
                    OWL-S and WSMO
 OWL-S Profile = WSMO capability + Goal + Non-
  functional properties
    OWL-S uses Profiles to express service capabilities and desired
     capabilities
    WSMO separates provider (capabilities) and requester points of
     view (goals)
 OWL-S Process = WSMO Service Interfaces
    OWL-S Process model describes operations performed by Web
     Service, including consumption as well as aggregation
    WSMO separates Choreography and Orchestration
    OWL-S formal semantics has been developed in different
     frameworks such as Petri Nets and Pi-calculus
    WSMO service interface model with ASM-based formal semantics
                    OWL-S and WSMO
 OWL-S Grounding is similar to WSMO Grounding
    Both map to WSDL
    WSMO also aims at an ontology-based grounding to avoid loss of
     ontological descriptions throughout service usage process
 Mediation
    External to OWL-S, performed in the orchestration process
    WSMO regards mediators as key conceptual elements
        Support mediator reuse
                    Some Other Concepts
 WSIF: Web Services Invocation Framework
    Similar to the tasks performed by Axis, but only for the client, and
     involves binding as well as invocation
    Support dynamic binding and asynchronous invocation
 WSCL: Web Services Conversation Language
    Defines the overall input and output message sequences of a web
     service using a finite state machine over the message types
 WS-Coordination
    Support the specification of a service whose job is to coordinate
     the activities of the Web services that are part of a business process
 WS-Transaction
    Support transaction execution on composite services
    Support conventional transaction protocols, such as 2PL
    E.g., travel agent, airline, hotel together perform transactions
                                                  WSCL Example
                                                                                          <Conversation name="StoreFrontServiceConversation" …
                                                                                             <ConversationInteractions>
<<ReceiveSend>>
                                                     <<ReceiveSend>>                            <Interaction interactionType="ReceiveSend" id="Login">
                                                             Login
   Registration
                                                         in: LoginRQ                               <InboundXMLDocument id="LoginRQ"/>
in: RegistrationRQ
out: RegistrationRS
                                                      out:ValidLoginRS                                  hrefSchema=“http://conv1.org/LoginRQ.xsd”
                                InvalidLoginRS       out: invalidLoginRS
                                                                                                   <OutboundXMLDocument id="ValidLoginRS"/>
                                                                             InvalidLoginRS
                                                                                                        hrefSchema=“http://conv1.org/ValidLoginRS.xsd”
                          <<ReceiveSend>>
                            CatalogInquiry                       ValidLoginRS                      <OutboundXMLDocument id="InvalidLoginRS"
                             in: CatalogRQ                                                              hrefSchema=“http://conv1.org/InvalidLoginRS.xsd”/>
                             out: CatalogRS                                                     </Interaction>
                                                                                                …
                          <<ReceiveSend>>                                                       <Interaction interactionType="Empty" id="Start" />
                                  Quote                                                         <Interaction interactionType="Empty" id="End" />
                              in: QuoteRQ
                              out: QuoteRS                                                   </ConversationInteractions>
                                                                                             <ConversationTransitions>
                          <<ReceiveSend>>
                                                                                               …
                                Purchase                                                       <Transition>
                            in: PurchaseRQ                                                         <SourceInteraction href="Login"/>
                      out: PurchaseAcceptedRS
                       out: InvalidPaymentsRS                                                      <DestinationInteraction href="Registration"/>
                          out: OutOfStockRS                                                        <SourceInteractionCondition href="InvalidLoginRS"/>
InvalidPaymentRS                                               <<ReceiveSend>>
                                                                      Logout                   </Transition>
             PurchaseAcceptedRS                                in: LogoutMessage               <Transition>
                               <<Send>>                                                            <SourceInteraction href="Logout"/>
                                Shipping                                                           <DestinationInteraction href="End"/>
                       out: ShippingInformation
                                                                                               </Transition>
                                                OutOfStockRS
                                              InvalidPaymentRS                               </ConversationTransitions>
                                                                                          </Conversation>
                            WS-Coordination
 A coordination service is an aggregation of three services:
    Registration: for parties to register with the coordinator
    Activation: to create an instance of a coordination context
    Coordination protocol: to define the specific protocol to be
     followed

                  CreateCoordinationContext           Register




                         Activation                 Registration
                          Service                     Service

                                      Coordinator

     Protocol X          Protocol                    Protocol      Protocol Y
                         Service X                   Service Y
                                     SOC
 SOC
    Offers a new paradigm for system development and deployment
    Can integrate hardware/software/other services through the same
     service composition concept and technologies
    But real-world system development is still a major challenge
 How to integrate services into systems
    The technologies still remain in the syntactical level, semantic
     information has not shown revolutionary contributions
        The foundation of discovery is specification
        Semantic technologies help better describe services
        But the actual specification technologies is still far from satisfactory
            o E.g., how to properly specify the functionality of Linux (or differentiate
              it with Windows)
                                    SOC
 How to integrate services into systems
    Still the same old barrier: software component specification
        In SE research, this has been investigated for 3 decades
        Will a sophisticated ontology really help?
            o Take the Linux example, how to use ontology to achieve a better
              specification?
        Will we ever be there?
    Best practice: design patterns
        Has been an effective technology for software design
        Now being considered in SOA (service patterns)
        In a way, it is already in SOA
            o In OWL-S, a service can be composition of existing services
        But service pattern can make is more explicit and flexible
    Planning and reasoning
        May provide some help in service composition as well
                                  SOC
 Evolution in software development
    First evolution: From hardware/assembly to high level languages
    Second evolution: From basic language constructs to high level
     components/objects/services
        Many models have been provided, a lot of improvement, but software
         development is still time/cost/effort intensive
    Future evolution: Need revolutionary techniques
        SOC may some additional help, but is still far from the solution

				
DOCUMENT INFO