2003년 6월 25일 - krnet.or.kr · Web Services 2003년 6월 25일 이 규 철 충남대학교 컴퓨터공학과 [email protected]

Web Services

2003년 6월 25일

이 규 철

충남대학교 컴퓨터공학과

[email protected]

http://dblab.ce.cnu.ac.kr

KRnet 2003 Web Services, © 2003 충남대학교 컴퓨터공학과 이규철 2

TOC

Current Web Services

Components of Web Services

Types of Web Services

Complex Web Service Standards

Semantic Web Service

Semantic Web Service Framework

Semantic Web Service Discovery

Semantic Web Service Composition



The Evolution of the Internet

Internet Chapter I : “The eye-ball web”

Web used to deliver information and perform e-commerce

transactions

Web applications targeted to human users, manual

interaction

Internet Chapter II : “The transactional web”

A variety of services available on the Internet

A variety of devices

Users, apps can automatically discover the available

services that best meet their needs at any given time.

Service quality negotiation and invocation are also

automated.


Web Services

Application accessible using standard Internet

protocols by humans and/or other applications


Web Service Roles, Operations, Artifacts

Service

Provider

Service

Registry

Service

Requester Find

Publish Bind

Description Client

Service

UDDI Registry

• Service Provider hosts access to the service

• Service Requester is the application that is looking for and invoking or

initiating an interaction with services



Described using a service description language. (WSDL)

Published by registering their descriptions and use

policies with a well-known registry. (UDDI)

Found by sending queries to that registry and receiving

the binding details of the service(s) that fit the parameters

of the query.(UDDI)

Bound by using the information contained in the service

description to create a callable service instance or proxy.

Invoked over a network by using the information

contained in the binding details of the service

description.(SOAP)

(Composed with other services into new services and

applications.)


Web Service Architecture

Structure

Wire Description Discovery

Syntax

Envelope & Extensibility

Service Description

Infrastructure

Web services family

Directory SOAP WSDL UDDI

XML XML Schemas

10/2000 XML 1.0 •XSD CR •SOAP? •SCL? •UDDI?

10/2001 XML 1.0 XSD 1.0 SOAP 1.1 WSDL 1.1 UDDI 2.0

Components of Web Services

SOAP

WSDL

UDDI 2.0 & 3.0


SOAP : Simple Object Access Protocol

SOAP 1.0: Userland, Microsoft, DevelopMentor

SOAP 1.0 was specific to COM and HTTP

SOAP 1.1(April 26, 2000) – includes contributions

from IBM and Lotus

substitutable Transport bindings (not just HTTP)

substitutable Language bindings (e.g. Java)

substitutable Data encoding (pluggable)

completely vendor-neutral

independent of : programming language, object model,

operating system, or platform

SOAP 1.2 – current Proposed Recommendation from

W3C “XML Protocol” Working group, will eventually

become a recommendation


SOAP Message

SOAP Message

SOAP Envelope

SOAP Header

SOAP Body

Message Name & Data

Headers

HTTP Headers

XML Encoded SOAP

Message Name & Data

<Body> contains SOAP

Message Name & Data

Individual headers

<Header> encloses headers

<Envelope> encloses payload

Standard HTTP and SOAP HTTP Headers

The complete SOAP Message


SOAP hide technology choices and implementation details

from both parties

Simple Standard XML message

We only care about message format and contents

the less we know about implementation details, the less for work

for us!


A SOAP Request Message

POST /path/foo.pl HTTP/1.1

Content-Type: text/xml

SOAPActor: interfaceURI#Add

Content-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV=

“http://www.w3.org/2001/06/soap-envelope”

SOAP-ENV:encodingStyle=

“http://www.w3.org/2001/06/soap-encoding”>

<SOAP-ENV:Body>

<m:Add xmlns:m=„interfaceURI‟>

<arg1>24</arg1>

<arg2>53.2</arg2>

</m:Add>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Parameter Data

Method ID

Interface ID

Object ID


A SOAP Response Message

200 OK

Content-Type: text/xml

Content-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV=

“http://www.w3.org/2001/06/soap-envelope”

SOAP-ENV:encodingStyle=

“http://www.w3.org/2001/06/soap-encoding”>

<SOAP-ENV:Body>

<m:AddResponse xmlns:m=„interfaceURI‟>

<sum>77.2</sum>

</m:AddResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Parameter Data

Status


SOAP Usage Models

RPC-Like message exchange

request message bundles up method name and

parameters

response message contains method return value(s)

SOAP specification allows any kind of body content

can be XML documents of any type

usage of message request and response is defined by the

service provider

your application may not have RPC semantics, yet it can

be a perfectly valid SOAP application

example :

Messaging Service such like sending a purchase order document to a

B2B partner


WSDL:Web Service Description

Language

An XML language for describing web service interfaces

Originally proposed in September 2000 by Ariba, IBM, and Microsoft

W3C Web Service Description WG

WSDL Version 1.2 [Working Draft]


Service Description in WSDL

Service implementation definition

describes how a particular service

interface is implemented by given

service provider

Service interface definition

abstract or reusable service

definition

can be referenced by multiple

service implementation definitions

convergence of IBM‟s NASSL,

CORBA‟s IDL, MS‟s SDL


WSDL Element Relationships


WSDL Elements

Types

Messages: abstract definition of data being exchanged

Operation: abstract definition of a method or function

Port Type: a set of (abstract) operations

<types><schema […]>

<element name=“PrintRequest”> […] </element>

