Ad
More Related Content
Viewers also liked (20)
Similar to Semantic web service (20)
Ad
Recently uploaded (20)
Ad
Semantic web service
- 1. Semantic Web Services OWL-S and others © Copyright 2010 Dieter Fensel and Srdjan Komazec 1
- 2. Where are we? # Title 1 Introduction 2 Web Science 3 Service Science 4 Web services 5 Web2.0 services 6 Semantic Web 7 Web Service Modeling Ontology (WSMO) 8 Web Service Modeling Language (WSML) 9 Web Service Execution Environment (WSMX) 10 OWL-S and others 11 Light-weight Annotations 12 Applications 13 Mobile Services 2
- 3. Outline • Motivation • Technical solution – Comparison approach • Framework description • Comparison criteria – Evaluated Semantic Web Service (SWS) frameworks • OWL-S • METEOR-S • SWSF – Evaluated Semantic Execution Environment (SEE) implementation • IRS – III • Illustration by larger example • Summary • References 3
- 4. Motivation 4
- 5. Motivation • WSMO is not the only initiative aimed towards Semantic Web Services • Other major approaches in the area are documented by recent W3C member submissions: – OWL-S, – METEOR-S, and – SWSF. • Other implementations of WSMO – IRS-III • Goals of this lecture: – Explain principal characteristics of the approaches, – Exemplify their usage, – Give overview of the tools support, – Compare approach to WSMO (for IRS-III to WSMX), and – Evaluate approach in contrast to the SWS framework requirements. 5
- 7. Comparison Approach Framework Description • Overall approach – Describes principal characteristics of evaluated framework • Conceptual model – Explains underlying model adopted by the framework • Example – Illustrates the framework usage through an example • Tool support – Overviews existing tools developed to support the framework • Relation to WSMO – Draws parallel between WSMO and evaluated framework 7
- 9. Comparison Approach Comparison Criteria • SWS are basically combining Semantic Web technologies and Web services. • Thus SWS frameworks need to integrate – basic Web design principles, – design principles defined for the Semantic Web, and – design principles for distributed, service-oriented computing on the Web. • A SWS framework should answer to the following requirements1: – Web compliance – Ontology-based – Strict decoupling – Centrality of mediation – Ontological role separation – Description vs. implementation – Execution semantics – Service vs. Web service 1 Fensel, Dieter; Kerrigan, Mick; Zaremba, Michal (Eds.). Implementing Semantic Web Services: The SESA Framework. Springer, 2008 9
- 10. Comparison Approach Comparison Criteria – Web Compliance • What is it? – A set of simple and flexible concepts forming the foundation of Web such as Universal Resource Identifier (URI), namespaces, etc. • Why is it important? – Reliance on the already established concepts such as URIs enables seamless integration of pre-existing Web resources and application of proven and tested tools and libraries. • What is expected from the framework? – A SWS framework should integrate with the current Web, thus it should reuse/rely on the basic Web concepts. 10
- 11. Comparison Approach Comparison Criteria – Ontology-based • What is it? – Ontologies are formal and explicit specifications of shared conceptualizations. – An ontology-based system is a system which adopts ontologies as a founding format to express data and processes which the system deals with. • Why is it important? – Ontologies are allowing enhanced information processing and automatic resolution of heterogeneity issues between resources. • What is expected from the framework? – Usage of ontologies as the data model throughout framework. – All resource descriptions and data exchanged are ontologically described. 11
- 12. Comparison Approach Comparison Criteria – Strict Decoupling • What is it? – Decoupling represents separation of resources which should not depend on each other. – Size, diversity and unanticipated usage of Web resources are advocating towards their strict decoupling. • Why is it important? – On the Web resources are developed in isolation from one another. • What is expected from the framework? – Resources should be strictly decoupled from one another. – Semantic descriptions are developed in isolation without regard for their possible usage or interaction with other resources. 12
- 13. Comparison Approach Comparison Criteria – Centrality of Mediation • What is it? – Mediation is an activity which reconciles heterogeneities between parties. • Why is it important? – Decoupling of resources requires existence of a mechanism for resolving heterogeneity issues between them. – Mediation performs the role of resolving potential mismatches between resources that occur at the data, protocol and process level. • What is expected from the framework? – Mediators should be top-level elements of the framework. – It should be easy to connect mediators to the other elements. 13
- 14. Comparison Approach Comparison Criteria – Ontological Role Separation • What is it? – Consumers and providers of Web Services are loosely coupled. – Consumption of a Web Service functionality can be cannot be expected neither enforced. • Why is it important? – The contexts within which requesters and providers of services exist can be very different from one another. • What is expected from the framework? – A framework should differentiate between the requirements that a given requester has and the functionality that service providers are willing to offer. – The framework should stress the difference between the goals and Web Services. 14
- 15. Comparison Approach Comparison Criteria – Description vs. Implementation • What is it? – Difference between description of functionality and its implementation. – Service description is separated from the way the service is implemented and offered. • Why is it important? – A firm distinction between the description of elements of Semantic Web Services and executable technologies should be present. – It allows decoupling from the current implementation technologies and possibility to ground descriptions to different underlying standards. • What is expected from the framework? – A framework should aim at providing ontological description model for the elements and to be compliant with the executable technologies. 15
- 16. Comparison Approach Comparison Criteria – Execution Semantics • What is it? – It is a formal description of the operational behavior of the system. – By separating the description of the system behavior from the system implementation greater flexibility can be achieved. • Why is it important? – It provides a mechanism to test, simulate and verify the SWS specification, identify anomalies such as deadlocks, livelocks and tasks that are never reached. – It provides sound foundation to build an engine being able to execute created models. – It improves or even rules out ambiguities in model understanding by humans. • What is expected from the framework? – Framework should provide means to specify and run formal execution semantics. 16
- 17. Comparison Approach Comparison Criteria – Service vs. Web Service • What is it? – A clear distinction between Services and Web Services. – A Web Service is a computational entity that is able to provide some functionality to the user by invoking it. – A service is the actual value provided by the invocation. • Why is it important? – Although services are what counts for the consumers their value may be subjective and context-dependent. – A SWS framework should provides means to describe Web Services. • What is expected from the framework? – A framework should be designed as a means to describe Web Services and not to replace services. – Actual value is provided by Web Service invocations. 17
- 18. Technical solution OWL – S 18
- 19. OWL-S Overall approach • OWL-S represents an upper ontology for the description of Semantic Web Services expressed in OWL. – It has its roots in the DAML Service Ontology (DAML-S). – It adopts existing Semantic Web recommendations (i.e. OWL). – It maintains bindings to the Web Services world by linking to WSDL descriptions. • W3C Member Submission 19
- 20. OWL-S Conceptual Model – Service Class • The class Service – provides an organizational point of reference for a declared Web service. • The class has three properties: – presents • Defines what service does. • Points to the ServiceProfile instance. – supports • Defines how to access the described service. • Points to the ServiceGrounding instance. Figure 1 – OWL-S Conceptual Model – describedBy • Defines how the service works. • Points to the ServiceModel instance. Figure taken from David Martin at al. OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004 20
- 21. OWL-S Conceptual Model – Service Profile Class • Expresses “what a service does” for – Advertising purposes - used to express the service functional and non functional properties, and – Template for service requests. • Specification of functionality provided by a service is given through: – requirements that the service requester must satisfy to use the service successfully. – Inputs and outputs (OWL classes) and – Preconditions and results (format not fixed). • Non-functional properties of a service are defined through: – Instances of the ServiceCategory class • an entry in some ontology or taxonomy of services. – Instances of the ServiceParameter class • expandable list of arbitrary properties that may accompany a profile description. – A set of simple value attributes such as serviceName, textDescription, serviceProduct, serviceClassification (explained later). 21
- 22. OWL-S Conceptual Model – Service Profile Class Figure 2 – OWL-S Service Profile Figure taken from David Martin at al. OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004 22
- 23. OWL-S Conceptual Model – Service Profile Class • Functional properties – hasParameter - ranges over a Parameter instance from the Service Model 2 ontology. Note that the Parameter class models our intuition that Inputs and Outputs (which are kinds of Parameters) are both involved in information transformation and therefore they are different from Preconditions and Effects. As a consequence, we do not expect this class to be instantiated. It's role is solely making domain knowledge explicit. – hasInput - ranges over instances of Inputs as defined in the Service Model 2 ontology. – hasOutput - ranges over instances of type Output, as defined in the Service Model 2 ontology. – hasPrecondition - specifies one of the preconditions of the service and ranges over a Precondition instance defined according to the schema in the Service Model 2 ontology. – hasResult - specifies one of the results of the service, as defined by the Result class in the Service Model2 ontology. It specifies under what conditions the outputs are generated. Furthermore, the Result specifies what domain changes are produced during the execution of the service 2 The Service Model ontology is explained in the upcoming slides. 23
- 24. OWL-S Conceptual Model – Service Profile Class • Non-functional properties – serviceParameter - is an expandable list of properties that may accompany a profile description. The value of the property is an instance of the class ServiceParameter (next slide). – serviceCategory - refers to an entry in some ontology or taxonomy of services. The value of the property is an instance of the class ServiceCategory (next slide). – serviceName - refers to the name of the service that is being offered. It can be used as an identifier of the service – textDescription - provides a brief description of the service. It summarizes what the service offers, it describes what the service requires to work, and it indicates any additional information that the compiler of the profile wants to share with the receivers – serviceClassification - defines a mapping from a Profile to an OWL ontology of services, such as an OWL specification of NAICS – serviceProduct - defines a mapping from a Profile to an OWL ontology of products, such as an OWL specification of UNSPSC NAICS – North American Industry Classification System - http://www.census.gov/naics/ UNSPSC – United Nations Standard Products and Services Code - http://www.unspsc.org/ 24
- 25. OWL-S Conceptual Model – Service Profile Class • Non-functional properties (cont’d) • ServiceParameter class - additional attributes include the quality guarantees that are provided by the service, possible classification of the service, and additional parameters that the service may want to specify – serviceParameterName - is the name of the actual parameter, which could be just a literal, or perhaps the URI of the process parameter (a property) – sParameter - points to the value of the parameter within some OWL ontology • ServiceCategory class - describes categories of services on the bases of some classification – categoryName - is the name of the actual category, which could be just a literal, or perhaps the URI of the process parameter (a property) – taxonomy - stores a reference to the taxonomy scheme. It can be either a URI of the taxonomy, or a URL where the taxonomy resides, or the name of the taxonomy or anything else – value - points to the value in a specific taxonomy There may be more than one value for each taxonomy, so no restriction is added here – code - to each type of service stores the code associated to a taxonomy 25
- 26. OWL-S Conceptual Model – Service Model Class • Exposes “how a service works” to enable invocation, composition, monitoring, recovery, etc. • The Service Model views interaction with the service as a process – The Process class represents the central class in the model, – Process generates and returns some new information based on the given information and the world state (inputs and outputs - slide # 23). – Process produces a change in the world (preconditions and results - slide # 23). • A Process instance is characterized by the number of properties: – Zero or more inputs - representing the information that is, under some conditions, required for the performance of the process, – Any number of outputs - the information that the process provides to the requester, – Any number of preconditions - which must all hold in order for the process to be successfully invoked, – Any number of effects - which must all hold after the process invocation. • The Process class is further specialized into the – Atomic process - a description of a service that expects one (possibly complex) message and returns one (possibly complex) message. – Simple process – used for abstraction and simplification purposes. – Composite process - maintains some state; each message the client sends advances it through the process. 26
- 27. OWL-S Conceptual Model – Service Model Class Figure 3 – OWL-S Service Process Model Figure taken from David Martin at al. OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004 27
- 28. OWL-S Conceptual Model – Service Model Class – Process Classification • Atomic processes – directly invocable (by passing them the appropriate messages), – no subprocesses and execute in a single step, – they take an input message, do something, and then return their output message, – provided a grounding that enables a service requester to construct messages to the process from its inputs and deconstruct replies • Simple processes – not invocable and are not associated with a grounding, – conceived of as having single-step executions – used as elements of abstraction • used to provide a view of (a specialized way of using) some atomic process • simplified representation of some composite process (for purposes of planning and reasoning) • Composite processes – decomposable into other (non-composite or composite) processes, – their decomposition can be specified by using control constructs such as Sequence and If-Then-Else – a composite process is not a behavior a service will do, but a behavior (or set of behaviors) the client can perform by sending and receiving a series of messages 28
- 29. OWL-S Conceptual Model – Service Model Class – Complex Process Control Structures • Sequence – A list of control constructs to be done in order • Split – The components of a Split process are a bag of process components to be executed concurrently. Split completes as soon as all of its component processes have been scheduled for execution • Split+Join – Here the process consists of concurrent execution of a bunch of process components with barrier synchronization. That is, Split+Join completes when all of its components processes have completed. With Split and Split+Join, we can define processes that have partial synchronization (e.g., split all and join some sub-bag). • Any-Order – Allows the process components (specified as a bag) to be executed in some unspecified order but not concurrently. Execution and completion of all components is required. The execution of processes in an Any-Order construct cannot overlap, i.e. atomic processes cannot be executed concurrently and composite processes cannot be interleaved. All components must be executed. As with Split+Join, completion of all components is required 29
- 30. OWL-S Conceptual Model – Service Model Class – Complex Process Control Structures • Choice – calls for the execution of a single control construct from a given bag of control constructs (given by the components property). Any of the given control constructs may be chosen for execution. • If-Then-Else – control construct that has properties ifCondition, then and else holding different aspects of the If-Then-Else. Its semantics is intended as ``Test If-condition; if True do Then, if False do Else.'' (Note that the class Condition, which is a placeholder for further work, will be defined as a class of logical expressions.) • Iterate – makes no assumption about how many iterations are made or when to initiate, terminate, or resume. The initiation, termination or maintenance condition could be specified with a whileCondition or an untilCondition • Repeat-While and Repeat-Until – Both of these iterate until a condition becomes false or true, following the familiar programming language conventions 30
- 31. OWL-S Conceptual Model – Service Grounding Class • Maps the constructs of the process model to detailed specifications of message formats, protocols and so forth. • Mapping of the atomic processes to WSDL operations and their I/Os to WSDL messages is supported. • Mappings might have XSLT transformations attached to solve the lifting/lowering problem between OWL and XML Schema. Figure 4 – Mapping between OWL-S and • Other grounding mechanisms can be WSDL supported • For example take a look at http://www.daml.org/services/owl- s/1.0/BravoAirGrounding.owl Figure taken from David Martin at al. OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004 31
- 32. OWL-S Example • Bravo Air - fictitious airline site • The site is providing a service which enables reservation of trips as a composite process consisting of following steps – Retrieval of the desired flight details – Selection of the available flights, and – Booking of the selected flights, which includes following substeps • Login and • Confirmation of reservation. • The example consists of the following artifacts – BravoAirService.owl - OWL-S service, – BravoAirProfile.owl – OWL-S ServiceProfile description, – BravoAirProcess.owl – OWL-S ServiceModel description, – BravoAirGrounding.owl – OWL-S ServiceGrounding description, and – BravoAirGrounding.wsdl – annotated WSDL which points to the specifics OWL-S descriptions used during the processing (not exemplified here). • Presented examples are lacking full details due to the space constrains. Example taken from http://www.daml.org/services/owl-s/1.0/examples.html 32
- 33. OWL-S Example – Bravo Air Service Ontology <rdf:RDF> <owl:Ontology rdf:about=""> <rdfs:comment> This ontology represents the OWL-S service description for the BravoAir web service example. </rdfs:comment> <owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.0/Service.owl"/> <owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.0/BravoAirProfile.owl"/> <owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.0/BravoAirProcess.owl"/> </owl:Ontology> <service:Service rdf:ID="BravoAir_ReservationAgent"> <!-- Reference to the BravoAir Profile --> <service:presents rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirProfile.owl#Profile_BravoAir_ReservationAgent"/> <!-- Reference to the BravoAir Process Model --> <service:describedBy rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirProcess.owl#BravoAir_ReservationAgent_ServiceModel"/> <!-- Reference to the BravoAir Grounding --> <service:supports rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirGrounding.owl#Grounding_BravoAir_ReservationAgent"/> </service:Service> </rdf:RDF> 33
- 34. OWL-S Example – Bravo Air Service Profile Ontology <rdf:RDF> <owl:Ontology rdf:about=""> <rdfs:comment>BravoAir Example for OWL-S Profile description</rdfs:comment> <owl:imports rdf:resource="http://www.daml.org/services/owl-s/1.0/Service.owl"/> ... </owl:Ontology> <profile:serviceParameter> <addParam:GeographicRadius rdf:ID="BravoAir-geographicRadius"> <profile:serviceParameterName>BravoAir Geographic Radius</profile:serviceParameterName> <profile:sParameter rdf:resource="http://www.daml.org/services/owl- s/1.0/Country.owl#UnitedStates"/> </addParam:GeographicRadius> </profile:serviceParameter> <profile:serviceCategory> <addParam:NAICS rdf:ID="NAICS-category"> <profile:value>Airline reservation services </profile:value> <profile:code>561599</profile:code> </addParam:NAICS> </profile:serviceCategory> ... <profile:hasInput rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirProcess.owl#DepartureAirport_In"/> <profile:hasOutput rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirProcess.owl#AvailableFlightItineraryList_Out"/> </rdf:RDF> 34
- 35. OWL-S Example – Bravo Air Service Model Ontology <rdf:RDF> <process:ProcessModel rdf:ID="BravoAir_ReservationAgent_ProcessModel"> <process:hasProcess rdf:resource="#BravoAir_Process"/> <service:describes rdf:resource="http://www.daml.org/services/owl- s/1.0/BravoAirService.owl#BravoAir_ReservationAgent"/> </process:ProcessModel> <process:CompositeProcess rdf:ID="BravoAir_Process"> <process:composedOf> <process:Sequence> <process:components rdf:parseType="Collection"> <process:AtomicProcess rdf:about="#GetDesiredFlightDetails"/> <process:AtomicProcess rdf:about="#SelectAvailableFlight"/> <process:CompositeProcess rdf:about="#BookFlight"/> </process:components> </process:Sequence> </process:composedOf> </process:CompositeProcess> 35
- 36. OWL-S Example – Bravo Air Service Model Ontology <process:CompositeProcess rdf:ID="BookFlight"> <process:composedOf> <process:Sequence> <process:components rdf:parseType="Collection"> <process:AtomicProcess rdf:about="#Login"/> <process:AtomicProcess rdf:about="#ConfirmReservation"/> </process:components> </process:Sequence> </process:composedOf> </process:CompositeProcess> <process:AtomicProcess rdf:ID="LogIn"> <process:hasInput rdf:resource="#AcctName_In"/> <process:hasInput rdf:resource="#Password_In"/> </process:AtomicProcess> <process:Input rdf:ID="AcctName_In"> <process:parameterType rdf:resource="http://www.daml.org/services/owl- s/1.0/Concepts.owl#AcctName"/> </process:Input> <process:Input rdf:ID="Password_In"> <process:parameterType rdf:resource="http://www.daml.org/services/owl- s/1.0/Concepts.owl#Password"/> </process:Input> </rdf:RDF> 36
- 37. OWL-S Example – Bravo Air Service Grounding Ontology <rdf:RDF> … <grounding:WsdlAtomicProcessGrounding rdf:ID="WsdlGrounding_LogIn”> <!-- Grounding for the Atomic Process LogIn --> <grounding:owlsProcess rdf:resource="&ba_process;#LogIn"/> <!-- Reference to the corresponding WSDL operation --> <grounding:wsdlOperation rdf:resource="#LogIn_operation"/> <!-- Reference to the WSDL input message --> <grounding:wsdlInputMessage><xsd:anyURI rdf:value="&BravoAirGroundingWSDL;#LogIn_Input"/></grounding:wsdlInputMessage> <!-- Mapping of OWL-S inputs to WSDL message parts --> <grounding:wsdlInputs rdf:parseType="Collection”> <grounding:WsdlInputMessageMap> <grounding:owlsParameter rdf:resource="&ba_process;#acctName_In"/> <grounding:wsdlMessagePart> <xsd:anyURI rdf:value="&BravoAirGroundingWSDL;#acctName"/> </grounding:wsdlMessagePart> </grounding:WsdlInputMessageMap> <grounding:WsdlInputMessageMap> <grounding:owlsParameter rdf:resource="&ba_process;#password_In"/> <grounding:wsdlMessagePart> <xsd:anyURI rdf:value="&BravoAirGroundingWSDL;#password"/> </grounding:wsdlMessagePart> </grounding:WsdlInputMessageMap> </grounding:wsdlInputs> <grounding:wsdlReference> <xsd:anyURI rdf:value="http://www.w3.org/TR/2001/NOTE-wsdl-20010315"/> </grounding:wsdlReference> </grounding:WsdlAtomicProcessGrounding> … 37
- 38. OWL-S Example – Bravo Air Service Grounding Ontology … <grounding:WsdlOperationRef rdf:ID="LogIn_operation”> <rdfs:comment>A pointer to the WSDL operation used for SelectAvailableFlight</rdfs:comment> <!-- locate port type to be used --> <grounding:portType> <xsd:anyURI rdf:value="&BravoAirGroundingWSDL;#LogIn_PortType"/> </grounding:portType> <!-- locate operation to be used --> <grounding:operation> <xsd:anyURI rdf:value="&BravoAirGroundingWSDL;#LogIn_operation"/> </grounding:operation> </grounding:WsdlOperationRef> … </rdf:RDF> 38
- 39. OWL-S Tool support • Reasoning – OWL-DL reasoners like Pellet and FaCT/FaCT++, – Rule-oriented extensions and embedded SWRL are used to overcome limitations of OWL-DL, as well as reasoners Racer and Kaon2, and – Possibility to use metareasoning. • Discovery – Match-making relies on the explicit specification of inputs and outputs, – Ontological relationships between the I/Os of “template” and a candidate services are compared, – A set of five filters classify structural relationships between the template and candidate I/Os – OWLS-MX matchmaker implements this classification and combines it with syntactic match – There is no full usage of IOPE-based matchmaking, neither discovery approach which takes into account behavioral aspects of the service 39
- 40. OWL-S Tool support • Choreography and Orchestration – OWL-S assumes invocation of services as atomic actions (choreography is not modeled) – Process-model allows services to be attached to the atomic but also composite processes thus allowing hierarchical control-flow oriented decomposition (i.e. ordering over atomic processes) – OWL-S VM is executes the atomic processes up to the completion of the composite process description. – OWL-S VM fulfills the basic role of an orchestration engine. • Mediation – No first-class support for data and process mediation. • Composition – Abstraction of service interactions to atomic ones and its simple model of composite processes are good fit to existing (AI planning-based) techniques. 40
- 41. OWL-S Relationship to WSMO • Underlying specification – OWL-S is specified using OWL, and WSMO uses abstract MOF model. • Language unification – OWL-S needs to combine OWL with more expressive languages (e.g. for expressing conditions and workflow constructs) while WSMO provides a single unified language framework. • Conceptual model similarities – OWL-S Service Profile is close to the capability of a service/goal in WSMO. • WSMO distinguishes requester’s and provider’s view – OWL-S Process Model is conceptually similar to the WSMO service/goal interfaces. • WSMO distinguishes between the external and internal behavior • OWL-S lacks mediation facilities • Grounding similarities – Both approaches adopt similar ideas with respect to binding to WSDL. • It is a top level concept in OWL-S and not in WSMO 41
- 42. OWL-S Criteria discussion • Web compliance – Supports URI, namespaces, XML • Ontology-based – Based on OWL • Strict decoupling – Ontologies and service descriptions can be specified independently • Centrality of mediation – No support for mediation • Ontological role separation – Doesn’t have notion of user desires • Description vs. implementation – OWL-S is a description framework based on appropriate formalisms in order to provide concise semantic descriptions • Execution semantics – Doesn’t have it • Service vs. Web services 42
- 43. Technical solution METEOR - S 43
- 44. METEOR-S Overall approach • METEOR-S3 project defines semantics for the complete lifecycle of Semantic Web processes including annotation, discovery, composition and enactments of Web Services. • It is strongly coupled with existing Web Services standards, thus extending them with semantics. • As opposed to the top-down approach embraced by WSMO and OWL- S, the project is promoting bottom-up approach. • Conceptual model is simple and quite generic – Relying on Semantically Annotated WSDL (explained in next slides). • Based on this simple model the project is providing a set of tools – Web Service Annotation Framework, – Web Service Discovery Infrastructure, – Web Service Composition Framework. 3 http://lsdis.cs.uga.edu/projects/meteor-s 44
- 45. METEOR-S Conceptual Model • The central point of METEOR-S approach is Semantically Annotated WSDL (SAWSDL) • It is a way to add semantic annotations to various parts of a WSDL document – Input and output message structures, interfaces and operations. • Relying to simple extension attributes – Compliant to WSDL v2.0 and v1.1, and XML Schema • Annotations can be used for various purposes: – WSDL interfaces and operations with categorization information used to advertise Web services – XML Schema types to foster discovery and composition – Specifying the data mapping of XML Schema to/from an ontology used during invocation (possible mediation) • Independent on the ontology expression language and mapping languages 45
- 46. METEOR-S Conceptual Model • Extension attributes of SAWSDL are: – modelReference • Pointers to a concept in some semantic model. • Annotates XML Schema type definitions, element declarations, and attribute declarations, WSDL interfaces, operations, and faults. – liftingSchemaMapping • Added to XML Schema element declarations and type definitions for specifying lifting mappings between semantic data and XML. – loweringSchemaMapping • Added to XML Schema element declarations and type definitions for specifying lowering mappings between semantic data and XML. 46
- 47. METEOR-S Example <wsdl:description targetNamespace="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#" xmlns=http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order# xmlns:wsdl=http://www.w3.org/ns/wsdl xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns:sawsdl="http://www.w3.org/ns/sawsdl"> <wsdl:types> <xs:schema targetNamespace=http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order# elementFormDefault="qualified"> <xs:element name="OrderRequest" sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder#OrderRequest" sawsdl:loweringSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/mapping/RDFOnt2Request.xml"> <xs:complexType> <xs:sequence> <xs:element name="customerNo" type="xs:integer" /> ... </wsdl:description> 47
- 48. METEOR-S Tools • Web Service Annotation Framework4 for semiautomatic annotation of Web Services' semantics addressing four different aspects: – Semantics of the inputs and outputs of Web Services, – Functional semantics (“what service does”), – Execution semantics to support verification of the correctness of the Web Service executions, and – Inclusion of information regarding the quality of service (performance, costs, …). • Semiautomatic annotation is based on – Transformation of both XML Schema part of Web Service definitions and ontologies into a common representation – SchemaGraph, and – Matching algorithms which compute “match score” between the SchemaGraph elements. • The framework comprises: – Ontology store – ontologies to be used during Web Service annotation, – Matcher library – algorithm implementations for linguistic and structural matching and – Translator library – SchemaGraph generation procedures. 48
- 49. METEOR-S Tools – Annotation Framework - Example Taken from Abhijit Patil et al. METEOR-S Web service Annotation Framework, Proceeding of the World Wide Web Conference, July 2004 49
- 50. METEOR-S Tools • Web Service Discovery Infrastructure – Attempts to enhance Web Service discovery infrastructure by using semantics, – Relies strongly on the existing UDDI Web Service registries, – Unifies access to the Web Service registries and ontology registries over P2P infrastructure. – User is expressing his requirements through the Service Templates which specify the inputs and outputs using concepts from the registered domain specific ontologies. – Semantic matchmaking is performed between the SAWSDL-enriched service descriptions and the Service Templates. • Web Service Composition Framework – Web Service Composition Framework (MWSCF) aims to increase the flexibility of WS compositions by relying on semantic process templates. – Template defines process in terms of semantically defined activities (BPEL control- flow constructs with activities). – Template is used to generate executable processes by binding the semantically defined activities to concrete WS. 50
- 51. METEOR-S Tools – Composition Framework - Example Figure taken from Sivashanmugam, K., et al. Framework for Semantic Web Process Composition, Special Issue of the International Journal of Electronic Commerce (IJEC), Eds: Christoph Bussler, Dieter Fensel, Norman Sadeh, Feb 2004 51
- 52. METEOR-S Relationship to WSMO • With its minimalistic approach can be viewed as orthogonal to WSMO, • It can reference WSMO descriptions from its annotations, • All the SAWSDL referenced concepts can be annotated in WSML/WSMO. • SAWSDL doesn’t clearly establish how requests should be defined – Usage of different languages hinder possibility to formally define requests, queries or notions of a “match” between service requests and service descriptions. • Other WSMO supported notions such as nonfunctional properties and behavioral/interface descriptions should be addressed by the initiative in the same manner (i.e. extending WS-Policy, BPEL or WS-CDL with lightweight notions). • SAWSDL has a strong industrial point – WSMO/L/X working groups are looking at closer alignment with industry standards and adoption of SAWSDL as a possible future grounding formalism for WSMO. 52
- 53. METEOR-S Criteria discussion • Web compliance – Supports URI, namespaces, XML • Ontology-based – Based on DAML and RDF-S • Strict decoupling – Ontologies and service descriptions can be specified independently, connected through SAWSDL annotations • Centrality of mediation – No support for mediation • Ontological role separation – Doesn’t have notion of user desires • Description vs. implementation – Follows a much more technology centered approach, not providing a conceptual model for the description of services and their related aspects • Execution semantics – Doesn’t have it • Service vs. Web services 53
- 54. Technical solution Semantic Web Services Framework (SWSF) 54
- 55. SWSF Overall Approach • Semantic Web Services Framework (SWSF) has its roots in OWL-S and the Process Specification Language (PSL). • It is based on two major components: – Ontology (Conceptual Model) • First-Order Logic Ontology for Web Services (FLOWS), and • Rules Ontology for Web Services (ROWS) – Language • SWSL-FOL, and • SWSL-Rules. • It is a complex solution which hasn’t received much of the attention in the community • General lack of tool support • Comprehensive examples are missing 55
- 56. SWSF Conceptual Model • Semantic Web Service Ontology (SWSO) – Influenced by OWL-S (shares the same 3 concepts), – Extension/refinement of OWL-S. • Underlying language (SWSL) is more expressive, and • Richer behavioral process model based on PSL. • Two independent formalizations of the conceptual model – First-order Logic Ontology for Web Services (FLOWS), and • Relies on the semantic of SWLS-FOL – Rule Ontology for Web Services (ROWS) • Relies on the semantics of SWLS-Rules. • In order to describe behavior of a service based on PSL approach two fundamental elements are added: – Structured notion of atomic processes, and – Infrastructure for specifying various forms of data flow. 56
- 57. SWSF Relationship to WSMO • From the conceptual model point of view the same consideration apply like in the case of OWL-S. • Many of the deficiencies of OWL-S have been overcome in SWSL: – Not being bound to the restricted expressivity of DL, – Providing rigid definitions of semantic aspects of conditions and dynamic aspects of SWS by reuse of PSL, and – Providing an single semantic language framework. 57
- 58. SWSF Criteria discussion • Web compliance – Supports URI, namespaces, XML • Ontology-based • Strict decoupling – Not supported • Centrality of mediation – No support for mediation • Ontological role separation – Doesn’t have direct notion of user desires • Description vs. implementation – Provides serialization/deserialization mechanisms to/from WSDL • Execution semantics – Doesn’t have it • Service vs. Web services 58
- 59. Technical solution Internet Reasoning Service - III 59
- 60. Internet Reasoning Service (IRS-III) Overall Approach • IRS III is a framework and implemented infrastructure which supports the creation of Semantic Web Services according to the WSMO ontology • Builds upon the previous version (IRS-II) by incorporating and extending the WSMO ontology within the IRS-III server, browser and API. 60
- 61. Internet Reasoning Service (IRS-III) Principal Characteristics • Ontological separation of User and Web Service Contexts – Consumer and service exist in their own contexts which should be modeled with distinct ontological structures. • Capability Based Invocation – Users can invoke a Web Service by specifying a concrete desired capability. Semantic descriptions in IRS-III are operational. • Ease of Use – Interfaces are designed to hide the complexities surrounding the creation of SWS-based applications. • One Click Publishing – Stand alone code written in a standard programming language (Java or LISP) can be turned into a Web Service by only one-click. • Agnostic to Service Implementation Platform – IRS-III is not making strict assumptions about the underlying service implementation platform. – It accepts the current dominance of Web Service stack of standards. 61
- 62. Internet Reasoning Service (IRS-III) Principal Characteristics • Connected to External Environment – Functions and relations can make extra logical calls (e.g. invoking a Web Service) which results can be integrated smoothly with the internal reasoning. • Open – IRS-III clients are based on publicly accessible Java APIs, components of the IRS-III server are Semantic Web Services which fosters flexibility. • Complete Descriptions – Data which can be represented is represented. It is not possible a priori to know which specific data will be required for SWS related reasoning. • Inspectable – Making the semantic descriptions accessible in a human readable form. The key is that the content and form are easily understandable by SWS application builders. • Interoperable with SWS Frameworks and Platforms – IRS-III has an OWL-S import mechanism. It is interoperable with the WSMO reference implementation WSMX. 62
- 63. Internet Reasoning Service (IRS-III) Features • Based on SOAP messaging standard • Provides Java API for client applications • Provides built-in brokering and service discovery support • Provides capability-centred service invocation • Publishing support for variety of platforms – Java, Lisp, Web Applications, Java Web Services • Enables publication of ‘standard code’ – Provides clever wrappers – One-click publishing of web services • Integrated with standard Web Services world – Semantic web service to IRS – ‘Ordinary’ web service 63
- 64. Internet Reasoning Service (IRS-III) Architecture Web Service J Publishing Platforms Java Code WSMX a Web Application v S SOAP WS Publisher a Browser O Registry Browser Handler Publisher OCML SOAP Publishing Clients A Handler Handler Invocation WSMO Library A P Handler IRS-III Server Invocation P LispWeb Server Client I OWL(-S) OWL(-S) Handler Figures taken from John Domingue at al. Demo of IRS-III: A Platform and Infrastructure for Creating WSMO-based Semantic Web Services, Demo from ISWC 2004 64
- 65. Internet Reasoning Service (IRS-III) Comparison with WSMX • Underlying language – In WSMX underlying language is WSML, while in IRS-III it is OCML. • Goals – In IRS-III goals have inputs and outputs while in WSMX they have pre- and post- conditions. • Discovery mechanism – IRS-III broker is finding applicable Web Services via mediators • Used mediator within WS capability • Mediator source = goal • WSMX doesn’t provide One-click-publishing 65
- 66. Summary WSMO OWL-S METEOR-S SWSF Web compliance √ √ √ √ Ontology-based √ √ √ √ Strict decoupling √ √ √ - Centrality of mediation √ - - - Ontological role separation √ - - - Description vs. implementation √ √ - √ Execution semantics √ - - - Services vs. Web services √ √ √ √ 66
- 67. References • Mandatory reading: – Dieter Fensel, Mick Kerrigan, Michal Zaremba (Eds.), Implementing Semantic Web Services: The SESA Framework. Springer-Verlag, 2008. (Chapter 13) • Further reading: – David Martin, et al., OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004, http://www.w3.org/Submission/OWL-S. – Joel Farrell and Holger Lausen, Semantic Annotations for WSDL and XML Schema, W3C Recommendation 28 August 2007, http://www.w3.org/TR/sawsdl – Dieter Fensel, Holger Lausen, Axel Polleres, Jos de Bruijn, Michael Stollberg, Dumitru Roman, John Domingue, Enabling Semantic Web Services: The Web Service Modeling Ontology, Springer-Verlag, 2007. – Steve Battle et al., Semantic Web Services Framework (SWSF), W3C Member Submission 9 September 2005, http://www.w3.org/Submission/SWSF – Sivashanmugam, K., et al. Framework for Semantic Web Process Composition, Special Issue of the International Journal of Electronic Commerce (IJEC), Eds: Christoph Bussler, Dieter Fensel, Norman Sadeh, Feb 2004 – Abhijit Patil, Swapna Oundhakar, Amit Sheth, Kunal Verma, METEOR-S Web service Annotation Framework, Proceeding of the World Wide Web Conference, July 2004 (Proceeding of the World Wide Web Conference, July 2004) http://lsdis.cs.uga.edu/lib/download/POSV-WWW2004.pdf – Verma, K., Sivashanmugam, K. , Sheth, A., Patil, A., Oundhakar, S. and Miller, J. METEOR–S WSDI: A Scalable P2P Infrastructure of Registries for Semantic Publication and Discovery of Web Services , Journal of Information Technology and Management, 2004. http://lsdis.cs.uga.edu/lib/download/VSS+03-TM06-003-METEOR-S-WSDI.pdf 67
- 68. References • Wikipedia and links – Semantic Web Services http://en.wikipedia.org/wiki/Semantic_Web_Services – OWL-S http://en.wikipedia.org/wiki/OWL-S – WSDL-S http://en.wikipedia.org/wiki/Web_Services_Semantics 68
- 69. Next Lecture # Title 1 Introduction 2 Web Science 3 Service Science 4 Web services 5 Web2.0 services 6 Semantic Web 7 Web Service Modeling Ontology (WSMO) 8 Web Service Modeling Language (WSML) 9 Web Service Execution Environment (WSMX) 10 OWL-S and others 11 Light-weight Annotations 12 Applications 13 Mobile Services 69
- 70. Questions? 70
Editor's Notes
- #10: Semantic Web services are aimed at producing an integrated technology for the next generation of the Web by combining Semantic Web technologies and Web services, thereby turning the Internet from a information repository for human consumption into a worldwide system for distributed Web computing. Therefore, appropriate frameworks for Semantic Web services need to integrate the basic Web design principles, the design principles defined for the Semantic Web, and design principles for distributed, service-oriented computing on the Web.
- #24: Functional Description An essential component of the profile is the specification of what functionality the service provides and the specification of the conditions that must be satisfied for a successful result. In addition, the profile specifies what conditions result from the service, including the expected and unexpected results of the service activity. The OWL-S Profile represents two aspects of the functionality of the service: the information transformation (represented by inputs and outputs) and the state change produced by the execution of the service (represented by preconditions and results). For example, to complete the sale, a book-selling service requires as input a credit card number and expiration date, but also the precondition that the credit card actually exists and is not overdrawn. The response of the sale is the output of a receipt that confirms the proper execution of the transaction, and as result the transfer of ownership and the physical transfer of the book from the warehouse of the seller to the address of the buyer. The Profile ontology does not provide a schema to describe IOPE instances. However, such a schema exists in the Process ontology, as discussed in the next section. Ideally, we envision that the IOPE's published by the Profile are a subset of those published by the Process. Therefore, the Process part of a description will create all the IOPE instances and the Profile instance can simply point to these instances. In this case a single instance is created for any IOPE, unlike in previous versions of OWL-S when, for a certain IOPE, an instance was created both in the Profile and Process part of the OWL-S description. However, if the IOPE's of the Profile are different from those of the Process, the Profile can still create its own IOPE instances using the schema offered by the Process ontology. The functional description of the service is expressed in terms of the transformation produced by the service. Specifically, it specifies the inputs required by the service and the outputs generated; furthermore, since a service may require external conditions to be satisfied, and it has the effect of changing such conditions, the profile describes the preconditions required by the service and the expected effects that result from the execution of the service. For example, a selling service may require as a precondition a valid credit card and as input the credit card number and expiration date. As output it generates a receipt, and as effect the card is charged.
- #25: The two properties, serviceClassification and serviceProduct , are used to specify the type of service provided and the products that are handled by the service. The values of the two properties are instances of classes specified in OWL ontologies of services and products. The properties serviceClassification and serviceProduct are similar to serviceCategory described above, but they differ in that the values of the properties are OWL instances rather than strings referring to some non-OWL business taxonomy.
- #32: The grounding of a service specifies the details of how to access the service - details having mainly to do with protocol and message formats, serialization, transport, and addressing. A grounding can be thought of as a mapping from an abstract to a concrete specification of those service description elements that are required for interacting with the service - in particular, for our purposes, the inputs and outputs of atomic processes. Note that in OWL-S, both the ServiceProfile and the ServiceModel are thought of as abstract representations; only the ServiceGrounding deals with the concrete level of specification. OWL-S does not include an abstract construct for explicitly describing messages. Rather, the abstract content of a message is specified, implicitly, by the input or output properties of some atomic process. Thus, atomic processes, in addition to specifying the basic actions from which larger processes are composed, can also be thought of as the communication primitives of an (abstract) process specification. Concrete messages, however, are specified explicitly in a grounding. The central function of an OWL-S grounding is to show how the (abstract) inputs and outputs of an atomic process are to be realized concretely as messages, which carry those inputs and outputs in some specific transmittable format. Due to the existence of a significant body of work in the area of concrete message specification, which is already well along in terms of industry adoption, we have chosen to make use of the Web Services Description Language (WSDL) in crafting an initial grounding mechanism for OWL-S. As mentioned above, our intent here is not to prescribe the only possible grounding approach to be used with all services, but rather to provide a general, canonical and broadly applicable approach that will be useful for the great majority of cases. The approach described here allows a service developer, who is going to provide service descriptions for use by potential clients, to take advantage of the complementary strengths of these two specification languages. On the one hand (the abstract side of a service specification), the developer benefits by making use of OWL-S' process model, and the expressiveness of OWL's class typing mechanisms, relative to what XML Schema Definition (XSD) provides. On the other hand (the concrete side), the developer benefits from the opportunity to reuse the extensive work done in WSDL (and related languages such as SOAP), and software support for message exchanges based on these declarations, as defined to date for various protocols and transport mechanisms. AN OWL-S/WSDL grounding is based upon the following three correspondences between OWL-S and WSDL: AN OWL-S atomic process corresponds to a WSDL (1.1) operation . Different types of operations are related to OWL-S processes as follows: An atomic process with both inputs and outputs corresponds to a WSDL request-response operation. An atomic process with inputs, but no outputs, corresponds to a WSDL one-way operation. An atomic process with outputs, but no inputs, corresponds to a WSDL notification operation. A composite process with both outputs and inputs, and with the sending of outputs specified as coming before the reception of inputs, corresponds to WSDL's solicit-response operation. 5 Note that OWL-S grounding doesn't mandate a one-to-one correspondence between an atomic process and a single WSDL operation (although that is the most normal case). To accommodate the WSDL-supported practice of providing multiple definitions (within different port types) of the same operation, OWL-S allows for a one-to-many correspondence between an atomic process and multiple WSDL operations. It is also possible, in these situations, to maintain a one-to-one correspondence, by using multiple (differently named) atomic processes. 2. The set of inputs and the set of outputs of an OWL-S atomic process each correspond to WSDL's concept of message . More precisely, OWL-S inputs correspond to the parts of an input message of a WSDL operation, and OWL-S outputs correspond to the parts of an output message of a WSDL operation. 3. The types (OWL classes) of the inputs and outputs of an OWL-S atomic process correspond to WSDL's extensible notion of abstract type (and, as such, may be used in WSDL specifications of message parts).
- #40: OWL-S MX http://www-ags.dfki.uni-sb.de/~klusch/owls-mx
- #41: OWL-S VM http://www.semwebcentral.org/projects/owl-s-vm
- #49: For more information take a look at
- #52: Steps to take: 1. The WSDL description for the desired process is generated using a WSDL editor. The process template will be linked to this file. 2. A process template is opened or created in the process designer. 3. Activities are added to the template and control flow constructs are added to the templates (if needed). 4. Activities may be semantically annotated using two XML files representing discovery details and QoS specifications are linked to them. 5. Services are discovered (using discovery criteria), ranked (using semantic matching and QoS criteria) and selected for each activity. 6. Data flow between services is established (based on the selected service). 7. The executable process is generated by the process generator using the WSDL of the process, the process template and the WSDL files of the participating services. 8. The process is validated, deployed and it is ready for invocation.
- #56: The promise of Web services and the need for widely accepted standards enabling them are widely recognized, and considerable efforts are underway to define and evolve standards in the commercial realm such as WSDL, BPEL4WS, WS-Choreography and UDDI. SWSL is used to specify formal characterizations of Web service concepts and descriptions of individual services. It includes two sublanguages. FLOWS is an axiomatized ontology of service concepts, which provides the conceptual framework for describing and reasoning about services. FLOWS draws many of its intuitions and lessons-learned from OWL-S. A key contribution of the FLOWS ontology is the development of a rich behavioural process model, based on ISO 18629 Process Specification Language (PSL). PSL provides the ideal foundation for interoperability among emerging Web service process models, while supporting the realization of automation task associated with the Semantic Web Service vision. FLOWS goes beyond PSL in modeling many Web-service specific process concepts including messages, channels, inputs and outputs. FLOWS is designed modularly. It comprises an ontology for service descriptors, somewhat akin to a domain-independent yellow-pages or OWL-S service profile, an extensive process model ontology, and a grounding that relates the process model message types to WSDL messages. The process model ontology is in turn comprised of a core ontology and a number of extensions. SWSL is a general-purpose logical language, with certain features to make it usable with the basic languages and infrastructure of the Web. These features include URIs, integration of XML built-in types, and XML-compatible namespace and import mechanisms. SWSL includes two layers of expressiveness: SWSL-FOL and SWSL-Rules. SWSL-FOL is a first-order logic. SWSL-Rules is a full-featured logic programming (LP) language. Nearly all the elements of the syntax are common to both SWSL-FOL and SWSL-Rules, so as to promote the ability of developers to easily work with both layers, and to facilitate various kinds of interchange and interoperation between the layers. The presentation syntax is designed for readability, and incorporates a number of convenience features, such as an object-oriented style of presentation, which can be used to improve code organization and comprehensibility, but without changing the expressiveness and tractability of the underlying logical systems. An XML-based serialization syntax, based on RuleML, is also specified.
- #62: Clean Ontological Separation of User and Web Service Contexts The starting point for our design is that web services are invoked by clients. A client may be a human end user invoking a web service for personal use, an employee of an organisation or a software program. In each case the client will exist in its own context which should be modelled within the semantic descriptions. This context will be quite different from that of the web service. For example, a personal end user may request a holiday with a preference for a certain climate, a location near particular cultural artefacts and amenable to children of a specific age range. The required flights and hotel booking web services will be described using concepts such as city and available date. Our view is that distinct ontological structures are required to describe potential users and web services. Moreover, within the IRS the independence between user desires and ontology means that we can specify user desire which may not in principle be satisfiable, even in principle, by a web service – for example “I want to be the UK Prime Minister”. Ontological role separation is also a principle which underlies WSMO [Feier, 2004]. Capability Based Invocation Building on the principle above we enable clients (human users or application programs) to invoke a web service simply by specifying a concrete desired capability. The IRS acts as a broker finding, composing and invoking appropriate web services in order to fulfil the request. Implementing this principle relies on the fact that the semantic descriptions with the IRS are operational . Ease of Use We have designed the IRS interfaces so that much of the complexity surrounding the creation of SWS based applications is hidden. For example, the IRS-III browser hides some of the complexity of underling ontology by bundling up related class definitions into a single tabbed dialog window. One Click Publishing A corollary of the above design principle. We have many users who have an existing system which they would like to be made available but have no knowledge of the tools and processes involved in turning a stand alone program into a web service. We therefore created the IRS so that it supports ‘one click’ publishing of stand alone code written a standard programming language (currently we support Java and Lisp) and of applications available through a standard web browser. Agnostic to Service Implementation Platform This principle is in part a consequent of the one-click-publishing principle. Within the design of the IRS we make no strong assumptions about the underlying service implementation platform. We do however accept the current dominance of the web services stack of standards and consequently program components which are published through the IRS also appear as standard web services with a SOAP based end-point.
- #63: Connected to the External Environment When manipulating web services, whether manually or automatically, one needs to be able to reason about their status. Often this information needs to be computed on-the-fly in a fashion which integrates the results smoothly with the internal reasoning. To support this we allow functions and relations to be defined which make extra-logical calls to external systems – for example, invoking a web service. Although, this design principle has a negative effect on the ability to make statements about the formal correctness of resulting semantic descriptions, it is necessary because our domain of discourse includes the status of web services. For example, a user may request to exchange currencies using “today’s best rate”. If our representation environment allows us to encode a current-currency-rate relation which makes an external call to an appropriate web service then this will not only make life easier for the SWS developer but the resulting descriptions will be more readable. Open Our aim is to make IRS-III as open as possible. The IRS-III clients are based on Java APIs which are publicly accessible. More significantly, components of the IRS-III server are semantic web services represented within the IRS-III framework. This feature allows our users to replace the main parts of the IRS broker with their own web services to suit their own particular needs. Complete Descriptions Our view is that any data which can be represented is. This principle also holds for other SWS frameworks. For example, OWL-S [OWL-S, 2002] has a grounding and non functional properties. Nevertheless, we believe that this dimension is important enough to stress. It is not possible a priori to know which specific data will be required for SWS related reasoning. Inspectibility In many parts of the life cycle of any software system it is important that the developers are able to understand the design and behaviour of the software being constructed. This is also true for SWS applications. This principle is concerned with making the semantic descriptions accessible in a human readable form. The descriptions could be within a plain text editor or within a purpose built browsing or editing environment. The key is that the content and form are easily understandable by SWS application builders. Interoperable with SWS Frameworks and Platforms One of the main aims for web services is to enable the interoperability of programs over the internet. A reasonable extension of this is that as far as possible SWS frameworks and platforms also should be interoperable. For this reason IRS-III has an OWL-S import mechanism [Hakimpour et al., 2004] and is interoperable with the WSMO reference implementation WSMX (see www.wsmx.org ).
- #64: IRS-III has four main classes of features which distinguish it from other work on semantic web services 1. it supports one-click publishing of ‘standard’ programming code , i.e. it automatically transforms programming code (currently we support Java and Lisp environments) into a web service, by automatically creating the appropriate wrapper. 2. by extending the WSMO goal and web service concepts users of IRS-III directly invoke web services via goals i.e. IRS-III supports capability-driven service execution. 3. IRS-III is programmable. IRS-III users can substitute their own semantic web services for some of the main IRS-III components 4. IRS-III services are web service compatible – standard web services can be trivially published through the IRS-III and any IRS-III service automatically appears as a standard web service to other web service infrastructures.
- #65: The IRS-III architecture is composed of the main following components: the IRS-III Server, Publisher and Client, which communicate through a SOAP-based protocol. The IRS-III Server is based on an HTTP server written in lisp which has been extended with a SOAP handler. Separate modules handle soap based requests from the browser, the publishing platforms and the invocation client. Messages result in a combination of queries to or changes within the entities stored in the WSMO library. Publishing with IRS-III entails associating a deployed web service with a WSMO web service description. Within WSMO a web service is associated with an interface which contains an orchestration and choreography. Orchestration specifies the control and dataflow of a web service which invokes other web services (a composite web service). Choreography specifies how to communicate with a web service. When a web service is published in IRS-III all of the information necessary to call the service, the host, port and path are stored within the choreography associated with the web service. Additionally, updates are made to the appropriate publishing platform. IRS-III contains publishing platforms to support the publishing of standalone Java and Lisp code and of web services. Web applications accessible as HTTP GET requests are handled internally by the IRS-III server. IRS-III was designed for ease of use, in fact a key feature of IRS-III is that web service invocation is capability driven. The IRS-III Client supports this by providing a goal-centric invocation mechanism. An IRS-III user simply asks for a goal to be solved and the IRS-III broker locates an appropriate web service semantic description and then invokes the underlying deployed web service.