Your SlideShare is downloading. ×
[RFC2119]
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

[RFC2119]

449
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
449
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1 2Semantic Web Services Architecture and 3Information Model 4Working Draft v0.1-r1, 8 September 2006 5Artifact Identifier: 6 wd-see-arch-v0.1-r1 7Location: 8 Current: docs.oasis-open.org/ex-semantics/architecture/latest 9 This Version: docs.oasis-open.org/ex-semantics/architecture/0.1 10 Previous Version: docs.oasis-open.org/ex-semantics/architecture/0.1 11Artifact Type: 12 architecture 13Technical Committee: 14 OASIS SEE TC 15Chair(s): 16 John Domingue, Open University, <j.b.domingue@open.ac.uk> 17 Michal Zaremba, DERI, <michal.zaremba@deri.org> 18Editor(s): 19 Michal Zaremba, DERI Innsbruck, <michal.zaremba@deri.org> 20 Matthew Moran, DERI Galway, <matthew.moran@deri.org> 21 Thomas Haselwanter, DERI Innsbruck, <thomas.haselwanter@deri.org> 22 Barry Norton, Open University, <b.j.norton@open.ac.uk> 23OASIS Conceptual Model topic area: 24 SOA 25Related work: 26 This specification replaces or supersedes: 27 • [specifications replaced by this standard] 28 • [specifications replaced by this standard] 29 This specification is related to: 30 • [related specifications] 31 • [related specifications] 32Abstract: 33 [Summary of the technical purpose of the document] 34Status: 35 This document is in DRAFT status. This document is updated periodically on no particular 36 schedule. 37 Technical Committee members should send comments on this specification to the Technical 38 Committee’s email list. Others should send comments to the Technical Committee by using the 1OASIS SEE TC Architecture and Information Model 08 September 2006 2Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 30
  • 2. 39 “Send A Comment” button on the Technical Committee’s web page at www.oasis- 40 open.org/committees/ex-semantics. 41 For information on whether any patents have been disclosed that may be essential to 42 implementing this specification, and any offers of patent licensing terms, please refer to the 43 Intellectual Property Rights section of the Technical Committee web page (www.oasis- 44 open.org/committees/ex-semantics/ipr.php. 45 The non-normative errata page for this specification is located at www.oasis- 46 open.org/committees/ex-semantics. 4OASIS SEE TC Architecture and Information Model 08 September 2006 5Copyright © OASIS Open 2006. All Rights Reserved. Page 2 of 30
  • 3. 47Notices 48Copyright © OASIS Open 2005. All Rights Reserved. 49All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 50Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 51This document and translations of it may be copied and furnished to others, and derivative works that 52comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 53and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 54and this section are included on all such copies and derivative works. However, this document itself may 55not be modified in any way, including by removing the copyright notice or references to OASIS, except as 56needed for the purpose of developing any document or deliverable produced by an OASIS Technical 57Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 58be followed) or as required to translate it into languages other than English. 59The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 60or assigns. 61This document and the information contained herein is provided on an "AS IS" basis and OASIS 62DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 63WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 64OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 65PARTICULAR PURPOSE. 66OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 67necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 68to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 69such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 70produced this specification. 71OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 72any patent claims that would necessarily be infringed by implementations of this specification by a patent 73holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 74Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 75claims on its website, but disclaims any obligation to do so. 76OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 77might be claimed to pertain to the implementation or use of the technology described in this document or 78the extent to which any license under such rights might or might not be available; neither does it represent 79that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 80rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 81OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 82to be made available, or the result of an attempt made to obtain a general license or permission for the 83use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 84Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 85information or list of intellectual property rights will at any time be complete, or that any claims in such list 86are, in fact, Essential Claims. 7OASIS SEE TC Architecture and Information Model 08 September 2006 8Copyright © OASIS Open 2006. All Rights Reserved. Page 3 of 30
  • 4. 87Table of Contents 881 Introduction..............................................................................................................................................6 89 1.1 What is a Semantic Execution Environment.....................................................................................6 90 1.2 Audience...........................................................................................................................................7 91 1.3 Relationships to Other Specifications...............................................................................................7 92 1.4 Terminology......................................................................................................................................7 93 1.5 Organization of the document...........................................................................................................7 94 1.6 Normative References......................................................................................................................7 95 1.7 Non-Normative References..............................................................................................................7 962 Motivation for SEE...................................................................................................................................9 97 2.1 Service Oriented Architectures.........................................................................................................9 98 2.2 Dynamic SOA...................................................................................................................................9 99 2.3 Nature of Existing Service Execution Environments.......................................................................10 100 2.4 Benefits of adding Semantics to SOA.............................................................................................10 101 2.5 Scope of SEE.................................................................................................................................11 1023 Architecture Overview............................................................................................................................12 103 3.1 Overview of SEE Infrastructure......................................................................................................12 104 3.2 Distribution of SEE.........................................................................................................................14 105 3.3 Overview of a Single Node.............................................................................................................16 1064 Structural View.......................................................................................................................................17 107 4.1 Problem Solving Layer....................................................................................................................17 108 4.1.1 Ontologies...............................................................................................................................17 109 4.1.2 Applications.............................................................................................................................17 110 4.1.3 Developer Tools......................................................................................................................17 111 4.2 Application Layer............................................................................................................................17 112 4.2.1 Discovery.................................................................................................................................17 113 4.2.2 Adaptation...............................................................................................................................18 114 4.2.3 Composition............................................................................................................................19 115 4.2.4 Choreography..........................................................................................................................20 116 4.2.5 Data Mediation........................................................................................................................20 117 4.2.6 Process Mediation...................................................................................................................21 118 4.2.7 Communication External (Grounding).....................................................................................21 119 4.2.8 Fault Handling.........................................................................................................................22 120 4.2.9 Monitoring................................................................................................................................22 121 4.3 Base Layer.....................................................................................................................................22 122 4.3.1 Formal Languages..................................................................................................................22 123 4.3.2 Reasoning...............................................................................................................................22 124 4.3.3 Storage....................................................................................................................................23 125 4.4 Vertical Services.............................................................................................................................24 126 4.4.1 Execution Management ..........................................................................................................24 127 4.4.2 Security...................................................................................................................................24 1285 Summary...............................................................................................................................................25 129A. Acknowledgements..............................................................................................................................26 10OASIS SEE TC Architecture and Information Model 08 September 2006 11Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 30
  • 5. 130B. Appendix A – SEE API (Operations)....................................................................................................27 131 Discovery........................................................................................................................................27 132C. Revision History...................................................................................................................................29 133 134 13OASIS SEE TC Architecture and Information Model 08 September 2006 14Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 30
  • 6. 1351 Introduction 136 1.1 What is a Semantic Execution Environment 137A Semantic Execution Environment is a service oriented architecture that uses the semantic descriptions 138of Web services, goals, and supporting concepts such as ontologies and mediators to create software 139applications where the services required to achieve a particular goal are determined at runtime. We adopt 140the OASIS SOA RM TC definition of Service Oriented Architecture (SOA) as “a paradigm for organizing 141and utilizing distributed capabilities that may be under the control of different ownership domains”. In the 142context of SEE, SOA is a software architectural style where the capabilities are provided by Web 143services. We define Semantic Web services to mean the semantic description of various aspects of Web 144services using a language with well-defined semantics such as WSML or OWL-S. For this document we 145choose to use the WSMO conceptual model for describing Semantic Web services along with its 146associated language WSML. Goals are the descriptions of the intent that service requester’s have when 147seeking to carry out their tasks and use the WSMO conceptual description for goals. 148The absence of common understanding (semantics) of data and process descriptions between service 149requesters and providers remains a substantial problem in the design and implementation of SOA. 150Solutions for service discovery, composition, invocation, data translation and monitoring exist but are 151usually based exclusively on the syntactic level with XML as the common representation language. 152Components for handling differences in semantics between requester and provider during service 153discovery or service invocation are notably absent in most software application designs. 154The purpose of SEE Semantic Web Services Architecture and Information Model is to define a software 155architecture with functionality that aims for the automation of service discovery, negotiation, adaptation, 156composition, invocation, and monitoring based on semantic descriptions of the various aspects of Web 157services. The SEE architecture will enable goal-based invocation of Web services. In the service-oriented 158world of the future, services will need to be discovered, composed, adapted and invoked on the fly based 159on various requirements. The contribution of the SEE specification is to describe the fixed component 160services of an infrastructure that MUST be provided to enable dynamic discovery, selection, mediation, 161invocation and inter-operation of services to facilitate the SOA evolution to towards flexible applications. 162Taking a supply chain management scenario as an example. One step may require that a shipping 163service be located for shipment from the UK to the USA. A goal is created that formally describes that a 164specific volume of goods needs to be shipped on a particular date. The SEE architecture will enable a 165service to be discovered that matches this goal. Conceptual differences between the data definitions used 166by the requester and provider will be resolved. The architecture will act as a broker coordinating the 167message exchange between the two parties and will monitor the status of the conversation. The 168advantage of the approach is that, if the next week, the same shipment is required again and the service 169provider is no longer available, no change on the service requester side is required, the architecture will 170discover a new provider if possible and, as before, resolve any semantic differences. 171 172As the volume of data published on the Web is grows exponentially, so too do the number of services, 173albeit at a slower rate. However this rate is increasing and will eventually lead to vast amount of available 174services. However the availability of services will be volatile as the complete connection between service 175requesters and providers will not be guaranteed over the Web. Machine-processable semantic 176descriptions of these services are critical to enable location of services and the interaction between them 177to be established automatically. As in the example above, when one service disappears, mechanisms will 178be required to establish communication with an alternative service provider. While the SEE Architecture 179specification identifies components that must be provided by the infrastructure, it remains agnostic about 180their internal design and implementation. Many research efforts and working groups already investigate 181specific topics such as service composition, discovery etc. We refer to this work in the related work 182deliverable referenced in section 1.3. 183 16OASIS SEE TC Architecture and Information Model 08 September 2006 17Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 30
  • 7. 184 1.2 Audience 185The anticipated audience for this work includes all OASIS Web Service and ebXML TCs, non-OASIS Web 186Service standards groups, Semantic Web Services research and interest groups, SOA architects and 187programmers, vendors and users. The work should be of interest to anyone involved with Semantic Web 188Services and more generally also in Service Oriented Architectures (SOAs). 189 1.3 Relationships to Other Specifications 190This is specified in the SEE TC deliverable – SEE-background-and-related-work_01.doc. 191 1.4 Terminology 192The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 193NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 194in [RFC2119]. 195 1.5 Organization of the document 196The specification is structured as following. Section 2 provides the motivation for SEE. In section 3 the 197architecture overview is presented. Section 4 discusses structural view and section 5 provides behavioral 198view. Section 6 presents related work (does it differ from the section 1.3?) and finally section 7 199summarizes this specification. 200 201 1.6 Normative References 202 [Cimpian 2005] E. Cimpian, T. Vitvar, M. Zaremba (editors): Overview and Scope of WSMX. 203 WSMX Deliverable D13.0, WSMX Final Draft v0.2, 2005, 204 http://www.wsmo.org/TR/d13/d13.0/v0.2/ 205 [OGSA 2002] Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke: Grid Services for 206 Distributed System Integration, Computer, vol 35, no. 6, pp 37-46, June 2002. 207 [Preist 2004] Chris Preist, A Conceptual Architecture for Semantic Web Services. in Third 208 International Semantic Web Services Conference (ISWC), Hiroshima, Japan, 209 2004, Springer, pp395-409 210 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 211 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 212 [Roman et al 2005] Dumitru Roman, Uwe Keller, Holger Lausen, Jos de Bruijn, Rubén Lara, Michael 213 Stollberg, Axel Polleres, Cristina Feier, Christoph Bussler, and Dieter Fensel: 214 Web Service Modeling Ontology, Applied Ontology, 1(1): 77 - 106, 2005. 215 [WSRF 2005] Steve Graham, Anish Karmarker, Jeff Mischkinsky, Ian Robinson, Igor Sedukhin 216 (editors): The WS-Resource Framework, Version 1.2, draft 0.2, available at http:// 217 www.oasis-open.org/committees/wsrf (2005) 218 [W3C Glossary 2004] Hugo Haas, and Allen Brown (editors): Web Services Glossary, W3C Working 219 Group Note 11 February 2004, available at http://www.w3.org/TR/ws-gloss/ 220 221 1.7 Non-Normative References 222 223 [Mocan et al 2005] Adrian Mocan, Emilia Cimpian: Mapping Creation Using a View Based Approach, 224 1st International Workshop on Mediation in Semantic Web Services (Mediate 225 2005), December 2005, Amsterdam, Netherlands 19OASIS SEE TC Architecture and Information Model 08 September 2006 20Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 30
  • 8. 226 [Cimpian et al 2005] Emilia Cimpian, Adrian Mocan: WSMX Process Mediation Based on 227 Choreographies, 1st International Workshop on Web Service Choreography and 228 Orchestration for Business Process Management (BPM 2005), September 2005, 229 Nancy, France 230 22OASIS SEE TC Architecture and Information Model 08 September 2006 23Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 30
  • 9. 2312 Motivation for SEE 232Section 2.1 provides an overview of Service Oriented Architecture. Section 2.2 looks at SOA in the 233situation where the services are distributed in the open environment provided by the Web. Section 2.3 234looks at what is understood by the term Service Execution Environment. In section 2.4, the advantages of 235applying semantics to SOA are introduced. Finally section 2.5 describes the scope and requirements for 236SEE. 237 2.1 Service Oriented Architectures 238The hot topic in today’s design of software architectures is to satisfy increasing software complexity as 239well as new IT needs, such as the need to respond quickly to new requirements of businesses, the need 240to continually reduce the cost of IT or the ability to integrate legacy and new emerging business 241information systems. In the current IT enterprise settings, introducing a new product or service, integrating 242multiple services and systems present unpredicted costs, delays and difficulty. Existing IT systems 243consist of a patchwork of legacy products, monolithic off-shelf applications and proprietary integration. It is 244even today’s reality that in many cases users on the “spinning chairs” manually re-enter data from one 245system to another within the same organization. The past and existing efforts in the Enterprise Application 246Integration (EAI) don’t represent successful and flexible solutions so far. Several studies showed that the 247EAI projects are lengthy, majority of these efforts are late and over budget. It is mainly costs, proprietary 248solutions and tightly-coupled interfaces that make EAI expensive and inflexible. 249Service Oriented Architecture (SOA) solutions are the next evolutionary step in software architectures. 250SOA is an IT architecture in which functions are defined as independent services with well-defined, 251invocable interfaces. SOA will enable cost-effective integration as well as bring flexibility to business 252processes. In line with SOA principles, several standards have been developed and are currently 253emerging in IT environments. In particular, Web Services technology provides means to publish services 254in a UDDI registry, describing their interfaces using Web Service Description Language (WSDL) and 255exchanging requests and messages over a network using SOAP protocol. Business Process Execution 256Language (BPEL) allows composition of services into complex processes as well as their execution. 257Although Web services technologies around UDDI, SOAP and WSDL have added a new value to the 258current IT environments in regards to the integration of distributed software components using web 259standards, they cover mainly characteristics of syntactic interoperability. With respect to a big number of 260services which will exist in IT environments in the inter and intra enterprise integration settings based on 261SOA, the problems with service discovery or selection of the best services conforming user’s needs, as 262well as resolving heterogeneity in services capabilities and interfaces will be again lengthy and costly 263process. From this reason, machine processable semantics should be used for description of services in 264order to allow total or partial automation of tasks such as discovery, selection, composition, mediation, 265invocation and monitoring of services. Along with this approach, Semantic Web Services defining 266concepts, language and execution environment is the next evolutionary step towards Semantic- 267empowered Service Oriented Architectures. 268 2.2 Dynamic SOA 269SEE is a an Execution Environment represented as a SOA. That is, almost all of its services can offer 270their functionality as Web Services, deployed by one or more providers. Additionally, each time a request 271passes the system boundaries it becomes a broker, an infrastructure, on which a new, ad-hoc, SOA will 272be created. This ad-hoc SOA is specialized in solving a precise task: the task formulated by the 273requester's goal. 25OASIS SEE TC Architecture and Information Model 08 September 2006 26Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 30
  • 10. 274We recognize the dual dimensions of SEE SOA: the SOA based SWS Execution Environment and the 275“on-demand” SOA built by using SEE. There are two triggers for dynamicity of SEE: (1) its own execution 276semantics, which formally specifies how system behaves; (2) user’s goals, which causes different 277services to be composed together to achieve functionality expected by the requester. 278SEE comes with four predefined branches of execution semantics, its expected functionality being 279described in terms of its entry points. Depending on the requestor’s requirements one of this branches 280gets trigged and several components are called to achieve the expected functionality (e.g. to find a Web 281Service we require discovery, choreography and process mediator, while to call a known Web Service we 282do not need discovery but additionally need the invoker). Additionally to these build-in branches, dynamic 283execution semantics can be defined. To achieve dynamic execution semantics we SEE extends SOA by 284allowing for model-driven execution of system components. We call dynamic execution semantics, a run- 285time deployable formal definition of a system behavior, which can be executed against components that 286are part of the system. Such execution semantics must not only be applicable at the design or startup 287time of the system, but must be executable in a running instance of the system as well. Due to the fact 288that WSMX system services are assembled on the fly, user services provided by external systems (such 289as enterprise systems) are also assembled on demand (unless service requestor specify in his/her goal 290which services should be used). 291 2.3 Nature of Existing Service Execution Environments 292Services by themselves do not go very far, even if they are semantically annotated. They need an 293environment that provides certain base functions for managing the interaction between services. This 294environment then acts to link the semantic descriptions of goals that service requesters wish to achieve 295with services that can solve these problems. Functionally this environment provides services for 296discovery, data and process mediation, composition, selection and invocation. Equally importantly, the 297environment must provide facilities to monitor service execution, support service level agreements, and 298react to unexpected failures. 299It is the function of the execution environment to make all this happen transparently to the requestor of the 300service. Taking an example from eBanking, an online credit card applicant may not necessarily need to 301know that for the application to be made an external check on her credit rating needs to be run. There 302may be a number of state-approved credit rating agencies available that the bank could use. Further, the 303details of how the messages that are sent to and from the selected credit rating agency may need to be 304encrypted and transformed into a specific data format. For the card-applicant, this would probably not be 305interesting; it is enough to make the card application. In other words, from a customer’s perspective, it is 306sufficient to express the wish that she would like to apply for a credit card through her bank. 307 2.4 Benefits of adding Semantics to SOA 308Service Oriented Architectures represent a huge step towards providing simpler, more dynamic and 309cheaper integration solutions. By having services to encapsulate discrete piece of functionality that can be 310later discovered and consumed is without a doubt the critical step in moving from a patchwork of legacy 311products, monolithic off-shelf applications and proprietary integration to a strongly decoupled, robust yet 312flexible software architecture. 313But SOA cannot (and it is not meant to) solve all the heterogeneity problems inherent to enterprises 314integration tasks. Such heterogeneity problems could be induced for example by the services (the key 315players of SOA) themselves or by the environment the enterprises are acting in. In the former case it is 316natural that services deployed by different providers to have specific requirements regarding data formats 28OASIS SEE TC Architecture and Information Model 08 September 2006 29Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 30
  • 11. 317or communication protocols. Further more, the invocation of such services can be part of complex 318business process that most probably differs from one vendor to another. Regarding the second case, the 319World Wide Web proves to be a more and more appealing (and suited) environment for businesses and 320Web Services could successfully fulfill the roll of services in SOA. Such a context allows for ad-hoc 321cooperation and on-the-fly business provision, but also pushes the interoperability problems to extreme, 322beyond the boundaries of the enterprises to be integrated. 323Semantics is coming to offer the tools to enable scalable, efficient and cost-effective solutions to these 324problems. Using ontologies and semantics, services can be un-ambiguous described, from data, 325functionality and behavior point of view. These semantics descriptions can be used in operations like 326discovery, selection, composition or aggregation of services to provide meaningful functionality through a 327truly Service Oriented Architecture. SOA can provide domain independent solutions for these operations 328that highly rely on semantics, formal specifications and reasoning. 329It is important to note that providing semantics descriptions for SOA it is not a trivial task and involves 330significant efforts: additionally to the actual implementation and technical interfaces an extra layer, the 331semantic layer, has to be added by each of the service providers. Only after this extra step is 332accomplished the real benefits of semantics can be exploited: old hard-coded, domain-specific solutions 333for service operations can be replaced by general, semantic-based ones and used in inter-enterprise (or 334even intra-enterprise) business scenarios. 335As such, bringing semantics to SOA means adding semantics to the services part of SOA and then 336augmenting SOA with semantic-aware mechanisms to support the elementary operations on services 337(e.g. discovery, selection, composition, invocation etc). 338 339 2.5 Scope of SEE 340The scope of the SEE Technical Committee is defined in the committee’s charter. 341Initial requirements have indicated that Semantic Web services systems should enable automatic or 342semi-automatic discovery, negotiation, selection, composition, mediation, invocation and interoperation of 343multiple services. The SEE TC will assess the subsequent and related works and implementation 344experience of existing efforts in a variety of sectors (financial, telecommunication, e-health and e- 345government) to define and implement these functions related with Semantic Web Services. Based on 346those experiences, the detailed analysis of requirements for Semantic Web services Architecture will be 347provided. 348The SEE TC will provide a test bed for the Web Services Modeling Ontology (WSMO), which is 349anticipated as a contribution for use by the TC on a non-exclusive basis, and will seek to demonstrate the 350viability of using WSMO concepts, relationships and definitions as a means to achieve successful 351dynamic interoperation of multiple ambient services, whether or not they share a common design or 352source. 353The TC anticipates contribution of the draft WSMX specifications and WSMO ontology on a non-exclusive 354basis. Other contributions will be accepted for consideration without any prejudice or restrictions, and 355evaluated on their technical merit, as long as the contributions conform to this charter. 356Following a top-down, component based development approach, the TC will provide a whole framework 357capable of carrying out the dynamic discovery, mediation, selection, invocation and inter-operation of 358Web Services and any other functionality which will be revealed during the requirements analysis phase. 359While the focus of this group will remain on a high level semantic description of components interfaces, 360the TC will seek tight cooperation with any group working on semantics-enabled functional components 361that fulfill the requirements of such system. 362The SEE TC will not implement actual software products or solutions based on the specifications 363developed along the course of work of this group. 31OASIS SEE TC Architecture and Information Model 08 September 2006 32Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 30
  • 12. 3643 Architecture Overview 365The following section provides an overview of the SEE infrastructure. It starts with a high level overview of 366the architecture, types of services it hosts, and it justifies division of platform services into vertical and 367horizontal layers. 368 3.1 Overview of SEE Infrastructure 369The key aim for SEE is to define functional mandatory services, decouple their functionality one from the 370other and to describe components’ interfaces in terms of offered functionality. One of the design principles 371of SOA (and Web Services in general) is the separation of the implementation of the service from its 372externally visible description. Such design allows replacement of one service with another as long as the 373new service supports the stable interface. Similarly, the SEE does not define services in terms of their 374design or implementation details, but only it terms of expected functionality and their externally visible 375behavior. The infrastructure of SEE is been presented in Figure 2. Ontologies – 1 Applications – 2 Developer Tools – 3 Problem Solving Layer Vertical Services e.g. Security – 16 Execution Management – 15 Discovery – 4 Adaptation – 5 Composition – 6 Choreography – 7 Mediation – 8 Communication Fault Handling – 10 Monitoring – 11 (external) – 9 Broker Layer Formal Languages – 12 Reasoning – 13 Storage – 14 Base Layer 376 377 Figure 2: SEE Infrastructure and its services 378We distinguish four different types of elements of an overall SEE where each element type is composed 379by some sub functionalities: 380 • The problem-solving layer which consists of (1) Ontologies, (2) Applications (e.g., e-tourism, e- 381 government) and (3) Developer tools (GUI tools such as ontology/web service description 382 engineering tools; generic developer tools such as language APIs, parsers/serializers, converters, 383 etc.). 384 • The broker layer which consists of (4) Discovery, (5) Adaptation (including selection and 385 negotiation), (6) Composition (web service composition techniques such as planning), (7) 386 Choreography, (8) Mediation ((a) Ontology mediation: techniques for combining Ontologies and 387 for overcoming differences between Ontologies; (b) Process mediation: overcoming differences in 388 message ordering, etc.), (9) Grounding (Communication – external), (10) Fault Handling 389 (Transactionality, Compensation, etc.), and (11) Monitoring. 390 • The base layer that is providing the exchange formalism used by the architecture, i.e., (12) 391 Formal languages (static ontology and behavioral, i.e., capability/choreography/orchestration 392 languages, connection between higher-level descriptions, e.g., WSML), (13) Reasoning 393 (techniques for reasoning over formal descriptions; LP, DL, FOL, behavioral languages, etc.) and 394 (14) Storage and Communication. 34OASIS SEE TC Architecture and Information Model 08 September 2006 35Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 30
  • 13. 395 • Finally, vertical services such as (15) Execution management and (16) Security (authentication/ 396 authorization, encryption, trust/certification). 397 398While some of these functionalities are provided as services, the others remain the entities required to let 399the overall system to function, but they are not services in terms of the Service Oriented Architectures. 400This causes that SEE is called an infrastructure, not just an architecture. While the Broker and Base 401layers (without Formal Languages) builds SEE architecture in terms of services, the Problem Solving 402layer adds the set of tools and entities, which causes that SEE becomes the complete Semantic Web 403Services oriented infrastructure. 404 405SOAs typically consist of a set of services, and a coordinator that combines the services and puts them to 406use. Talking about SOA in the context of SEE can sometimes be misleading since SEE is a SOA and at 407the same time it is the coordinator of another, larger SOA. The SEE differentiates two types of services: 408platform services (such as Discovery, Choreography, Data and Process mediation etc.) and user 409services (e.g. back-end applications services). Platform services are mandatory to enable the 410infrastructure to deliver its functionality as defined by its execution semantics. User services are exposed 411by information system external to SEE infrastructure, but they are still coordinated using SEE platform 412services. The SEE recommendation defines the scope for particular platform services in terms of their 413functionality, while it remains silent about the scope and the functionality of user services. In the diagram 4143 kappa is the SOA that SEE uses to enable the External SOA. SEE services are complementary pieces 415of functionality that directly enable aspects of External SOA. External SOA User Service User Service SEE Platform Service: Data Mediation Execution Management Platform Service: (Execution Discovery Semantics) Platform Service: […] User Service User Service 416 417 Figure 3: Platform Services versus User Services 418The SEE infrastructure consists of several decoupled services. This enables independent refinement of 419these services, so each of them can have its own architecture, without hindering the overall SEE 420infrastructure. Following the SOA design principles, the SEE infrastructure separates concerns of the 421components thereby separating the service descriptions and their interfaces from the implementation. 422This adds flexibility and scalability for upgrading or replacing the implementation of the services provided 423by the components that adhere to the required interfaces. 424The SEE recognizes vertical and horizontal services. Vertical services remain invisible to horizontal 425services, and during its execution, the horizontal services remain unaware that vertical services are 426executed together with them. This type of vertical service is provided through the inversion of control. 37OASIS SEE TC Architecture and Information Model 08 September 2006 38Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 30
  • 14. 427With this principle the vertical services invoke horizontal services, coordinating overall workflow, rather 428than horizontal service invoking the vertical. The following mandatory vertical platform services have been 429identified: Discovery, Adaptation, Composition, Choreography, Data Mediation, Process Mediation, 430Communication, Fault Handling, Monitoring, Storage and Reasoning. Additionally to it, the SEE specifies 431End User and Developer Tools services enabling end users and developers to interact with platform 432services. The SEE recognizes two vertical services, namely: Execution Management and Security. 433The existing Web Service technology describes and publishes the services interfaces as a WSDL 434document providing a good starting point for SOA. The architecture of the SEE TC infrastructure builds on 435the cornerstone technologies of the current web service technology and extends them towards the 436semantically enriched architecture. The service interfaces are provided to emphasize the reuse of 437components, where possible. WSML has been identified to describe platform services. 438 3.2 Distribution of SEE 439Fundamentally, in a Peer-to-Peer (P2P) network each node is entitled to have equal control. The network 440is controlled and maintained through the cooperation between participating nodes. Thus, there is no 441central control of operations but it is distributed over the network. Nodes in the network may cooperate 442with each other while performing some task(s). Figure 4 is a high level overview derived from the Web 443Services architecture. In the original diagram - kept in light blue – illustrated the internal and external 444facets of the web service architecture. The added red parts are logical extensions of the architecture to 445carter for the needs of semantics. Company A (provider) SWS interface Access to internal systems Company D (client) Internal SWS architecture client Company C (provider) WS interface Access to internal systems S WS External SWS architecture S WS Internal WS architecture Company B (provider) S WS middleware Internal service Internal service S WS S WS 446 447 Figure 4: Extension of Web Services Architecture with Semantic Layer 448A large bulk of the architecture concerns itself with the internal workings of the external architecture, 449decomposing its overall functionality in components like Discovery, Choreography, Data and Process 450Mediation, and specifying the relations between them. It is however worthwhile not forgetting about the 451internal architecture, for without it some envisioned aspects, like automatic negotiation, will not be 452achievable. 453In particular an application of SEE to grid environments makes a provider-side tier necessary. However, it 454is not strictly required and a business service with lesser requirements may choose to expose a standard 455WS interface plus a semantic description of it. Having an internal SWS architecture poses additional 456requirements for service providers, but given that service providers are willing to set up an additional WS 457tier, on top of their internal services to provide machine accessibility, the odds are in the favor that they 458are willing to set up an SWS tier to gain the benefits of machine processability. 459The requirement of a provider-side SWS tier does not contradict |anytoany|, it rather extends the 460architecture to the upper tier of the service providers, as illustrated by the Figure 5. 461 462 40OASIS SEE TC Architecture and Information Model 08 September 2006 41Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 30
  • 15. Service SEE Service Internal External Internal ANY SWS Architecture SWS Architecture SWS Architecture ANY 463 464 Figure 5: Distribution of SEE 465 466SEE’s SOA enables anarchic growth. Anarchic growth is characterized by a low or non-existent barrier of 467entry, and the limitation of resources and effort spent, to the node that is crossing the barrier, as opposed 468to load-balancing it over a set of common nodes. If somebody wants to set up a website then all he has to 469do is set up a web server and make sure it is listed on the major search engines. The economic burden of 470running the server lies with the one that wants to offers a web page. It is a self-regulating system in the 471sense that more traffic enables that particular node to grow in its computational and bandwidth capacity, 472because of the economic implications of increased traffic. 473Similarly the architecture of SEE may make use of provider-side hosted services to achieve the 474functionality that is required to interact with this service. This shifts the economic burden to a large extent 475from the broker to the endpoints, the actual service providers (see figure 5). 476 477It also allows business services which speak exotic protocols and that have developed custom adapters 478and mediation rules for themselves, to simply register their mediators with the broker like a website 479registers itself with (or is being crawled by) a search engine, instead of the economic-transaction implying, 480high-barrier task of asking the broker to host the mediation rules and use its resources for mediation. 481 Realm of the Service Provider External SOA User Service SEE Platform Service: Data Mediation SEE Execution Platform Management Service: (Execution Discovery Semantics) Platform Service: […] 482 Realm of the Broker 483 Figure 6: Anarchic growth of SEE 43OASIS SEE TC Architecture and Information Model 08 September 2006 44Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 30
  • 16. 484 3.3 Overview of a Single Node 485SEE the Service Oriented Architectural style where a software system is a set of collaborating 486components with well defined interfaces. Each component provides a specific service, exchange 487message with other component collectively performing a set of tasks. The components may reside in the 488same machine or may be distributed over the network as long as they can be accessed through a 489communication channel(s). Thus adopting SOA architectural style, SEE components are loosely coupled 490and provide a service that consists of a service layer, communication layer, persistency layers and a 491public interface to access the service. The service layer consists of application services (e.g., discovery, 492mediation, selection, etc.), a base service (e.g., reasoner, storage.), and a vertical service (e.g., security, 493monitoring, etc). Services are often characterized by exactly these operations, which they provide to other 494components. Preferably these services have machine processable meta-data descriptions. The 495component decoupling improves optimization allowing component clustering and load balancing among 496them. 497The internal communication model for a SEE node is based on an event-based messaging mechanism. The 498event-based messaging mechanism has is increased flexibility, better extensibility and improved reusability 499compared to other messaging mechanisms. 500The SEE architecture is decomposed to a set of functional (or service) layers where each layer 501corresponds to an abstraction of some aspect of the system. In most cases services provided by the upper 502layers are transparent to the lower layer. Software systems have progressed from initial one layer systems 503(e.g. mainframes) through two layer systems (e.g. simple client server), through three tiered application 504servers, through to n-layer systems, a generalization of three layer architectures, where multi-layer 505subarchitecture may be present in a top-level-layer. An example of a layered architecture is shown in 506figure 7. SEE Node Presentation/Interface Layer Service/Logic Layer Application Services Common Services Base Services Communication Layer Persistence Layer 507 508 Figure 7: SEE Node Layered Structure 509In figure 4 the user interface provides functionality for registering service descriptions with the SEE node 510and for displaying information on the execution of the system. The service layer includes the functional 511components providing application services, base services and common (or vertical) services and the 512communication layer is responsible for handling message exchange between SEE nodes, the requesters 513and providers of Web services. Finally the persistence layer consists of repositories for storing and 514retrieving data. 46OASIS SEE TC Architecture and Information Model 08 September 2006 47Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 30
  • 17. 5154 Structural View 516As presented in section 3, We distinguish four different types of elements of an overall SEE where each 517element type is composed by some sub functionalities: 518 • The problem-solving layer 519 • The broker layer 520 • The base layer 521 • The vertical services 522This chapter identifies functional components that play a role in the SEE architecture. Section 4.1 523describes the set of compulsory services for the Base and Application layers from figure 2. Section 4.2 524details the vertical services that are required across different layers of the architecture such as security 525and reliability. Section 4.3 describes interfaces to SEE for different categories of end-users and 526component developers. 527 4.1 Problem Solving Layer 528Problem solving layer rather than offering services itself, is utilizing services from the other layers 5294.1.1 Ontologies 530Ontologies are community contracts about a representation of a domain of discourse. Representation in 531here includes (1) formal parts that can be used for machine reasoning, and (2) informal parts like natural 532language descriptions and multimedia elements that help humans establish, maintain, and renew 533consensus about the meaning of concepts. 5344.1.2 Applications 535This component/service is concerned with (1) use case scenarios that help validate the real-world fitness 536of SEE services and (2) domain-specific implementations which will be used for testing of SEE services. 5374.1.3 Developer Tools 538The developer tools are any kind of tools related to Semantic Web Services that can be used by users of 539all competency levels. These can be editors for ontologies, web services, goals and mediators. Any kind 540of tools for creating mappings between ontologies for runtime mediation, for executing WSDL web 541services and managing SEE execution environments itself. 542 4.2 Application Layer 5434.2.1 Discovery 544Following the specification in the Web Service glossary, the Service Discovery component is responsible 545for “locating a machine-processable description of a Web service-related resource that may have been 546previously unknown and that meets certain functional criteria". WSMO Discovery provides a complete 547conceptual solution for the discovery problem in SWS settings, defining the border line between the 548different steps involved in the process of locating services, namely: goal discovery, goal refinement, 549service discovery and service contracting. Assuming that the users are expressing their requests using 550natural language or any other means, Goal discovery is about abstracting goals from these user requests. 551These goals are intended to be generic and reusable, thus the second step, Goal refinement, will refine 552the pre-defined goal discovered in the previous step to the actual user desire. 553For the next steps, a clear distinction between services and Web services must be made: a service is a 554concrete instance of a Web service having all the inputs specified, while a Web service is an abstract 49OASIS SEE TC Architecture and Information Model 08 September 2006 50Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 30
  • 18. 555entity, a class of concrete services. The third step becomes thus Web service discovery and implies 556matching formalized goals with formalized Web service descriptions, selecting Web services that can 557potentially be used to get the desired service. The last step becomes Service discovery and is about 558finding concrete services based on the abstract descriptions discovered in the previous step. 559In the case of SEE, the focus is on the Web service discovery step from the WSMO framework. Three 560different approaches, delivering discovery results of different accuracy, have been distinguished: 561Keyword-based discovery, Discovery based on simple descriptions of services (also known as 562Lightweight semantic discovery) and Discovery based on rich semantic descriptions of services 563(Heavyweight semantic discovery). 564In the Keyword-based discovery approach, a query engine matches the keywords from an input query 565against the keywords used to describe the service. Such an approach has the advantage that a huge 566amount of available services can be filtered or ranked rather quickly. 567In the Discovery based on simple descriptions of services, Web services and goals are modeled as sets 568of objects. More precisely, a Web service is represented as a set of objects that it delivers, while a goal is 569represented as a set of elements which are relevant to the client as the outcome of a service execution. 570The descriptions of these sets refer to ontologies that capture general knowledge about the problem 571domain under consideration. Logics based on set theory (e.g. Description Logics) are used to determine 572whether a goal description matches service descriptions. 573In the Discovery based on rich semantic descriptions of services approach, relations between inputs and 574outputs of the services and the goal as well as transition states, are considered during the matching 575process. More expressive logics that provide rule support (e.g. F-Logic) can be used to determine 576whether a goal description matches services descriptions. 577The Discovery interface provides two operations by which Web services matching a specific Goal 578description can be obtained. The first operation returns a possibly empty list of WG-mediators, linking to 579Goal description to Web Service descriptions. These are returned in descending order of how well the 580Web Services match the supplied Goal. The algorithm that determines the matching is part of the 581implementation of the method itself. This is shown in the model and choreography in Figures 8 and 9 582respectively. 583 Figure 8: Discovery communications Figure 9: Discovery choreography 584 585The second operation allows a ranking mechanism described as an ontology to be used in the discovery 586process. The ordering of results is in descending order as in the first method. 5874.2.2 Adaptation 588After discovering a set of potentially useful services, the Semantic Execution Environment (SEE) needs to 589check whether the services can actually fulfill the user's concrete goal and under what conditions. Those 590that cannot fulfill the goal are removed from the list of discovered services. This step is required as it is 591not feasible for a service to provide an exhaustive semantic description. Giving the Amazon bookstore 592service as an example, it is not feasible for Amazon to update the semantic description of their Web 52OASIS SEE TC Architecture and Information Model 08 September 2006 53Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 30
  • 19. 593service every time a new book is available or an existing book is changed, therefore we must check that 594Amazon actually currently has a copy of the book requested by the user. The process of checking 595whether and under what conditions a service can fulfill a concrete Goal is called negotiation in SEE. 596Once a list of Web services than can fulfil the user's concrete goal is prepared, the SEE must then 597choose one of the services to invoke. It is important that this selection is tailored to the user's needs, as 598for example while one user may require high quality another may prefer low price. This process is called 599selection. 600Negotiation and selection are tasks of the Adaptation component in SEE. 601The Adaptation component provides the following functionalities: 602 • checking which of the discovered Web services can fulfill the user's concrete goal 603 • finding out the non-functional properties related to the concrete goal, e.g. the currently applicable 604 price of the service 605 o potentially also dynamic negotiation of such properties, e.g. the best trade-off between 606 quality of service and the respective price 607 • selecting the most suitable Web service (or ordering them according to suitability) with respect to 608 the preferences of the user 609 Figure 10: Adaptation communications Figure 11: Adaptation choreography 610 6114.2.3 Composition 612The orchestration part of a service interface describes how the service makes use of other services to 613achieve its functionality. This definition is in accordance to the following definition given by the W3C 614Glossary [W3C Glossary, 2004]: An orchestration defines the sequence and conditions in which one Web 615Service invokes other Web Services in order to realize some useful function. That is, an orchestration is 616the pattern of interactions that a Web Service agent must follow in order to achieve its goal. 617Not only does this allow service provides to compose new services out of existing ones, reusing them as 618component parts at design time, it also gives the means to achieve composing functionality of services at 619runtime. 620Orchestrations and choreography are related concepts but orthogonal to each other. Every component 621service of an orchestrated service has a choreography and the choreography of the orchestrated service 622itself is an abstraction of the details of the orchestration where only communication with external entities 623is taken into account. 624 55OASIS SEE TC Architecture and Information Model 08 September 2006 56Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 30
  • 20. 6254.2.4 Choreography 626The Choreography part of a service interface describes the behavior of the service from a client point of 627view; this definition is in accordance to the following definition given by the W3C Glossary [W3C Glossary, 6282004]: Web Services Choreography concerns the interactions of services with their users. Any user of a 629Web service, automated or otherwise, is a client of that service. These users may, in turn, may be other 630Web Services, applications or human beings. 631After discovering a Web service description, one has to know the observable behavior of the Web service 632in order to achieve the desired functionality. The Choreography Engine is responsible for using the 633choreography descriptions of both the service requester and provider to drive the conversation between 634them. It is the responsibility of the Choreography Engine to maintain the state of a conversation and to 635take the correct action when that state is updated. For example, the update of the state of a choreography 636instance may be the result of a message received from a service provider. The consequent action, as 637described in the choreography instance, could be to forward the unchanged message to the service 638requester. 639 640The Choreography Engine in the SEE architecture has three main responsibilities: 641 1. Evaluating the transition rules defined in the Choreography Interface descriptions in WSMO Web 642 Service descriptions 643 2. Determines the legal instances for the last choreography step 644 3. Appropriately managing invocation requests to and from the Communication Manager 645 646During the first step, the interface descriptions are either fetched from the Resource Manager Service or 647appropriately parsed from the description (this depending on whether the requester sends her/his own 648descriptions). Once the choreographies of both parties are initialized, the start of the conversation is 649triggered by the instance data sent by the requester. This leads to the second step where the 650conversation is handled. During the interaction between the two choreographies, the data being 651exchanged is appropriately checked for conformance with respect to the choreography description and is 652always sent through the Process Mediation which determines which kind of data should be sent (if any) to 653the other party. Furthermore, during the evaluation of the rules, the choreography engine sets up the data 654required for invocation from the choreography description. The Choreography Engine does not perform 655the invocation itself but it rather forwards the invocation data to the Communication Manager which then 656processes this information appropriately and performs the invocation. The interaction between the two 657parties stops when either a choreography fails or all the required input data from the requester is 658consumed. 6594.2.5 Data Mediation 660SEE implements two levels of mediation, data and process level mediation, as distinct components. 661 662The Data Mediation component in SEE deals with heterogeneity problems that can appear at the data 663level. All messages in SEE are semantically described in WSML, meaning that data to be mediated is 664described in terms of ontologies, i.e. data consists of ontology instances. 665 666In this context, the heterogeneity problems at the data level appear when the requester and the provider 667of a service use different ontologies to conceptualize their domain. As a consequence, data has to be 668transformed from terms of one ontology (e.g. requester’s ontology) into terms of the other ontology (e.g. 669provider’s ontology). Due to the fact that these transformations are taking place during run-time the whole 670process has to be completely automatic. The data mediator component in SEE achieves this by relying on 671a set of mappings (semantic relationships) between the source and target ontology identified during 672design-time and stored in a persistent storage 1.7. 673 58OASIS SEE TC Architecture and Information Model 08 September 2006 59Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 30
  • 21. 674The mappings are in fact logical rules that are executed during run-time by a reasoner component against 675the incoming data, to output data as required by the target party. There are several ways (languages) of 676representing these rules, depending of the reasoning support available. In order to encourage 677interoperability between various mediation systems and to allow a flexible and an easy management of 678these mappings, a language independent format (called the Abstract Mapping Language) is used. As a 679consequence, each time a set of such mappings have to be used in a concrete scenario (as the instance 680transformation in SEE) the mappings have to be “grounded” to a concrete ontology representation 681language (in our case WSML). The grounding not only transforms the mappings in an executable form, 682but also associate them a formal semantics, a meaning in respect with the concrete representation 683language and the mediation scenario to be used in. 6844.2.6 Process Mediation 685Process level mediation deals with solving the interaction mismatches. Every semantic Web service has a 686specific choreography that describes they way in which the user should interact with it. Similarly, every 687requester of a service describes the way he wants to interact with a Web service by defining its own 688choreography. These choreographies describe semantically the control and data flow of messages that 689every partner can exchange. In cases where the choreography of the requestor (goal choreography) and 690the choreography of the Web Service do not match, process mediation is required. The Process 691Mediation component in SEE operates based on the two choreographies, and it is responsible for 692resolving mismatches between the choreographies (often referred to as public processes). These 693mismatches can appear not only when the requestor and the provider of a service use different 694conceptualizations of a domain (in which case data mediation is required), but also if they have different 695requirements for the message exchange pattern to be followed. Essentially this means that one of them 696expects to receive/send messages in a particular order while the other one has a different messages or a 697different message order that doesn’t match. The role of the process mediator is to retain, postpone, 698rebuild or create messages that would allow the communication process to continue 1.7. 6994.2.7 Communication External (Grounding) 700Apart from discovering Web services and composing them, the Semantic Execution Environment (SEE) 701also needs to communicate with the services — send the necessary request messages and receive the 702responses. All such external communication will be taken care of by this component. 703Because internal communication within the SEE uses semantic data and practically all currently deployed 704Web services use their specific XML formats, the External Communication component needs to translate 705between the involved data forms. This translation is also known as data grounding. Above that, this 706component also needs to support concrete network protocols (HTTP, SOAP, other bindings) to be able to 707exchange messages with the Web service. 708The External Communication component provides the following functionalities (only to be used where 709applicable): 710 • data grounding — two-way transformations between semantic data within SEE and the XML data 711 used in external communication 712 • network protocol binding — based on the WSDL description of the target Web service, the best 713 supported protocol binding will be selected for communication 714 • potentially also triple-space grounding for communication using TripleSpace 715The External Communication component provides the following functionalities (only to be used where 716applicable): 61OASIS SEE TC Architecture and Information Model 08 September 2006 62Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 30
  • 22. 717 • data grounding — two-way transformations between semantic data within SEE and the XML data 718 used in external communication 719 • network protocol binding — based on the WSDL description of the target Web service, the best 720 supported protocol binding will be selected for communication 721 • potentially also triple-space grounding for communication using TripleS 7224.2.8 Fault Handling 7234.2.9 Monitoring 724SEE expects to send and receive semantically enriched messages at its boundaries. A semantically 725enriched message is one where the content data of the message is described exclusively in terms of 726concepts from one or more ontologies. Other components of the framework may use the validator to 727check a document for consistency and correctness before continuing to process it. Correct data 728descriptions are then parsed by the individuals components into an internal representation .This 729guarantees that clients of SEE get consistent exceptions and faults for ill-defined WSML documents, 730giving more freedom to the components parser choice. 731 4.3 Base Layer 7324.3.1 Formal Languages 733Descriptions in SEE need different formal languages for the specification of different aspects of 734knowledge and services. The descriptions in a SEE can be decomposed into four dimensions: 735 736 • Static knowledge (ontologies) 737Ontologies are the core of the Semantic Web and of any Semantic Service Oriented Architecture. They 738can be used to formally describe any kind of knowledge on the Semantic Web and they form the 739vocabulary for the other dimensions for description in a SEE. 740 741 • Functional description (capabilities) 742 743With capabilities, services are viewed as functions which provide a certain output, given a particular input. 744This simplified view of services is useful for such tasks as discovery and composition. 745 • Behavioural description (choreography/orchestration) 746Choreographies describe the interface of a service in terms of possible interactions with a service. 747Orchestrations describe compositions of services. Choreographies and Orchestrations can both be 748viewed as decompositions of capabilities. 749 750 • Non-functional Properties 751Besides a functional description, services also have a non-functional description, with things as author, 752natural language description, QoS, pricing, service-level agreements, etc. 7534.3.2 Reasoning 754The semantic markup of Web services using specific ontologies provides the knowledge required by 755computer systems to help them automate tasks that otherwise require human intervention at run-time. 756Combining ontology-based markup with logic and reasoning provides very powerful instruments. 757Knowledge represented formally, using logical languages, can be interpreted and reasoned about by 758machines. Reasoning allows implicit knowledge to be inferred from existing knowledge and form an 759extremely powerful tool when combined with ontologies. 64OASIS SEE TC Architecture and Information Model 08 September 2006 65Copyright © OASIS Open 2006. All Rights Reserved. Page 22 of 30
  • 23. 760In the context of SEE, the Reasoner component is required for discovery as well as both process and 761data mediation. As a starting input, the current release of the WSMX Reasoner component allows for 762hierarchical queries on concepts, such as requests for subconcepts or superconcepts, entailment and, 763some support for queries against the knowledge base available to the reasoner. 764 765The Semantic Execution Environment (SEE) needs the reasoning component for service discovery as 766well as both process and data mediation. To enable processing of these tasks in an automated manner, 767machines need to have access to structured knowledge. Knowledge described formally using logical 768languages can be interpreted and reasoned about by machines. 769 770The Reasoning component in the SEE architecture provides an infrastructure for defining, managing and 771reasoning about formally represented knowledge. Mission critical features of this component are: hybrid 772reasoning based on DLs and logic programming, reasoning with very large instance bases, reasoning 773with heterogeneous and conflicting information, and reasoning in distributed environments. 774The Reasoning component provides a reasoner with the following functionalities: 775 • Hybrid reasoning with DLs and rules 776 • Implementation of novel efficient deductive database algorithms and optimization techniques 777 • Implementation of the RIF specification in order to handle rules from diverse rule systems and 778 allow WSML rules to be interchangeable with other rule languages supported by RIF 779 • Reasoning with very large instance databases 780 • Reasoning with heterogeneous formats of data possibly containing conflicting information 781 • Reasoning in a distributed environment - knowledge that is not necessarily present in one 782 location 783 • Common reasoning tasks - query answering, checking logical entailment, consistency checking 784 etc. 7854.3.3 Storage 786The Storage service in SEE is required to provide support based on two major aspects. Firstly, for storing 787information in distributed and scalable storage repositories and secondly to carryout communication 788according to Web principles, based on the model of persistent publish and read. 789 790The storage space is based on Web and semantics, i.e. it can be accessed over Web and have Resource 791Description Framework (RDF) triples as fundamental storage element. It supports storing information both 792at run time and at design time. It allows storing formal descriptions of Ontologies, Semantic Web Service 793descriptions, Mediation mappings, user Goals along with any contextual information about their use, any 794intermediary data during inter-platform services communication. The storage space can be composed on 795a single repository or widely distributed on multiple Web accessible storage repositories and visible as 796single virtual storage. 797 798The Storage service in SEE is not only about semantic data storage but also about scalable 799communication and coordination of Semantic Web Services based on emerging Triple Space Computing 800[1]. It has been achieved by extending Tuple Space Computing to support RDF and carding out 801communication and coordination based on persistent publish and read to enable decoupling based on 802time, reference and location. It supports intra SEE communication (i.e. inter Platform services 803communication), hence enables the decoupling of Platform services of Kappa SOA. It also supports 804communication between different SEE systems to form SEE cluster, hence enables the decoupling of 805different Semantic Web Services. 67OASIS SEE TC Architecture and Information Model 08 September 2006 68Copyright © OASIS Open 2006. All Rights Reserved. Page 23 of 30
  • 24. 806 4.4 Vertical Services 8074.4.1 Execution Management 808The execution management service is responsible for the coordination of the overall operational 809semantics of SEE that let the system achieve the promised functional semantics of its client-side 810interface. It takes the functionality offered by the individual services of the framework and orchestrates 811these atomic pieces into a coherent whole in an orderly, logical, and consistent fashion. 812 813These properties are guaranteed by the execution semantics, which are the topic of another specification 814developed in the SEE TC. The execution management service executes the execution semantics over the 815set of services that are available to it. 816 817The borders of one instance of SEE are defined by the services that are registered with the execution 818management service and may vary over time. By managing the control flow as well as the dataflow 819between the components it serves as a layer of indirection between the individual services, that are 820neither aware of each other nor of the context in which they are being invoked. 821 822Much of the perceived reliability of a SEE instance is rooted in this service, as it is the place where 823unavailability of individual services can be compensated for. It monitors its own execution as well as 824registered service, for a range of data relevant to the manageability of the overall system. 8254.4.2 Security 70OASIS SEE TC Architecture and Information Model 08 September 2006 71Copyright © OASIS Open 2006. All Rights Reserved. Page 24 of 30
  • 25. 8265 Summary 827This document outlined a comprehensive framework that integrates two complimentary and revolutionary 828technical advances, Service-Oriented Architectures (SOA) and Semantic Web, into a single computing 829architecture, that we call Semantically Execution Environment. While SOA is widely acknowledged for its 830potential to revolutionize the world of computing, that success depends on resolving two fundamental 831challenges that SOA does not address, integration, and search or mediation. In a services-oriented world, 832billions of services must be discovered and selected based on requirements, then orchestrated and 833adapted or integrated. SOA depends on but does not address either search or integration. The 834contribution of this document is to provide the semantics-based solution to search and integration that will 835enable the SOA revolution. The document provided a vision of the future enabled by SEE framework that 836places computing and programming at the services layer and places the real goal of computing, problem 837solving, in the hands of end users. 73OASIS SEE TC Architecture and Information Model 08 September 2006 74Copyright © OASIS Open 2006. All Rights Reserved. Page 25 of 30
  • 26. 838A. Acknowledgements 76OASIS SEE TC Architecture and Information Model 08 September 2006 77Copyright © OASIS Open 2006. All Rights Reserved. Page 26 of 30
  • 27. 839B. Appendix A – SEE API (Operations) 840Presentation of operations in pseudo syntactical syntax 841 Discovery 842Operation A: 843Searches the repository for those Web services that match the goal of the requester. The operation 844receives a goal as input and return a number of web services leading to the following signature. 845 846 discover(Goal goal): WebService[] 847 848Operation B: 849Searches the repository for those Web services that match the goal of the requester, according to a 850specific matching function. 851 852 discover(Goal goal, Matchtype type): WebService[] 853 854<WSML Supportive Ontologies> 855http://www.oasis-open.org/ex-semantics/ontologies/discovery 856http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess 857http://www.wsmo.org/2004/d2 858 859<WSML service description> 860 861wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-rule" 862namespace { _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#", 863 dc _"http://purl.org/dc/elements/11#", 864 xsd _"http://www.w3c.org/2001/XMLSchema#", 865 wsml _"http://www.wsmo.org/2004/wsml#", 866 d _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#", 867 dp _"http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess#", 868 dc _"http://www.oasis-open.org/ex-semantics/ontologies/discoverychoreography#", 869 oasm _"http://www.wsmo.org/ontologies/choreography/oasm#", 870 d2 _"http://www.wsmo.org/2004/d2#" 871} 872 873webService _"http://www.oasis-open.org/ex-semantics/services/discovery" 874 nonFunctionalProperties 875 dc#title hasValue "Discovery" 876 dc#type hasValue d2#Webservice 877 wsml#version hasValue "0.01" 878 endNonFunctionalProperties 879 880 importsOntology _"http://www.oasis-open.org/ex-semantics/ontologies/discovery" 881 79OASIS SEE TC Architecture and Information Model 08 September 2006 80Copyright © OASIS Open 2006. All Rights Reserved. Page 27 of 30
  • 28. 882capability _"http://www.oasis-open.org/ex-semantics/services/discovery#capability" 883 importsOntology { _"http://www.oasis-open.org/ex-semantics/ontologies/discovery"} 884 885 precondition discoveryPrecondition 886 postcondition discoveryPostcondition 887 888interface DiscoveryInterface 889 890choreography DiscoveryChoreography 891 stateSignature _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#statesignature" 892 importsOntology { 893 _"http://www.oasis-open.org/ex-semantics/ontologies/discovery", 894 _"http://www.oasis-open.org/ex-semantics/ontologies/discoveryprocess", 895 _"http://www.oasis-open.org/ex-semantics/ontologies/discoverychoreography" 896 } 897 898 in d2#Goal withGrounding { _"http://www.example.org/services/discovery/a" } 899 out dp#DiscoveryResult 900 controlled oasm#ControlState 901 902transitionRules _"http://www.oasis-open.org/ex-semantics/ontologies/discovery#transitionRules" 903 904 /* 905 * Request-reply style MEP 906 */ 907 forall {?controlstate, ?request} with ( 908 ?controlstate[oasm#value hasValue oasm#InitialState] memberOf 909oasm#ControlState and 910 ?request memberOf d2#Goal 911 ) do 912 add(?controlstate[oasm#value hasValue dc#EntreatyReceived]) 913 delete(?controlstate[oasm#value hasValue oasm#InitialState]) 914 add(_# memberOf dp#DiscoveryResult) 915 endForall 916 917 /* 918 * If the request specifies a match type the response will be 919 * matches from this type. 920 * 921 * Binds to a goal even though it's not used in the conclusion 922 * of the rule to make sure that we never fire without a request. 923 */ 924 forall {?controlstate, ?request} with ( 925 ?controlstate[oasm#value hasValue oasm#InitialState] memberOf 926oasm#ControlState and 927 ?request memberOf d2#Goal and 928 ?matchtype memberOf d#Match 929 ) do 930 add(_#[d#matchtype hasValue ?matchtype] memberOf dp#DiscoveryResult) 931 endForall 82OASIS SEE TC Architecture and Information Model 08 September 2006 83Copyright © OASIS Open 2006. All Rights Reserved. Page 28 of 30
  • 29. 932C. Revision History 933[optional; should not be included in OASIS Standards] 934 Revision Date Editor Changes Made 1 30/11/2005 michal.zaremba@deri.org Document created. Initial document structure proposed 2 14/12/2005 michal.zaremba@deri.org Explained what is SEE in section 1.1 Initial relationships to others groups and committees recognized in section 1.3 3 16/12/2005 matthew.moran@deri.org Added updates for section 2.3 and 2.5 4 16/12/2005 tomas.vitvar@deri.org Added updates for section 2.1 5 12/1/2006 matthew.moran@deri.org Added updates to section 4.1 6 4/2/2006 thomas.haselwanter@deri.org Added updates to section 3.2, 3.4, 4.1.1, 4.1.2, 4.1.3, 4.1.9, 4.1.10 7 17/2/2006 michal.zaremba@deri.org Architecture diagram updated based on research seminar in Innsbruck. Introduced concepts of user services and platform services. Introduced concepts of vertical and horizontal services. 8 18/02/2006 matthew.moran@deri.org Added paragraphs on relationship to WSRF in section 1.3 9 24/03/2006 Matthew.moran@deri.org Added section 2.6 – Conceptual model for SEE, first rough draft 10 24/03/2006 Michal.zaremba@deri.org Description for most of the components provided 11 17/04/2006 Matthew.moran@deri.org Structural updates to streamline the deliverable. Removed section on Conceptual Model for SEE (may be introduced in a separate deliverable). Removed shaded sections on distribution model for SEE (redundant). Removed section on Related Work (this goes to new SEE TC deliverable). 12 29/04/2006 Matthew.moran@deri.org Minor structural updates to document 13 1/05/2006 Michal.zaremba@deri.org Added section 2.4 Benefits of adding Semantics to SOA and section 2.2 on Dynamic SOA. Complete description of discovery with Informal Description of Functionality and Informal Interface 85OASIS SEE TC Architecture and Information Model 08 September 2006 86Copyright © OASIS Open 2006. All Rights Reserved. Page 29 of 30
  • 30. Discovery Operations added in SEE API Appendix End User Tools changed to Applications Data and Process Mediation merged on diagram just to Mediation. Short description provided for Ontologies, Formal Languages, Developer Tools and Applications Short Summary Provided Introduction to Section 4 provided Updated figure 3 and figure 6 – removed Kappa and Lambda Diagram from figure 2 updated – numbers added 14 8/05/2006 Michal.zaremba@deri.org Rename application layer to broker layer, Move beginning of section 4, which introduces SEE services to section 3. 15 8/05/2006 Michal.zaremba@deri.org Add explanation of what is the difference between architecture and infrastructure 16 8/09/2006 Matthew.moran@deri.org Revised section 1. 17 14/09/2006 B.j.norton@open.ac.uk Added choreography UML diagrams. 935 88OASIS SEE TC Architecture and Information Model 08 September 2006 89Copyright © OASIS Open 2006. All Rights Reserved. Page 30 of 30