1 discovery and mediation using diane service descriptions ulrich küster and birgitta könig-ries...

1

Discovery and Mediation using

Diane Service Descriptions

Ulrich Küster and Birgitta König-Ries(also contains work by Michael Klein)

University JenaGermany

ukuester|[email protected]

Third International SWS-Challenge 2006 workshop Athens, GA, USA2

Agenda

Introduction to DIANE Service Descriptions (DSD) Solution to Discovery Scenario

Example descriptions (Muller offer, Goal 4a) Enhancements to the solution since Budva Matching Invocation

Solution to Mediation Scenario Version 1 Adaptations performed to switch to Version 2


What is DIANE and DSD?

Project goal: Complete efficient automation of service discovery, matchmaking and invocation

Assumption: Simple two-phase choreography n stateless estimation (negotiation) steps 1 execution step

DSD language: lightweight ontology language (object oriented) special constructs to describe services Keep efficient matching in mind


Service specific elements of DSD (1)

Operational elements to capture world

altering effects states

(instances of state ontology: Owned, Known, Printed, Shipped, Accessible, …)

Aggregational elements Moon sells more than one item, Muller

transports to a variety of countries Usually describe sets of effects Normal semantic: One out of a

set of effects is requested / created

ShippedV

upper.profileStateV

domain.locationAddressE

topPhysicalEntityE

...

fromAddress

cargo

pickupdomain.measure

DateTimeFrameV

...

Shipped


Service specific elements of DSD (2)

Selecting elements to support configuration by the requestor

(select one out of the offered effects) to inform requestor about produced effect variables (input / output)

Valuing elements to express preferences of the requestor fuzzy sets (the higher the membership, the higher the

preference) strategies (specify how to i.e. trade-off price versus

shipping time, underspecified offers, …) unbiased, deterministic, precise matching

AddressIN,e,1IN,x,1

Double

~== [0, 20] 0


Agenda





Excerpt from Muller offer description

OFFER:uppermuller : Service

upper.profile : ServiceProfilepresents

effect

AddressIN,e,1IN,x,1 Address

IN,e,1IN,x,1

fromAddress toAddress

PhysicalEntityIN,e,1IN,x,1

cargo

WeightMeasure

weight

pickupDateTimeFrame

IN,x,1

Country

Cityy

city

locatedIn

Country

city

locatedIn

WeightUnit

== pound

Double<=50

val unit

Continent

in {africa, northAmerica, europe, asia}

Continent

in {africa, northAmerica, europe, asia}

locatedIn locatedIn

Shipped

PriceOUT,e,1

Currency

== usdDouble

currencyval

price

City

service instanc

e

offered effect(s)


Improvements since Budva

Enhanced handling of temporal semantics

Special instances like now, today, …

Still unable to perform computations

unable to express constraints on length of pickup interval

Currently no support of time zones

DateTimeFrameIN,x,1 beginTime

endTime

Time

>= <06:00>

Date

>= today

Time

<= <20:00>

Date

<= todayPlusTwoWorkDays

endDate

beginDate


Excerpt from description of Goal 3b

unit

3

2

10

REQUEST: upperswsShipping3b : Service

upper.profile : ServiceProfile

presents

effect

Shipped

PriceDouble

~== [0, 20] 0amount

currency

price

cargo

domain.measure : DimensionMeasure

domain.measure : WeightMeasure

dimension

weight

val

domain.measurepound : WeightUnit

domain.measure : LengthMeasure



length

width

height

domain.measureinch : LengthUnit



unit

unit

unit

val

val

val

domain.moneyusd : Currency

pickup

top : PhysicalEntity

10

DateTimeFrame

DateTime

== <2006-06-08T10:00>

DateTime

== <2006-06-08T20:00>

begin

end

service instanc

e

requested

effect(s)

preferrably 0 but up to 20

accepted


Added since Budva: Goal 4a

