IV Lezione. Web Services Semantic Web Services OWL-S Discovery Composition

Transcript

1 IV Lezione s s

2 Dal Statico al Computing Inizialmente pagine HTML dinamiche (CGI Common Gateway Interface); Successivamente: s duzione di linguaggi di scripting (JavaScript) in HTML; Ampliamento delle potenzialità di elaborazione lato server attraverso linguaggi integrati con il Server stesso (JSP, PHP, ASP, ) dando luogo a quelli che sono oggi più propriamente noti come Application Server; Utilizzo del web come piattaforma applicativa che oggi trova la sua massima espressione nei. HTML CGI JavaScript JSP, PHP, ASP statico dinamico computing

3 s Search Authentication Inter-library loan request Document Translation Payment s Il web abilita alla connessione di utenti ad applicazioni rese disponibili I web services abilitano Internet Digital Library Application alla connessione di applicazioni ad altre distribuite e disponibili in rete (from B2C to B2B).

4 Interoperabilità a s Il offre sia un linguaggio per definire ontologie (OWL) sia un linguaggio per l interscambio di metadati (RDF), ma l interoperabilità semantica richiede la definizione di un modello concettuale che supporti la descrizione di tutti i processi di una SOA realizzata tramite s. Mismatching: Content Level Il Provider restitusce il valore Pennsylvania, ma il richiedente comprende solo il codice dello stato composto da 2 lettere(i.e. PA); Attribute level Il richiedente necessita di un informazione climatica riguardante la pioggia ma il provider fornisce informazioni relative alle precipitazioni; Units of Measure Il richiedente ha valori in inches, ma il provider li richiede in cm; Message level Il richiedente ha length & width, ma il provider richiede l area;

5 verso i s services e loro composizioni in Processes ampliano le potenzialità di ecommerce and es; Il supporto a Processes su scala introduce una serie di sfide in merito alla gestione di heterogeneity / integration, scalability, dynamic environment e performance; Le tecnologie semantiche rivestono un ruolo chiave in tal senso; La tendenza è aggiungere la semantica ai s e sfruttarla in Process Lifecycle, cioè: Specification,,, Execution.

6 s s services are a new breed of application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the. services perform functions, which can be anything from simple requests to complicated business processes. Once a service is deployed, other applications (and other services) can discover and invoke the deployed service. IBM web service tutorial

7 s Caratteristiche Principali s Modular: unità di computazione riutilizzabile ed eventualmente componibile in componenti software più complessi e articolati; Available: i Servizi devono essere esclusivamente esposti indipendententemente dal particolare paradigma che utilizzano. Described: sono dotati di una descrizione machinereadable utilizzabile per identificare l interfccia del servizio web. Implementation-independent; Published: le descrizioni del servizio sono depositate in appositi repository dove utenti possono trovarli ed attraverso tale descrizione possono accedervi.

8 Architecture s

9 s Attori, Protocolli e Operazioni s Protocolli standard XML-based: Simple Object Access Protocol (SOAP); Universal Description Language (UDDI); s Description Language (WSDL). Attori: Fornitore; Broker Consumatore. Operazioni: Pubblicazione; Registrazione; Fruizione. UDDI Consumer Find Points to description Points to SOAP Comunicate with XML Messages WSDL Describes

10 s Protocols SOAP a framework for exchanging XML-based information in a network WSDL: s Description Language s Interface (what): abstract model of the service. Interface binding (how): binds the abstract model to a concrete protocol. Implementation (where): Access point of the service. UDDI: Universal Description, and Integration types: Contain abstract services and link to the Description interfaces. Several business can offer the same type of interface providers: associate businesses to the service types. Categorization: classification of the businesses and their service types

11 s Syntax only! UDDI Points to description WSDL s Find Points to Describes Consumer SOAP Comunicate with XML Messages s = Technology + Technology

12 Dove esplicitare la semantica s Abilitare meccanismi di discovery caratterizzati da alta precisione e ranking efficace da utilizzare non solo per il discovery di servizi semplici, ma anche per il discovery di servizi composti e di servizi in grado di compensare gli effetti di uno o più servizi invocati Catturare il comportamento del servizio in termini di proprietà funzionali e non funzionali del servizio Abilitare la composizione di servizi e monitorarne l esecuzione Applicare trasformazioni a livello di dati e al livello di protocollo per adattare servizi non immediatamente compatibili