<element name=“…”> […] </element> </schema> </types>

<message name=“PrintInput”> <part name=“body” element=“nsp1:PrintRequest”/> </message>

<message name=“PrintOutput”> […] </message>

<portType name=“PrintPortType”>

<operation name=“Print”>

<input message=“tns: PrintInput”/>

<output message=“…”/>

</operation> </portType>


WSDL Elements

Binding: a concrete protocol for a port type

Port: an address for a binding

Service: a collection of ports

<binding name=“PrintSoapBinding” […] >

<soap:binding style=“document”

transport=http://schemas.xmlsoap.org/soap/http/>

<operation name=“Print”> […]

</binding>

<service name=“PrintService”> <documentation> Great print service

</documentation>

<port name=“PrintPort” binding=“tns:PrintSoapBinding”>

<soap:address location=“http://…” /> </port>

</service>


WSDL speeds Implementation


What is UDDI?

Universal Description Discovery and Integration

Industry-wide initiative supporting Web services

Specifications

Service Descriptions

Business Descriptions

Registry Query and Publication

Developed on industry standards (XML, HTTP, TCP/IP,

SOAP)

Applies equally to XML and non-XML Web services

Implementations

Public business Web service registry and supporting

development resources

Developer and private resources are available as well


How UDDI Works

UDDI Registry

3. UDDI Registry assigns a programmatically

unique identifier to each service and

registration

Marketplaces, search

engines, and business

applications query the

registry to discover services

at other companies and to

facilitate integration

4.

Service Types

1.

Implementations Implementers

populate the

registry with

descriptions of

their businesses

and the services

they expose

2.

Large businesses

apply the same

architecture and

technologies internally

5.

Software companies, standards

bodies, and developers populate

the registry with descriptions

(specifications) of types of

services


UDDI Registry Entries

Standards Bodies,

Agencies, Programmers,

Publishers register

specifications for their

Service Types

Service providers register

precise information about

themselves and their Web

services


White Pages

Service provider name

General description

Any number of languages

Contact information

Names, phone numbers,

fax numbers, Web sites, etc.

Known identifiers

List of unique identifiers for a service provider or business

e.g., D-U-N-S Numbers, Thomas Supplier ID

e.g., Domain name, stock ticker symbol, tax ID, others

Identifiers can be „validated‟ or „unvalidated‟ in

version 2 implementations


Yellow Pages

Service provider categories

3 standard taxonomies in Version 1

Industry: NAICS (Industry codes – US Govt.)

Product/Services: UN/SPSC (ECCMA)

Location: Geographical taxonomy (ISO 3166)

Version 2 enhancements

Freely extensible to support local or industry requirements

Taxonomies can be hosted within the UDDI sites or through

external services

Categorization assertions can be „validated‟ or „unvalidated‟


Green Pages

New set of information to describe how to “do web

services” with a provider

Nested model

Functional process

Service specifications (technical)

Binding information (implementation)

Programming/platform/implementation agnostic

Service implementations can also be categorized


Service Type Registration

Specification for a protocol or behavior Independent of Implementation

Also may be considered programming interface

Assigned a unique identifier (or “fingerprint”)

Contains: Unique identifiers

Basic information

Categorizations

Links to specifications and/or WSDL resources

Examples: “Requisition Management” service

“Weather Forecast” service

“Imagery” service

A given organization‟s Purchase Order or Invoice services

RosettaNet PIPs

Considered by UDDI to be a “tModel”


Name: Lakes And Sons

Description: We manufacture clothing.

Phone: (319) 555-1212

Sales Team: [email protected]

Identifier: 122-34-2345 (D-U-N-S Number)

Identifier: 899922 (Thomas Supplier ID)

Identifier: Lakes And Sons (RealNames)

Lakes And Sons

Geo: USA (US)

Industry: Clothing (448)

Product Types: Suits (531019), Jackets (531018)

Service: Catalog

Description: Online catalog service

Protocol: Commerce Server v4 (12345678-123-123-11)

URL: http://LakesAndSons.com/catalog.asp

Catalog

Catalog

http://LakesAndSons.com/catalog.asp

Service: Order/Invoice

Description: Online order management service

Protocol: Great Plains v3 (45874588-222-111-99)

Protocol: BizTalk Framework 2.0 (34512355-222-111-09)

URL: http://LakesAndSons.com/submitPO.asp

Order/Invoice

Great

Plains

Custom

CRM

BizTalk

Server

http://LakesAndSons.com/submitPO.asp


UDDI 2.0 Data Structure

businessEntity: Information about the

party who publishes information about a

family of services

businessService: Descriptive

information about a particular service

bindingTemplate: Technical

information about a service entry

point and construction specs

publisherAssertion: Information about

a relationship between two parties,

asserted by one of both

tModel: Descriptions of specifications

for services or taxonomies. Basis for

technical fingerprints


UDDI and WSDL

Interface definition

save as tModel type

Implementation definition

Service in WSDL -> BusinessService

port in WSDL -> BindingTemplate


UDDI 2.0 API

Inquiry API

Find things

find_business

find_service

find_binding

find_tModel

Get Details about things

get_businessDetail

get_serviceDetail

get_bindingDetail

get_tModelDetail

Publishers API

Save things

save_business

save_service

save_binding

save_tModel

Delete things

delete_business

delete_service

delete_binding

delete_tModel

security…

get_authToken

discard_authToken


Public UDDI Registry

IBM

Ariba