Normal semantic: One effect requested Changed with Iteration Directive: <Best 2 1> New semantic: Best two effects are requested Will finally result in two invocations of a shipper

Currently work in progress and only partially finished


effect

Shipped cargo

dimension

weight

top : PhysicalEntity

<Best 2 1>

...

...


Matching

Given fuzzy request r and configurable offer o solve the following problem:a) Compute fuzzy containment value

subset Є [0, 1] of o in r(How well is the offer contained in the requested effects?)

b) Where possible, configure o such as to maximize subset

Implementation descends through description graphs, fills variables with optimal values, recursively computes subset for each element, combines subset values

DEMO


Automated Service Invocation

service grounding (part of offer description) SOAP-grounding specifies

endpoint, SOAP Action header and empty message template

mapping definitions DSD-Elements <-> XML

given configured offer description (DSD-Elements) fill XML message template

invoke service create results (DSD-Elements) from reply message if necessary fill xml template to return to requestor

(request grounding)


Excerpt from Racer's grounding

soapOperations += anonymous SOAPOperation at upper.grounding [soapAction = "ShipmentOrder",xmlTemplatePath = "racerInvoke.xml",endpoint = "http://sws-challenge.org/shipper/v2/racer",

mappingIN += anonymous XmlDsdMapping at upper.grounding [variable = $toAddress,dataNodePath = "OrderOperationRequest/to",attributeMappings += anonymous XmlDsdAttributeMapping at upper.grounding [

attributePath = "name",subNodePath = "LastName"

],attributeMappings += anonymous XmlDsdAttributeMapping at upper.grounding [

attributePath = "city/locatedIn",subNodePath = "Country",// name of united kingdom differs from ontology namesconverterClassName = "diane.converter.RacerCountryConverter",converterMethodName = "convert"

],...

],


Agenda





Mediation Scenario 1 - Architecture

Moo

n O

M

Sys

tem

DSD Service

Moo

n C

RM

S

yste

m

DSD Service Description

DSD Middleware

DSD Planner Module

DSD Execution Module

DSD Matcher Module

RosettaN

et S

ystem(s)

Rosetta – D

SD

T

ranslator

WSDL-Grounding1

6

5

8

7

5

4

32

9

DSDServiceRequest

BP

EL

-Pro

cess


Excerpt from Moon's offer description

upperMoonServiceOffer : Service


presents

Owned

effect

ItemSetIN,x,1

entity

Order

belongsTo

Item

contains

Customer

contact

String

businessName

Address

shipTo


Switching to Mediation Scenario 2

shipTo on item level / New Production Scheduling Both solved by adapting Rosetta-DSD Translator and BPEL-

Wrapper DSD-descriptions did not have to change

switching fast and easy (but not very "semantic")

Moo

n O

M

Sys

tem

DSD Service

Moo

n C

RM

S

yste

m

DSD Service Description

DSD Middleware

DSD Planner Module

DSD Execution Module

DSD Matcher Module

RosettaN

et S

ystem(s)

Rosetta – D

SD

T

ranslator

WSDL-Grounding1

6

5

8

7

5

4

32

9

DSDServiceRequest

BP

EL-

Pro

cess

Pro

duct

ion

Sch

edul

ing


Remarks about Mediation Scenario

Modelling of services easy Handwritten BPEL wrapper to expose simple interface

( Process mediation mainly performed manually, not so nice…?)

Rosetta-DSD Translator mainly handwritten (internal ontology differs from RosettaNet modelling – need to mediate)

Quite a bit of effort, approach only advantageous if more partners cooperate

Switching to Mediation Scenario 2 was easy (but not very "semantic")


Thank you for your attendance!

Questions?

Ulrich KüsterDIANE project (services in ad hoc networks)

http://hnsp.inf-bb.uni-jena.de/DIANE/

1 discovery and mediation using diane service descriptions ulrich küster and birgitta könig-ries...

Documents