Solution Jena

From SWS Challenge Wiki

This page contains documentation of the solution of University Jena's FUSION group to the SWS-Challenge problem scenarios as presented at the fourth SWS-Challenge workshop in Innsbruck.

This page is still under construction. Last change April 11th 2008

Contact author:
Ulrich Küster ( - Please do not hesitate to contact me in case of questions!)

1 Papers Describing the Solution
2 Ontologies
3 Solution to Discovery Scenarios
4 Solution to Mediation Scenarios

[edit]

Papers Describing the Solution

The following papers cover our participation in the SWS-Challenge:

First workshop (Stanford) short paper describes the overall idea
Second workshop (Budva) full paper describes the initial solution to both, the mediation and the original shipping discovery scenario
Third workshop (Athens) full paper describes the improvements made to the mediation and the original shipping discovery scenario
Fourth workshop (Innsbruck) full paper describes how the extensions to the shipping discovery scenario as well as the second discovery scenario have been solved.
ICEIS 2007 paper jointly written with the Polimi Milano/Cefriel team containing a comparison of both approaches
Fifth workshop discovery paper provides a consolidated description of our discovery solution.
Fifth workshop mediation paper provides a consolidated description of our mediation solution.

[edit]

Ontologies

The ontologies used in our solution are based on the DSD language (see papers). DSD comes in different notations: a graphical notation (called GDSD) that is based on Microsoft Visio files and can be exported into the main textual notation (called FDSD). FDSD can be parsed and transformed to a Java-based notation (called JDSD). Ontological classes and instances in JDSD are simply Java classes. JDSD is the format that is used internally at runtime by the DIANE middleware.

Some core concepts of the language contain functionality which can only be represented in JDSD, thus for these concepts no FDSD version exist. Additionally we made use of the fact that we can inject Java-code in JDSD instances to deal with temporal reasoning aspects. We created for instance a DateTime instance now that accesses the current system time to represent the concept now. Such instances, too, exist only in the JDSD notation and not in the FDSD notation.

Please find the ontologies used for the SWS-Challenge scenarios here. Most ontologies are provided in FDSD and JDSD notation, but some - as mentioned above - only exist in JDSD notation. For browsing it will usually be easier to look at the FDSD files since they are much more compact.

Ontologies are packaged. The most important packages are the following:

All needed instances (currencies, countries, units,...): FDSD-Format and JDSD-Format
The upper ontology defines concepts like Service, ServiceProfile, ServiceGrounding etc: FDSD-Format (only grounding classes available) and JDSD-Format (all classes)
Category ontologies define different states of the world which are of interest in the context of service descriptions like Owned or Shipped. Find them in JDSD-Format here and in FDSD-Format (the files starting with category) here
The top ontology defines some top-level concepts that are the base classes for the classes in the domain ontologies (see below): FDSD-Format and JDSD-Format
Domain ontologies describe certain domains of interests, like domain.money, domain.computer, domain.measure etc.: FDSD-Format (files starting with domain) and JDSD-Format
The core elements of the language have been added for completeness only: JDSD-Format (no FDSD-Format available)

[edit]

Solution to Discovery Scenarios

[edit]

Service offer and request descriptions

are provided in textual so-called FDSD format. At runtime the DIANE middleware will transform and compile them to JDSD for internal processing.

Please find all offer descriptions for the services used by the scenarios here
Please find all request descriptions used in the scenarios here
The groundings of the offer description refer to xml-template files needed to properly lower and lift ontological information to xml. Please find all used template files here
Some classes were used in the process of lowering and lifting (conversion between xml and ontological data)
- A converter to retrieve a proper string representation of a product type given a particular product. This class is used to retrieve the product type that will be fed into the listProduct operation of the vending services of the second discovery scenario. The source of the class can be found here
Rule-based computations as needed to compute prices of shipped packages or estimate shipping times had to be delegated to external helper services in our solution (see below for the WSDLs). The sources of these services can be found here.

[edit]

Additionally created auxiliary services

The following services have been created and offer additional information that can aid the discovery process. Feel free to reuse them if you have use for it.

