1 / 34

A Universal Service-Semantics Description Language

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.

maggard
Download Presentation

A Universal Service-Semantics Description Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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 machine-processable 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: W3C Web Services Architecture, W3C Working Draft 14 November 2002

  4. Engaging a Web Service Step 2: HUH? Agree onSemantics??? Source: W3C Web Services Architecture, W3C Working Draft 14 November 2002

  5. 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, VeriSign • 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, WebMethods…

  6. Semantics and the average $3B 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

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

  8. 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 AS/400 RPG Java J2EE 2. Java method interacts with database 6. RPG app processes order and returns status 4. Middleware transforms and routes order data Oracle AS/400 DB2 Middleware Procedures 5. Middleware transforms and routes order data 3. Oracle DB stores order. A trigger initiates synchronization

  9. Ends up in Complex Human Integration 1 Simple Composite Application6 Technology Layers, supported by multiple roles & groups Repeat: All using different terminologies for business concepts.

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

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

  12. 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!

  13. 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.

  14. 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.

  15. 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.

  16. 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 WordNet 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.

  17. Overview of USDL • Starts with OWL WordNet ontology to provide the missing Semantic semantics of atomic services • Consists of OWL surrogates for service constructs • PortType 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

  18. OWL WordNet 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 WordNet concepts. • WordNet lexical concepts are used, as opposed to syntactic words, in order to avoid ambiguity of definitions.

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

  20. WordNet Lexeme isA property Atomic Concept WordNet Lexeme ofKind property Atomic Concept • Actual contact point between USDL and WordNet. • Acts as a proxy for WordNet lexical entities. • Has exactly one defining value for isA property • Has at most one defining value for ofKind property • Example: Atomic Concept OrderNumber isA number ofKind order.

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

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

  23. Atomic Condition • Condition/Predicate is a trait or aspect of the resource being described. • An Atomic Condition represents a Predicate which is of type USDL Concept. • Has exactly one value for onPart property and at most one value for hasValue property. • Example constraint C1: OrderNumber greater than 1000 Concept greaterThan hasConcept property Atomic Condition C1 Concept OrderNumber onPart property hasValue property Concept 1000

  24. 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.

  25. Class Message • Message class is surrogate for WSDL message. • Message is a composite entity with zero or more parts. • For example: FlightReservationService <Message rdf:about="#ReserveFlight_Request"> <hasPart rdf:resource="#CustomerName" /> <hasPart rdf:resource="#FlightNumber" /> </Message> <Message rdf:about="#ReserveFlight_Response"> <hasPart rdf:resource="#ReservationCode"/> </Message>

  26. Class PortType • USDL surrogate for WSDL portType. • A collection of procedures or operations that are parametric on messages. • Has zero or more Operations as values of hasOperation property. • For example: FlightReservationService. <PortType rdf:about="#FlightReservation_Service"> <hasOperation rdf:resource="#ReserveFlight" /> </PortType>

  27. Class Operation • Operation class defines the side-effect of the service via affects property. • Also defines the input and output messages via hasInput and hasOutput properties. • For Example: FlightReservationService. <Operation rdf:about="#ReserveFlight"> <hasInput rdf:resource="#ReserveFlight_Request"/> <hasOutput rdf:resource="#ReserveFlight_Response"/> <creates rdf:resource="#ReservationReceipt" /> </Operation>

  28. Example WSDL Description <definitions> ... <PortType name="BookBuying_Service"> <operation name="BookBuying"> <input message="BuyBook_Request"/> <output message="BuyBook_Response"/> </operation> </PortType> <message name="BuyBook_Request"> <part name="BookISBN" type="xsd:string"/> <part name="UserIdentifier" type="xsd:string"/> <part name="Password" type="xsd:string"/> </message> <message name="BuyBook_Response"> <part name="OrderNumber/Availability" type="xsd:string"/> </message> ... </definitions>

  29. Example USDL Description <definitions> <PortType rdf:about="#BookBuying_Service"> <hasOperation rdf:resource="#BuyBook" /> </PortType> <Operation rdf:about="#BuyBook"> <hasInput rdf:resource="#BuyBook_Request"/> <hasOutput rdf:resource="#BuyBook_Response"/> <creates rdf:resource="#BookOrder" /> </Operation> <Message rdf:about="#BuyBook_Request"> <hasPart rdf:resource="#BookISBN" /> <hasPart rdf:resource="#UserIdentifier" /> <hasPart rdf:resource="#Password" /> </Message> <Message rdf:about="#BuyBook_Response"> <hasPart rdf:resource="#OrderNumber/Availabilty"/> </Message> <AtomicConcept rdf:about="#BookISBN"> <isA rdf:resource="&wn;identifier"/> <ofKind rdf:resource="#Book" /> </AtomicConcept> <AtomicConcept rdf:about="#BookISBN"> <isA rdf:resource="&wn;identifier"/> <ofKind rdf:resource="#Book" /> </AtomicConcept> <AtomicConcept rdf:about="#Book"> <isA rdf:resource="&wn;book"/> </AtomicConcept> <AtomicConcept> <isA rdf:resource="&wn;Password"/> </AtomicConcept> <AtomicConcept rdf:about="#UserIdentifier"> <isA rdf:resource="&wn;identifier"/> <ofKind rdf:resource="#User" /> <hasCondition rdf:resource="#UserExists" /> </AtomicConcept> <Condition rdf:about="#UserExists"> <hasConcept rdf:resource="#exists"/> <onPart rdf:resource="#UserIdentifier"/> </Condition> … continued on next slide

  30. Example USDL Description cont’d… <DisjunctiveConcept rdf:about="#OrderNumber/Availability"> <hasConcept rdf:resource="#OrderNumber" /> <hasConcept rdf:resource="#NotAvailable" /> </DisjunctiveConcept> <InvertedConcept rdf:about="#NotAvailable"> <hasConcept rdf:resource="#Available" /> </InvertedConcept> <AtomicConcept rdf:about="#BookOrder"> <isA rdf:resource="&wn;order"/> <ofKind rdf:resource="#Book" /> <hasCondition rdf:resource="#CreditExists" /> </AtomicConcept> <Condition rdf:about="#CreditExists"> <hasConcept rdf:resource="#exists" /> <onPart rdf:resource="#CreditCard" /> </Condition> <AtomicConcept rdf:about="#User"> <isA rdf:resource="&wn;user"/> </AtomicConcept> <AtomicConcept rdf:about="#exists"> <isA rdf:resource="&wn;exists"/> </AtomicConcept> <AtomicConcept rdf:about="#OrderNumber"> <isA rdf:resource="&wn;number"/> <ofKind rdf:resource="#Order" /> </AtomicConcept> <AtomicConcept rdf:about="#Order"> <isA rdf:resource="&wn;order"/> </AtomicConcept> <AtomicConcept rdf:about="#Available"> <isA rdf:resource="&wn;available"/> </AtomicConcept> <AtomicConcept rdf:about="#CreditCard"> <isA rdf:resource="&wn;card" /> <ofKind rdf:resource="#Credit" /> </AtomicConcept> </definitions>

  31. 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 web-services, i.e., web-services implemented via composition of pre-existing web-services.

  32. USDL and OWL-S • Atomic services in OWL-S are described using domain-specific ontology • Limits the applicability of OWL-S. • Allows arousal of semantic aliasing problem. • OWL-S provides tags • presents for service profile • describedBy 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. OWL-S is a language for composing USDL descriptions.

  33. 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 WordNet 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.

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

More Related