The ability to provide robust implementations is a very important aspect to create high quality Web Service-enabled applications and to accelerate the adoption of Web Services. The Framework for Web Services Implementation (FWSI) TC aims to enable robust implementations by defining a practical and extensible methodology consisting of implementation processes and common functional elements that practitioners can adopt to create high quality Web Services systems without reinventing them for each implementation.

This document specifies a set of Functional Elements for practitioners to instantiate into a technical architecture, and should be read in conjunction with the Functional Elements Requirements document. It is the purpose of this specification to define the right level of abstraction for these Functional Elements and to specify the purpose and scope of each Functional Element so as to facilitate efficient and effective implementation of Web Services.

Status:

This document is updated periodically on no particular schedule.

Committee members should send comments on this specification to the fwsi-fesc@lists.oasis-open.org list. Others should subscribe to and send comments to the fwsi-comment@lists.oasis-open.org list. To subscribe, send an email message to fwsi-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

For information on whether any patents[1] 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 FWSI TC web page (http://www.oasis-open.org/committees/fwsi/).

Table of Contents

1 Introduction. 8

1.1 Document Outline. 8

1.2 Motivation. 9

1.3 Terminology. 9

2 List of Functional Elements. 10

2.1 Data Integrator Functional Element (new) 10

2.1.1 Motivation. 10

2.1.2 Terms Used. 10

2.1.3 Key Features. 12

2.1.4 Interdependencies. 12

2.1.6 Model 13

2.1.7 Usage Scenarios. 14

2.2 Error Management Functional Element (new) 27

2.2.1 Motivation. 27

2.2.2 Terms Used. 28

2.2.3 Key Features. 29

2.2.4 Interdependencies. 30

2.2.6 Model 31

2.2.7 Usage Scenarios. 31

2.3 Event Handler Functional Element 43

2.3.1 Motivation. 43

2.3.2 Terms Used. 43

2.3.3 Key Features. 44

2.3.4 Interdependencies. 46

2.3.6 Model 47

2.3.7 Usage Scenarios. 48

2.4 Group Management Functional Element 65

2.4.1 Motivation. 65

2.4.2 Terms Used. 65

2.4.3 Key Features. 65

2.4.4 Interdependency. 66

2.4.6 Model 67

2.4.7 Usage Scenarios. 67

2.5 Identity Management Functional Element 72

2.5.1 Motivation. 72

2.5.2 Terms Used. 72

2.5.3 Key Features. 74

2.5.4 Interdependencies. 74

2.5.6 Model 76

2.5.7 Usage Scenarios. 77

2.6 Information Catalogue Functional Element (new) 81

2.6.1 Motivation. 81

2.6.2 Terms Used. 81

2.6.3 Key Features. 81

2.6.4 Interdependencies. 82

2.6.6 Model 83

2.6.7 Usage Scenario. 83

2.7 Information Reporting Functional Element (new) 90

2.7.1 Motivation. 90

2.7.2 Terms Used. 90

2.7.3 Key Features. 91

2.7.4 Interdependencies. 91

2.7.6 Model 92

2.7.7 Usage Scenario. 92

2.8 Key Management Functional Element (new) 104

2.8.1 Motivation. 104

2.8.2 Terms Used. 104

2.8.3 Key Features. 104

2.8.4 Interdependencies. 105

2.8.6 Model 106

2.8.7 Usage Scenarios. 107

2.9 Log Utility Functional Element 113

2.9.1 Motivation. 113

2.9.2 Terms Used. 113

2.9.3 Key Features. 113

2.9.4 Interdependencies. 114

2.9.6 Model 115

2.9.7 Usage Scenarios. 115

2.10 Notification Functional Element 122

2.10.1 Motivation. 122

2.10.2 Terms Used. 122

2.10.3 Key Features. 123

2.10.4 Interdependencies. 123

2.10.6 Model 124

2.10.7 Usage Scenarios. 124

2.11 Phase and Lifecycle Management Functional Element 130

2.11.1 Motivation. 130

2.11.2 Terms Used. 130

2.11.3 Key Features. 131

2.11.4 Interdependencies. 131

2.11.6 Model 131

2.11.7 Usage Scenarios. 132

2.12 Policy Management Functional Element (new) 137

2.12.1 Motivation. 137

2.12.2 Terms Used. 137

2.12.3 Key Features. 138

2.12.4 Interdependency. 139

2.12.6 Model 140

2.12.7 Usage Scenarios. 140

2.13 Policy Enforcement Functional Element (new) 145

2.13.1 Motivation. 145

2.13.2 Terms Used. 145

2.13.3 Key Features. 145

2.13.4 Interdependency. 146

2.13.6 Model 146

2.13.7 Usage Scenarios. 147

2.14 Presentation Transformer Functional Element (Deprecated) 149

2.15 QoS Functional Element (new) 150

2.15.1 Motivation. 150

2.15.2 Terms Used. 150

2.15.3 Key Features. 151

2.15.4 Interdependencies. 151

2.15.6 Model 152

2.15.7 Usage Scenarios. 153

2.16 Role and Access Management Functional Element 162

2.16.1 Motivation. 162

2.16.2 Terms Used. 162

2.16.3 Key Features. 163

2.16.4 Interdependencies. 164

2.16.6 Model 165

2.16.7 Usage Scenario. 165

2.17 Search Functional Element 175

2.17.1 Motivation. 175

2.17.2 Terms Used. 175

2.17.3 Key Features. 176

2.17.4 Interdependencies. 176

2.17.6 Model 177

2.17.7 Usage Scenario. 177

2.18 Secure SOAP Management Functional Element 180

2.18.1 Motivation. 180

2.18.2 Terms Used. 180

2.18.3 Key Features. 181

2.18.4 Interdependencies. 181

2.18.6 Model 182

2.18.7 Usage Scenarios. 182

2.19 Sensory Functional Element 186

2.19.1 Motivation. 186

2.19.2 Terms Used. 186

2.19.3 Key Features. 186

2.19.4 Interdependencies. 187

2.19.6 Model 187

2.19.7 Usage Scenarios. 187

2.20 Service Level Management Functional Element (new) 190

2.20.1 Motivation. 190

2.20.2 Terms Used. 190

2.20.3 Key Features. 190

2.20.4 Interdependencies. 191

2.20.6 Model 191

2.20.7 Usage Scenarios. 192

2.21 Service Level Enforcement Functional Element (new) 198

2.21.1 Motivation. 198

2.21.2 Terms Used. 198

2.21.3 Key Features. 198

2.21.4 Interdependencies. 198

2.21.6 Model 199

2.21.7 Usage Scenarios. 199

2.22 Service Management Functional Element 204

2.22.1 Motivation. 204

2.22.2 Terms Used. 204

2.22.3 Key Features. 204

2.22.4 Interdependencies. 205

2.22.6 Model 206

2.22.7 Usage Scenarios. 206

2.23 Service Registry Functional Element 212

2.23.1 Motivation. 212

2.23.2 Terms Used. 212

2.23.3 Key Features. 213

2.23.4 Interdependencies. 213

2.23.6 Model 214

2.23.7 Usage Scenario. 214

2.24 Service Router Functional Element (new) 223

2.24.1 Motivation. 223

2.24.2 Terms Used. 223

2.24.3 Key Features. 224

2.24.4 Interdependencies. 225

2.24.6 Model 226

2.24.7 Usage Scenarios. 226

2.25 Service Tester Functional Element (Deprecated) 234

2.26 Transformer Functional Element (new) 235

2.26.1 Motivation. 235

2.26.2 Terms Used. 235

2.26.3 Key Features. 236

2.26.4 Interdependencies. 236

2.26.6 Model 237

2.26.7 Usage Scenarios. 237

2.27 User Management Functional Element 243

2.27.1 Motivation. 243

2.27.2 Terms Used. 243

2.27.3 Key Features. 244

2.27.4 Interdependencies. 245

2.27.6 Model 245

2.27.7 Usage Scenarios. 246

2.28 Web Service Aggregator Functional Element 253

2.28.1 Motivation. 253

2.28.2 Terms Used. 253

2.28.3 Key Features. 254

2.28.4 Interdependencies. 255

2.28.6 Model 255

2.28.7 Usage Scenarios. 256

3 Functional Elements Usage Scenarios. 261

3.1 Service Monitoring. 262

3.2 Securing SOAP Messages. 263

3.3 Decoupled User Access Management 264

3.4 Single-Sign-On for Distributed Services (Applications) 265

4 References. 266

Appendix A. Acknowledgments. 268

Appendix B. Revision History. 269

Appendix C. Notices. 271

1 Introduction

The purpose of OASIS Framework for Web Services Implementation (FWSI) Technical Committee (TC) is to facilitate implementation of robust Web Services by defining a practical and extensible methodology consisting of implementation processes and common functional elements that practitioners can adopt to create high quality Web Services systems without re-inventing them for each implementation. It aims to solve the problem of the slow adoption of Web Services due to a lack of good Web Services methodologies for implementation, cum a lack of understanding and confidence in solutions that have the necessary components to reliably implement Web Service-enabled applications.

One of the FWSI TC’s deliverables is the Functional Elements Specification, which is detailed in this document. This Specification specifies a set of functional elements that practical implementation of Web Services-based systems will require. A Functional Element (FE) is defined as a building block representing common reusable functionalities for Web Service-enabled implementations, i.e. from an application Point-Of-View. These FEs are expected to be implemented as reusable components, with Web Services capabilities where appropriate, and to be the foundation for practitioners to instantiate into a technical architecture. The implementations of these FEs are further supported by another complementary work that is also from the FWSI TC, the Web Services Implementation Methodology (WSIM) [[1]]. As such, the TC hopes that through the implementations of these FEs, robust Web Service-enabled applications can be constructed quickly and deployed in a rapid manner.

The target audiences for this document are expected to be solution providers who intend to use the Functional Elements Specification to create building blocks that can be instantiated into the technical architecture of their solutions or software vendors and independent software vendors (ISVs) that are expected to build the functional elements specified into their products. Individuals and researchers who are interested in Web Services will also be able to benefit from this document. It is recommended that this document should be used in tandem with the Functional Elements Requirements document, to ensure that readers have a holistic view to the thought processes and knowledge that are encapsulated.

1.1 Document Outline

This document describes the Functional Elements in three main sections. In this section, explanation on the motivation for creating this Specification and the kind of impact that it will create for Web Service-enabled implementations and the terminology used in the normative part of this document are included.

Section 2 lists the identified Functional Elements arising from requirements documented in the Functional Elements Requirements document [[2]]. Under each of the ensuing FE, the following descriptions are provided:

· Motivation

A section for providing a short introduction explaining the motivation of including the FE from an application Point-Of-View, including cross-referencing of the requirements for the Functional Element

· Terms Used

A glossary of the terms used. An explanation or illustration of the runtime capabilities of the Functional Element are also provided where appropriate.

· Key Features

A list of key features to be implemented is provided here and is expressed in the normative form.

· Interdependencies

In this section, the interdependencies between Functional Elements are provided to clarify the linkages between FEs (if any).

· Related Technologies and Standards

Here, the reliance of the Functional Elements on related technologies and specifications (or standards) are provided

Section 3 provides the examples of how the Functional Elements can be assembled to accelerate web service-enabled applications. From these Functional Elements, a variety of solutions can be built.

1.2 Motivation

In a Service-Oriented Architecture (SOA) environment, new applications/services are created through the assembly of existing services. One of the key advantages of this loosely coupled model is that it allows the new application/service to leverage on 3^rd party services. As a typical 3^rd party’s implementation of the services is done via the software component approach, this specification further proliferate new applications/services by defining a framework for Web Services implementation consisting of Functional Elements. Through these Functional Elements, which are implementation neutral, this Specification hopes to influence future software development towards assembly of services rather than ‘pure built only’.

1.3 Terminology

Within this document the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119 [[3]].

Cross-references to the Functional Elements Requirements document [2] are designated throughout this specification to the requirement contained where the requirement number is enclosed in square brackets (e.g. [MANAGEMENT-005]).

2 List of Functional Elements

2.1 Data Integrator Functional Element (new)

2.1.1 Motivation

The Data Integrator Functional element is expected to be used for enabling easy and simple mechanisms to access disparate data sources by

· Providing unified data view of enterprise across various data sources

· Enabling the partitioned view of data for different groups/departments based on defined logical views, and

· Performing data processing or transformation before presenting the defined logical data view(s).

This Functional Element fulfills the following requirements from the Functional Elements Requirements Document 02:

Primary Requirements

1.1 PROCESS-220 to PROCESS-236.

Secondary Requirements

1.2 None

2.1.2 Terms Used

Terms	Description
Batch Retrieval Definition	Batch retrieval definition defines how batch data retrieval is performed. The definition of batch retrieval would include the XML schema for the XML format of retrieved data, the mapping of the data fields in the format to the data fields in the logical data view and the schedule of batch retrieval
Data Repository	Data repository is a form of persistent data storage used by Data Integrator to store information of logical data views information.
Data Source	Data source is physical data storage where data can be retrieved. It may include relational database, XML database, LDAP, text file, XML file, URL that pointing to a set of data in Internet.
Data Transformation Rule	Data transformation rule defines how raw data is transformed into the data format that is requested by final presentation. Data transformation rule has two types. –The first type is the one that applies at the logical data view level and generates instances of data for the whole data view. » An example of this type rule could be a name of the pre-defined function that gets data instances from various data sources and fills in the data view. –The second type is the one that applies at the data field level of the logical data view and only generates the data for that particular data field. » An examples of this type rule could be a formula like: data field 1 in logical data view = data field 1 in data source 1 X data field 2 in data source 2