Services used to compute shipping prices (Muller offers such an endpoint already itself), valid input continent names are "Europe", "Asia", "North America", "South America" and "Australia":
Services used to compute expected shipping times (Time input must be given in valid xml schema time format like 20:30, you can use any format for the countries, if they are equal, shipping is domestic, otherwise it is international):

[edit]

How to get the solution running

[edit]

Get and start the middleware

Download dsd-middleware.zip
Extract the zip file
Start the Middleware-GUI (a very rudimentary and incomplete GUI that has been created for convenience only) using the startMW.xml ant file contained in dsd-middleware.zip. A small JFrame should show up on your screen.
Start the Middleware server (Middleware ==> Run Middleware) or CTRL + R
This will cause the Middleware server to be started.
- Communication to the Middleware is done via Sockets. Upon startup by default the Middleware will open two sockets at ports 4913 and 4914. These ports need to be open (in particular the Middleware can only be started once since those ports will be blocked otherwise). You should receive an output similar to the one shown below.
- Upon startup service offer descriptions stored in resource/autoPublishServices will be automatically published to the Middleware. You should receive an output that the SWS-Challenge descriptions (bargainer, hawker, mullerWithGrounding, ...) have been successfully published. See below.
- The Middleware is now ready to receive service requests.
- Output when the Middleware is started:

CommunicationServer: No application home parameter was specified, will use current working directory: D:\temp\dsd-middleware
Starting DSD Middleware in D:\temp\dsd-middleware...
DIANE Service Middleware on port 4913 started.
DIANE Service Middleware on port 4914 started.
Publishing bargainer.dod...Finished: Successfully published bargainer at http://sws-challenge.org/shops/Bargainer
Publishing hawker.dod...Finished: Successfully published hawker at http://sws-challenge.org/shops/Hawker
Publishing mullerWithGrounding.dod...Finished: Successfully published Muller at http://sws-challenge.org/shipper/v2/muller
Publishing racerWithGrounding.dod...Finished: Successfully published Racer at http://sws-challenge.org/shipper/v2/racer
Publishing rummage.dod...Finished: Successfully published rummage at http://sws-challenge.org/shops/Rummage
Publishing runnerWithGrounding.dod...Finished: Successfully published Runner at http://sws-challenge.org/shipper/v2/runner
Publishing walkerWithGrounding.dod...Finished: Successfully published Walker at http://sws-challenge.org/shipper/v2/walker
Publishing weaselWithGrounding.dod...Finished: Successfully published Weasel at http://sws-challenge.org/shipper/v2/weasel
DSD Middleware successfully started!

[edit]

Run service requests against the middleware

[edit]

1. A simple matchmaking request

Try to receive matching services for one of the SWS-Challenge request descriptions which can be found in the samples directory.
- Run Service ==> Get Matches For Request (or CTRL + M) and choose (for instance) samples/swsShippingA1.drd
- You should receive the following output:

Retrieved 3 matching offers:

Muller at http://sws-challenge.org/shipper/v2/muller: 1.0
Offer-IN for Muller: toAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Muller: fromAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Muller: cargo(dsd.schema.top.PhysicalEntity) = Instance of type dsd.schema.top.PhysicalEntity: physicalentity11760.27804326855973116
Offer-IN for Muller: pickup(dsd.schema.domain.measure.DateTimeFrame) = Instance of type dsd.schema.domain.measure.DateTimeFrame

Runner at http://sws-challenge.org/shipper/v2/runner: 1.0
Offer-IN for Runner: toAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Runner: fromAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Runner: cargo(dsd.schema.top.PhysicalEntity) = Instance of type dsd.schema.top.PhysicalEntity: physicalentity11760.27804326855973116
Offer-IN for Runner: pickup(dsd.schema.domain.measure.DateTimeFrame) = Instance of type dsd.schema.domain.measure.DateTimeFrame

