A Universal ServiceSemantics Description Language Ajay Bansal Srividya

A Universal Service-Semantics Description Language Ajay Bansal, Srividya Kona, Luke Simon, Ajay Mallya, and Gopal Gupta Department of Computer Science University of Texas at Dallas Thomas D. Hite Metallect Corp. Dallas, Texas CONFIDENTIAL 1

Context and Agenda • • What Web Services *really* are The next milestone for some ‘better times’ Need for Semantic Services Description Overview of USDL and an Universal Ontology Design of USDL Example USDL annotation of a service Applications of USDL Conclusions CONFIDENTIAL 2

Web Services As if this is new info… Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Source: W 3 C Web Services Architecture, W 3 C Working Draft 14 November 2002 CONFIDENTIAL 3

Engaging a Web Service Step 2: HUH? Agree on Semantics? ? ? Source: W 3 C Web Services Architecture, W 3 C Working Draft 14 November 2002 CONFIDENTIAL 4

Web Services Landscape • Description – WSDL, SAP (IFR), . NET and Java (Introspection), … – Players: Microsoft, IBM, SAP, Oracle … • Policy and Security – WS-Policy – Players: IBM, BEA, Microsoft, SAP, Sonic Software, Veri. Sign • Composition – BPEL, WSFL and WSCI (older), OWL-S, SWSL, WSML … – Players: Startups, Researchers, Consultants • Execution – Mostly Proprietary – Players: Oracle, Sun, Microsoft, Tibco, Blue Titan, Actional, Web. Methods… CONFIDENTIAL 5

Semantics and the average $3 B Fortune 1000… • Has hundreds of software applications – Most of which use different business dictionaries (loosely – taxonomies) – Multiple technologies (programming languages, packaged applications, databases, middleware) – Millions of lines of source code, database tables/columns, etc. – Multiple metadata repositories – Tens of millions of individual components (functions, variables, DB columns, etc. ) • Spends $105 (70% of total budget) million maintaining those apps • Has very little visibility into the apps on which they spend: – What they comprise and how they’re interconnected – What software artifacts relate to business drivers and terms – How the ‘guts’ are, or can be, leveraged to meet business needs • Lack of this kind of visibility is: – A major barrier to IT agility, a driver of cost and a contributor to risk Solved through Web Services with Automated Semantics CONFIDENTIAL 6

“Typical” enterprise application infrastructure Today’s applications are complex, started with different semantic domains, yet are highly interdependent CONFIDENTIAL 7

Real-life Case Study: A Seemingly Simple Composite Service Internet Order Application “Legacy” Order Application 1. Order placed via web app – invokes Java method(s) Web Pages JSP Java J 2 EE 2. Java method interacts with database 4. Middleware transforms and routes order data Middleware Oracle Procedures 3. Oracle DB stores order. A trigger initiates synchronization CONFIDENTIAL AS/400 RPG 6. RPG app processes order and returns status AS/400 DB 2 5. Middleware transforms and routes order data 8

Ends up in Complex Human Integration 1 Simple Composite Application 6 Technology Layers, supported by multiple roles & groups JSP Java Oracle Middleware for web pages for order processing for storage and triggers for trans. and messaging AS/400 DB 2 for storage AS/400 RPG for order processing Repeat: All using Oracle Middleware RPG DB 2 DBA’s Engineers developers DBA’s different terminologies Distributed Systems Architect AS/400 Architect Middleware for business concepts. Development Manager Web Developers Java Developers Quality Assurance Architect Quality Assurance Enterprise Architect Quality Assurance Business Analyst IT Executive CONFIDENTIAL 9

Existing Web Service Technologies • WSDL (Web Services Description Language) • UDDI (Universal Description, Discovery & Integration) • SOAP (Simple Object Access Protocol) Web Service Provider Interact via SOAP Messages Web Service Requester Describes Service Points to Service WSDL Points to Description CONFIDENTIAL Finds a Service UDDI Registry Do not solve the problems for realworld F 1000 companies. 10

Automated Semantics, order and RR 1 2 0 3 CONFIDENTIAL 11

Automating Web Services • Service Discovery – involves automatically locating a service adhering to all the requested properties. • Service Execution – involves automatically executing a discovered service that is appropriate. • Service Composition – involves automatically selecting, composing & executing appropriate services for a particular task. An infrastructure for automation of these tasks was missing! CONFIDENTIAL 12

Need for Semantic Description of Services • Infrastructure capable of automation of services must be semantics based. • Applications should be able to automatically reason about a service's capabilities. CONFIDENTIAL 13

WSDL Review from the working class • Purely syntactic in nature. • Only specifies the format of a service’s program interface (i. e. Call Semantics). • Does not specify what a service does at a conceptual level. CONFIDENTIAL 14