Microsoft

other

Register

with any node

Registrations replicated

Complete set of

registered records

available at all nodes

Common set of

SOAP APIs

supported

by all nodes

Compliance enforced

by business contract

UDDI V.1 : MS, IBM

UDDI V.2 : MS, IBM,

HP, SAP

UDDI.org

queries

Hewlett

Packard

(v2)


Private UDDI: Inside the Enterprise


UDDI 3.0 Specification(OASIS)

UDDI Data Structure businessEntity, businessService, bindingTemplate, tModel,

publisherAssertion,

OperationalInfo

subscription

To keep track of changes to the entities described by the subscriber

UDDI Services and API Sets Node API Sets

UDDI inquiry

UDDI publication

UDDI Security

UDDI Custody & Ownership Transfer

UDDI Subscription

UDDI Replication

Client API Sets

UDDI Subscription Listener

UDDI Value Sets


UDDI 3.0 Features[1/4]

Expanding on the foundation of Version 1,2

Backward Compatibility is enabled

Support for Multi-Registry Environment

Affiliation of Registries

group composed by multiple registries

UBR(Universal Business Registry) as Root

registries have compatible policies for assigning keys to

entities

Human-friendly URI-based keys : uddi:example.com:1

Support for digital signature

UDDI entities to be digitally signed by XML Digital

Signature

New level of data integrity and authenticity is delivered



Policy

Need to provide flexibility for implementations to support

vastly different operational policies

identify all the policy decisions that each UDDI registry

and/or node must make: authorization models, data

custody, keying, publication limits, audit policy…

Information Model Improvements

Operational Information

Complex Categorization

Internalization and language support

Timezone, language-specific sorting order, …

Improved WSDL Support

enables WSDL files to be more easily registered and

consumed from UDDI



Extended Discovery

Nested-query

multi-step queries into single-step complex queries

New and extensible find qualifiers

6 more query patterns, 3 more sorting patterns

Extended Wildcard support

SQL-LIKE approximate matching

Subscription API

provides the ability to register their interest in receiving

information

Monitoring patterns

Asynchronous notification

Synchronous notification



Registry Management Improvements

Custody and Ownership Transfer API

transfer custody of one or more businessEntity or tModel

structures from one node to another

allow the transfer of ownership of these structures from one

node to another

External Validation

provides the ability for 3rd parties to register value sets

control the validation process used by UDDI to perform

validation checks

Improved Replication

Document Makeover

consolidates the UDDI specification into one

document(412p)




Simple: RPC based

Supports synchronous exchanges

Complex: Conversational/Message-based

Supports loosely coupled asynchronous exchanges

Required for Enterprise Web Services

Requires Enterprise QoS


Simple Web Services

Typically stateless

Appears as an URI to the client application.

The interaction centers around a service-specific

interface

Tightly coupled and synchronous, meaning response

without request context is meaningless


Complex Web Services

Loosely coupled and document-driven

Client invokes a message-based Web Service by

sending it an entire document, such as a purchase

order, rather than a discrete set of parameters

The Web Service accepts the entire document,

processes it, and may or may not return a result

message

Promotes a looser coupling between requestor and

provider


Complex Web Services

Protocol Stack Messages

Internal

Business

Processes

Business

Information Business Process

Communication

Protocol

Application or

Trading Partner

A

Application or

Trading Partner

B

Standards-

based

Collaboratio

n

------

------

------

Protocol Stack

Business Process

Communication

Protocol

Internal

Business

Processes

Business

Information

------

------

------

ERP/DB ERP/Appl

2

1

3

4

5 Messaging Protocol

(Transport, Routing,

Packaging, Security)

Messaging Protocol

(Transport, Routing,

Packaging, Security)


Web Services for Real e-business

More is needed to cover the full range of

requirements for e-business

To fully support e-business

Security

QoS : Reliable messaging & Routing

Transactions

Business Process flow


Complex WS Standards

ebXML

BPSS, CPP, Registry, ebXML MS

MS‟s GXA

Various (in the works)

Open Standards

Security : SAML & XKMS, WS-Security

Reliable Messaging : WS-Reliability

Transaction : XAML, BTP, WS-Transaction

Business Process flow : BPML, BPEL4WS

Complex Web Service

Standards

ebXML

MS‟s GXA

Open Standards

Transaction : XAML, BTP, WS-Transaction

Business Process flow : BPSS, BPEL4WS


ebXML Overview

Business Service

Business Service

Collaboration Protocol

Agreement

Business Process

Core Components

Context

Repository

Registry

ebMS ebMS

Business Process & Core

Components

Collaboration Protocol

Agreement

Business Transaction

Trading Partner A Trading Partner B


Main ebXML Concepts

Core Components : “Tiny” bits of information

that may be used to provide “semantics” to

content

Business Processes : BPSS: Defined as

models, expressed in XML

Collaboration Protocol Profile : Expressed in

XML. Specifies parameters for interaction

Messaging Service : Moves the actual XML data

between trading partners

Registry : Provides a “container” for process

models, vocabularies, and profiles


Friends or Foes?

Company X

Communicates using SOAP and XML Messages

UDDI

WSDL

Web Service

Gets Web Service info

Queries Directory Company Y

using ebXML Messaging Service

ebXML Reg/Rep

Contains Partnering and Business Process Info

Enters into Partner Agreement with Business Flow


ebXML vs. Web Service – GM Example

Coupling Tighter

Looser

Security Limited

Extensive

ebXML

