figure 1

Semantic SOA Reference Architecture

Working Draft v0.1-r5, 21 July 2007

Artifact Identifier:wd-see-ssoa-ra-v0.1-r5

Location:Current: v0.1-r5, 21 July 2007This Version: v0.1-r5, 21 July 2007Previous Version: v0.1-r3, 16 June 2007

Artifact Type:Reference Architecture

Technical Committee:OASIS SEE TC

Chair(s):John Domingue, Open University, <[email protected]>Michal Zaremba, DERI Innsbruck, <[email protected]>

Editor(s):Mick Kerrigan, DERI Innsbruck, <[email protected]>Matthew Moran, DERI Galway, <[email protected]>Michal Zaremba, DERI Innsbruck, <[email protected]>

Contributing Authors(s):Emilia Cimpian, DERI Innsbruck <[email protected]>Thomas Haselwanter, DERI Innsbruck, <[email protected]>Joerg Hoffmann, DERI Innsbruck, <[email protected]>Jacek Kopecký, DERI Innsbruck <[email protected]>Adrian Mocan, DERI Innsbruck, <[email protected]>Barry Norton, Open University, <[email protected]>James Scicluna, DERI Innsbruck <[email protected]>Ioan Toma, DERI Innsbruck <[email protected]>Tomas Vitvar, DERI Galway <[email protected]>Maciej Zaremba, DERI Galway, <[email protected]>

OASIS Conceptual Model topic area:SOA, Reference Architecture, Semantic Web

Related work:This specification is related to:

1 The related work is specified in the separate OASIS SEE TC document titled “Background and Related Work”.

1 The reference model is specified in the separate OASIS SEE TC document titled “Reference Model for Semantic Service Oriented Architecture”.

Abstract:This document provides a specification for a Semantic Service Oriented Reference Architecture. The application of Semantic Web technology to SOA brings enormous potential for tackling interoperability problems that recur between software applications both within the scope of an organization and across organization boundaries in the case of business-to-business (B2B)

OASIS SEE TC Architecture and Information Model 08 September 2006Copyright © OASIS Open 2006. All Rights Reserved. of 25

1

2

3

45

6789

1011

1213

141516

17181920

2122232425262728293031

323334

3536

37383940

4142434445

12

3

interactions. Industry middleware, supporting Web Services as an enabling technology for SOA, face the need to incorporate Semantic Web technology to allow for greater automation of the tasks surrounding interoperability issues. In this specification, a reference architecture is described, identifying the functionality required for a Semantic SOA, and describing how that functionality can be combined to satisfy the semantic interoperability problems of SOAs.