Semantic Description Languages • A couple of good examples: – OWL-S – WSML • Some limitations: – Use Domain-specific ontology – Semantic aliasing problem • distinct syntactic representations with distinct formal semantics yet equal conceptual semantics. – Domain specific ontologies require a formal standardization process (slow) and is not always possible. CONFIDENTIAL 15

Overcoming the Limitations Universal Service-Semantics Description Language • USDL does not preclude or replace OWL-S, WSML or the others. • USDL does address their limitations in atomic service description • Comprises just a few, easy to grasp components: – A universal ontology: OWL Word. Net Ontology – Restricted connectives, such that the semantics always equates things that are conceptually equal. • Concepts • Affects • Conditions • In short: a language that service providers and consumers alike can use to easily specify precise, formal and decidable semantics of the services themselves. CONFIDENTIAL 16

Overview of USDL • Starts with OWL Word. Net ontology to provide the missing Semantic semantics of atomic services • Consists of OWL surrogates for service constructs – Port. Type and Message are defined in the form of classes and properties – Formal Language for Service Documentation • There are only a few things to USDL – Concepts – Affects – Conditions CONFIDENTIAL 17

OWL Word. Net ontology • A coarse-grained ontology. • At a conceptual level, it is similar to common real world concepts. • USDL maps instances of service constructs into OWL Word. Net concepts. • Word. Net lexical concepts are used, as opposed to syntactic words, in order to avoid ambiguity of definitions. CONFIDENTIAL 18

USDL Concepts • Generic class Concept is defined in USDL. • Concept class defines the semantics of parts of messages. Concept Atomic Concept Inverted Concept Conjunctive Concept Disjunctive Concept Subclasses of Concept Class CONFIDENTIAL 19

Atomic Concept • Actual contact point between USDL and Word. Net. is. A property Word. Net Lexeme Atomic Concept of. Kind property • • Word. Net Lexeme Acts as a proxy for Word. Net lexical entities. Has exactly one defining value for is. A property Has at most one defining value for of. Kind property Example: Atomic Concept Order. Number is. A number of. Kind order. CONFIDENTIAL 20

USDL Affects • Semantics of how a service affects the external world is given by the affects property. • Current design of USDL assumes that each sideeffect is one of the following: – – creates updates deletes finds • Generic affects can be used wherein the affects property has USDL Concept as its value. CONFIDENTIAL 21

USDL Conditions • Generic class Condition is defined to describe constraints. • Conditions are represented as conjunction or disjunction of binary predicates. Condition Atomic Condition Conjunctive Condition Disjunctive Condition Subclasses of Condition Class CONFIDENTIAL 22

Atomic Condition • Condition/Predicate is a trait or aspect of the resource being described. • An Atomic Condition represents a Predicate which is of Concept type USDL Concept. greater. Than has. Concept property Atomic Condition C 1 on. Part property Concept Order. Number has. Value property Concept 1000 • Has exactly one value for on. Part property and at most one value for has. Value property. • Example constraint C 1: Order. Number greater than 1000 CONFIDENTIAL 23

Conjunctive and Disjunctive Conditions: • Conjunctive condition denotes the conjunction of USDL conditions. • Disjunctive condition denotes the disjunction of USDL conditions. • Any n-ary condition can be written as a combination of conjunctions and disjunctions of binary conditions. CONFIDENTIAL 24

Class Message • Message class is surrogate for WSDL message. – Message is a composite entity with zero or more parts. • For example: Flight. Reservation. Service <Message rdf: about="#Reserve. Flight_Request"> <has. Part rdf: resource="#Customer. Name" /> <has. Part rdf: resource="#Flight. Number" /> </Message> <Message rdf: about="#Reserve. Flight_Response"> <has. Part rdf: resource="#Reservation. Code"/> </Message> CONFIDENTIAL 25

Class Port. Type • USDL surrogate for WSDL port. Type. • A collection of procedures or operations that are parametric on messages. • Has zero or more Operations as values of has. Operation property. • For example: Flight. Reservation. Service. <Port. Type rdf: about="#Flight. Reservation_Service"> <has. Operation rdf: resource="#Reserve. Flight" /> </Port. Type> CONFIDENTIAL 26

Class Operation • Operation class defines the side-effect of the service via affects property. • Also defines the input and output messages via has. Input and has. Output properties. • For Example: Flight. Reservation. Service. <Operation rdf: about="#Reserve. Flight"> <has. Input rdf: resource="#Reserve. Flight_Request"/> <has. Output rdf: resource="#Reserve. Flight_Response"/> <creates rdf: resource="#Reservation. Receipt" /> </Operation> CONFIDENTIAL 27

Example WSDL Description <definitions>. . . <Port. Type name="Book. Buying_Service"> <operation name="Book. Buying"> <input message="Buy. Book_Request"/> <output message="Buy. Book_Response"/> </operation> </Port. Type> <message name="Buy. Book_Request"> <part name="Book. ISBN" type="xsd: string"/> <part name="User. Identifier" type="xsd: string"/> <part name="Password" type="xsd: string"/> </message> <message name="Buy. Book_Response"> <part name="Order. Number/Availability" type="xsd: string"/> </message>. . . </definitions> CONFIDENTIAL 28