Web Services for XML Message

Web Services for RPC

Reusable Components

SOAP/HTTP (JAX-M for ebXML)

ebXML

WS

SOAP/HTTP (JAX-RPC)

ORB (RMI/IIOP)

WS

SOAP/HTTP WS (JAX-M for WS-Routing)

Typical access via:

Granularity

Small A2A Integrated

Apps

Homogeneous Application

WS

WS Big A2A Integrated App

Families

B2B Market, Global Multi-

enterprise

ebXML


ebXML & Web Services : convergence

Interoperability btwn ebXML Registry and UDDI

Push ebXML ebMS to W3C

Possible Technical Actions Submit ebBPSS as a Note to W3C

Add a WSDL Interface Extensions to BPSS

Use WSDL as a Step within BPSS

...


Global XML Web Services Architecture –

GXA (MS)

Directory

Inspection

Description

Referral

Routing License

Security

…

Reliable Messaging

Transactions

…


Extending The Semantics

Security: primary concern today

Support end-to-end security including authentication,

authorization, message integrity, and message encryption

Routing: scalability & fault tolerance

Dynamically configure message routing paths

Reliable Messaging: needed for mission

critical apps

End-to-end guarantee of message delivery with a range of

semantics (at-least-once, at-most-once, and exactly-once)

Transactions: need to transact across companies

Support variety of transaction and compensation

semantics

…


Transaction :Traditional Model

ACID Properties

Atomic : All or nothing

Consistent : A consistent result is obtained, allowing

clean state changes

Isolated : A Transaction‟s intermediate states are not

visible to other transaction

Durable : The effects of a completed transaction are

persistent

Two-Phase Commit Protocol

Transactional protocol for distributed environments

Implicit contract that exists between

Transaction Coordinator

Participants


WS Transaction versus OLTP

Web Services Transaction OLTP

Multiple parties B2B

- Complex interactions

- on a long time

- E-Business

- Plug & Play e-Commerce

One party

- Few interactions

- on a short time

- Transaction code is used several

time

Several TP Monitors

- May not have one global

coordinator

One Vendor TP Monitor

- standards(Xopen, OSI/TP..)

- Interoperability is hard

Across Several Firewalls An (secure) Intranet

Request with XML, HTTP,

SMTP, SOAP on Web Server

Requests on DBMS(SQL, RPC)


XAML Group

Vendor-Neutral Standard

http://www.xaml.org

Promoted by Bowstreet, Hewlett-Packard Company, IBM,

Oracle, Sun Microsystems

Initial draft of the specification

public availability: Jan 15, 2001

currently deprecated


BTP: Business Transaction Protocol

OASIS Business Transaction Committee

Specification 1.0 (June 2002)

Transactional protocol

Allow independent participants and coordinators to

negotiate commitment to a business transaction

Allow implementations to manage those commitments to

coordinate termination of the business transaction

Based on two-phase commit for small scale

interactions

Several implementations underway

HP, Bowstreet, TalkingBlocks, BEA


BTP Stack

User-Defined

Participants

Atomic

Coordination

Cohesion Composition

Implementation

Or Application

Extensions

Application logic, user

interface etc.

Composers which

coordinate non-ACID

business transactions

Coordinators which

coordinate ACID

transactions

BTP Aware (Web)

Services


Atom & Cohesions

Atom

similar to transaction in tightly coupled systems, but the

isolation property is relaxed

atom coordinator and zero or more sub-coordinators

coordinate a transaction

Participants manages by coordinators

outcome of an atom is atomic

Cohesion

Cohesive Business Transactions

Atoms can be aggregated into Cohesions

may deliver different termination outcomes to its

participants

Consistency is determined by agreement and interaction

between the client and the coordinator


Atom Example

Client performs work by

interacting with the

participants

Work undertaken within

context of a transaction

which the client drives via

coordinator

Each separate service has a

participant which takes part

in a two-phase atomic

transaction

Work is either fully

completed or fully rolled-

back

via cancel or confirm

methods

Atom

Coordinator

Credit Card

Clearance

Book Shop

Client

Application


Cohesion Example

Cohesion aggregates a number of atoms into a business transaction

Not require that all atoms complete successfully for the cohesion to

be successful

Business logic dictates which subsets of successful atoms will lead to

a successful cohesion

Allows for more flexible composition of works

Atom 1 Atom 2 Atom N Cohesion

Composer

Cohesion

Client

Application


Architectural Stack using BTP


WS-Standards for Transactions

IBM, Microsoft, BEA announced web service

specifications(August 2002)

WS-Coordination

standard mechanisms to create and register services

using the protocols defined in the WS-Transaction spec. that

coordinate the execution of distributed operations in a WS

environment

WS-Transaction

BPEL4WS(Business Process Execution Language for

Web Services)

Implementation

WSTK(IBM), WebLogic Application Server(BEA)


Architectural Stack using WS-Standards


New design for transactions

Coordination framework (WS-Coordination) supports:

Activation Service to create an activity

Registration Service to coordinate protocol selection and

register participants

Coordination service for activity completion processing

Coordination Protocols(WS-Transaction) are:

Protocols for Atomic Transaction

for atomic transactions handle activities that are short-lived

referred as 2-phase commitment protocol

Protocols for Business Transaction

for business Transactions handled long-lived activities

results of interim operations need to be released before the

overall activity has completed

mechanisms for fault and compensation handling


WS-Coordination Framework


Coordination Service

Activity Service

begin a new activity