Walker at http://sws-challenge.org/shipper/v2/walker: 1.0
Offer-IN for Walker: toAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Walker: fromAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Walker: cargo(dsd.schema.top.PhysicalEntity) = Instance of type dsd.schema.top.PhysicalEntity: physicalentity11760.27804326855973116
Offer-IN for Walker: pickup(dsd.schema.domain.measure.DateTimeFrame) = Instance of type dsd.schema.domain.measure.DateTimeFrame

- The first lines contain debug information and can be ignored. As you can see you correctly receive three matching services: Muller, Runner and Walker (all match the request perfectly - matchvalue 1.0)
- For all matches the determined (optimal) configuration of the respective offer, that is, values for all inputs of the offer, is provided. Unfortunately the provided automated output is not very useful but you can see that for both services the variables toAddress, fromAddress, cargo and pickup have been filled with instances (even though you do not get much information about these instances).

[edit]

2. An automated invocation

Now try to not only receive matching services but have the best service be invoked automatically.
- Run Service ==> Execute Request (or CTRL + E) and again choose (for instance) samples/swsShippingA1.drd
- You should receive the following output:

Invoking service Muller at http://sws-challenge.org/shipper/v2/muller...

29.06.2007 11:00:26 XmlDsdConverter marshall
WARNUNG: Warning: XSD_Type of type dsd.elements.xsd.XSD_String has value null and cannot be marshalled. NULL will be returned!
29.06.2007 11:00:26 XmlDsdConverter fillComplexXml
WARNUNG: Marshalling of variable "dsd.elements.xsd.XSD_String: null" of class dsd.elements.xsd.XSD_String returned NULL! Empty String  will be used as filling! Attribute path was "city/state/name", node was identified by "location/state"
Sending request to: http://sws-challenge.org/shipper/v2/muller
Request: 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body>
        <tns:shipmentOrderRequest xmlns:tns="http://www.example.org/muller/">
            <tns:addressFrom>
                <tns:firstname/>
                <tns:lastname>Mr. Michael Moon, Moon Company</tns:lastname>
                <tns:address>Moon Road 13</tns:address>
                <tns:location>
                    <tns:postalCode>1234</tns:postalCode>
                    <tns:country>US</tns:country>
                    <tns:state>CA</tns:state>
                </tns:location>
                <tns:contactInformation>
                    <tns:phone>+1424242</tns:phone>
                    <tns:EMail>michael.moon@moon.ie</tns:EMail>
                    <tns:fax>+1424243</tns:fax>
                </tns:contactInformation>
            </tns:addressFrom>
            <tns:shipmentDate>
                <tns:earliestPickupDate>2007-06-29T11:00:26.683</tns:earliestPickupDate>
                <tns:latestPickupDate>2007-06-29T12:30:25.933</tns:latestPickupDate>
            </tns:shipmentDate>
            <tns:packageInformation>
                <tns:quantity>1</tns:quantity>
                <tns:weight>1</tns:weight>
                <tns:length>7</tns:length>
                <tns:height>4</tns:height>
                <tns:width>6</tns:width>
            </tns:packageInformation>
            <tns:addressTo>
                <tns:firstname/>
                <tns:lastname>Mr. Moe Szyslak</tns:lastname>
                <tns:address>105 Avenue de la Libert.</tns:address>
                <tns:location>
                    <tns:postalCode>10002</tns:postalCode>
                    <tns:country>TN</tns:country>
                    <tns:state/>
                </tns:location>
            </tns:addressTo>
        </tns:shipmentOrderRequest>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


SOAP Response Received:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
        <shipmentOrderResponse xmlns="http://www.example.org/muller/">
            <pickupDate>2007-06-29T11:38:50.963+02:00</pickupDate>
            <price>65.06</price>
        </shipmentOrderResponse>
    </soapenv:Body>
</soapenv:Envelope>


Retrieved 0 out variables:

- The middleware performs the matchmaking and - since equally well matching services are found - arbitrarily picks a service (in this case Muller) to be invoked.
- Again some debug and warning information is given that can be ignored (some warnings for instance refer to the fact that addresses in Tunisia do not have a state part like addresses in the United States do).
- For information purposes you can see the SOAP message being created and sent to the server and the servers response.
- Finally you are informed about out variables of the service invocation ("Retrieved 0 out variables"). Since the request did not specify any out variables no values are extracted from the SOAP response of the service invocation. Had the requester required to retrieve the pickup date or the price of the shipment after the service invocation this information would have been extracted from the server response and provided as request out variable.

