• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Figure 1
 

Figure 1

on

  • 329 views

 

Statistics

Views

Total Views
329
Views on SlideShare
329
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Figure 1 Figure 1 Document Transcript

    • 1 2 Semantic SOA Reference Architecture 3Working Draft v0.1-r5, 21 July 2007 4Artifact Identifier: 5 wd-see-ssoa-ra-v0.1-r5 6Location: 7 Current: v0.1-r5, 21 July 2007 8 This Version: v0.1-r5, 21 July 2007 9 Previous Version: v0.1-r3, 16 June 2007 10Artifact Type: 11 Reference Architecture 12Technical Committee: 13 OASIS SEE TC 14Chair(s): 15 John Domingue, Open University, <j.b.domingue@open.ac.uk> 16 Michal Zaremba, DERI Innsbruck, <michal.zaremba@deri.at> 17Editor(s): 18 Mick Kerrigan, DERI Innsbruck, <mick.kerrigan@deri.at> 19 Matthew Moran, DERI Galway, <matthew.moran@deri.org> 20 Michal Zaremba, DERI Innsbruck, <michal.zaremba@deri.at> 21Contributing Authors(s): 22 Emilia Cimpian, DERI Innsbruck <emilia.cimpian@deri.at> 23 Thomas Haselwanter, DERI Innsbruck, <thomas.haselwanter@deri.at> 24 Joerg Hoffmann, DERI Innsbruck, <joerg.hoffmann@deri.at> 25 Jacek Kopecký, DERI Innsbruck <jacek.kopecky@deri.at> 26 Adrian Mocan, DERI Innsbruck, <adrian.mocan@deri.at> 27 Barry Norton, Open University, <b.j.norton@open.ac.uk> 28 James Scicluna, DERI Innsbruck <james.scicluna@deri.at> 29 Ioan Toma, DERI Innsbruck <ioan.toma@deri.at> 30 Tomas Vitvar, DERI Galway <tomas.vitvar@deri.org> 31 Maciej Zaremba, DERI Galway, <maciej.zaremba@deri.org> 32 33OASIS Conceptual Model topic area: 34 SOA, Reference Architecture, Semantic Web 35Related work: 36 This specification is related to: 37 1 The related work is specified in the separate OASIS SEE TC document titled 38 “Background and Related Work”. 39 2 The reference model is specified in the separate OASIS SEE TC document titled 40 “Reference Model for Semantic Service Oriented Architecture”. 1OASIS SEE TC Architecture and Information Model 08 September 2006 2Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 25
    • 41Abstract: 42 This document provides a specification for a Semantic Service Oriented Reference Architecture. 43 The application of Semantic Web technology to SOA brings enormous potential for tackling 44 interoperability problems that recur between software applications both within the scope of an 45 organization and across organization boundaries in the case of business-to-business (B2B) 46 interactions. Industry middleware, supporting Web Services as an enabling technology for SOA, 47 face the need to incorporate Semantic Web technology to allow for greater automation of the 48 tasks surrounding interoperability issues. In this specification, a reference architecture is 49 described, identifying the functionality required for a Semantic SOA, and describing how that 50 functionality can be combined to satisfy the semantic interoperability problems of SOAs. 51Status: 52 This document is in DRAFT status. This document is updated periodically on no particular 53 schedule. 54 Technical Committee members should send comments on this specification to the Technical 55 Committee’s email list. Others should send comments to the Technical Committee by using the 56 “Send A Comment” button on the Technical Committee’s web page at www.oasis- 57 open.org/committees/ex-semantics. 58 For information on whether any patents have been disclosed that may be essential to 59 implementing this specification, and any offers of patent licensing terms, please refer to the 60 Intellectual Property Rights section of the Technical Committee web page (www.oasis- 61 open.org/committees/ex-semantics/ipr.php. 62 The non-normative errata page for this specification is located at www.oasis- 63 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 25
    • 64Notices 65Copyright © OASIS Open 2007. All Rights Reserved. 66All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 67Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 68This document and translations of it may be copied and furnished to others, and derivative works that 69comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 70and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 71and this section are included on all such copies and derivative works. However, this document itself may 72not be modified in any way, including by removing the copyright notice or references to OASIS, except as 73needed for the purpose of developing any document or deliverable produced by an OASIS Technical 74Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 75be followed) or as required to translate it into languages other than English. 76The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 77or assigns. 78This document and the information contained herein is provided on an "AS IS" basis and OASIS 79DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 80WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 81OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 82PARTICULAR PURPOSE. 83OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 84necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 85to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 86such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 87produced this specification. 88OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 89any patent claims that would necessarily be infringed by implementations of this specification by a patent 90holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 91Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 92claims on its website, but disclaims any obligation to do so. 93OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 94might be claimed to pertain to the implementation or use of the technology described in this document or 95the extent to which any license under such rights might or might not be available; neither does it represent 96that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 97rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 98OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 99to be made available, or the result of an attempt made to obtain a general license or permission for the 100use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 101Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 102information or list of intellectual property rights will at any time be complete, or that any claims in such list 103are, in fact, Essential Claims. 7OASIS SEE TC Architecture and Information Model 08 September 2006 8Copyright © OASIS Open 2006. All Rights Reserved. Page 3 of 25
    • 104Table of Contents 1051 Introduction..............................................................................................................................................5 106 1.1 Organization of the Deliverable........................................................................................................5 107 1.2 Motivation.........................................................................................................................................5 108 1.3 Scope...............................................................................................................................................5 109 1.4 Underlying Principles........................................................................................................................5 110 1.5 Summary..........................................................................................................................................5 1112 Global View..............................................................................................................................................6 1123 Conceptual Model....................................................................................................................................8 1134 Services View........................................................................................................................................10 114 4.1 Broker Services..............................................................................................................................10 115 4.1.1 Discovery.................................................................................................................................10 116 4.1.2 Selection .................................................................................................................................11 117 4.1.3 Composition............................................................................................................................12 118 4.1.4 Data Mediation........................................................................................................................13 119 4.1.5 Process Mediation...................................................................................................................14 120 4.1.6 Transport Handler...................................................................................................................14 121 4.1.7 Grounding................................................................................................................................15 122 4.1.8 Choreography Execution.........................................................................................................15 123 4.1.9 Orchestration Execution..........................................................................................................16 124 4.2 Base Services.................................................................................................................................16 125 4.2.1 Logical Reasoner....................................................................................................................16 126 4.2.2 Repository...............................................................................................................................17 127 4.3 Vertical Services.............................................................................................................................19 128 4.3.1 Service management..............................................................................................................19 129 4.3.2 Security...................................................................................................................................19 1305 Process View.........................................................................................................................................20 131 5.1 Processes in the Context of SSOA.................................................................................................20 132 5.2 Describing process behavior as Execution Semantics...................................................................20 133 5.3 Goal-based Discovery Process......................................................................................................20 134 5.4 Service Invocation Process............................................................................................................20 135 5.5 Achieve Goal (Discovery and Invocation) Process.........................................................................20 136 5.6 Summary........................................................................................................................................20 1376 Future Work...........................................................................................................................................21 1387 References............................................................................................................................................22 139Appendix A. Acknowledgements..............................................................................................................23 140Appendix B. Appendix A – SEE API (Operations).....................................................................................24 141Appendix C. Revision History...................................................................................................................25 142 143 10OASIS SEE TC Architecture and Information Model 08 September 2006 11Copyright © OASIS Open 2006. All Rights Reserved. Page 4 of 25
    • 1441 Introduction 1451.1 Organization of the Deliverable 146It’s organized in four sections. This first section describes the motivation and scope. The second provides 147a global view placing the SSOA RA in context. The third and fourth sections describe two views on the 148reference architecture. The first of these is the services view, which describes the functionality required by 149a SSOA. Next is the process view which identifies the behavior required of an SSOA and describes the 150how the various services that make up the reference architecture combine to provide this behavior. 1511.2 Motivation 152Reading this should provide a non-expert in this area with the motivation for why an SSOA RA is useful 153and relevant. 1541.3 Scope 155For example the SSOA RA identifies the functionality and behavior required, but does not prescribe the 156ontological language or any technology-specific design choices (with the exception of the dependence on 157grounding to WSDL Web Service descriptions). 1581.4 Underlying Principles 159Brief description on principles of Semantic Web Services and SOA (and possibly others) 1601.5 Summary 13OASIS SEE TC Architecture and Information Model 08 September 2006 14Copyright © OASIS Open 2006. All Rights Reserved. Page 5 of 25
    • 1612 Global View 162 163 Figure 1: Global view on SEE (modified from [ref to SESA journal]) 164 165The global view shows how the services of SEE fit in the context of a problem-solving system (modified 166from [ref to SESA journal]. There are five layers shown in Figure 1. These are: 167 • Stakeholders: they form the group of various users that use the functionality of the architecture. 168 They include the users of backend systems, users formulating requests through graphical tools 169 and Web portals, and developers and system administrators monitoring and modifying the 170 resources used by the system. 171 • Problem solving layer: the applications and tools supporting stakeholders in the formulation of 172 problems and the description of requests that semantically encapsulate the problem description. 173 • Service request layer: these are represented as the goals that are created by the problem solving 174 layer that are dispatched to SEE for resolution 175 • Middleware layer: contains the platform services that are required to enable Semantic Web 176 services to be used for the resolution of goals from the problem-solving layer. This is analogous 177 to the middleware functionality offered by many enterprise service bus products. However the 178 services provided by SEE pay special attention to how Semantic Web technology can be 179 harnessed to provide a more automated solution to the design and execution of applications 180 using a Service Oriented Architecture. 16OASIS SEE TC Architecture and Information Model 08 September 2006 17Copyright © OASIS Open 2006. All Rights Reserved. Page 6 of 25
    • 181 • Service provider’s layer: the business services that provide the functionality to actually achieve 182 part of or the entire goal. They are represented as endpoints usually, but not necessarily, 183 described using WSDL. 19OASIS SEE TC Architecture and Information Model 08 September 2006 20Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 25
    • 1843 Conceptual Model 185The conceptual model is provided by the Semantic Execution Environment Technical Committee’s 186document, currently available as a draft, ‘Reference Model for Semantic Service Oriented Architecture’ 187[Norton and Mocan, 2007]. In this section we provide only an overview for convenience, explaining the 188model as diagrammed in Figure 2. 189 190 191 Figure 2: Reference Model as UML Class Diagram 22OASIS SEE TC Architecture and Information Model 08 September 2006 23Copyright © OASIS Open 2006. All Rights Reserved. Page 8 of 25
    • 192 193The central notions for service description are the WebService concept, and its counterpart Goal. The 194Semantic SOA Reference Model is notable is drawing this distinction between the offered service, 195described from the point of view of the provider, and the required goal, described from the point of view of 196the would-be consumer. Both are given a description in terms of ontologies, which they import. In both 197the description subsists in two parts: the capability is used to structure the description of functionality; the 198interface is used to describe behaviour. The latter therefore subsists in the SOA-RM concepts of an 199action model and a process model. The former imposes logical conditions that must exist over the action 200model and other ontological features before execution, in the precondition and assumption respectively, 201and over these models following successful execution, in the postcondition and effect respectively. 202Mediators are used to specify a connection between two models and the mediation that needs to take 203place to bridge their dissimilar representations. The Reference Architecture will use a WG-Mediator, for 204instance, to which WebService models can be connected to which Goals using mediation to overcome 205the differences in action and process models. 206This is provided by the SSOA Reference Model [reference]. Provide a summary of Web services, goals, 207ontologies and mediators for completeness. 25OASIS SEE TC Architecture and Information Model 08 September 2006 26Copyright © OASIS Open 2006. All Rights Reserved. Page 9 of 25
    • 2084 Services View 209As introduced in section 2 there are two types of services involved when a requester wishes to interact 210with a Semantic Execution Environment namely platform services and business services. Business 211services are those services available on the Web and whose semantic descriptions are available to the 212SEE. This section is related to the Platform services, which are those services that make up the Semantic 213Execution Environment itself and which manipulate elements of the Reference Model in order to fulfill the 214requests of users. Platform services are broken down into three different categories within the Semantic 215Execution Environment, namely broker services, base services and vertical services. In this section each 216of these different categories are explained and examples of the sorts of services that exist within each 217category are made with associated descriptions. 2184.1 Broker Services 219Middleware is software that allows independent applications, using heterogeneous definitions for the 220various information items that they require, to be able to communicate with each other, in an apparently 221transparent manner. For SEE, the middleware services enable it to act as a broker between client service 222requests and business services capable of satisfying those requests. Ultimately, through discovery, 223composition, mediation and invocation based on Semantic Web service annotation, SEE aims for flexible 224goal-driven service invocation where independent and heterogeneous service requesters and providers 225transparently co-operate together. 2264.1.1 Discovery 227The functionality of service discovery is further decomposed into three aspects. These are goal 228abstraction, service discovery and Web service discovery: 229 230Goal Abstraction: Goal abstraction is an optional pre-processing step that creates an abstract goal from 231a concrete goal. An abstract goal contains no instance data in its definition whereas a concrete goal will 232contain instance data. For example a concrete goal would be buy a book called Harry Potter and The 233Goblet of Fire while a corresponding abstract goal would be simply buy a book. The motivation for 234abstract goals is they provide a higher level goal description used in the next step (Web service 235discovery) to filter a potentially large set of candidate services. It can also be the case that the goal can 236be matched with some existing abstract brokered goal via data mediation, in which case a GG-Mediator 237connecting the goals, and specifying the mediation, will be returned. In many cases goal abstraction will 238not be required as the goal given to a Semantic Execution Environment by the requester will already be 239abstract and any instance data required will already be provided in a separate ontology. 240 Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#Goal 1 rm#Instance 0..* rm#GG-Mediator 0 .. * 241 242Web Service Discovery: At this stage, Web services are matched with goals at an abstract level based 243on the requested capability described in the abstract goal. Several types of matches may be found 244between the goal and candidate Web service descriptions. These include exact match, plug-in match, 245subsumption match, intersection match, and disjointness. The match may also involve an already 28OASIS SEE TC Architecture and Information Model 08 September 2006 29Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 25
    • 246computed mediation, which may be communicated via a WG-Mediator. This phase identifies a set of Web 247service descriptions that may be able to handle the request without yet taking cognizance of the instance 248data sent by the service requester. In our example, the request is not to buy any book but specifically a 249Harry Potter book. 250 251 Input Output (type) (multiplicity) (type) (multiplicity) rm#WG-Mediator0 .. 1 rm#WebService 0 .. * *rm#Goal 252 253Service Discovery: At this stage, services which match at abstract level are matched at instance-level. 254This involves the use of the original data provided by the service requester and may involve invoking the 255service provider to obtain information that is not included directly in the service description. In the context 256of our example, it is unlikely that a book seller will include details of their entire catalogue in the service 257description. Rather, book sellers like Amazon, provide an operation on their Web service enabling the 258lookup on the availability and details of specific items. This part of discovery may also involve the 259resolution of contractual or usage-negotiation issues that may be indicated in the service description. 260 Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#WebService 0 .. * rm#Instance 0..* rm#WG-Mediator 0 .. * 261 2624.1.2 Selection 263Selection is the process where one service which best satisfies user preferences is selected from the 264candidate services returned from the service discovery stage. As selection criteria, specified by the user, 265various non-functional properties such as Service Level Agreements (SLA), Quality of Services (QoS), 266etc. can be obtained from the goal description. On the service side the requested non-functional 267properties values are either directly specified in the service description or are provided (computed or 268collected) by a monitoring tool. Non-functional properties specified in goal and service descriptions are 269expressed in a semantic language, by means of logical rules using terms from NFP ontologies. 270An integrated part of the Selection is the Ranking process which generates an order list of services out of 271the candidate services set. The logical rules used to model non-functional properties of services are 272evaluated, during the ranking process, by a reasoning engine. Additional data is considered including 273user preferences i.e. which non-functional properties user is interested and the ordering direction as well 274as concrete instances data extracted from the goal description. The non-functional properties values 275obtained by evaluating the logical rules are sorted and the order list of services is built. Once the ranking 276process is completed, as a final step of the selection process the best candidate service is selected. 277 Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#WebService 0..1 31OASIS SEE TC Architecture and Information Model 08 September 2006 32Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 25
    • rm#WebService 1 .. * 2784.1.3 Composition 279Often, a web service that fulfills the entire user requirement is not available. A common example is travel 280planning, where usually there is no single provider covering all the transportation and accommodation as 281required for a particular itinerary. A more significant example is Business Process Management (BPM), 282where a company seeks to implement a new functionality by combining different services in its existing 283repository. 284Combining existing Web Services in a way that suits the requirement is, in general, a programming task. 285Composition, or web service composition (WSC), serves to support, or even fully automate, that 286programming. Automatic programming is known to be prohibitively difficult both in theory and practice; 287however, WSC has better chances to succeed due to its strong reliance on existing pieces (combination 288of existing functionalities as opposed to implementation of entirely new functionalities). Also, in many 289practical scenarios, the desired combinations are not overly complex. The tedious aspect for human work 290is finding the right services, and working out the details of combining them; both things might be 291supported quite well by a computer. 292Composition is usefully seen to happen at two different levels of abstraction: the functional level and the 293process level. At the functional level, web service executions are atomic transactions characterized 294entirely by the properties of their start and end points. The process level is much more realistic, in viewing 295web services as evolving and interacting processes with complex behavioral interfaces. Naturally, 296composition at the functional level (although it is still a hard problem) is much easier, both in theory and 297practice, than at the process level. Hence the former serves as a pre-filter for the latter: once a solution 298has been found that is valid relative to the functional descriptions, that solution is used as input to process 299level composition, where it is refined to also be valid relative to the procedural descriptions. 300Functional level descriptions of web services are typically written using a logic, specifying a condition – 301the precondition -- that must hold in order to apply the web service, and specifying another condition – the 302postcondition – that will hold upon execution of the web service. Formalisms of this kind have been 303considered for a long time in AI, and can be suitably adapted and extended for the purpose of WSC. For 304process-level composition, formalisms and methods from formal verification and from automatic deduction 305naturally lend themselves. 306In its simplest form, the component returns accepts a Goal and returns a sequence of Web Services that 307fulfill the task. Optionally, if a specific set of Web Services is at hand prior the composition, the component 308attempts to find the relevant Web Services within this set. Although the returned Web Services are in 309sequence, it might be the case that some (or all) of them are independent of each other and may be 310executed in parallel or in some other order. To this extent, we leave this process up to an external 311tool/component. This behavior is based on typical A.I. Planning techniques whereby the planner is not 312responsible for determining the flow of control of the relevant actions but rather to order the actions in a 313simple way such that the target goal is achieved. 314However, in most contexts related to Web Services (especially within BPM), one would like to achieve a 315workflow of the composed web services. Such a workflow would then be directly executed by an 316execution engine. In the context of SEE, such workflows would be described as an Orchestration. Note 317that a parallelization tool may also be integrated within this phase but it is not necessary. Without such a 318facility, the orchestration would be simply an explicit description with a sequence of Web Services to 319execute. 320Compose Goal Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#WebService 0..* 34OASIS SEE TC Architecture and Information Model 08 September 2006 35Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 25
    • 321 322Compose Goal Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#WebService 0..* rm#WebService 0..* 323 324Compose Goal Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#Orchestration 0..* 325 326Compose Goal Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 rm#Orchestration 0..* rm#WebService 0..* 327 3284.1.4 Data Mediation 329The Data Mediation component in SEE deals with heterogeneity problems that can appear at the data 330level. All messages in SEE are expressed in a semantic language, meaning that data to be mediated is 331described in terms of ontologies, i.e. data consists of ontology instances. 332 333In this context, the heterogeneity problems at the data level appear when the requester and the provider 334of a service use different ontologies to conceptualize their domain. As a consequence, data has to be 335transformed from the terms in one ontology (e.g. the requester’s) into the terms of the other ontology (e.g. 336the provider’s). This can be done during the discovery phase or in subsequent interactions between 337requester and provider. Due to the fact that these transformations must take place during run-time the 338whole process has to be completely automatic. The data mediator component in SEE achieves this by 339relying on a set of mappings (semantic relationships) between the source and target ontology identified 340during design-time and stored in a persistent storage. 341 342The mappings correspond to logical rules that are executed during run-time by a reasoning engine. There 343are various ways (formalisms) of representing these rules, depending on the reasoning support available. 344In order to encourage and enable the interoperability between various mediation systems and to allow the 345flexible and the easy management of these mappings, a language independent format is more desirable. 346But as a consequence, each time a set of such mappings have to be applied in a concrete scenario (as 347the instance transformation in SEE) the mappings have to be grounded to a concrete ontology 348representation language. The grounding not only transforms the mappings in an executable rules, but 349also associates them with a formal semantics which assures that the mapping rules are unequivocally 350interpreted and executed. 351 37OASIS SEE TC Architecture and Information Model 08 September 2006 38Copyright © OASIS Open 2006. All Rights Reserved. Page 13 of 25
    • Input Output (type) (multiplicity) (type) (multiplicity) rm#Instance 1..* rm#Instance 0..* rm#OO-Mediator 1 3524.1.5 Process Mediation 353Process Mediation deals with solving the heterogeneity mismatches at the behavioral level. That is, 354considering that two processes have to interact (one of them has to provide inputs that will contribute to 355the successful execution of the other one), but their interaction is hampered either by the underlying 356ontological formalism or by the sequence of actions taken by the two processes, the Process Mediator 357has the role of providing the necessary mechanism for solving these heterogeneity problems. As a 358service, a Process Mediator operates on two processes, represented in a certain formalism. It needs to 359know on what particular stage of the execution the two processes are, and what outputs have already 360been generated by the two processes. 361 362[Baeten, 2005] in his well known history of process algebra, provides several definitions for processes. 363One of them states that a process consists of a number of states and a number of transitions for going 364from one state to another. The draw-back of this model is the lack of mechanisms for modeling the 365interaction aspects – that is, during the execution from initial state to the final state, a system may interact 366with another system. Considering this definition with respect to the choreography definition of a Semantic 367Web Service, the choreography model can actually be considered a process, with the additional 368advantage of offering information regarding these interactions. 369In this context, the process mediation interface needs to be adjusted as defined in the following table 370 Input Output (type) (multiplicity) (type) (multiplicity) rm# 2 [rm#Choreograhy, 2 <identifier>] <identifier> 1 371 3724.1.6 Transport Handler 373The purpose of SEE is to enable the more flexible discovery, selection, composition and invocation of 374Web services. Invoking a Web service means sending a message over the wire, using one of a number of 375combinations of transport and messaging protocols. The Transport Handler is responsible for encoding 376any required protocols for outgoing messages and decoding any such protocols for incoming messages. 377Needs more. 378 Input Output (type) (multiplicity) (type) (multiplicity) 40OASIS SEE TC Architecture and Information Model 08 September 2006 41Copyright © OASIS Open 2006. All Rights Reserved. Page 14 of 25
    • 3794.1.7 Grounding 380Within SEE, all data types are instances of the semantic concepts from the SSOA RM. However, as the 381majority of existing Web services communicate using XML messages, transformations from the semantic 382data to XML (and vice versa) is necessary. These transformations are called lifting (from XML to 383semantics) and lowering (from semantics to XML). Both lifting and lowering can potentially be achieved 384with a single bidirectional mapping specification. 385The grounding transformations are required in order for the SEE to be able to invoke a Web service. For 386instance, Choreography Execution will be creating service-invocation events that identify the Web service 387operation to be invoked, along with any required input data. As shown in Figure 2, this data is lowered 388into an XML message that is then sent to the Web service, and any XML message coming back is then 389lifted back to the semantic form that can be used by the SEE. 390 391 392 Figure 2: An illustration of lifting and lowering grounding transformations 393 Input Output (type) (multiplicity) (type) (multiplicity) 3944.1.8 Choreography Execution 395The Choreography part of a service interface describes the behavior of the service from a client point of 396view; this definition is in accordance to the following definition given by the W3C Glossary [W3C Glossary, 3972004]: Web Services Choreography concerns the interactions of services with their users. Any user of a 398Web service, automated or otherwise, is a client of that service. These users may, in turn, may be other 399Web Services, applications or human beings. 400After discovering a Web service description, one has to know the observable behavior of the Web service 401in order to achieve the desired functionality. Choreography Execution is responsible for using the 402choreography descriptions of both the service and goal to drive the conversation between them. It is the 403responsibility of Choreography Execution to maintain the state of a conversation and to take the correct 404action when that state is updated. For example, the update of the state of a choreography instance may 405be the result of a message received from a service provider. The consequent action, as described in the 406choreography instance, could be to forward the unchanged message to the service requester. 407 408In SSOA RM, we propose the use of abstract state machines as the formalism for the rule-based 409description of choreographies. Choreography Execution in the SEE architecture has three main 410responsibilities: 411 • Evaluating the transition rules defined in the Choreography Interface descriptions 412 • Determining the legal instances after each transition fires 413 • Driving service invocation through creation of service-invocation events 414 43OASIS SEE TC Architecture and Information Model 08 September 2006 44Copyright © OASIS Open 2006. All Rights Reserved. Page 15 of 25
    • 415During the first step, the interface choreography descriptions of the goal and Web service are fetched and 416instantiated. Once both choreographies are initialized, the start of the conversation is triggered by the 417instance data sent by the requester. This leads to establishment of a conversation. During the interaction 418between the two choreographies, the data being exchanged is appropriately checked for conformance 419with respect to the choreography description. Process and data mediation are used as required. 420Furthermore, during the evaluation of the rules, the choreography engine sets up the data required for 421invocation from the choreography description. The Choreography Engine does not perform the invocation 422itself but rather creates the appropriate service-invocation events. The interaction between the two parties 423stops when either a choreography fails or all the required input data from the requester is consumed. Input Output (type) (multiplicity) (type) (multiplicity) rm#WebService 1 rm#Instance 0..1 rm#Goal 1 4244.1.9 Orchestration Execution 425Web services may use a composition of other Web services, goals and mediators to provide their 426functionality. In such a case, execution of the Web service involves the invocation of an Orchestration 427Engine over the orchestration of the service, which is a process model. Each step within an orchestration 428process may involve the evaluation of logical expressions over an ontology, the execution of a new goal, 429Web service or mediator, or the interaction with a goal or Web service, and as a result the update or 430storage of instances in an ontology. 431 Input Output (type) (multiplicity) (type) (multiplicity) rm#WebService 1 rm#Instance 0..1 432 4334.2 Base Services 434The lowest layer within the SEE reference architecture is the base service layer, which provides low level 435functionality required by the broker layer above. This layer can be view as a utility layer providing the 436generic tools needed to perform my complex functions at higher levels. 4374.2.1 Logical Reasoner 438The semantic markup of Web services using specific ontologies provides the knowledge required by 439computer systems to help them automate tasks that otherwise require human intervention at run-time. 440Combining ontology-based markup with logic and reasoning provides very powerful instruments. 441Knowledge represented formally, using logical languages, can be interpreted and reasoned about by 442machines. Reasoning allows implicit knowledge to be inferred from existing knowledge and form an 443extremely powerful tool when combined with ontologies. 444In the context of SEE, the Reasoner component is required for discovery as well as both process and 445data mediation. As a starting input, the current release of the WSMX Reasoner component allows for 446hierarchical queries on concepts, such as requests for sub-concepts or super-concepts, entailment and, 447some support for queries against the knowledge base available to the reasoner. 448The Semantic Execution Environment (SEE) needs the reasoning component for service discovery as 449well as both process and data mediation. To enable processing of these tasks in an automated manner, 450machines need to have access to structured knowledge. Knowledge described formally using logical 451languages can be interpreted and reasoned about by machines. The Reasoning component in the SEE 46OASIS SEE TC Architecture and Information Model 08 September 2006 47Copyright © OASIS Open 2006. All Rights Reserved. Page 16 of 25
    • 452architecture provides an infrastructure for defining, managing and reasoning about formally represented 453knowledge. 4544.2.2 Repository 455The repository component within the SEE reference architecture is responsible for storing all those 456elements of the SEE Reference model needed by other components within the architecture in order to 457fulfill their functionality. Thus the repository must be capable of storing ontologies, goals, web services 458and mediators. In terms of functionality over this repository of content it must be possible for new 459elements to be stored within the repository, existing elements to be retrieved or removed from the 460repository, and information provided to a requester about the contents of the repository. 461Store Ontology Input Output (type) (multiplicity) (type) (multiplicity) rm#Ontology 1 462 463Store Web Service Input Output (type) (multiplicity) (type) (multiplicity) rm#WebService 1 464 465Store Goal Input Output (type) (multiplicity) (type) (multiplicity) rm#Goal 1 466 467Store Mediator Input Output (type) (multiplicity) (type) (multiplicity) rm#Mediator 1 468 469Retrieve Ontology Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Ontology 0..1 470 471Retrieve Web Service Input Output (type) (multiplicity) (type) (multiplicity) 49OASIS SEE TC Architecture and Information Model 08 September 2006 50Copyright © OASIS Open 2006. All Rights Reserved. Page 17 of 25
    • <Identifier> 1 rm#WebService 0..1 472 473Retrieve Goal Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Goal 0..1 474 475Retrieve Mediator Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Mediator 0..1 476 477Remove Ontology Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Ontology 0..1 478 479Remove Web Service Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#WebService 0..1 480 481Remove Goal Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Goal 0..1 482 483Remove Mediator Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 1 rm#Mediator 0..1 484 485List Ontologies Input Output (type) (multiplicity) (type) (multiplicity) 52OASIS SEE TC Architecture and Information Model 08 September 2006 53Copyright © OASIS Open 2006. All Rights Reserved. Page 18 of 25
    • <Identifier> 0…* 486 487List Web Services Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 0…* 488 489List Goals Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 0…* 490 491List Mediators Input Output (type) (multiplicity) (type) (multiplicity) <Identifier> 0…* 492 4934.3 Vertical Services 494Needs Intro 4954.3.1 Service management 496 • Deploying and managing of services for SEE middleware 497 • Management of service descriptions in the SEE registry 4984.3.2 Security 499Security is ubiquitous across all layers and must be entwined with each middleware service as 500appropriate. Additionally there may be authentication and authorization control for access to SEE as a 501unit. 502 503 55OASIS SEE TC Architecture and Information Model 08 September 2006 56Copyright © OASIS Open 2006. All Rights Reserved. Page 19 of 25
    • 5045 Process View 505This section should contain simple UML diagrams for each of the processes that SEE supports. UML 506sequence diagrams may be easier to read than activity diagrams. Existing material is available from the 507earlier SEE Architecture intermediate deliverable and DIP and Knowledge Web research project. 508The processes should be a superset of those supported by IRS and WSMX as two concrete architectures 509and implementations for SEE. 5105.1 Processes in the Context of SSOA 5115.2 Describing process behavior as Execution Semantics 5125.3 Goal-based Discovery Process 5135.4 Service Invocation Process 5145.5 Achieve Goal (Discovery and Invocation) Process 5155.6 Summary 516 58OASIS SEE TC Architecture and Information Model 08 September 2006 59Copyright © OASIS Open 2006. All Rights Reserved. Page 20 of 25
    • 5176 Future Work 61OASIS SEE TC Architecture and Information Model 08 September 2006 62Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 25
    • 5187 References 519[Baeten, 2005] J. C. M. Baeten: A brief history of process algebra, Theoretical Computer Science, 335(2– 5203):131–146, 2005. 521[Norton and Mocan, 2007] B. Norton and A. Mocan: Reference Model for Semantic Service Oriented 522Architecture, OASIS Semantic Execution Environment Technical Committee Draft, 2007 523 64OASIS SEE TC Architecture and Information Model 08 September 2006 65Copyright © OASIS Open 2006. All Rights Reserved. Page 22 of 25
    • 524Appendix A.Acknowledgements 67OASIS SEE TC Architecture and Information Model 08 September 2006 68Copyright © OASIS Open 2006. All Rights Reserved. Page 23 of 25
    • 525Appendix B.Appendix A – SEE API (Operations) 70OASIS SEE TC Architecture and Information Model 08 September 2006 71Copyright © OASIS Open 2006. All Rights Reserved. Page 24 of 25
    • 526Appendix C.Revision History 527[optional; should not be included in OASIS Standards] 528 Revision Date Editor Changes Made 1 23/02/2007 matthew.moran@deri.org First ToC of SSOA RA specification taking draft specification for SEE Architecture and Interoperability v0.1 r16, as foundational input. 2 18/04/2007 matthew.moran@deri.org Added initial content for section 3: Global View and section 5: Services View. The content came from existing work within SEE directly and from a journal paper on SESA, referenced and to be published in June 2007. 3 16/05/2007 mick.kerrigan@deri.org Minor editorial changes, added comments to existing text and built to-do list for the next revision 4 16/06/2997 mick.kerrigan@deri.org New content on Data Mediation from Adrian Mocan, on Orchestration from Barry Norton, and Process Mediation review by Emilia Cimpian. Interfaces for *most* of the components along with Additional content additions in the headings of some sections and general editorial contributions by Mick Kerrigan. 5 21/07/07 mick.kerrigan@deri.org New content on composition from James, new content on grounding from Jacek. Updates of interfaces and descriptions from Mick. Process Mediation updated by Emilia. 6 29/08/07 b.j.norton@open.ac.uk New content on Reference Model. 529 73OASIS SEE TC Architecture and Information Model 08 September 2006 74Copyright © OASIS Open 2006. All Rights Reserved. Page 25 of 25