Status:This document is in DRAFT status. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasis-open.org/committees/ex-semantics.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (www.oasis-open.org/committees/ex-semantics/ipr.php.

The non-normative errata page for this specification is located at www.oasis-open.org/committees/ex-semantics.


4647484950

515253

54555657

58596061

6263

45

6

Notices

Copyright © OASIS Open 2007. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.


64

65

6667

6869707172737475

7677

7879808182

8384858687

8889909192

93949596979899100101102103

78

9

Table of Contents

1 Introduction......................................................................................................................................... 5

1.1 Organization of the Deliverable..................................................................................................5

1.2 Motivation................................................................................................................................... 5

1.3 Scope......................................................................................................................................... 5

1.4 Underlying Principles.................................................................................................................. 5

1.5 Summary.................................................................................................................................... 5

2 Global View......................................................................................................................................... 6

3 Conceptual Model............................................................................................................................... 7

4 Services View..................................................................................................................................... 8

4.1 Broker Services.......................................................................................................................... 8

4.1.1 Discovery............................................................................................................................... 8

4.1.2 Selection.............................................................................................................................. 99

4.1.3 Composition....................................................................................................................... 109

4.1.4 Data Mediation.................................................................................................................1110

4.1.5 Process Mediation............................................................................................................1211

4.1.6 Transport Handler............................................................................................................1211

4.1.7 Grounding........................................................................................................................ 1211

4.1.8 Choreography Execution..................................................................................................1312

4.1.9 Orchestration Execution...................................................................................................1412

4.2 Base Services....................................................................................................................... 1413

4.2.1 Logical Reasoner.............................................................................................................1413

4.2.2 Repository........................................................................................................................ 1413

4.3 Vertical Services...................................................................................................................1716

4.3.1 Service management.......................................................................................................1716

4.3.2 Security............................................................................................................................ 1716

5 Process View................................................................................................................................ 1817

5.1 Processes in the Context of SSOA.......................................................................................1817

5.2 Describing process behavior as Execution Semantics.........................................................1817

5.3 Goal-based Discovery Process............................................................................................1817

5.4 Service Invocation Process..................................................................................................1817

5.5 Achieve Goal (Discovery and Invocation) Process...............................................................1817

5.6 Summary.............................................................................................................................. 1817

6 Future Work.................................................................................................................................. 1918

Appendix A. Acknowledgements...........................................................................................................2119

Appendix B. Appendix A – SEE API (Operations).................................................................................2220

Appendix C. Revision History................................................................................................................2321


104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

1011

12

1 Introduction

1.1 Organization of the DeliverableIt’s organized in four sections. This first section describes the motivation and scope. The second provides a global view placing the SSOA RA in context. The third and fourth sections describe two views on the reference architecture. The first of these is the services view, which describes the functionality required by a SSOA. Next is the process view which identifies the behavior required of an SSOA and describes the how the various services that make up the reference architecture combine to provide this behavior.

1.2 MotivationReading this should provide a non-expert in this area with the motivation for why an SSOA RA is useful and relevant.

1.3 ScopeFor example the SSOA RA identifies the functionality and behavior required, but does not prescribe the ontological language or any technology-specific design choices (with the exception of the dependence on grounding to WSDL Web Service descriptions).

1.4 Underlying PrinciplesBrief description on principles of Semantic Web Services and SOA (and possibly others)

1.5 Summary


143

144

145146147148149

150

151152

153

154155156

157

158

159

1314

15

2 Global View

Figure 1: Global view on SEE (modified from [ref to SESA journal])

The global view shows how the services of SEE fit in the context of a problem-solving system (modified from [ref to SESA journal]. There are five layers shown in Figure 1. These are:

Stakeholders: they form the group of various users that use the functionality of the architecture. They include the users of backend systems, users formulating requests through graphical tools and Web portals, and developers and system administrators monitoring and modifying the resources used by the system.

Problem solving layer: the applications and tools supporting stakeholders in the formulation of problems and the description of requests that semantically encapsulate the problem description.

Service request layer: these are represented as the goals that are created by the problem solving layer that are dispatched to SEE for resolution

Middleware layer: contains the platform services that are required to enable Semantic Web services to be used for the resolution of goals from the problem-solving layer. This is analogous to the middleware functionality offered by many enterprise service bus products. However the services provided by SEE pay special attention to how Semantic Web technology can be harnessed to provide a more automated solution to the design and execution of applications using a Service Oriented Architecture.


160

161162

163

164165

166167168169

170171

172173

174175176177178179

1617

18

Mick Kerrigan, 06/16/07,

This picture is now out of date but I don’t have the original to change it. The only change is that the service registry and knowledge bases are joined into one repository. Matt can you send it to me.

Service provider’s layer: the business services that provide the functionality to actually achieve part of or the entire goal. They are represented as endpoints usually, but not necessarily, described using WSDL.


180181182

1920

21

3 Conceptual ModelThe conceptual model is provided by the Semantic Execution Environment Technical Committee’s document, currently available as a draft, ‘Reference Model for Semantic Service Oriented Architecture’ [Norton and Mocan, 2007]. In this section we provide only an overview for convenience, explaining the model as diagrammed in Figure 2.

Figure 2: Reference Model as UML Class Diagram


183

184185186187

188

189190

2223

24

mhaines, 08/29/07,

I still think a concept map similar to SOA-RM should come first. This diagram is just too disconnected from SOA-RM.


Minor updates from Mick

The central notions for service description are the WebService concept, and its counterpart Goal. The Semantic SOA Reference Model is notable is drawing this distinction between the offered service, described from the point of view of the provider, and the required goal, described from the point of view of the would-be consumer. Both are given a description in terms of ontologies, which they import. In both the description subsists in two parts: the capability is used to structure the description of functionality; the interface is used to describe behaviour. The latter therefore subsists in the SOA-RM concepts of an action model and a process model. The former imposes logical conditions that must exist over the action model and other ontological features before execution, in the precondition and assumption respectively, and over these models following successful execution, in the postcondition and effect respectively.

Mediators are used to specify a connection between two models and the mediation that needs to take place to bridge their dissimilar representations. The Reference Architecture will use a WG-Mediator, for instance, to which WebService models can be connected to which Goals using mediation to overcome the differences in action and process models.

This is provided by the SSOA Reference Model [reference]. Provide a summary of Web services, goals, ontologies and mediators for completeness.


191

192193194195196197198199200

201202203204

205206

2526

27


Waiting for update from Barry

4 Services ViewAs introduced in section 2 there are two types of services involved when a requester wishes to interact with a Semantic Execution Environment namely platform services and business services. Business services are those services available on the Web and whose semantic descriptions are available to the SEE. This section is related to the Platform services, which are those services that make up the Semantic Execution Environment itself and which manipulate elements of the Reference Model in order to fulfill the requests of users. Platform services are broken down into three different categories within the Semantic Execution Environment, namely broker services, base services and vertical services. In this section each of these different categories are explained and examples of the sorts of services that exist within each category are made with associated descriptions.

4.1 Broker ServicesMiddleware is software that allows independent applications, using heterogeneous definitions for the various information items that they require, to be able to communicate with each other, in an apparently transparent manner. For SEE, the middleware services enable it to act as a broker between client service requests and business services capable of satisfying those requests. Ultimately, through discovery, composition, mediation and invocation based on Semantic Web service annotation, SEE aims for flexible goal-driven service invocation where independent and heterogeneous service requesters and providers transparently co-operate together.

4.1.1 Discovery

The functionality of service discovery is further decomposed into three aspects. These are goal abstraction, service discovery and Web service discovery:

Goal Abstraction: Goal abstraction is an optional pre-processing step that creates an abstract goal from a concrete goal. An abstract goal contains no instance data in its definition whereas a concrete goal will contain instance data. For example a concrete goal would be buy a book called Harry Potter and The Goblet of Fire while a corresponding abstract goal would be simply buy a book. The motivation for abstract goals is they provide a higher level goal description used in the next step (Web service discovery) to filter a potentially large set of candidate services. It can also be the case that the goal can be matched with some existing abstract brokered goal via data mediation, in which case a GG-Mediator connecting the goals, and specifying the mediation, will be returned. In many cases goal abstraction will not be required as the goal given to a Semantic Execution Environment by the requester will already be abstract and any instance data required will already be provided in a separate ontology.

Input

(type) (multiplicity)

Output


rm#Goal 1 rm#Goal 1

rm#Instance 0..*

rm#GG-Mediator 0 .. *

Web Service Discovery: At this stage, Web services are matched with goals at an abstract level based on the requested capability described in the abstract goal. Several types of matches may be found between the goal and candidate Web service descriptions. These include exact match, plug-in match, subsumption match, intersection match, and disjointness. The match may also involve an already


207

208209210211212213214215216

217

218219220221222223224

225

226227

228

229230231232233234235236237238

239

240

241242243244

2829

30


Interface updated by Mick

computed mediation, which may be communicated via a WG-Mediator. This phase identifies a set of Web service descriptions that may be able to handle the request without yet taking cognizance of the instance data sent by the service requester. In our example, the request is not to buy any book but specifically a Harry Potter book.

Input


Output


rm#Goal 1 rm#WebService 0 .. *

rm#WG-Mediator 0 .. *

Service Discovery: At this stage, services which match at abstract level are matched at instance-level. This involves the use of the original data provided by the service requester and may involve invoking the service provider to obtain information that is not included directly in the service description. In the context of our example, it is unlikely that a book seller will include details of their entire catalogue in the service description. Rather, book sellers like Amazon, provide an operation on their Web service enabling the lookup on the availability and details of specific items. This part of discovery may also involve the resolution of contractual or usage-negotiation issues that may be indicated in the service description.

Input


Output


rm#Goal 1 rm#WebService 0 .. *

rm#Instance 0..* rm#WG-Mediator 0 .. *

4.1.2 Selection

Selection is the process where one service which best satisfies user preferences is selected from the candidate services returned from the service discovery stage. As selection criteria, specified by the user, various non-functional properties such as Service Level Agreements (SLA), Quality of Services (QoS), etc. can be obtained from the goal description. On the service side the requested non-functional properties values are either directly specified in the service description or are provided (computed or collected) by a monitoring tool. Non-functional properties specified in goal and service descriptions are expressed in a semantic language, by means of logical rules using terms from NFP ontologies.

An integrated part of the Selection is the Ranking process which generates an order list of services out of the candidate services set. The logical rules used to model non-functional properties of services are evaluated, during the ranking process, by a reasoning engine. Additional data is considered including user preferences i.e. which non-functional properties user is interested and the ordering direction as well as concrete instances data extracted from the goal description. The non-functional properties values obtained by evaluating the logical rules are sorted and the order list of services is built. Once the ranking process is completed, as a final step of the selection process the best candidate service is selected.

Input


Output


rm#Goal 1 rm#WebService 0..1


245246247248

249

250

251

252253254255256257258

259

260

261

262263264265266267268

269270271272273274275

276

3132

33



Barry Norton, 05/16/07,

I su

rm#WebService 1 .. *

4.1.3 Composition

Often, a web service that fulfills the entire user requirement is not available. A common example is travel planning, where usually there is no single provider covering all the transportation and accommodation as required for a particular itinerary. A more significant example is Business Process Management (BPM), where a company seeks to implement a new functionality by combining different services in its existing repository.

Combining existing Web Services in a way that suits the requirement is, in general, a programming task. Composition, or web service composition (WSC), serves to support, or even fully automate, that programming. Automatic programming is known to be prohibitively difficult both in theory and practice; however, WSC has better chances to succeed due to its strong reliance on existing pieces (combination of existing functionalities as opposed to implementation of entirely new functionalities). Also, in many practical scenarios, the desired combinations are not overly complex. The tedious aspect for human work is finding the right services, and working out the details of combining them; both things might be supported quite well by a computer.

Composition is usefully seen to happen at two different levels of abstraction: the functional level and the process level. At the functional level, web service executions are atomic transactions characterized entirely by the properties of their start and end points. The process level is much more realistic, in viewing web services as evolving and interacting processes with complex behavioral interfaces. Naturally, composition at the functional level (although it is still a hard problem) is much easier, both in theory and practice, than at the process level. Hence the former serves as a pre-filter for the latter: once a solution has been found that is valid relative to the functional descriptions, that solution is used as input to process level composition, where it is refined to also be valid relative to the procedural descriptions.

Functional level descriptions of web services are typically written using a logic, specifying a condition – the precondition -- that must hold in order to apply the web service, and specifying another condition – the postcondition – that will hold upon execution of the web service. Formalisms of this kind have been considered for a long time in AI, and can be suitably adapted and extended for the purpose of WSC. For process-level composition, formalisms and methods from formal verification and from automatic deduction naturally lend themselves.

In its simplest form, the component returns accepts a Goal and returns a sequence of Web Services that fulfill the task. Optionally, if a specific set of Web Services is at hand prior the composition, the component attempts to find the relevant Web Services within this set. Although the returned Web Services are in sequence, it might be the case that some (or all) of them are independent of each other and may be executed in parallel or in some other order. To this extent, we leave this process up to an external tool/component. This behavior is based on typical A.I. Planning techniques whereby the planner is not responsible for determining the flow of control of the relevant actions but rather to order the actions in a simple way such that the target goal is achieved.

However, in most contexts related to Web Services (especially within BPM), one would like to achieve a workflow of the composed web services. Such a workflow would then be directly executed by an execution engine. In the context of SEE, such workflows would be described as an Orchestration. Note that a parallelization tool may also be integrated within this phase but it is not necessary. Without such a facility, the orchestration would be simply an explicit description with a sequence of Web Services to execute.

Compose Goal

Input


Output


rm#Goal 1 rm#WebService 0..*


277

278279280281282

283284285286287288289290

291292293294295296297298

299300301302303304

305306307308309310311312

313314315316317318

319

320

3435

36

Compose Goal

Input


Output


rm#Goal 1 rm#WebService 0..*

rm#WebService 0..*

Compose Goal

Input


Output


rm#Goal 1 rm#Orchestration 0..*

Compose Goal

Input


Output


rm#Goal 1 rm#Orchestration 0..*

rm#WebService 0..*

4.1.4 Data Mediation

The Data Mediation component in SEE deals with heterogeneity problems that can appear at the data level. All messages in SEE are expressed in a semantic language, meaning that data to be mediated is described in terms of ontologies, i.e. data consists of ontology instances.

In this context, the heterogeneity problems at the data level appear when the requester and the provider of a service use different ontologies to conceptualize their domain. As a consequence, data has to be transformed from the terms in one ontology (e.g. the requester’s) into the terms of the other ontology (e.g. the provider’s). This can be done during the discovery phase or in subsequent interactions between requester and provider. Due to the fact that these transformations must take place during run-time the whole process has to be completely automatic. The data mediator component in SEE achieves this by relying on a set of mappings (semantic relationships) between the source and target ontology identified during design-time and stored in a persistent storage.

The mappings correspond to logical rules that are executed during run-time by a reasoning engine. There are various ways (formalisms) of representing these rules, depending on the reasoning support available. In order to encourage and enable the interoperability between various mediation systems and to allow the flexible and the easy management of these mappings, a language independent format is more desirable. But as a consequence, each time a set of such mappings have to be applied in a concrete scenario (as the instance transformation in SEE) the mappings have to be grounded to a concrete ontology representation language. The grounding not only transforms the mappings in an executable rules, but also associates them with a formal semantics which assures that the mapping rules are unequivocally interpreted and executed.


321

322

323

324

325

326

327

328329330

331

332333334335336337338339

340

341342343344345346347348349

350

3738

39


Update from James

Input


Output


rm#Instance 1..* rm#Instance 0..*

rm#OO-Mediator 1

4.1.5 Process Mediation

Process Mediation deals with solving the heterogeneity mismatches at the behavioral level. That is, considering that two processes have to interact (one of them has to provide inputs that will contribute to the successful execution of the other one), but their interaction is hampered either by the underlying ontological formalism or by the sequence of actions taken by the two processes, the Process Mediator has the role of providing the necessary mechanism for solving these heterogeneity problems. As a service, a Process Mediator operates on two processes, represented in a certain formalism. It needs to know on what particular stage of the execution the two processes are, and what outputs have already been generated by the two processes.

[Baeten, 2005] in his well known history of process algebra, provides several definitions for processes. One of them states that a process consists of a number of states and a number of transitions for going from one state to another. The draw-back of this model is the lack of mechanisms for modeling the interaction aspects – that is, during the execution from initial state to the final state, a system may interact with another system. Considering this definition with respect to the choreography definition of a Semantic Web Service, the choreography model can actually be considered a process, with the additional advantage of offering information regarding these interactions.

In this context, the process mediation interface needs to be adjusted as defined in the following table

Input


Output


rm# 2 [rm#Choreograhy, <identifier>]

2

<identifier> 1

4.1.6 Transport Handler

The purpose of SEE is to enable the more flexible discovery, selection, composition and invocation of Web services. Invoking a Web service means sending a message over the wire, using one of a number of combinations of transport and messaging protocols. The Transport Handler is responsible for encoding any required protocols for outgoing messages and decoding any such protocols for incoming messages.

Needs more.

Input


Output



351

352353354355356357358359

360

361362363364365366367

368

369

370

371

372373374375

376

377

4041

42


Matt to provide update


Updated by Emilia

4.1.7 Grounding

Within SEE, all data types are instances of the semantic concepts from the SSOA RM. However, as the majority of existing Web services communicate using XML messages, transformations from the semantic data to XML (and vice versa) is necessary. These transformations are called lifting (from XML to semantics) and lowering (from semantics to XML). Both lifting and lowering can potentially be achieved with a single bidirectional mapping specification.

The grounding transformations are required in order for the SEE to be able to invoke a Web service. For instance, Choreography Execution will be creating service-invocation events that identify the Web service operation to be invoked, along with any required input data. As shown in Figure 2, this data is lowered into an XML message that is then sent to the Web service, and any XML message coming back is then lifted back to the semantic form that can be used by the SEE.

Figure 2: An illustration of lifting and lowering grounding transformations

Input


Output


4.1.8 Choreography Execution

The Choreography part of a service interface describes the behavior of the service from a client point of view; this definition is in accordance to the following definition given by the W3C Glossary [W3C Glossary, 2004]: Web Services Choreography concerns the interactions of services with their users. Any user of a Web service, automated or otherwise, is a client of that service. These users may, in turn, may be other Web Services, applications or human beings.

After discovering a Web service description, one has to know the observable behavior of the Web service in order to achieve the desired functionality. Choreography Execution is responsible for using the choreography descriptions of both the service and goal to drive the conversation between them. It is the responsibility of Choreography Execution to maintain the state of a conversation and to take the correct action when that state is updated. For example, the update of the state of a choreography instance may be the result of a message received from a service provider. The consequent action, as described in the choreography instance, could be to forward the unchanged message to the service requester.

In SSOA RM, we propose the use of abstract state machines as the formalism for the rule-based description of choreographies. Choreography Execution in the SEE architecture has three main responsibilities:

Evaluating the transition rules defined in the Choreography Interface descriptions

Determining the legal instances after each transition fires

Driving service invocation through creation of service-invocation events

During the first step, the interface choreography descriptions of the goal and Web service are fetched and instantiated. Once both choreographies are initialized, the start of the conversation is triggered by the


378

379380381382383

384385386387388

389

390391

392

393

394395396397398

399400401402403404405

406

407408409

410

411

412

413

414415

4344

45


Content updated by Jacek


Mick to update Image

instance data sent by the requester. This leads to establishment of a conversation. During the interaction between the two choreographies, the data being exchanged is appropriately checked for conformance with respect to the choreography description. Process and data mediation are used as required. Furthermore, during the evaluation of the rules, the choreography engine sets up the data required for invocation from the choreography description. The Choreography Engine does not perform the invocation itself but rather creates the appropriate service-invocation events. The interaction between the two parties stops when either a choreography fails or all the required input data from the requester is consumed.

Input


Output


rm#WebService 1 rm#Instance 0..1

rm#Goal 1

4.1.9 Orchestration Execution

Web services may use a composition of other Web services, goals and mediators to provide their functionality. In such a case, execution of the Web service involves the invocation of an Orchestration Engine over the orchestration of the service, which is a process model. Each step within an orchestration process may involve the evaluation of logical expressions over an ontology, the execution of a new goal, Web service or mediator, or the interaction with a goal or Web service, and as a result the update or storage of instances in an ontology.

Input


Output


rm#WebService 1 rm#Instance 0..1

4.2 Base ServicesThe lowest layer within the SEE reference architecture is the base service layer, which provides low level functionality required by the broker layer above. This layer can be view as a utility layer providing the generic tools needed to perform my complex functions at higher levels.

4.2.1 Logical Reasoner

The semantic markup of Web services using specific ontologies provides the knowledge required by computer systems to help them automate tasks that otherwise require human intervention at run-time. Combining ontology-based markup with logic and reasoning provides very powerful instruments. Knowledge represented formally, using logical languages, can be interpreted and reasoned about by machines. Reasoning allows implicit knowledge to be inferred from existing knowledge and form an extremely powerful tool when combined with ontologies.

In the context of SEE, the Reasoner component is required for discovery as well as both process and data mediation. As a starting input, the current release of the WSMX Reasoner component allows for hierarchical queries on concepts, such as requests for sub-concepts or super-concepts, entailment and, some support for queries against the knowledge base available to the reasoner.

The Semantic Execution Environment (SEE) needs the reasoning component for service discovery as well as both process and data mediation. To enable processing of these tasks in an automated manner, machines need to have access to structured knowledge. Knowledge described formally using logical languages can be interpreted and reasoned about by machines. The Reasoning component in the SEE architecture provides an infrastructure for defining, managing and reasoning about formally represented knowledge.


416417418419420421422

423

424425426427428429

430

431

432

433434435

436

437438439440441442

443444445446

447448449450451452

4647

48


Removed the interface of the reasoner. Does everyone still agree with this?






This is too long in my opinion

4.2.2 Repository

The repository component within the SEE reference architecture is responsible for storing all those elements of the SEE Reference model needed by other components within the architecture in order to fulfill their functionality. Thus the repository must be capable of storing ontologies, goals, web services and mediators. In terms of functionality over this repository of content it must be possible for new elements to be stored within the repository, existing elements to be retrieved or removed from the repository, and information provided to a requester about the contents of the repository.

Store Ontology

Input


Output


rm#Ontology 1

Store Web Service

Input


Output


rm#WebService 1

Store Goal

Input


Output


rm#Goal 1

Store Mediator

Input


Output


rm#Mediator 1

Retrieve Ontology

Input


Output


<Identifier> 1 rm#Ontology 0..1

Retrieve Web Service

Input


Output


<Identifier> 1 rm#WebService 0..1


453

454455456457458459

460

461

462

463

464

465

466

467

468

469

470

471

4950

51

Retrieve Goal

Input


Output


<Identifier> 1 rm#Goal 0..1

Retrieve Mediator

Input


Output


<Identifier> 1 rm#Mediator 0..1

Remove Ontology

Input


Output


<Identifier> 1 rm#Ontology 0..1

Remove Web Service

Input


Output


<Identifier> 1 rm#WebService 0..1

Remove Goal

Input


Output


<Identifier> 1 rm#Goal 0..1

Remove Mediator

Input


Output


<Identifier> 1 rm#Mediator 0..1

List Ontologies

Input


Output


<Identifier> 0…*


472

473

474

475

476

477

478

479

480

481

482

483

484

485

5253

54

List Web Services

Input


Output


<Identifier> 0…*

List Goals

Input


Output


<Identifier> 0…*

List Mediators

Input


Output


<Identifier> 0…*

4.3 Vertical ServicesNeeds Intro

4.3.1 Service management

Deploying and managing of services for SEE middleware

Management of service descriptions in the SEE registry

4.3.2 Security

Security is ubiquitous across all layers and must be entwined with each middleware service as appropriate. Additionally there may be authentication and authorization control for access to SEE as a unit.


486

487

488

489

490

491

492

493

494

495

496

497

498499500

501

502

5556

57


Is this enough or do we wish to extend?


Thomas Haselwanter will provide an update for this in the next version


I still have to do this

5 Process ViewThis section should contain simple UML diagrams for each of the processes that SEE supports. UML sequence diagrams may be easier to read than activity diagrams. Existing material is available from the earlier SEE Architecture intermediate deliverable and DIP and Knowledge Web research project.

The processes should be a superset of those supported by IRS and WSMX as two concrete architectures and implementations for SEE.

5.1 Processes in the Context of SSOA

5.2 Describing process behavior as Execution Semantics

5.3 Goal-based Discovery Process

5.4 Service Invocation Process

5.5 Achieve Goal (Discovery and Invocation) Process

5.6 Summary


503

504505506

507508

509

510

511

512

513

514515

5859

60


I think we should complete section 4 completely before we tackle section 5.

6 Future Work


516

6162

63

7 References[Baeten, 2005] J. C. M. Baeten: A brief history of process algebra, Theoretical Computer Science, 335(2–3):131–146, 2005.

[Norton and Mocan, 2007] B. Norton and A. Mocan: Reference Model for Semantic Service Oriented Architecture, OASIS Semantic Execution Environment Technical Committee Draft, 2007


517

518519

520521

522

6465

66

Appendix A. Acknowledgements


523

6768

69

Appendix B. Appendix A – SEE API (Operations)


524

7071

72

Appendix C. Revision History

[optional; should not be included in OASIS Standards]

Revision Date Editor Changes Made

1 23/02/2007 [email protected] First ToC of SSOA RA specification taking draft specification for SEE Architecture and Interoperability v0.1 r16, as foundational input.

2 18/04/2007 [email protected] 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 [email protected] Minor editorial changes, added comments to existing text and built to-do list for the next revision

4 16/06/2997 [email protected] 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 [email protected] 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 [email protected] New content on Reference Model.


525

526

527

528

7374

75

mailto:[email protected]





figure 1

Documents

deri innsbruck

separate oasis

oasis party

oasis standard

oasis requests

oasis technical74committee

oasis website

copyright oasis open