[edit]

3. A more complex matchmaking example

Now try for instance an example that is a little more advanced
- Run Service ==> Get Matches for Request (or CTRL + M) and choose (for instance) samples/swsShippingC3.drd. This request poses a price limit of 20$ (and our request definition additionally specifies preference for lower prices - see papers).
- You should receive the following (a little lengthy) output:

CoreMatcher performing estimation.
Sending request to: http://sws-challenge.org/shipper/v2/muller
Request: 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
       <tns:invokePriceRequest xmlns:tns="http://www.example.org/muller/">
           <tns:country>GB</tns:country>
           <tns:packageInformation>
               <tns:quantity>1</tns:quantity>
               <tns:weight>20</tns:weight>
               <tns:length>10</tns:length>
               <tns:height>3</tns:height>
               <tns:width>2</tns:width>
           </tns:packageInformation>
       </tns:invokePriceRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP Response Received:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
       <invokePriceResponse xmlns="http://www.example.org/muller/">
           <price>100</price>
       </invokePriceResponse>
   </soapenv:Body>
</soapenv:Envelope>

CoreMatcher performing estimation.
Sending request to: http://hnsp.inf-bb.uni-jena.de:8080/axis/RacerInvokePriceService.jws
Request: 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
       <racerInvokePrice xmlns:xsd="http://www.w3.org/2001/XMLSchema">
           <continent type="xsd:string">Europe</continent>
           <weight type="xsd:double">20.0</weight>
           <length type="xsd:double">10.0</length>
           <height type="xsd:double">3.0</height>
           <width type="xsd:double">2.0</width>
       </racerInvokePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP Response Received:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
       <racerInvokePriceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
           <racerInvokePriceReturn xsi:type="xsd:double">188.5</racerInvokePriceReturn>
       </racerInvokePriceResponse>
   </soapenv:Body>
</soapenv:Envelope>

CoreMatcher performing estimation.
Sending request to: http://hnsp.inf-bb.uni-jena.de:8080/axis/RunnerInvokePriceService.jws
Request: 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
       <runnerInvokePrice xmlns:xsd="http://www.w3.org/2001/XMLSchema">
           <continent type="xsd:string">Europe</continent>
           <weight type="xsd:double">20.0</weight>
           <length type="xsd:double">10.0</length>
           <height type="xsd:double">3.0</height>
           <width type="xsd:double">2.0</width>
       </runnerInvokePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP Response Received:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
       <runnerInvokePriceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
           <runnerInvokePriceReturn xsi:type="xsd:double">165.0</runnerInvokePriceReturn>
       </runnerInvokePriceResponse>
   </soapenv:Body>
</soapenv:Envelope>

CoreMatcher performing estimation.
Sending request to: http://hnsp.inf-bb.uni-jena.de:8080/axis/WalkerInvokePriceService.jws
Request: 

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
       <walkerInvokePrice xmlns:xsd="http://www.w3.org/2001/XMLSchema">
           <continent type="xsd:string">Europe</continent>
           <weight type="xsd:double">20.0</weight>
           <length type="xsd:double">10.0</length>
           <height type="xsd:double">3.0</height>
           <width type="xsd:double">2.0</width>
       </walkerInvokePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP Response Received:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
       <walkerInvokePriceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
           <walkerInvokePriceReturn xsi:type="xsd:double">151.0</walkerInvokePriceReturn>
       </walkerInvokePriceResponse>
   </soapenv:Body>
</soapenv:Envelope>

Retrieved 1 matching offer

Muller at http://sws-challenge.org/shipper/v2/muller: 0.16666666666666663
Offer-IN for Muller: toAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Muller: fromAddress(dsd.schema.domain.location.Address) = Instance of type dsd.schema.domain.location.Address
Offer-IN for Muller: cargo(dsd.schema.top.PhysicalEntity) = Instance of type dsd.schema.top.PhysicalEntity: physicalentity13180.24717494446990262
Offer-IN for Muller: pickup(dsd.schema.domain.measure.DateTimeFrame) = Instance of type dsd.schema.domain.measure.DateTimeFrame