specify the coordination protocols available to the

activity

optionally allows the user to specify a relationship

between a newly created activity and an existing activity

Registration Service

allows a WS to register and to select a protocol for the

activity

Coordination service

controls the activity completion processing for the

registered web services

using selected coordination protocol(defined in WS-

Transaction)


Scenario of Atomic transactions


Scenario of Business Transactions


XML-based BP Flow Specifications

ebXML

BPSS [UN/CEFACT, OASIS, 2002]

Web Service

WSFL [IBM, 2001]

XLANG [MS, 2001]

WSCL [HP, 2002]

BPML [Intalio, 2002]

WSCI [BEA, Intalio, SAP, Sun, 2002]

BPEL4WS [BEA, IBM, MS, 2002]

DAML-S [DAML-S Coalition, 2002]


Modeling Primitive (BPSS)

Req.

Business

Activity

Res.

Business

Activity

Document Flow

ReceiptAcknowledgment Signal

AcceptanceAcknowledgment Signal

Requesting Role Responding Role

Document Flow

ReceiptAcknowledgment Signal

AcceptanceAcknowledgment Signal


Examples (BPSS)

<BusinessTransaction name="Create Order">

<RequestingBusinessActivity name=""

isNonRepudiationRequired="true"

timeToAcknowledgeReceipt=”P2D"

timeToAcknowledgeAcceptance=”P3D">

<DocumentEnvelope BusinessDocument="Purchase Order"/>

</RequestingBusinessActivity>

<RespondingBusinessActivity name=""

isNonRepudiationRequired="true"

timeToAcknowledgeReceipt=”P5D">

<DocumentEnvelope isPositiveResponse="true"

BusinessDocument="PO Acknowledgement"/>

</DocumentEnvelope>

</RespondingBusinessActivity>

</BusinessTransaction>


Modularization

* Documentation~

Package~

BinaryCollaboration~

BusinessTransaction~

*

MultiPartyCollaboration~

Package~

Package

ProcessSpecification

Package


Context-Sensitive Document Assembly

Context Rules

Taxonomy (UN/SPSC,

ISO3166, NAICS,

…)


BPEL4WS

Combining and extending the functions of WSFL + XLANG

P2P Interaction between services described in WSDL

Business Processes

Executable (private) business processes model actual behavior of a participant in a business interaction"

Abstract (public) business processes are the descriptions for business protocols (choreographed representation of the interactions between parties)

No notion of process composition and sub-process

Long-running Business Transaction

Fault handling and compensation

Purely local and within a single business process instance


Control Flow

A nice hybrid model

half-way between block

structured and state

transition control flow

definitions

The creation of a BP

instance is always

implicit

Termination of a BP instance

•Normal

•Abnormal (Fault Handling Allowed)

•Explicit by Terminate

•Compensation Handling


Collaboration

<process name="purchaseOrderProcess" …>

<partners>

<partner name=“buyer" serviceLinkType="lns:BuyerSellerLT"

myRole=“buyerService"/>

…

</partners>

<containers>

<container name="PO" messageType="lns:POMessage"/>

<container name="Invoice" messageType="lns:InvMessage"/>

</containers>

<sequence>

<receive partner=“buyer" portType="lns:BuyerPT"

operation="sendPurchaseOrder" container="PO">

</receive>

<flow>…</flow>

<reply partner=“buyer" portType="lns:BuyerPT"

operation="sendInvoice" container="Invoice">

</reply>

</sequence>

<serviceLinkType name="BuyerSellerLT“>

<role name="Buyer">

<portType name="buy:BuyerPT"/>

</role>

<role name="Seller">

<portType name="sell:SellerPT"/>

</role>

</serviceLinkType>

A little bit weak as a

collaboration definition

because of the

expression at the port

type level and not at the

operation level

WSDL

Passing information

between the different

activities in an implicit way

through the sharing of

globally visible data

containers


Problems in BP Flow of WS[1/2]

Getting lost in the intricacies of WSDL

Basic Client/Server Assumption: the server exposes

his interface, which has a behavior described by

WSCI/BPEL such that a client knows how to use it

Forming an "agreement" on two interface definitions

which may eventually not be compatible

No understanding about the importance of business

collaboration


Problems in BP Flow of WS[2/2]

Collaboration is mostly a B2B concept, and therefore should have B2B semantics such as non-repudiation, legally binding, confidentiality, security, tamperproof, collaboration agreement, etc.

In P2P mode, the interface disappears behind a collaboration definition which specifies how the two peers collaborate to achieve a particular purpose.

BPEL4WS ahead of WSCI/BPML in expressiveness and completeness [Dubray, 2002]

With two service definitions interacting in P2P mode, the process definitions must constantly hop from one definition to another based on the direction of the operation



The Evolution of Integration

Web Services

Next-Generation Integration

•Reduced Cost • Enabled Line-of-Business • Standards-Focused • High Reusability and Adoption

EAI and B2Bi

Traditional Integration

• Costly • High Resource Requirements • Proprietary Focus • Point-to-Point Approach

One-Off

Custom Integration

• Costly • High Resource Requirements • Slow Time to Market • Lacked Reusability

Intelligent

Integration


Internet Chapter III: Semantic Web

Tim Bernes-Lee

SemanticWeb.org

The vision projects the Web as a network of

hypertext resources that is created and linked by

individuals to the hypertext resources of other

individuals which, over time and use, grows into a

global web of “meaning” that can be understood

and processed by man or machine