13 s - Benefici s Automazione parziale del processo di utilizzazione dei s: Publication: rendere disponibile la descrizione del servizio in termini di capacità di computazione offerte; : localizzare l insiememe di servizi adattabili a un dato compito; Selection: scegliere I servizi maggiormente appropriati fra quelli disponibili; : combinare servizi eterogenei in un processo computazionale composto; Mediation: risolvere i mismatches (data, protocol, process) tra le entità combinate; Execution: invocare I servizi seguendo un approccio basato sulle tecniche di programmazione convenzionali; Monitoring: controllare il processo di esecuzione; Compensation: fornire un supporto oculato, intelligente in grado di revocare o mitigare effetti indesiderati; Replacement: facilitare il rimpiazzamento tra servizi equivalenti per risolvere eventuali situazioni critiche.

14 s Requisiti s Occorre: Descrivere tutte le informazioni necessarie ad abilitare l automazione di: Execution, etc. Utilizzare le ontologie e i linguaggi ontologici, dunque I formalismi del ; Garantire la registrazione e la reperibilità delle descrizioni semantiche dei servizi; Disporre di tools e piattaforme di supporto a: discovery Strategie di matchmaking; composizione Risoluzione dei mismatching; execution & monitoring Selezionare tenendo conto del QoS;

15 s s Le principali iniziative attive nel contesto dei s sono, è un ontologia dei servizi definita in OWL e SWRL Supportato dal programma DAML finanziato dalla DARPA Sottomesso al W3C nel Novembre del 2004., Modeling Ontology, Guidato da DERI e supportato da numerosi progetti europei Sottomesso al W3C è nel giugno 2005 WSDL-S, WSDL with Annotation, Un lavoro portato avanti in collaborazione da University of Georgia e IBM Sono in corso lavori per allinare e WSDL-S e per integrare WSDL-S nelle specifiche di WSDL 2.0 SWSF, Framework Supportato dalla Initiative Sottomesso al W3C nel settembre del L idea è completare (gli standard esistenti dei ), non competere

16 Approach s Markup for s - Un ontologia scritta in OWL per descrivere i servizi offerti usando s Abilitare l uso automatico di servizi discovery, composition, invocation,... L idea principale è non competere ma completare non intende rimpiazzare gli standard in uso ma modellare il semantic layer in aggiunta ad essi: usa WSDL per invocare service (Grounding) estende UDDI per service discovery (mapping /UDDI) Un approccio costruito su molte basi Description logic, AI planning, Workflow, Formal process modeling, Agents, services,

17 Approach (2) s fornisce: Un insieme di costrutti linguistici per descrivere: services in modo non ambiguo e machine-readable; services Capabilities; services Process Model; Mappare il web service Process Model sul WSDL per l invocazione; Un infrastruttura adeguata per supportare l interazione dei servizi sul : Descrizione delle capacità per abilitare il discovery capability-based dei WS; Descrizione del processo per comporre le attività di WS differenti; Mapping verso e da WSDL per l automazione dell invocazione dei WS;

18 è un ontologia espressa in OWL e su una proposta di linguaggio per esprimere regole (SWRL) costruito su OWL s

19 Supports Tasks che abilita: Automatic service discovery s Automated location of WSs that provide a particular service and adhere to requested constraints Automatic service invocation Automated execution of an identified WS by a computer program or agent Automatic service composition and interoperation Automatic selection, composition and interoperation of WSs to perform some task (e.g. arrangement for a conference) Automatic service execution monitoring Individual services and composition services generally require some time to execute completely It is useful to know the state of execution of services

20 Upper Ontology for s s Come funziona? il flusso di controllo Black/Grey/Glass Box view Specifica del protocollo messaggi astratti Che cosa fa? Specifica delle Capability Caratteristiche generali del servizio Quality of Classificazione in tassonomie di Servizi Come faccio ad utilizzarlo? Mapping su WSDL communication protocol (RPC, HTTP, ) marshalling/serialization trasformazione da/in OWL a/di XSD