- The output is similar to the first example except for two differences:
  - As mentioned the request C3 specifies a price limit of $120, thus the actual price has to be inquired from the Muller service. Since rule-based computations had to be delegated to external auxiliary services (see above) the price of the shipment for the other services had to be inquired in a similar fashion. Thus you can see corresponding SOAP requests and responses to the services in the estimation phase ("CoreMatcher performing estimation."). Note that the request used in the first example did not specify a price limit. Therefore this additional work was not necessary and has not been performed! Also, since the shipping destination (United Kingdom) in Goal C3 already excludes some of the services (Weasel), the gathering of the price has not been performed for them.
  - The matchvalue of the matching Muller service is not 1.0 but roughly 0.17. The request had specified a price limit of $120 and preference for lower prices. This has been modelled by a DSD fuzzy set for the price with any prices higher than $120 resulting in a matching value of 0 (and thus a fail), any prices equal to 0 resulting in a perfect match (1.0) and any prices in between resulting in a corresponding linearly decreasing matching value. The matchvalue 0.167 corresponds to the price of $100 that the shipping costs at Muller.

[edit]

How to use the DIANE-middleware as a service

The discovery solution offered by the DIANE-Middleware can be used as a service in integrated solutions (for example in the future for more complex scenarios combining process mediation and discovery). There are different ways to do this which are briefly sketched in turn.

[edit]

General architecture and functionality provided

The core functionality of the DIANE Middleware is:

matchmaking of service descriptions (a request against the known offers)
matchmaking plus automated invocation of the best matching service (if one was found)

Other functionality like publishing of offer descriptions to a repository or binding of request templates etc. are auxiliary.

The DIANE Middleware functionality can be consumed using three different ways:

Using Java method calls directly
Communicating via sockets with the middleware
Using a web service interface to access the middleware

Each will be described in turn.

Note: The easiest way to publish offers at the middleware is to have them stored in FDSD format in the folder resource/autoPublishServices (files names have to end with .dod. These services will be published automatically when the middleware is started. All auxiliary files like grounding templates need to be deployed at the middleware by storing them in the appropriate folder anyway.

[edit]

Accessing the Middleware from a Java program

This is the most convenient way to access the Middleware and is actually an interfaced version of a socket access using the class diane.dsd.implementation.facade.proxy.MiddlewareProxy (which is also used by the Middleware GUI frontend). To use this singleton class obtain the instance using the getInstance() method and then use any of its functions to perform your actions on the middleware. The most important are getMatches(String or Service) and useService(String or Service). Please refer to the javadoc and contact me in case of question.

[edit]

Accessing the Middleware over plain sockets

To access the DIANE-Middleware from other technologies than Java you can also use plain socket access (by default to port 4914, the other default port - 4913 - expects serialized Java objects as inputs). The protocol supported at this port is incomplete, but it should not be a problem at all to extend it if necessary. If you are considering to use the Middleware by this way please do not hesitate to contact me to let me know which functionality is needed in order to se whether it can be added.

[edit]

Accessing the Middleware as a web service

Documentation yet to be done.

[edit]

Solution to Mediation Scenarios

Documentation yet to be done.

Retrieved from "http://sws-challenge.org/wiki/index.php/Solution_Jena"

Solution Jena

From SWS Challenge Wiki

Contents

Papers Describing the Solution

Ontologies

Solution to Discovery Scenarios

Service offer and request descriptions

Additionally created auxiliary services

How to get the solution running

Get and start the middleware

Run service requests against the middleware

1. A simple matchmaking request

2. An automated invocation

3. A more complex matchmaking example

How to use the DIANE-middleware as a service

General architecture and functionality provided

Accessing the Middleware from a Java program

Accessing the Middleware over plain sockets

Accessing the Middleware as a web service

Solution to Mediation Scenarios

Views

Personal tools

Navigation

Search

Toolbox