Semantic Web

Unicode URI

XML + Namespace + XML Schema

RDF + RDF Schema

Ontology Vocabulary

Logic

Proof

Trust

Dig

ital Sig

natu

re

Self-

Desc.

Doc.

Data

Data

Rules

RDF : DAML+OIL, DAML-S, OWL, SHOE

Topic Map : XTM, TMQL


Problems of Web Service

Discovery

The programs such as agents have no way to locate one that will perform a specific function

This process, called service discovery Can happen only when there is a common language to describe a

service in a way that lets other agents "understand" both the function offered how to take advantage of it

But, Jini… : Low level, syntactical based, standardized functionalities

UDDI : Based on keyword search

WSDL : Not support the definition of logical constraints

Composition

The development of integrated services is still largely ad-hoc, time-consuming and requiring a considerable effort of low-level programming


Solutions

Make services computer-interpretable,user-apparent

and agent –enabled

Personalized machine agents to support automatic

Web service discovery, execution, composition and

interoperation

Break out the virtual realm and extend it to into our

physical world


Bringing the web to its full potential

Static

Dynamic

Serious Problems in information

(finding, extracting, representing,

interpreting, maintaining)

Bringing the computer back

as a device for computation

Toward Semantic Web Service

WWW URI, HTML, HTTP

Semantic Web RDF, RDF(S), OWL

Web Service UDDI, WSDL, SOAP

Semantic Web

Service


Framework

DAML-S

WSMF


DAML-S

A DARPA Agent Markup Language for Services

Objective Provide an upper ontology for describing properties &

capabilities of (Web) services in an unambiguous, computer

interpretable markup language

Developed by a coalition of researchers from

Stanford, SRI, CMU, BBN, and Nokia, under the

auspices of DARPA

Release of DAML-S version 0.9 Beta May, 2003


DAML-S : Ontology


Pro

cess M

odel

Gro

undin

g

Development … Deployment … Use

…

Publication

Simulation

Verification

Discovery

Composition

Key

Selection

Invocation, Interoperation

Monitoring, Recovery

Pro

file

DAML-S Layout


Service Profile : What does it do?

High-level characterization/summary of a service

Used for

Populating service registries

A service can have many profiles

Automated service discovery

Service selection (matchmaking)

One can derive :

Service advertisements

Service requests


Service Profile Ontology

Non Functional Properties

Functionality Description


Profile Hierarchy

Class hierarchical yellow pages

Implicit capability characterization

Arrangement of attributes on class hierarchy

Can use multiple inheritance


ServiceProfile

ProductProviding

Service

Manufacturing

Transportation

ActionService

InfoService

PhysicalProduct

Service Repair

Information

Product+

physicalProduct+

manufacturer+

deliveryRegion*

deliveryProvider*

deliveryType

Physical_

Product+

transportationMode+

geographicRegion+

physicalProduct+

Tie in with UDDI, UNSPSC, …

DL Basis for matchmaking

Multiple profiles; multiple taxonomies

name

provider

role+

avgResponseTime?

…

FeeBased feeBasis+

paymentMethod+

Exploiting Taxonomies of Services


Modeling Service as Process

Two chief components:

Process - enables planning, composition, and

interoperation

Process control Model, which allows agents to monitor

the execution of a service request

Used for:

Service invocation, planning/composition,

interoperation, monitoring


The Process Ontology


Funtion/Dataflow and Action/Process Metaphor

Input:

• confirmation no.

• ...

Output:

• failure notification

• …

truck available

+

valid credit card

Y

N

? Preconditions:

• customer name

• origin

• destination

• pickup date

• ...

• knowledge of

the input

• ...

• goods at location

if successful

• credit card debited...

Effect:

Output:

Effect: <no effect>

Acme Book

Truck Shipment


Simple and Composite Process

truck available

+

valid credit card

Y

N

Confirm Shipping Region

Get Quote

Get Shipping Dates

Book Truck Shipment

Acme

Truck

Shipping

Service

expands

AcmeTruckShpng ExpandedAcmeTruckShpng


Process Control Ontology

To monitor and Control the execution of a process,

an agent needs a model to interpret process

instantiations with three characteristics:

Provide the mapping rules for various input state

properties to the corresponding output state state

properties

Provide a model of the temporal or state dependencies

described by the constructs, sequence…etc

Provide representation for message about the execution


Resource

Allocation Types

resources are allocated to the activities or process

consumabelAllocation, ReusableAllocation

Capacity Types

DiscreteCapacity, ContinuousCapacity

Resource Compositions

AtomicResource, AggregateResource


B2C-Purchase : Grounding

Transport : secure HTTP

Protocol : HTTP Form

Address : https ://buybot.congo.com:4040/initsub.htm

Type Serializations

ItemDescription(keywords) : Set of DAML literals

PriceRange : pair of monetary units, ISO 5678

CreditCard

https ://transcredit.com/S1.daml#SecureTransferFormat


DAML-S : Architecture

Service Discovery

Service Flow Composition

Service Interaction

Service Publication

Service Description

Communication Protocol(KQML, ACL)

XML Messaging Protocol

Network Protocol(HTTP, FTP, SMTP)

Agent

UDDI

DAML - S Process/WSFL

DAML - S Process

DAML - S Profile & UDDI

DAML - S Grounding

SOAP


Web Service Modeling Framework

The Vision

Provides the appropriate conceptual model for developing

and describing web services and their composition

The Main principles

Maximal de-coupling of various complements