21 Upper Ontology for s s Sono necessari 3 tipologie di informazioni semantiche del servizio: Che cosa fa? (cosa il provider deve fornire al cliente) La risposta si concretizza nel Profile che è usato per formalizzare l advertise del servizio offerto; Perciò ciascuna istanza della classe definita nell ontologia è relazionata ad una istanza della classe Profile attraverso la proprietà presents. Come funziona? La risposta si concretizza nel Process Model; Queste informazioni sono incluse istanziando la classe Model. Istanze della classe usano la proprietà describedby per riferirsi al Model del servizio. Come faccio ad utilizzarlo? Specificando il Grounding Un grounding associato ad un servizio fornisce in modo formalizzato la descrizione dei dettagli riguardanti il protocollo di trasporto da utilizzare. Istanze della classe riferiscono attraverso la proprietà supports ad istanze di Grounding.

22 Grounding Process Model Profile Upper Ontology for s Publication Cosa fa! s Simulation Verification Come lo uso! Selection Come lo fa! Invocation, Interoperation Monitoring, Recovery Development Deployment Use

23 Upper Ontology for s s The class provides an organizational point of reference for a declared service One instance of will exist for each distinct published service. The properties presents, describedby, and supports are properties of. The classes Profile, Model, and Grounding are the respective ranges of those properties. Each instance of presents a Profile description, that is describedby a Model description, and supports a Grounding description. The Profile provides the information needed to automatically discover a service, while the Model and Grounding, taken together, provide enough information to make use of a service, once found.

24 Upper Ontology for s The upper ontology for services specifies only two cardinality constraints: A service can be described by at most one service model s A grounding must be associated with exactly one service. It deliberately does not specify any minimum cardinality for the properties presents or describedby In principle, a service needs all three properties to be fully characterized; in some situations a partial characterization could be useful. Nor does it specify any maximum cardinality for presents or supports It can be useful for some services to offer multiple profiles and/or multiple groundings.

25 Example s <?xml version="1.0" encoding="iso "?> <!DOCTYPE uridef (View Source for full doctype...)> <rdf:rdf xmlns:rdf=" xmlns:rdfs=" xmlns:owl=" xmlns:service=" xmlns=" <owl:ontology rdf:about=""> <owl:versioninfo> </owl:versioninfo> <rdfs:comment>this ontology </rdfs:comment> <!-- Specifica degli imports necessari --> <owl:imports rdf:resource=".owl" /> </owl:ontology> <service: rdf:id="fullcongobuy"> <!-- Reference to the Profile --> <service:presents rdf:resource="profile_congo_bookbuying_" /> <!-- Reference to the Process Model --> <service:describedby rdf:resource="fullcongobuyprocessmodel" /> <!-- Reference to the Grounding --> <service:supports rdf:resource="fullcongobuygrounding" /> </service:> </rdf:rdf> Da:

26 IOPE Profile - Example s <profile:profile rdf:id="profile_full_congo_bookbuying_"> <service:presentedby rdf:resource="fullcongobuy" /> <profile:has_process rdf:resource="fullcongobuyprocessmodel" /> <profile:servicename>congo_bookbuying_agent</profile:servicename> <profile:textdescription> This agentified service provides the opportunity to browse a book selling site and buy books there </profile:textdescription> <profile:contactinformation rdf:resource="#congobuy_contacts" /> <profile:qualityrating rdf:resource="#congo-rating" /> QoS <profile:has_process rdf:resource="#fullcongobuyprocessmodel" /> <profile:hasinput rdf:resource="#bookname" /> <profile:hasoutput rdf:resource="#locatebookoutput" /> <profile:hasinput rdf:resource="#putincart" /> <profile:hasinput rdf:resource="#signininfo" /> <profile:hasinput rdf:resource="#deliveryaddress" /> <profile:hasinput rdf:resource="#packagingselection" /> <profile:hasinput rdf:resource="#deliverytypeselection" /> <profile:hasinput rdf:resource="#creditcardnumber" /> <profile:hasinput rdf:resource="#specifypaymentmethodcreditcardtype" /> <profile:hasinput rdf:resource="#creditcardexpirationdate" /> <profile:hasinput rdf:resource="#createacctinfo" /> <profile:hasoutput rdf:resource="#createacctoutput" /> <profile:hasprecondition rdf:resource="#profileexists" /> </profilehierarchy:bookselling> Da:

27 (Process) Model - Example s <process:processmodel rdf:id="expresscongobuyprocessmodel"> <service:describes rdf:resource="#expresscongobuy" /> <process:hasprocess rdf:resource="#expresscongobuy" /> </process:processmodel> <process:compositeprocess rdf:id="fullcongobuy"> <process:composedof> <process:sequence> <process:components rdf:parsetype="collection"> <process:atomicprocess rdf:about="#locatebook" /> <process:compositeprocess rdf:about="#congobuybook"/> </process:components> </process:sequence> </process:composedof> </process:compositeprocess> Da:

28 Profile s Profile: descrizione ad alto livello del servizio. Due principali usi: 1. Advertisements delle s capabilities (nonfunctional properties, QoS, Description, classification, etc.) 2. Richiesta del servizio, esibendo ( publishing ) un certo insieme di funzionalità ( capabilities )

29 Profile s The class Profile provides a superclass of every type of high-level description of a service provides one possible representation of a service profile through the class Profile, describing a service as a function of three basic types of information: What organization provides the service Contact information that refers to the entity that provides the service What function the service computes Specified in terms of: Inputs required by the service and outputs generated Preconditions required by the service and expected effects that result from the execution of the service A host of features that specify characteristics of the service The category of a given service The quality rating of the service (some services may be very good, reliable, and quick to respond) An unbounded list of service parameters that can contain any type of information

30 Profile vs. Model s The Profile and the Process Model play different roles during the transaction between services But they are two different representations of the same service and the input, output, precondition, and effects (IOPEs) of one are reflected in the IOPEs of the other does not dictate any constraint between Profiles and Process Models the two descriptions may be inconsistent without affecting the validity of the OWL expression

31 Profile Properties s Selected class and properties of the Profile

32 Profile Functionality Description s Generally the IOPE's published by the Profile are a subset of those published by the Process. The Process part of a description will create all the IOPE instances and the Profile instance can simply point to these instances. The Profile can create its own IOPE instances according to the schema in the Process ontology The Profile ontology defines the following properties of the Profile class: hasparameter hasinput hasoutput hasprecondition hasresult Specifies under what conditions the outputs are generated and what domain changes are produced during the execution of the service

33 Profile Additional Properties s serviceparameter An expandable list of properties that may accompany a profile description. The value of the property is an instance of the class Parameter serviceparametername Name of the actual parameter (e.g. the URI) sparameter Points to the value of the parameter within some OWL ontology. servicecategory Describes categories of services on the bases of some classification. The value of the property is an instance of the class Category categoryname taxonomy A reference to the taxonomy scheme (not necessarily an URL). value Points to the value in a specific taxonomy code Code associated to a taxonomy.

34 OWL (Process) Model s Process Model Descrizione delle attività del servizio Descrizione interna dei processi: Specifica il protocollo di interazione; Specifica i messaggi: riferimento ontologico del tipo di informazione transmessa; Facilitates Invocazione Composizione Monitoraggio dell esecuzione

35 Modelling s as Processes s A process is intended as a specification of the ways a client may interact with a service An atomic process is a description of a service that expects one (possibly complex) message and returns one (possibly complex) message in response. A composite process is one that maintains some state; each message the client sends advances it through the process. A process can have two sorts of purpose: 1. It can generate and return some new information. Information production is described by the inputs and outputs of the process. 2. It can produce a change in the world. This transition is described by the preconditions (which must all hold in order for the process to be successfully invoked) and effects of the process Preconditions and effects are represented as logical formulas (using languages more expressive than OWL: RuleML or OWL Rules Language)

36 (Process) Model Properties s Top level of the Process ontology

37 Model Simple Process Simple processes are not invocable and are not associated with a grounding They are conceived of as having single-step executions s Simple processes are used as elements of abstraction. A simple process may be used to provide: A view of (a specialized way of using) some atomic process The simple process is realizedby the atomic process A simplified representation of some composite process (for purposes of planning and reasoning). The simple process expandsto the composite process

