Your SlideShare is downloading. ×
Sws Han
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sws Han


Published on

Introduction to Semantic Web Services. This slides show the current research efforts and trend in Semantic Web Services.

Introduction to Semantic Web Services. This slides show the current research efforts and trend in Semantic Web Services.

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Semantic Web Services: Challenges and Research Trend July, 2009 Prof. Sung-Kook Han Semantic Technology Research Grou Won Kwang Universuty
  • 2. Agenda Semantic Web Semantic Services Ontology Semantic Technology Web Documents Services / Agents Static Dynamic Information Resources Active Resources 2010-01-28 page 2
  • 3. Agenda  Review of Semantic Web Services Technologies  Web Services  Semantic Web Services  Approaches towards Semantic Web Services  OWL-S Coalition  Semantic Web Service Initiative  WSMO / WSML / WSMX  Discussion on Semantic Web Services  Future Trend  Cloud Computing 2010-01-28 page 3
  • 4. Review of Web Services
  • 5. Evolution of Web Technologies Web Applications Web Pages Applet XML Servlet SOAP JSP/ASP WSDL Web Services JDBC/ODBC UDDI HTTP HTML AJAX Services URL Folksonomy Semantic Web Web 2.0 StyleSheet RSS / ATOM XML RDF/S Semantic Web Content OWL Information Knowledge 2010-01-28 page 5
  • 6. Web Services Services Description Location Communication Web Services Web Services UDDI, WSDL, SOAP UDDI,WSDL,SOAP Semantic Web Dynamic Web Services Services UDDI,WSDL,SOAP Semantic Integration Web Services Semantic Web Static UDDI,WSDL,SOAP Resource ontology Current Web Web Services URL, HTML, HTTP UDDI,WSDL,SOAP Information Knowledge 2010-01-28 page 6
  • 7. Web Services Loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols.  Loosely coupled  Loosely coupled systems require a much simpler level of coordination and allow for more flexible reconfiguration.  Reusable software components  Web services are service components that allows developers to reuse the building blocks of a system created by others to assemble and extend them in new ways.  Semantically encapsulate discrete functionality  Web services are self-contained, self-describing modular applications.  Accessed programmatically  Web services certainly will be incorporated into other Web services and applications.  Distributed over the Internet  Web services make use of existing, ubiquitous transport protocols like HTTP. 2010-01-28 page 7
  • 8. Web Services Architecture Service Broker Service Registration: UDDI Web Services Repository  Find  Publish Service Description: WSDL Service Service Requester Provider  Bind Service Messaging: SOAP 2010-01-28 page 8
  • 9. Web Services Architecture Service Location Service Interface   Publish Services Search Service Return URL Service Requester  Request WSDL Service Provider Application Application Return WSDL A Web Service-B B Proxy C  Request Service WSDL Return Service Result SOAP Engine SOAP Engine 2010-01-28 page 9
  • 10. Example: On-Line Bookstore Customer Amazon-Korea Enterprise Bank 2010-01-28 page 10
  • 11. Example: Virtual Travel Agency Customer Virtual Travel Hotel Agency Airline Ticket Enterprise Rent a Car 2010-01-28 page 11
  • 12. Core Technologies for Web Services  XML (Extensible Markup Language): the basic foundation on which Web services are built provides a language for defining data and how to process it. XML represents a family of related specifications published and maintained by the World Wide Web Consortium(W3C)and others.  WSDL (Web Services Description Language): an XML-based technology, defines Web services interfaces, data and message types, interaction patterns, and protocol mappings.  SOAP (Simple Object Access Protocol): a collection of XML-based technologies, defines an envelope for Web services communication ─ mappable to HTTP and other transportsㅡand provides a serialization format for transmitting XML documents over a network and a convention for representing RPC interactions.  UDDI (Universal Description, Discovery, and Integration): a Web services registry and discovery mechanism, is used for storing and categorizing business information and for retrieving pointers to Web services interfaces Page 12 2010-01-28 kr
  • 13. SOAP Message SOAP Message The complete SOAP Message HTTP Headers Standard HTTP and SOAP HTTP Headers SOAP Envelope <Envelope> encloses payload SOAP Header <Header> encloses headers Headers Individual headers <Body> contains SOAP SOAP Body Message Name & Data Message Name & Data XML Encoded SOAP Message Name & Data 2010-01-28 page 13
  • 14. Message Exchange (1) message  One-way Client Webservice (1) request  Request-Response Client Webservice (2) response (1) message  Solicit-Response Client Webservice (2) correlated message (1) message  Notification Client Webservice 2010-01-28 page 14
  • 15. WSDL  XML document for describing Web Services WSDL specification  Input and output data structures • Includes or refers to XML Schema type information  Method signatures abstract part  Protocol bindings (HTTP, SMTP etc.) types  Location of the service messages  Document can be stored in UDDI registry operations or served from the provider server port types  Typically generated by a tool  xrpcc in Java Web Services Developer Pack concrete part bindings services and ports 2010-01-28 page 15
  • 16. WSDL Interface : What Support PortType Operation Format and How to Input/Output protocol invoke Access Binding How to Message encode specification implement provide Port Service Endpoint : Where 2010-01-28 page 16
  • 17. UDDI  Universal Description, Discovery, and Integration  Specification to Publish & Discover Web Services  Shared Distributed Registry on the Web  Analogy: Universal Phone Book  UDDI enables three basic functions:  Publish function – how a Web Service registers  Find function – how a client finds a Web Service  Bind function – how the client connects and interacts with a Web Service Name of Business White Page Contact Information Description of the Company Business Classification Information Based on NAICS, UNSPSC, or Yellow Page Geographical Index List of Products (multiple entries) Technical Information about services Green Page Example: business processes, binding info, etc. 2010-01-28 page 17
  • 18. UDDI Registry 2010-01-28 page 18
  • 19. Service Finder 2010-01-28 page 19
  • 20. Web Service Composition Workflow = Automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedure rules (W (WfMC) B A N1 E N2 F Organization A Organization B Organization C + 10101011 C D t1 + t7 t8 t5 t6 t2 t3 t4 Set_Data DB_Access Manager Lab Tech GET_ Seq DB_Access Lab Tech II 2010-01-28 page 20
  • 21. Workflow Application Architecture Consumer Process Services and Messages Service Architecture Provider Component Architecture Component Architecture 2010-01-28 page 21
  • 22. Web Services Choreography & Orchestration  Web Services orchestration  implies the presence of a single agent that controls and coordinates interactions between and among multiple Web Services  Web Services choreography  involves non-executable descriptions of observable behavior of Web Services through the definition of observable message exchanges between a collection of services Web Web Service Service Collaboration Web Process flow Web Web Web Service Service Service Service Web Services orchestration Web services choreography 2010-01-28 page 22
  • 23. Choreography & Orchestration  Travel Agency example When the service is When the service requested requests Date, Time Date Hotel Service Hotel Time Error Flight, Hotel Travel Agenc y Date, Time Error Service Confirmation Flight Flight Service Error  Choreography = how to interact with the service to consume its functionality  Orchestration = how service functionality is achieved by aggregating other Web services 23
  • 24. WSBPEL  Business Process Execution Language for Web Services  WSBPEL replaces WSFL and XLANG by combining and extending the functions of both  Describe business process involving many WS  XML-based workflow definition language  Standard for Web Service composition language 2010-01-28 page 24
  • 25. WSBPEL Elements  Partner  the different parties that interact with the business process  Container  WSDL messages that are received from or sent to partner  faultHandlers  the ways to handle and recover from errors in businesses.  Compensation  allowing the process designer to implement compensation actions for certain irreversible errors in business  Activities  the actions that are being carried out within a business process <receive> <reply> <invoke> <assign> <throw> <terminate> <wait> <empty> <sequence> <switch> <while> <pick> <flow> <scope> <compensate>  Correlation  figuring out which instance an incoming message is meant for 2010-01-28 page 25
  • 26. WSBPEL Core Concepts Web Service Partner (Service) Linking Implementation <partnerLink>, <receive>, <reply> defined <partnerLinkType> implements defined Correlations <correlationSet>, Process Definition Web Service invocation <correlationSets>, <process> <invoke> <property>, Iden- <propertyAlias> tified comprise uses defined Sequencing and Flow Scopes Control uses Non deterministic <scope>, <faulthandler>, <sequence>, <flow>, support <compensationhandler>, Contained <while>, <switch>, <pick>, <onMessage>, <eventhandler> in <onAlarm> <link> uses uses Fault Handling Variable Definition and <catch>, <compensate>, Assignment <throw> <variable>, <assign> 2010-01-28 page 26
  • 27. Web Services and Security  When Web Services-based exchanges branch out beyond an organization’s firewall and span across organizations, security becomes a much larger factor than it is for exchanges that are behind the firewall  Security involves multiple requirements, such as:  Integrity: Ensuring that messages have not been tampered with en route or otherwise  Non-Repudiation: Ensuring that a party to a contract or communication cannot deny the authenticity of their signature or the fact that they originated a message  Authentication/Identity Management: Requiring proof of identity in a Web-based transaction  Authorization: Controlling access privileges to resources  Confidentiality: Protecting information from interception during transmission, and potentially afterward 2010-01-28 page 27
  • 28. Web Services and Security Specification Satisfies Security Requirement OASIS Web Services Security  Integrity (message-level)  Non-Repudiation (message-level)  Confidentiality (message-level) OASIS SAML (Security Assertion  Authentication Markup Language)  Identity Management (Version 2.0) The Liberty Alliance  Identity Management WS-Federation (Web Services  Identity Management Federation Language) WS-Trust (Web Services Trust  Managing trust relationships Language) WS-SecureConversation (Web Services  Integrity (session-level) Secure Conversation Language)  Non-Repudiation (session-level)  Confidentiality (session-level) XACML (Extensible Access Control  Authorization/Access Control Markup Language) 2010-01-28 page 28
  • 29. Service implementation - logical A service is a software component designed and built in order to be reused by another software component in different execution contexts. Provides service identification, definition of Service Interface parameters, and conventions concerning passing the service results back to the consumer Service content provides business logic Service such as a stateless computation Content Services might need to be able to distinguish messages from individual consumers and also be able to correlate those messages into meaningful conversations. Author: Peter Campbell, ANZ Banking Group Australia Source: Applying EA Roadmapping: An SOA Roadmap, Cutter Consortium 2010-01-28 29
  • 30. Service-oriented Architecture (SOA) 1. Point to point systems 2. Message-based middleware with integration broker Partner Partner App B App D Warehouse App A App A (J2EE) Warehouse App B Sales (.Net) App C Service Bus / MOM Sales App C App D (.Net) (J2EE) Adapter Adapter Shared Legacy System Legacy Legacy System Application Application Finance Finance Service Oriented Architecture & Enterprise Service Bus Business Consumer Custom Package Business Rules Process applications applications Engine “Above the bus” Orchestration HTTP Enterprise Service Bus Internet Service Provider Routing Transformation (Process) Services Adapter Adapter orchestration Legacy Shared “Below the bus” System System Author: Peter Campbell, ANZ Banking Group Australia 30 2010-01-28 kr
  • 31. SOA Layers Composite Business Service Service Services Composite Application Enterprise Service Bus Business Service Bus Service Service Service Service Service Service Implementation-Based and Utility Services Other Service Enablement Service Providers Providing Resources Internal and External Resources and Implementations 2010-01-28 page 31
  • 32. Service / Business Process Business Process “Open account for customer” Presentation – user interface Business Process Orchestration Business Get Locate Add Services customer account account to Coarse Grained details type customer Service Orchestration (Process Orchestration) Lookup Create Fine Locate Check Retrieve Technical customer customer account account Customer- Grained Services type Account record status details table record 32 2010-01-28 kr
  • 33. Service / Business Process Composition BEA WebLogic Platform 33 2010-01-28 kr
  • 34. Business Process Standards 34 2010-01-28 kr
  • 35. Web Services and SOA  SOA can be implemented without Web services, and Web services can be used for non- SOA (e.g. RPC) interactions. However, Web services delivers key standards for implementing SOA.  The WS-* family scales to meet integration challenges intra-enterprise (enterprise application integration [EAI]) and inter-enterprise (business to business [B2B]).  XML is an ideal candidate for loosely coupled inter-application data sharing. XML is not self-describing, but XML Schema can be be used to constrain message layout and content. SOA “The architecture”  Services architecture  Web services specs  RPC interactions  Service contract  WSDL  Binary XML  Message based  SOAP & XML  Service directory  UDDI Web services  Protocol independent  HTTP  Coarse grained & document  Doc literal binding “The plumbing” centric  Process orchestration (BPEL) You don't have SOA until you build/buy Web Services is the stack of standard web technologies services and compose them to implement required at both consumer and provider ends to implement the business functionality. pipe for shipping XML messages between them. Author: Peter Campbell, ANZ Banking Group Australia 2010-01-28 page 35
  • 36. Standards Stack for Web Services 2010-01-28 page 36
  • 37. Trend in Web Services 2010-01-28 page 37
  • 38. WS standards: Lack of Semantics! Syntax only! Problem: Enable interoperability by using the same format, but still discovery, combinability only syntax based, no way to describe functionality. 2010-01-28 page 38
  • 39. Semantic Web Services
  • 40. Semantic Web Services Ontology Semantic Information Knowledge Model Semantic Based Resources Web System Semantic Web Services Distributed Processing Distributed Model Web Services EAI Services Service 2010-01-28 page 40
  • 41. Semantic Enabled Web Services Semantics 2010-01-28 page 41
  • 42. Semantic Web Services (SWS) Three characteristics of SWS: 1. Enhance Web Service usage by adding semantics for automation  Web service aspect 2. Use an ontology as the underlying model for the Web Service description  Ontology aspect 3. Support ontology reuse to build a Web of Links  Semantic Web aspect
  • 43. Tackling Semantic Interoperability… Publication Make available the description of the capability of a service Discovery Locate different services suitable for a given task Choose the most appropriate services among Selection the available ones Composition Combine services to achieve a goal Solve mismatches (data, protocol, process) among Mediation the combined Web services Execution Invoke services following programmatic conventions Monitoring Control the execution process Provide transactional support and undo or mitigate Compensation unwanted effects Replacement Facilitate the substitution of services by equivalent ones 2010-01-28 page 43
  • 44. Semantic Web Services Lifecycle Qos Description Security Publication Enactment Discovery Engagement 2010-01-28 page 44
  • 45. Building on Existing Web Services Standards OWL-S OWL-S Service (Grounding) Matching XML WSDL UDDI SOAP HTTP 2010-01-28 page 45
  • 46. OWL-S Objectives  Provide:  An upper ontology for describing properties & capabilities of agents & (Web) services in an unambiguous, computer interpretable markup language.  Supporting ontologies for describing service types, security definitions, execution parameters, access and invocation characteristics.  Guidelines for advertising, modeling and requesting services.  Infrastructure to support the location and invocation of services.  Model services using DAML syntax and description-logics  Achieve semantic interoperability through tight coupling with Semantic Web standards.  Automate:  WS Discovery  WS Invocation  WS Selection, Composition & Interoperation  WS Execution Monitoring 2010-01-28 page 46
  • 47. OWL-S Upper Ontology • Capability specification • General features of the Service • Quality of Service • Classification in Service taxonomies • Mapping to WSDL • communication protocol (RPC, HTTP, …) • marshalling/serialization • Control flow of the service • transformation to and from XSD to OWL • Black/Grey/Glass Box view • Protocol Specification • Abstract Messages 2010-01-28 page 47
  • 48. Service Profiles  Service Profile  Presented by a service.  Represents • what the service provides  Two main uses: • Advertisements of Web Services capabilities (non-functional properties, QoS, Description, classification, etc.) • Request of Web services with a given set of capabilities 2010-01-28 page 48
  • 49. OWL-S Service Profile Non Functional Properties Functionality Description 2010-01-28 page 49
  • 50. Service Model  Process Model  Describes how a service works: internal processes of the service  Specifies service interaction protocol  Specifies abstract messages: ontological type of information transmitted  Facilitates  Web service invocation  Composition of Web services  Monitoring of interaction 2010-01-28 page 50
  • 51. OWL-S Service Model (Overview) 2010-01-28 page 51
  • 52. Process Model Control Constructs  Four types of control construct  Sequential, concurrent, conditional, and iteration  Test and conditional constructs used to control workflow 2010-01-28 page 52
  • 53. Composite Process Example (Sequence) <rdfs:Class rdf:ID="BookFlight"> <rdfs:subClassOf rdf:resource="#CompositeProcess" /> <rdfs:subClassOf rdf:resource="" /> <daml:subClassOf> <daml:Restriction> <daml:onProperty rdf:resource="" /> <daml:toClass> <daml:subClassOf> <daml:unionOf rdf:parseType="daml:collection"> <rdfs:Class rdfs:about="#GetFlightDetails" /> <rdfs:Class rdfs:about="#GetContactDetails" /> <rdfs:Class rdfs:about="#ReserveFlight" /> <rdfs:Class rdfs:about="#ConfirmReservation" /> </daml:unionOf> </daml:subClassOf> Composite Process </daml:toClass> BookFlight </daml:Restriction> </daml:subClassOf> </rdfs:Class> Get Flight Get Contact Confirm Reserve Flight Details Details Reservation Sequence Sequence Sequence 2010-01-28 page 53
  • 54. Service Grounding  Service Grounding  Provides a specification of service access information.  Service Model + Grounding give everything needed for using the service  Builds upon WSDL to define message structure and physical binding layer  Specifies:  communication protocols, transport mechanisms, agent communication languages, etc. 2010-01-28 page 54
  • 55. Mapping OWL-S / WSDL 1.1  Operations correspond to Atomic Processes  Input/Output messages correspond to Inputs/Outputs of processes OWL-S Process Model DL-based Types Atomic Process Inputs / Outputs Operation Message Binding to SOAP, HTTP, etc. WSDL 2010-01-28 page 55
  • 56. Web Services vs. Semantic Web Services Items Web Services Semantic Web Services Service Requestor Human Agents UDDI May not be necessary Service Publication Description Language WSDL( Service taxanomy) Ontology-based language Ontology-based Service Descriptions Operations, messages and binding Goals and Capabilities Message Exchange Syntactic-based Semantic-based Core technologies UDDI/WSDL/SOAP Ontology and Reasoning Service Composition Passive using WSBPEL Goal-driven approach by agents choreography / Passive using WSBPEL Automatic generation by BPM orchestration Heterogeneity Passive Semantic mediation Service Discovery/Selection Search repository by human Automatic discovery by agents Transportation Protocols SOAP SOAP, and other XML protocols 2010-01-28 page 56
  • 57. Overview: Semantic Web Services Research Ontology W3C OWL OWL-S SWSI (USA) Coalition STI2 WSMF WSMO (EU) Web Services 2010-01-28 page 57
  • 58. Semantic Web Services Framework Semantic Web Services Language Semantic Web Services Architecture (SWSA) (SWSL) SWSL-FOL SWRL-Rules Semantic Web Services Dynamic Service Lifecycle and Resource Discovery Management Services Semantic Web Service Engagement Community Support Services Semantic Web Services Ontology (SWSO) Service Process Enactment and Cross-Cutting Issues FLOWS ROWS Management 2010-01-28 page 58
  • 59. Semantic Web Services Framework (SWSF) general purpose language designed to Semantic Web Service Language (SWSL) address the needs of Semantic Web Services • based on FOL SWSL–FOL • used to express the formal characterization (ontology) of Web Service concepts • based on logic programming SWSL–Rules • used to support the use of the Service ontology in reasoning and execution environments Semantic Web Service Ontology (SWSO) conceptual model and axiomatization FLOWS (First-Order Logic Ontology for Web Services) • axiomatized ontology of service ontology learned from OWL-S, PSL ROWS (Rules Ontology for Web Services)  a (partial) translation of FLOWS into SWSL-Rules 2010-01-28 page 59
  • 60. The Layered Structure of SWSL-Rules  a rule-based language with non-monotonic semantics.  to provide support for a variety of tasks that range from service profile specification to service discovery, contracting, policy specification, and so on. Courteous Nonmon LT NAF Reification Equality Mon LT HiLog Frames Horn 2010-01-28 page 60
  • 61. The Layered Structure of SWSL-Rules  Core language: pure Horn subset of SWSL-Rules.  Monotonic Lloyd-Topor (Mon LT) extension  permits disjunctions in the rule body and conjunction and implication in the rule head.  NAF extension  allows negation in the rule body, which is interpreted as negation-as-failure.  Non-Nonotonic Lloyd-Topor extension (Non-Non LT)  permits quantifiers and implication in the rule body.  Courteous rules extension  introduces two new features: restricted classical negation and prioritized rules.  HiLog extension  allowing variables to range over predicate symbols, function symbols, and even formulas.  Despite second-order features, the semantics of HiLog remains first-order and tractable.  Frames extension  introduces the most common object-oriented features, such as the frame syntax, types, and inheritance.  Reification extension  provides a mechanism for making objects out of a large class of SWSL-Rules formulas, which puts such formulas into the domain of discourse and allows reasoning about them. 2010-01-28 page 61
  • 62. SWSL-FOL  is used to specify the dynamic properties of services, namely, the processes that they are intended to carry out  a specification language for SWSO, and specialized reasoners will be used to reason with the service ontology  a common platform to support semantic interoperability among the different first-order based service ontologies, such as OWL-S  All of the above layers have been implemented in one system or another.  FLORA-2: all layers except Courteous rules and Non-Monotonic Lloyd-Topor.  SweetRules: Courteous extensions  Ontobroker: Non-Monotonic Lloyd-Topor and frames. 2010-01-28 page 62
  • 63. The Layers of SWSL-FOL SWSL-FOL+HiLog SWSL-FOL+Equality SWSL-FOL+Frames SWSL-FOL HiLog Equality Mon LT Frames Horn 2010-01-28 page 63
  • 64. Semantic Web Services Ontology (SWSO)  SWSO: Two ontologies  FLOWS  First-order Logic Ontology for Web Services. FLOWS  also known as SWSO-FOL  First-order logic version of the Semantic Web Services Ontology.  An extension of the PSL-OuterCore ontology, to incorporate the fundamental aspects of (web and other electronic) services, including service descriptors, the service activity, and the service grounding.  ROWS  Rules Ontology for Web Services.  ROWS, also known as SWSO-Rules  Rules-based version of the Semantic Web Services Ontology.  created by a relatively straight-forward, almost faithful, transformation of fundamental aspects of (web and other electronic) services, including service descriptors, the service activity, and the service grounding.  Enables a rules-based specification of a family of services, including both the underlying ontology and the domain-specific aspects. 2010-01-28 page 64
  • 65. SWSO: FLOWS  First-order Logic Ontology for Web Services  Representational Desiderata  Model-theoretic semantics  Primitive and complex processes are first-class objects  Taxonomic representation  Leverages existing service ontologies (OWL-S)  Embraces and integrates with existing and emerging standards and research (BPEL, W3C choreography, etc.)  Explicit representation of messages and dataflow (cf. W3C choreography, behavioral message-based signatures, etc.)  Captures activities, process preconditions and effects on world.  Captures process execution history.  FLOWS comprises:  Service Descriptors  Process Model  Grounding 2010-01-28 page 65
  • 66. SWSO: FLOWS FLOWS Service Process Grounding Descriptors Model Control Ordering Occurrence State Exception FLOWS-Core Constraints Constraints Constraints Constraints Constraints 2010-01-28 page 66
  • 67. Service Descriptors  Service Name: name(service,service_name)  Service Author: author(service,service_author)  Service Contact Information: contact(service,contact_info)  Service Contributor: contributor(service,service_contributor)  Service Description: description(service,service_description)  Service URL: url(service,service_URL)  Service Identifier: identifier(service,service_identifier)  Service Version: version(service,service_version)  Service Release Date: releaseDate(service,service_release_date)  Service Language: language(service,service_language)  Service Trust: trust(service,service_trust)  Service Subject: subject(service,service_subject)  Service Reliability: reliability(service,service_reliability)  Service Cost: cost(service,service_cost) 2010-01-28 page 67
  • 68. Process Model  Extension of PSL, a generic ontology for processes  the structured notion of atomic process as found in OWL-S  infrastructure for specifying various forms of data flow Module Major Concepts Service AtomicProcess FLOWS-Core composedOf message channel Split Sequence Unordered Control Constraints Choice IfThenElse Iterate RepeatUntil Ordering Constraints OrderedActivity Occurrence Constraints OccActivity State Constraints TriggeredActivity Exception Constraints Exception 2010-01-28 page 68
  • 69. Process Modeling Constructs 2010-01-28 page 69
  • 70. SWSO: ROWS  Rules Ontology of Web Services  Partial translation of FLOWS into SWSL- Rules  Features of ROWS  Since SWSL-Rules is inherently less expressive than SWSL-FOL, some axioms in ROWS are weakened with respect to the corresponding axiom in SWSL-FOL.  Top-level Classes of ROWS  Correspond to similar to classes of FLOWS  Service, Process, AutomicProcess, Message, Channel prefix xsd = "". Service[ name *=> xsd#string, author *=> xsd#string, contactInformation *=> xsd#string, contributor *=> xsd#string, …………………………. identifier *=> xsd#string, subject *=> xsd#string, trust *=> xsd#string, reliability *=> xsd#string, cost *=> xsd#string ]. 2010-01-28 page 70
  • 71. Semantic Web Service Architecture (SWSA)  Mission of the Semantic Web Services Initiative Architecture committee (SWSA): Development of architectural and protocol abstractions forming a reference architecture to support Semantic Web Service technologies on the World Wide Web  extends the Web Services Architecture developed by the Web Services Architecture Working Group of W3C  make use of terms and concepts in a conceptual architecture for semantic web services that extends the Web Services WG Architecture.  is based in part on the layered Semantic Web Architecture as proposed by Tim Berners-Lee  is taken from the OWL-S Coalition, WSMO Working Group, the open grid services architecture and the METEOR-S project  abstract protocols for interactions between clients and Semantic Web Services and other support services that may be needed in some contexts to fulfill the basic requirements of the proposed architecture  support functions to be accomplished by Semantic Web agents (service providers, requestors, and middle agents). 2010-01-28 page 71
  • 72. SWSA Architectural Considerations  Dynamic Service Discovery:  The capability of a software agent, through interaction with other agents, to identify candidate services for particular objectives.  Service Engagement - Negotiation and Contracting:  The capability of two agents to mutually formulate, by offline or online interaction, a shared agreement on the terms of performance of a service to be provided by one agent for the other.  Service Process Enactment and Management:  The capability to dynamically select and invoke or interact with services to achieve some defined objective.  Semantic Web Community Support Services:  Capabilities associated with sharing semantic descriptions, ontologies and ontology mappings, and service catalogs within and across communities.  Semantic Web Service Lifecycle and Resource Management Services:  The capability to spawn, allocate, manage and report on the life status of services, computational host platforms and storage facilities for Semantic Web Services.  Cross-cutting Issues:  Semantic representations of two kinds of service quality meta-properties may be important during discovery of appropriate services, may appear in service agreements, and may be monitored during execution. 2010-01-28 page 72
  • 73. Service Interaction Process of SWSA • 발견 (Service Discovery) 단계 서비스 • 약속 (Service Engagement) 단계 서비스 • 처리 규약 및 관리 (Service Process Enactment and Management) 서비스 • 웹 지원 관련 서비스 (Semantic Web Community Support Services) 시맨틱 • 웹 서비스 생명주기 및 자원관리 서비스 (Semantic Web Service Lifecycle 시맨틱 and Resource Management Services) • 부가적 요구사항 (Cross-cutting Requirement) 2010-01-28 page 73
  • 74. Negotiation-Commitment Process 2010-01-28 page 74
  • 75. Main Principles of WSMF Automatic finding and Diverse heterogeneous Diverse heterogeneous comparing data format business logic Machine-Processible Ontology Mediation Semantics Technology Two complementary principles  Strong de-coupling - information hiding : private process and public process - scalable interaction for coupling process  Strong mediation - mediate different terminologies / different interaction styles 2010-01-28 page 75
  • 76. WSMO Framework WSMO WG  Conceptual Model of Web Services WSML WG WSMX WG  Languages for WSMO  Run-Time Execution Environment ∙ WSMO Working Group : 시맨틱 웹서비스 모델 연구 ∙ WSML Working Group : 시맨틱 웹서비스 언어 연구 Formal Language Rule-base Language ∙ WSMX Working Group WSMO for : 시맨틱 웹서비스 실행 환경 연구 2010-01-28 page 76
  • 77. WSMO Design Principles  Web Compliance  inherits the concept of URI (Universal Resource Identifier) for unique identification of resources  adopts the concept of Namespaces for denoting consistent information spaces, and supports XML and other W3C Web technology recommendations, as well as the decentralization of resources.  Ontology-Based  used as the data model throughout WSMO, meaning that all resource descriptions as well as all data interchanged during service usage are based on ontologies.  semantically enhanced information processing as well as support for interoperability  Strict Decoupling  is specified independently without regard to possible usage or interactions with other resources.  Centrality of Mediation  addresses the handling of heterogeneities that naturally arise in open environments.  Ontological Role Separation  differentiates between the desires of users or clients and available Web services.  Description versus Implementation  differentiates between the descriptions of Semantic Web services elements (description) and executable technologies (implementation).  Execution Semantics -  verify the WSMO specification, the formal execution semantics of reference implementations like WSMX as well as other WSMO-enabled systems provide the technical realization of WSMO.  Service versus Web service –  A Web service is a computational entity which is able (by invocation) to achieve a goal. A service in contrast is the actual value provided by this invocation. 2010-01-28 page 77
  • 78. Core Components of WSMO  Ontologies  consisted of concepts, relations, functions, axioms, instances, non-functional properties, imported ontologies, and used mediators  Web Services  describe the functional properties for service discovery, invocation, composition, mediation, compensation and…  consisted of non-functional properties, imported ontologies, used mediators, capability and interfaces  should have more than one capability  Goals  describe the required user’s goal of service.  consisted of non-functional properties, imported ontologies, used mediators, requested capability and requested interface  Mediators  mediation of structural, semantic, conceptual mismatches  consisted of non-functional properties, imported ontologies, source comjponent, target comjponent and mediation service  4 types of mediators 2010-01-28 page 78
  • 79. WSMO – the Web service element 2010-01-28 page 79
  • 80. WSML  WSML provides a formal grounding for the conceptual elements of WSMO, based on:  Description Logics  Rule Languages  First-Order Logic  Many current Semantic Web languages have  undesirable computational properties  unintuitive conceptual modeling features  inappropriate language layering • RDFS/OWL • OWL Lite/DL/Full • OWL/SWRL  WSML aims to:  Provide a Web Service Modeling Language based on the WSMO conceptual model • Concrete syntax • Semantics  Provide a Rule Language for the Semantic Web 2010-01-28 page 80
  • 81. Web Service Modelling Language (WSML)  Ontology / Rule Languages WSML  WSML Core: efficiency and compatibility  WSML DL: decidability, open world semantics Static Dynamic  WSML Rule: efficient existing rule engines Aspects Aspects  WSML Full: unifying language, theorem proving  Languages for dynamics  Transaction Logic over ASMs WSML Full  Mapping languages  for dynamics (process mediation) WSML Rule WSML DL  for data (data mediation) WSML Core RDF (S) XML Unicode URI 2010-01-28 page 81
  • 82. Variants of WSML  WSML-Core  Based on the intersection of Description Logics and Datalog  Semantics defined through OWL Lite-  Has (frame-based) conceptual syntax and logical expression syntax  WSML-Flight  Based on OWL Flight • Basic meta-class facility • Constraints • Non-monotonic features (default negation)  “Fixes” some of the mistakes in OWL, such as unintuitive modeling constructs  Preferred ontology modeling language  WSML-Rule  Based on Logic Programming with default negation and F-Logic/HiLog syntactical extensions  Preferred goal/web service modeling language  WSML-DL  Based on species of OWL  WSML-Full  Combining FOL with minimal models and non- monotonicity 2010-01-28 page 82
  • 83. WSMO/WSML: Examples  Concept example  Relation example concept phoneNumber nonFunctionalProperties relation hasRoute(ofType routeDescription, ofType route) dc#description hasValue "concept of a nonFunctionalProperties dc#description hasValue "Relation that holds between phone number" endNonFunctionalProperties a route description and a route" endNonFunctionalProperties countryCode ofType _string areaCode ofType _string number ofType _string  Instance example instance myPhoneNumber memberOf phoneNumber countryCode hasValue “43“ areaCode hasValue “664“  Sub-concept example number hasValue “49322607“ concept mobilePhoneNumber subConceptOf phoneNumber nonFunctionalProperties dc#description hasValue "concept of a  Axiom example axiom ValidInformationQuality mobile phone number" definedBy endNonFunctionalProperties forall {?x} ( mobileProvider ofType Provider ?x memberOf informationQualityType impli es ?x[value hasValue “low“] or ?x[value hasValue “high“]). 2010-01-28 page 83
  • 84. WSMO/WSML: Examples webService _"" nfp dc#title hasValue "MobtelPhoneLocationService" dc#publisher hasValue "Mobtel“ dO#informQualityType hasValue "high" endnfp importsOntology _"" capability MobtelPhoneLocationServiceCapability sharedVariables {?P} precondition definedBy ?P memberOf dO#phoneNumber. postcondition definedBy ?L memberOf dO#location and dO#hasLocation(?P,?L). interface MobtelPhoneLocationServiceInterface choreography MobtelPhoneLocationServiceChoreography stateSignature in dO#phoneNumber withGrounding ssWSDL#wsdl.interfaceMessageReference(MobtelPhoneLocationServicePortType/doIt/In) out dO#location withGrounding ssWSDL#wsdl.interfaceMessageReference(MobtelPhoneLocationServicePortType/doIt/Out) transitionRules forAll{?P} with (?P memberOf dO#phoneNumber) do add(?L memberOf dO#location and dO#hasLocation(?P,?L)) endForall 2010-01-28 page 84
  • 85. WSMX Architecture 2010-01-28 page 86
  • 86. WSMX Functionality  Core Component: interactions between components (business logic of the system, events engine, internal worklow engine...)  Resource Manager: management of repositories to store definitions of any WSMO (Web Services, goals, ontologies and mediators) and non-WSMO related objects for WSMX.  Web Services Repository: Semantic Description of Web Services  Goals repository: semantic description of general goals  Ontology repository: ontologies to be stored in the registry describing semantics of particular domains.  Mediator repository: mediators to be stored in the registry.  Data repository :system data and any component specific data required for correct system execution.  Service Discovery: provide functionality on matching of usable SWS with the goals.  Goal-driven matching with the capability of Web Services and the user goal.  Service Selection: Selection of the appropriate Web Services among the candidate services discovered in Service Discovery  variant selection strategies: “best”, “optimal”, and “first”  Non-functional properties: cost, performance, geographical location, reliability, security, etc.  Data and Process Mediator: Mediator when two entities that cannot communicate directly need to interact.  Communication Manager  Choreography  mediate between the requester's and the provider's communication patterns.  provide the necessary means for a runtime analysis of two given choreography instances and to use Mediators to compensate the possible mismatches that may appear,  WSMT Web Service Modeling Toolkit (WSMT): framework for the rapid deployment of graphical administrative tools 2010-01-28 page 87
  • 87. WSMX – Components 2010-01-28 page 88
  • 88. Core Standardization Initiatives in the Area of SWS  OASIS Semantic Execution Environment TC  Developing guidelines, justifications, and implementation directions for deploying Semantic Web services in SOA   W3C Semantic Annotations for Web Services Description Language Working Group  Develop a mechanism to enable annotation of Web services descriptions  2010-01-28 page 89
  • 89. Semantic Web Services System
  • 90. OWL-S VM  OWL-S 기반 지원도구  주요 3 모듈로 구성  OWL-S 프로세스 모델 지원  기본적인 추론 기능 2010-01-28 page 91
  • 91. IRS-III Web Service Publishing Platforms Java Code  UPML 기반의 문제해결 추론 시스템 Web Application WSMX J S  WSMO 생성 지원 a v O SOAP WS Publisher Registry  편리한 서비스 공표 기능 Browser Browser a A Handler  서비스 발견과 실행 P SOAP Handle r Publisher OCML Handler Publishing Clients A  OWL-S 지원 P WSMO Library Invocation I Handler Invocation IRS-III Server Client LispWeb Server OWL(-S) OWL(-S) Handler 2010-01-28 page 92
  • 92. SWWS Studio  클라이언트용 통합개발환경  WSMO 지원  Visual Service Composer와 Service Editor 로 구성  서비스 합성은 OWL-S만 지원 2010-01-28 page 93
  • 93. ODE-SWS  개념 수준에서의 서비스 기술과 합성  WebODE 서비스 확장  언어 중립적 2010-01-28 page 94
  • 94. Web Service Semantics - WSDL-S  A mechanism to augment WSDL descriptions with semantics  a set of annotations can be created to semantically describe the inputs, outputs and operations of a Web service.  keeps the semantic model outside WSDL, making the approach agnostic to any ontology representation language  WSDL-S doesn’t provide a conceptual model and language for SWS  a bottom up approach to SWS (annotating existing standards with metadata)  Could be used as a grounding mechanism for SWS 2010-01-28 page 95
  • 95. METEOR-S Development Discovery Composition  대규모 Workflow 관리 시스템을 시맨틱 웹서비스에 확장 WSDL-S Semantic Invoker & Web Process Development Publishing & Testing Designer Deployment Discovery  서비스 라이프 사이클 관리 가능 GUI Core  서비스 기술에 WSDL-S 이용 WSDL-S Publishing & Invoker Process Manager API Discovery Engine Constraint Policy  서비스 저장고에 MWSDI 이용 Analyzer Optimizer Handler Infrastructure  본격적인 시맨틱 웹서비스 플랫폼 WSDL UDDI SOAP Inference ILP BPEL Parser Registry Engine Engine Solver Engine WSDL4J JWSDP Apache Jena/ Lindo BPWS Axis Snobase 4J 2010-01-28 page 96
  • 96. SUPER Project SUPER Project The major objective of Semantics Used for Process management within and between EnteRprises (SUPER) is to raise Business Process Management to the business level, where it belongs, from the IT level where it mostly resides now. SUPER aims to create the technological framework constituting BPM enriched with machine readable semantics by employing Semantic Web and Semantic Web Services accompanied by universal reference implementation for mechanized BPM.  SUPER Goals: • To develop a comprehensive ontology stack that describes formal semantics for semantic business processes • To facilitate/support BPM tasks by semantic web service technology • Semantic Business Process Composition • Semantic Business Process Mediation • To provide a holistic, semantically enriched modeling stack for BPM • To provide “advanced” BPM functionality like semantic business process mining & analysis 2010-01-28 page 97
  • 97. SUPER Modeling Stack 2010-01-28 page 98
  • 98. SUPER Semantic Service Bus 2010-01-28 page 99
  • 99. Summary & Research Trend
  • 100. Different Approaches Services Description STI2 approach Location Communication Web Services Web Services Semantic Web Dynamic Web Services UDDI, WSDL, SOAP UDDI,WSDL,SOAP Services UDDI,WSDL,SOAP Semantic SWSI approach Integration Current Web Web Services Semantic Web Web Services Static URL, HTML, HTTP UDDI,WSDL,SOAP Ontology UDDI,WSDL,SOAP Resource Information Knowledge Semantic Interoperability 2010-01-28 page 101
  • 101. Framework Comparison WSMO WG  Conceptual Model of Web Services WSMO/WSML/WSMX WSML WG WSMX WG  Languages for WSMO  Run-Time Execution Environment Formal Language Rule-base Language for WSMO Semantic Web Services Language (SWSL) Semantic Web Services Architecture (SWSA) SWSL-FOL SWRL-Rules Semantic Web Services Dynamic Service Lifecycle and Resource Discovery Management Services SWSI Service Process Semantic Web Enactment and Community Management Support Services Semantic Web Services Ontology (SWSO) Service Engagement Cross-Cutting Issues FLOWS ROWS 2010-01-28 page 102
  • 102. Research Trend Semantic Web Services Initiative (SWSI) (WSMO/WSML/WSMX •••) BPEL4WS Semantic Annotation WSCL Web process Advertisement WSCI Discovery XLANG Web process Selection WSFL Composition Time ••• Execution SOAP Web service Semantic OWL-S WSDL Web service OWL UDDI DAML-S XML DAML ••• ••• Industry Research Academic Research 2010-01-28 page 103
  • 103. The Cloud is rising…  Definition by Wikipedia  Cloud computing literally means Internet ('Cloud') based development and use of computer technology ('Computing'). It is a style of computing where IT-related capabilities are provided “as a service” using Internet technologies to multiple external customers. It allows users to access technology-enabled services without knowledge of, expertise with, or control over the technology infrastructure that supports them.  Definition by Gartner  a style of computing where massively scalable IT related capabilities are provided 'as a service' using Internet technologies to multiple external customers.  Cloud computing is disruptive  IT-related capabilities provided “as a service”  Current economic downturn makes Cloud Computing more relevant than ever  Gartner reports that 25% of software will be delivered as SaaS 2011. 2010-01-28 page 104
  • 104. X-as-a-Service 2010-01-28 page 105
  • 105. as-a-Service Concept SaaS PaaS IaaS SaaS is a model of Provides the facilities to software deployment support the end-to-end Typically a virtualized life cycle of building platform environment Managed from central and delivering web locations rather than at applications and Evolution towards costomer`s site services ubiquitous utility computing Provisioned on the fly, on-demand model 2010-01-28 page 106
  • 106. Cloud Computing 2010-01-28 page 107
  • 107. Examples 2010-01-28 page 108
  • 108. Core Players 2010-01-28 page 109
  • 109. Unified Ontology of Cloud Computing. 2010-01-28 page 110
  • 110. Cloud Ontology 2010-01-28 page 111
  • 111. Thank you….