Scalable mediation service

http://informatik.uibk.ac.at/users/c70385/wese/index.

html


WSMF : Elements

Ontologies Provide the terminology used by other elements

Goal repositories Define the problems that should be solved by web services

Pre-conditions, post-conditions

Web services Define various aspects of a web services

Name, goal reference, pre/post condition, input data, output data, error data, invoked web service proxy, data flow…

Mediator Bypass interoperability problems

Mediation of data structures/business logics/message exchange protocols/dynamic service invocation


DAML-S vs. WSMF

DAML-S WSMF

Ontology for Web Service - easily

to establish the relationship of

services

Ontology for concepts - No Service

Ontology

Public process for monitoring Emphasize the process and

mediation in interactions

Lack of interface definition

Conflicting points in the composition

by requestor, since the process is

black-box, how requestor know the

process?

No semantic support for service

composition


Discovery

The MIT Handbook Project

ATLAS Project – CMU


Semantic Web Service Discovery

“Find a service that sells airline tickets between San Francisco and Toronto and that accepts payment by Diner’s Club credit card”

Automatic location of Web Service that provide a particular service and that adhere to requested properties

Procedures Specify the information as computer-interpretable

semantic markup at the service web sites

Locate the services automatically by a service registry or ontology-enhanced search engine


MIT Process Handbook Project

Part of MIT Center for Coordination Science (1993 ~)

The goal is to develop rich on-line repositories of

business knowledge

To share and manage knowledge about existing

businesses

To generate innovative ideas about new business

possibilities


Service Broker

Techniques for allowing highly accurate and focused

search for on-line services

Functional architecture of process-based service retrieval

Model service as a process

Index service modelInto process ontology

Define query

Find matches


A process-based service model

Sell electronically

Identify customers

via data mining Inform customers Take orders

Output port Input port Internet Unwanted

solicitations

Remove names

on output lists

Has-subtask Has-subtask Has-subtask

Has-port Has-port Uses-mechanism

Is-c

on

necte

d-t

o

Is-avoided-by

Ont(Entity, Relationships)


Process Ontology

A Specialization hierarchy for process, resources and

so on

Sell Savings and Investment Service

Sell Loan

Sell Management Service

Sell Account Access Services

Sell Account

Sell Reserve Credit

Sell Credit Card

Sell Installment Loan

Sell Letter of Credit

Sell ATM Access

Sell Certificate of Deposit

Sell Retirement Plan

Sell Payroll Management

Sell Account Management Services

Sell Telephone Access

Sell Financial Service

Activity

Specialization

Specialization hierarchy for grant loan


Query Example

Retrieve process models indexed in an ontology

Attribute “Name” of?sell includes “sell”

Relation ?sell has-specialization ?process*