Example USDL Description <definitions> <Port. Type rdf: about="#Book. Buying_Service"> <has. Operation rdf: resource="#Buy. Book" /> </Port. Type> <Operation rdf: about="#Buy. Book"> <has. Input rdf: resource="#Buy. Book_Request"/> <has. Output rdf: resource="#Buy. Book_Response"/> <creates rdf: resource="#Book. Order" /> </Operation> <Message rdf: about="#Buy. Book_Request"> <has. Part rdf: resource="#Book. ISBN" /> <has. Part rdf: resource="#User. Identifier" /> <has. Part rdf: resource="#Password" /> </Message> <Message rdf: about="#Buy. Book_Response"> <has. Part rdf: resource="#Order. Number/Availabilty"/> </Message> <Atomic. Concept rdf: about="#Book. ISBN"> <is. A rdf: resource="&wn; identifier"/> <of. Kind rdf: resource="#Book" /> </Atomic. Concept> CONFIDENTIAL <Atomic. Concept rdf: about="#Book. ISBN"> <is. A rdf: resource="&wn; identifier"/> <of. Kind rdf: resource="#Book" /> </Atomic. Concept> <Atomic. Concept rdf: about="#Book"> <is. A rdf: resource="&wn; book"/> </Atomic. Concept> <is. A rdf: resource="&wn; Password"/> </Atomic. Concept> <Atomic. Concept rdf: about="#User. Identifier"> <is. A rdf: resource="&wn; identifier"/> <of. Kind rdf: resource="#User" /> <has. Condition rdf: resource="#User. Exists" /> </Atomic. Concept> <Condition rdf: about="#User. Exists"> <has. Concept rdf: resource="#exists"/> <on. Part rdf: resource="#User. Identifier"/> </Condition> … continued on next slide 29

Example USDL Description cont’d… <Disjunctive. Concept rdf: about="#Order. Number/Availability"> <has. Concept rdf: resource="#Order. Number" /> <has. Concept rdf: resource="#Not. Available" /> </Disjunctive. Concept> <Inverted. Concept rdf: about="#Not. Available"> <has. Concept rdf: resource="#Available" /> </Inverted. Concept> <Atomic. Concept rdf: about="#Book. Order"> <is. A rdf: resource="&wn; order"/> <of. Kind rdf: resource="#Book" /> <has. Condition rdf: resource="#Credit. Exists" /> </Atomic. Concept> <Condition rdf: about="#Credit. Exists"> <has. Concept rdf: resource="#exists" /> <on. Part rdf: resource="#Credit. Card" /> </Condition> <Atomic. Concept rdf: about="#User"> <is. A rdf: resource="&wn; user"/> </Atomic. Concept> CONFIDENTIAL <Atomic. Concept rdf: about="#exists"> <is. A rdf: resource="&wn; exists"/> </Atomic. Concept> <Atomic. Concept rdf: about="#Order. Number"> <is. A rdf: resource="&wn; number"/> <of. Kind rdf: resource="#Order" /> </Atomic. Concept> <Atomic. Concept rdf: about="#Order"> <is. A rdf: resource="&wn; order"/> </Atomic. Concept> <Atomic. Concept rdf: about="#Available"> <is. A rdf: resource="&wn; available"/> </Atomic. Concept> <Atomic. Concept rdf: about="#Credit. Card"> <is. A rdf: resource="&wn; card" /> <of. Kind rdf: resource="#Credit" /> </Atomic. Concept> </definitions> 30

Applications of USDL • Formal Semantic documentation of web services. • Intelligent, conceptual-level querying of directories of web-services. • Automation of service integration. • Automation of the development of composite webservices, i. e. , web-services implemented via composition of pre-existing web-services. CONFIDENTIAL 31

USDL and OWL-S is a language for composing USDL descriptions. • Atomic services in OWL-S are described using domainspecific ontology – Limits the applicability of OWL-S. – Allows arousal of semantic aliasing problem. • OWL-S provides tags – presents for service profile – described. By for service model – For incorporating domain specific ontological descriptions. • USDL and OWL-S are perfect compliments – USDL describes atomic services within OWL-S. – Overcomes limitation of domain specific ontologies. CONFIDENTIAL 32

Conclusions • To make web services ubiquitously available we need a standard formal way of specifying semantics of web services. • USDL can be used to formally and semantically describe web-services. • USDL uses OWL Word. Net ontology and connectives to provide: – universal ontology: – solves semantic aliasing problem. – does not depend on the process of building domain-specific ontologies which may have been known to be slow, difficult, and often abandoned. CONFIDENTIAL 33

A Universal Service-Semantics Description Language Q/A Tom Hite: tom@metallect. com CONFIDENTIAL 34