38 Esempio di Atomic Process s Inputs / Outputs Result Precondition Condition Output Constraints Effect <process:atomicprocess rdf:id="login"> <process:hasinput rdf:resource="#acctname"/> <process:hasinput rdf:resource="#password"/> <process:hasoutput rdf:resource="#ack"/> <process:hasprecondition ismember(accname)/> <process:hasresult> <process:result> <process:incondition> <expr:swrl-condition> correctlogininfo(accname,password) </expr:swrl-condition> </process:incondition> <process:withoutput rdf:resource= #Ack > <valuetype rdr:resource= #LoginAcceptMsg > </process:withoutput> <process:haseffect> <expr:swrl-condition> loggedin(accname,password) </expr:swrl-condition> </process:haseffect> </process:result> </process:hasresult> </process:atomicprocess>

39 Model Composite Process s Composite processes are decomposable into other (non-composite or composite) processes Their decomposition can be specified by using control constructs A process can often be viewed at different levels of granularity, either as a primitive, undecomposable process or as a composite process. These are sometimes referred to as ``black box'' and ``glass box' views, respectively. When a composite process is viewed as a black box, a simple process can be used to represent it. A composite process is not a behavior a service will do, but behavior (or set of behaviors) the client can perform by sending and receiving a series of messages. If the composite process has an overall effect, then the client must perform the entire process in order to achieve that effect.

40 Esempio di Composite Process Airline Sequence BookFlight Flight Control Flow Links Specify order of execution s Data-Flow Links Specify transfer of data Perform Airline Depart Arrive Get Flights Flights Perform Flights Select Flight Flight Perform statements Specify the execution of a process

41 Model Control Constructs s Sequence Split A list of control constructs to be done in order. 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 The process consists of concurrent execution of a bunch of process components with barrier synchronization. Split+Join completes when all of its components processes have completed. 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. Choice Execution of a single control construct from a given bag of control constructs. Any of the given control constructs may be chosen for execution If-Then-Else Iterate Is an "abstract" class, serves as the common superclass of Repeat-While, Repeat- Until, and potentially other specific iteration constructs. Repeat-While and Repeat-Until Iterate until a condition becomes false or true, following the familiar programming language conventions.

42 Data Flow and Parameter Bindings s In composite processes we can have different type/pattern of data flow specifications The input to one process component can be obtained as one of the outputs of a preceding step. The outputs of a composite process may be derived from outputs of some of its components The convention adopted is that the source of a datum is identified when the user of the datum is declared (consumer-pull convention) If step 1 feeds step 3, this fact is specified in the description of step 3 rather than in the description of step 1 (the opposite is called producer-push convention).

43 Grounding s Grounding Fornisce la specifica a basso livello delle informazioni di accesso al servizio; Costruisce il mapping con WSDL riguardo la struttura del messaggio e il binding fisico; Model + Grounding costituiscono gli elementi necessari ad utilizzare un servizio; Specifica i protocolli di comunicazione, meccanismi di transporto, languaggi di comunicazione, ecc.

44 Grounding Providing details on how to interoperate/access the service s Protocol, message formats, serialization, A mapping from an abstract specification to a concrete realization How the abstract inputs and outputs of an atomic process are to be realized concretely as messages (which carry these inputs and outputs) WSDL as a possible grounding approach Exploiting the extensibility elements of WSDL

45 /WSDL Grounding Process Model Description Logic Based Types s Atomic Process Operation Inputs / Outputs Message Binding to SOAP, HTTP, etc. WSDL To construct an /WSDL grounding one must first identify, in WSDL, the messages and operations by which an atomic process may be accessed, and then specify correspondences

46 /WSDL Grounding s

47 /WSDL Grounding Airline Sequence BookFlight Flight s Perform Perform Airline Depart Arrive Get Flights Flights Flights Select Flight Flight Arrive Depart Airline Get Flights Op Flights Flights Select Flight op Flight WSDL

48 e UDDI s The main problem with UDDI is that it does not provide a capability representation language such as the Profile. But UDDI supports the location of information about a services, once it is known which service to use UDDI does not provide capability based search (impossible to locate a service on the basis of what problems it solves) and UDDI complement each other Integrate capability matching in the UDDI registry. Mapping of Profiles into UDDI service representations. A set of specialized UDDI TModels to store information that cannot be represented in the standard UDDI /UDDI provides all the functionalities provided by UDDI using exactly the same API; any UDDI can interact with it to retrieve information about available services. /UDDI supports capability matching by taking advantage of capability representation.