When exists (relation ?process has-subtask ?subtask*

attribute “Name” of ?subtask includes “inform”

attribute “Description” of ?subtask includes

“internet”


CMU ATLAS Project

ATLAS

Agent Transaction Language for Advertising Services

A DAML-based agent advertising language that will

enable agents and devices to locate each other and

interoperate

Matchmaker

A middle agent that facilitates connections among agents

that provide services and agents that request services

Serves as a “yellow pages” of agent capabilities, matching

service providers with service requestors based on agent

capability descriptions

LARKS matchmaker, DAML-S matchmaker


LARKS Matchmaking Process


The Agent Capability Description Language

Enables agents to advertise, request and perform

matchmaking between the requesters and the

providers

Domain-specific knowledge is specified as local

ontologies in the concept language ITL.


Specification in LARKS Find Computer Info

Context (context of specification) Computer*Computer;

Types

(Declaration of used variable types)

InfoList = ListOf(model:Model*ComputerModel,

brand: Brand*Brand,

price: Price*Money,

color: Color*Colors);

Input

(Declaration of input variables)

brands: SetOf Brand*Brand;

areas: SetOf State;

processor: SetOf CPU*CPU;

priceLow*LowPrice: Integer;

priceHigh*HighPrice: Integer;

Output

(Declaration of output variables) Info: InfoList;

InConstraints

(Constraints on input variables)

OutConstraints

(Constraints on output variables) Sorted(Info)

ConcDescriptions

(Ontological descriptions of used words)

Computer = ( and Product (exists has-processor CPU) (all has-memory Memory) (all is-model ComputerModel));

LowPrice = (and Price (ge 1800)(exists in-currency aset(USD)))…


LARKS Matchmaking

Context

Matching

Profile

Matching

Similarity

Matching

Signature

Matching

Semantical

Matching

AuxiliaryDB

(WordDistance,

Type Hierarchy)

ConceptDB

(Ontology)00 AdvertisementDB

GenericSort

IntegerSort

Ranked Set of Agents

with capability to sort

integer numbers

“Find agent that

can sort integer

numbers

Requester Agent

Matchmaker Agent


DAML-S Matchmaker

Developed method for the DAML-S matchmaker to

interoperate with UDDI

Automatically register DAML enabled services with

UDDI

Automatic retrieval of UDDI entries upon matching

Enable capability descriptions and matching of DAML

enabled services registered with UDDI


Matching Algorithm

“sufficiently similar” – Support flexible semantic matches

Match succeeds when:

Outputs of request are subsumed by outputs

advertisement The service provides all the outputs expected by the request

Inputs advertisement are subsumed by inputs of the

request The service expects all the information that the requester is willing to provide

Degrees Input/Output of Match

Exact, Plug In, Subsume, Fail

Sorting Matches

Match performed against all advertisements

Registry returns only the advertisements with the

highest degree of match


outputMatch, degreeOfMatch, sortRule

degreeOfMatch (outR, outA)

if outA = outR then return exact

if outR subclassOf outA then return exact

if outA subsumes outR then return plugIn

if outR subsumes outA then return subsumes

otherwise fail

outputMatch (outputsRequest, outputsAdvertisement)

globalDegreeMatch = Exact

forall outR in outputsRequest do {

find outA in outputsAdvertisement such that

degreeMatch = maxDegreeMatch (outR, outA)

If (degreeMatch = fail) return fail

If (degreeMatch < globalDegreeMatch)

globalDegreeMatch = degreeMatch

return sort (recordMatch); }

sortRule (match1, match2)

if match1.output > match2.output then match1 > match2

if match1.output = match2.output

& match1.input > match2.input then match1 > match2

if match1.output = match2.output

& match1.input = match2.input then match1 = match2


DAML-S UDDI Matchmaking System

Communicator &

Protocol Handler

DAML-S

UDDI

Translator

DAML-S

Matchmaking

Engine

UDDI

Repository

DAML-S includes:

DAML+OIL Ontology

RuleML Rules

DAML-S

UDDI API

Internet

DAML-S + UUID

DAML+OIL

Ontology

Service Provider &

Requester Service Provider &

Requester

Web Application Server

Client User Client Program

UDDI-compliant Program Web Browser

HTTP+ACL+DAML-S HTTP+SOAP+{UDDI/XML | DAML-S}

DAML-S Parsers

HTTP+SOAP+UDDI/XML


Compiling DAML-S profile into UDDI

BusinessEntity

name

Contacts

person Name

phone

email

address

discoveryURLs

businessKey

BusinessService

name

description

businessKey

bindingTemplates

CategoryBag

DAML-S_TModel

serviceType_TModel

serviceCategory_TModel

intendedPurpose_TModel

role_TModel

requestedBy_TModel

providedBy_TModel

domainResource_TModel

communicationThru_TModel

qualityGuarantee_TModel

qualityRating_TModel

input_TModel

output_TModel

precondition_TModel

effect_TModel

DAML-S Profile

ServiceProvider

name

phone

fax

e-mail

webURL

physicalAddress

serviceName

textDescription

isPresentedBy

hasProcess

serviceType

serviceCategory

intendedPurpose

role

requestedBy

providedBy

domainResource

communicationThru

qualityGuarantee

qualityRating

input

output

precondition

effect


Composition


Semantic Web Service Composition

“Make the travel arrangements for my IJCAI 2002 conference

trip”

Specify the control and data flow semantics of the

new services based on elementary services or other

composite services

Dynamic service discovery


Problem for Composition

How to you know when it is “safe” to compose A and

B?

Output semantics of A match input semantics of B

The main problem is semantic mapping of arguments

In most systems to date, this requires human level

knowledge

If system is purpose-built for composition, semantic

mapping can be explicitly coded into service interface


Stanford University’s DAML-S Composition

Service

Agent Technology for Service Composition

Objective

To develop agent technology that will perform these types

of tasks automatically by exploiting DAML markup of Web

services and DAML markup of user constraints

Approach

Reusable generic procedures with customizing user

constraints

Plan a sequence of services that realize user‟s objective

Exploitation of AI technologies for reasoning about action


Generic Procedure

Agents are tasked using high-level, reusable”generic

procedure”

“The what not necessarily the how”

Generic Procedures stored in mark-up ontologies

using the same DAML-S like markup

Book-transportation (origin, des-d, date-r, purpose)

pick-one-of

Book-plane (origin, dest) | drive (origin, dest) | book-train (origin,dest)

end pick

end


Realizing Generic Procedure in Golog

Golog:

a high-level logic programming

language, for specification and

execution of complex actions in

dynamical domains.

Built on the top of situation

calculus, a first-order logical

language for reasoning about

action and change

Procedure constructs:

Sequencing

If-then-else

Nondeterministric choice

While-do, etc.

Rent-car

Get-plane-sche

Buy-plane-ticket

S


Customize and Deduction

Customizing User Constraints

Personal constraints/preferences

Group constraints

Instance-specific constrains

Deductive Instantiation

Deductive machinery Instantiates in the context of the

agent‟s KB, which includes the generic procedure,

properties of the agent and its user and the state of world

Agent‟s KB is updated by Web Service response


Knowledge

base

Agent Technology Framework

Agent Broker

Email

Web Procedures

ontology

Web Service

ontology

Semantic markup of

personal or company

constraints and preferences

Semantic markup of

Web service sites

Semantic-markup-enabled

agent technology

…..


Things - 1014

Computers 108

Embed Computers 1011

Desktops

Phones

TVs

Cars

Games

Switches Milk Cartons

Thermostats

Transfer Access Compose Integrate Assimilate Interact

IP v6 IP v4

Client/Server

Web Applications

Web Services

Fractal

Polyarchical

N-tier

FTP Telnet

IIOP

WAP HTTP

X RPC/XDR

SMTP

Clients

Functions

Organization

Protocols

SOAP RMI/IIOP

JINI

Identity

UDDI LDAP

JXTA

IP Layer

Waves of the Internet

Clothes

Documents

2003년 6월 25일 - krnet.or.kr · Web Services 2003년 6월 25일 이 규 철 충남대학교 컴퓨터공학과 [email protected]