49 /UDDI Mapping CMU Matching è stato integrato in un server UDDI mappando parte di Profile nella struttura dati di UDDI. CMU UDDI server mette a disposizione s Le porte standard UDDI Publish/Inquiry Completa interoperabilità con qualsiasi client UDDI La Capability Port è a disposizione per richieste che sfruttano capability CMU UDDI è disponibile su matchmaker o su SemCentral Una variante del CMU UDDI è stato installato presso NTT UDDI Business Registry (il principale UDDI pubblico in Giappone)

50 /UDDI Mapping s

51 Conclusioni s supporta i principali processi di una SOA Permette di descrivere in modo formale le capabilities dei s Usando OWL/ è possibile implementare diverse tecniche di discovery Invocation È compatibile con i meccanismi di invocazione dei s Chiara separazione tra descrizione dei s e loro implementazione Composizione Permette di rappresentare in modo formale il processo implementato da dei s Il Process Model può essere utilizzato da sistemi di plannig per automatizzare la composizione Tutte le soluzioni sono pensate in stretta relazione con gli standard attuali per i s

52 Approach s is an ontology and conceptual framework to describe services and related aspects Based Modeling Framework (WSMF) is a SDK-Cluster Working Group A Conceptual Model for SWS A Formal Language for Execution Environment for

53 vs s Scelte condivise: Basati su un robusto modello concettuale per la specificazione di s; Preservare gli attuali standard in uso per i WS ma stabilire un add-on infrastrutturale ontology-based Principali differenze: separa gli elementi necessari a descrivere un servizio in Ontologies, services, Goals and Mediators; non differenzia la rappresentazione della richiesta utente dall advertise del servizio; raccomanda l uso di vocabolari di metadati noti ed ampiamente accettati per le proprietà non funzionali, come Dublin Core and Friend of a Friend (FOAF) metadata; Per definire espressioni logiche, fornisce una flessibile scelta tra SWRL, DRS e KIF; fornisce una famiglia di linguaggi per definire le regole (vedi Modeling Language); non affronta esplicitamente il problema della mediazione: delega l infrastruttura sottostante a gestirli; è chiaramente più maturo come approccio, mentre fornisce un modello concettuale più completo;

54 WSDL-S Approach s Idea Mapping di Input e Output Message Parts su un ontologia Problema: Gli elementi XML usati nei messaggi Input/Output non riflettono la semantica dei dati scambiati in un operazione eseguita tramite Stesso frammento di XML diversi usi Diversi frammento di XML stessi usi Soluzione: l utilizzo di metadati standard definiti in una ontologia (es. RosettaNet Business/Technical dictionary o ebxml Core Component catalog/dictionary) permette di assegnare un preciso significato ai dati scambiati Mapping delle Operations su un ontologia Problema: molto spesso operazioni con la stessa signature mettono a disposizioni funzionalità differenti Stesso messaggio diversi usi Diversi messaggi stessi usi Soluzione: anche in questo caso è possibile annotare semanticamente le operazioni per renderne esplicito il significato Aggiungere degli elementi per rappresentare pre-condizioni ed effetti/postcondizionidi ciascuna operazione

55 Prossimi step s Rilasciare diagrammi delle ontologie; Utilizzare una sintassi abbreviata è preferibile; Non estendere i concetti non necessari di FOAF o di altri schemi ereditati; Ontologia Dati Veicolo durre tassonomie Profilo utente: quanti km fai in media al mese; ti rechi a lavoro con l auto, etc.; Dati Veicolo: Euro 4, etc. Venerdì 29/10 1h di incontro per condividere quanto realizzato al primo task e valutare taluni problemi derivanti dall uso dei tool (Protégé, etc.)

56 Prossimi step s Se rispettiamo la scadenza del 29/10 E possibile produrre dei servizi di esempio Georeferenziare i servizi attraverso Geonames Parametrizzare i servizi rispetto alle funzionalità tipiche del Green Driving Collegare owl-s a tassonomie SKOS Collegare owl-s ad ontologie di dominio