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 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. 13

2.2 Error Management Functional Element (new) 26

2.2.1 Motivation. 26

2.2.2 Terms Used. 27

2.2.3 Key Features. 28

2.2.4 Interdependencies. 29

2.2.6 Model 30

2.2.7 Usage Scenarios. 30

2.3 Event Handler Functional Element 42

2.3.1 Motivation. 42

2.3.2 Terms Used. 42

2.3.3 Key Features. 43

2.3.4 Interdependencies. 45

2.3.6 Model 46

2.3.7 Usage Scenarios. 47

2.4 Group Management Functional Element 64

2.4.1 Motivation. 64

2.4.2 Terms Used. 64

2.4.3 Key Features. 64

2.4.4 Interdependency. 65

2.4.6 Model 66

2.4.7 Usage Scenarios. 66

2.5 Identity Management Functional Element 71

2.5.1 Motivation. 71

2.5.2 Terms Used. 71

2.5.3 Key Features. 73

2.5.4 Interdependencies. 73

2.5.6 Model 75

2.5.7 Usage Scenarios. 76

2.6 Information Catalogue Functional Element (new) 80

2.6.1 Motivation. 80

2.6.2 Terms Used. 80

2.6.3 Key Features. 80

2.6.4 Interdependencies. 81

2.6.6 Model 82

2.6.7 Usage Scenario. 82

2.7 Information Reporting Functional Element (new) 89

2.7.1 Motivation. 89

2.7.2 Terms Used. 89

2.7.3 Key Features. 90

2.7.4 Interdependencies. 90

2.7.6 Model 91

2.7.7 Usage Scenario. 91

2.8 Key Management Functional Element (new) 103

2.8.1 Motivation. 103

2.8.2 Terms Used. 103

2.8.3 Key Features. 103

2.8.4 Interdependencies. 104

2.8.6 Model 105

2.8.7 Usage Scenarios. 106

2.9 Log Utility Functional Element 112

2.9.1 Motivation. 112

2.9.2 Terms Used. 112

2.9.3 Key Features. 112

2.9.4 Interdependencies. 113

2.9.6 Model 114

2.9.7 Usage Scenarios. 114

2.10 Notification Functional Element 121

2.10.1 Motivation. 121

2.10.2 Terms Used. 121

2.10.3 Key Features. 122

2.10.4 Interdependencies. 122

2.10.6 Model 123

2.10.7 Usage Scenarios. 123

2.11 Phase and Lifecycle Management Functional Element 129

2.11.1 Motivation. 129

2.11.2 Terms Used. 129

2.11.3 Key Features. 130

2.11.4 Interdependencies. 130

2.11.6 Model 130

2.11.7 Usage Scenarios. 131

2.12 Policy Management Functional Element (new) 136

2.12.1 Motivation. 136

2.12.2 Terms Used. 136

2.12.3 Key Features. 137

2.12.4 Interdependency. 138

2.12.6 Model 139

2.12.7 Usage Scenarios. 139

2.13 Policy Enforcement Functional Element (new) 144

2.13.1 Motivation. 144

2.13.2 Terms Used. 144

2.13.3 Key Features. 144

2.13.4 Interdependency. 145

2.13.6 Model 145

2.13.7 Usage Scenarios. 146

2.14 Presentation Transformer Functional Element (Deprecated) 148

2.15 QoS Functional Element (new) 149

2.15.1 Motivation. 149

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. 152

2.16 Role and Access Management Functional Element 163

2.16.1 Motivation. 163

2.16.2 Terms Used. 163

2.16.3 Key Features. 164

2.16.4 Interdependencies. 165

2.16.6 Model 166

2.16.7 Usage Scenario. 166

2.17 Search Functional Element 176

2.17.1 Motivation. 176

2.17.2 Terms Used. 176

2.17.3 Key Features. 177

2.17.4 Interdependencies. 177

2.17.6 Model 178

2.17.7 Usage Scenario. 178

2.18 Secure SOAP Management Functional Element 181

2.18.1 Motivation. 181

2.18.2 Terms Used. 181

2.18.3 Key Features. 182

2.18.4 Interdependencies. 182

2.18.6 Model 183

2.18.7 Usage Scenarios. 183

2.19 Sensory Functional Element 187

2.19.1 Motivation. 187

2.19.2 Terms Used. 187

2.19.3 Key Features. 187

2.19.4 Interdependencies. 188

2.19.6 Model 188

2.19.7 Usage Scenarios. 188

2.20 Service Level Management Functional Element (new) 191

2.20.1 Motivation. 191

2.20.2 Terms Used. 191

2.20.3 Key Features. 191

2.20.4 Interdependencies. 192

2.20.6 Model 192

2.20.7 Usage Scenarios. 193

2.21 Service Level Enforcement Functional Element (new) 199

2.21.1 Motivation. 199

2.21.2 Terms Used. 199

2.21.3 Key Features. 199

2.21.4 Interdependencies. 199

2.21.6 Model 200

2.21.7 Usage Scenarios. 200

2.22 Service Management Functional Element 205

2.22.1 Motivation. 205

2.22.2 Terms Used. 205

2.22.3 Key Features. 205

2.22.4 Interdependencies. 206

2.22.6 Model 207

2.22.7 Usage Scenarios. 207

2.23 Service Registry Functional Element 213

2.23.1 Motivation. 213

2.23.2 Terms Used. 213

2.23.3 Key Features. 214

2.23.4 Interdependencies. 214

2.23.6 Model 215

2.23.7 Usage Scenario. 215

2.24 Service Router Functional Element (new) 224

2.24.1 Motivation. 224

2.24.2 Terms Used. 224

2.24.3 Key Features. 225

2.24.4 Interdependencies. 226

2.24.6 Model 227

2.24.7 Usage Scenarios. 227

2.25 Service Tester Functional Element (Deprecated) 235

2.26 Transformer Functional Element (new) 236

2.26.1 Motivation. 236

2.26.2 Terms Used. 236

2.26.3 Key Features. 237

2.26.4 Interdependencies. 237

2.26.6 Model 238

2.26.7 Usage Scenarios. 238

2.27 User Management Functional Element 244

2.27.1 Motivation. 244

2.27.2 Terms Used. 244

2.27.3 Key Features. 245

2.27.4 Interdependencies. 246

2.27.6 Model 246

2.27.7 Usage Scenarios. 247

2.28 Web Service Aggregator Functional Element 254

2.28.1 Motivation. 254

2.28.2 Terms Used. 254

2.28.3 Key Features. 255

2.28.4 Interdependencies. 256

2.28.6 Model 256

2.28.7 Usage Scenarios. 257

3 Functional Elements Usage Scenarios. 262

3.1 Service Monitoring. 263

3.2 Securing SOAP Messages. 264

3.3 Decoupled User Access Management 265

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

4 References. 267

Appendix A. Acknowledgments. 269

Appendix B. Revision History. 270

Appendix C. Notices. 272

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 [[4]]:

· Primary Requirements

· PROCESS-220 to PROCESS-236.

· Secondary Requirements

· 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 .
Logical Data View	Logical data view is a conceptual/semantic data model. It is defined by the name of logical data view, owner, created date, the data fields, the sources of data fields, the constraints of data view, and the transformation rule associated.

Figure 1: An Overview of the Data Integrator Functional Element

Figure 1 depicts the basic concepts of how the participating entities collaborate together in the Data Integrator Functional Element. Data can be physically scattered across various data sources, residing on the local area network (LAN) or over Wide Area Network (WAN). Examples include RDBMS, XML database, XML files, URLs that point to a set of data in the Internet, etc. Data Integrator enables the creation of different set of logical data views for various applications or systems. Users of Data Integrator manipulate the data according to the logical data view defined through a unified access interface. Logical data views could be physically stored in Data Repository for easy and fast access.

2.1.3 Key Features

Implementations of the Data Integrator Functional Element are expected to provide the following key features:

1. The Functional Element MUST provide the capability to manage the available data sources. This includes capability to:

1.1. Add new data source to the pool of available data sources.

1.2. Remove data source from the pool of available data sources.

2. The Functional Element MUST provide the capability to define a logical data view based on the pool of available data sources

3. The Functional Element MUST provide capability to manage the updating and deletion of a logical data view

4. The Functional Element MUST provide capability to manage the creation, updating and deletion of data transformation rules

5. The Functional Element MUST provide capability to retrieve data based on the logical data view defined

6. The Functional Element MUST provide a unified way to query data based on defined logical data views

7. The Functional Element MUST provide a mechanism to extract data from various data sources and transform the data according to defined transformation rules for a logical data view

In addition, the following key features could be provided to enhance the Functional Element further:

1. The Functional Element MAY provide capability to insert, update and delete data based on a logical data view (where applicable).

2. The Functional Element MAY provide the capability to retrieve batch data based on logical data view according to a schedule and present the retrieved data in predefined XML formats.

3. The Functional Element MAY provide the capability to manage the definition of batch data retrieval. This includes capability to:

3.1 Define a batch data retrieval

3.2 Disable the schedule of batch data retrieval

3.3 Enable the schedule of batch data retrieval

3.4 Remove the definition of batch data retrieval

4. The Functional Element MAY implement data repository to host consolidated data. This data repository hosts the physical entity that stores the content of a logical data view.

5. The Functional Element MAY provide a mechanism to synchronize data between data repository and data sources if data repository is provided.

2.1.4 Interdependencies

None

2.1.5 Related Technologies and Standards

RDBMS, LDAP, XML Database

2.1.6 Model

Figure 2: Model Of the Data Integrator Functional Element

2.1.7 Usage Scenarios

2.1.7.1 Manage data sources

2.1.7.1.1 Description

This use case allows the user to manage the available data sources on which logical data views are created.

2.1.7.1.2 Flow of Events

2.1.7.1.2.1 Basic Flow

The use case begins when the user of the Data Integrator wants to add in new data sources or remove existing data sources.

1: The user sends a request to Data Integrator together with data source profile and operation.

2: Based on the operation it specified, one of the following sub-flows is executed:

If the operation is ‘Add in data source’, then sub-flow 2.1 is executed.

If the operation is ‘Remove data source’, then sub-flow 2.2 is executed.

2.1: Add in data source.

2.1.1: The Functional Element gets the data source profile data, i.e. name, description, data source location for connection, login Id and password of the user who has privileges to manipulate data sources.

2.1.2: The Functional Element registers the data source as available data source.

2.2: Remove data source.

2.2.1: The Functional Element gets the name of data sources

2.2.2: The Functional Element checks whether the data source is valid data source.

2.2.3: The Functional Element removes the data source from the pool of available data source (with the assumption that the user has a valid login Id and password).

3: The Functional Element returns the results to indicate the success or failure of this operation to the user and the use case ends.

2.1.7.1.2.2 Alternative Flows

1: Data Source Already Registered.

1.1: If in the basic flow 2.1.2, the data source is already registered, Functional Element will return an error message to the user and the use case ends.

2: Data Source Not Exist.

2.1: If in the basic flow 2.2.2, the data source is not registered as available data source, Functional Element will return an error message to the user and the use case ends.

3: Persistency Mechanism Error.

3.1: If in the basic flow 2.1 and 2.2, the Functional Element cannot perform data persistency, Functional Element will return an error message to the user and the use case ends.

2.1.7.1.3 Special Requirements

None.

2.1.7.1.4 Pre-Conditions

None.

2.1.7.1.5 Post-Conditions

None.

2.1.7.2 Manage Data Views

2.1.7.2.1 Description

This use case allows the user to manage the logical data views.

2.1.7.2.2 Flow of Events

2.1.7.2.2.1 Basic Flow

The use case begins when the user wants to create/retrieve/update/delete a logical data view.

1: The user sends request to manage logical data view together with logical data view definition and operation.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Create Data View’, the sub-flow 2.1 is executed.

If the operation is ‘Retrieve Data View’, the sub-flow 2.2 is executed.

If the operation is ‘Update Data View’, the sub-flow 2.3 is executed.

If the operation is ‘Delete Data View’, the sub-flow 2.4 is executed.

2.1: Create Data View.

2.1.1: The Functional Element gets logical data view definition, i.e. name, description, owner of data view, created date, data fields of data view, the source fields of data fields, and transformation rule.

2.1.2: The Functional Element checks whether the logical data view exists.

2.1.3: The Functional Element creates the logical data view exists.

2.2: Retrieve Data View.

2.2.1: The Functional Element gets name of the logical data view and retrieve condition.

2.2.2: The Functional Element retrieves the logical data view’s information according to the condition.

2.3: Update Data View.

2.3.1: The Functional Element gets name of the logical data view and its definition

2.3.2: The Functional Element checks whether the logical data view exists.

2.3.3: The Functional Element updates the logical data view definition

2.4: Delete Data View.

2.4.1: The Functional Element gets name of the logical data view.

2.4.2: The Functional Element checks whether the logical data view exists.

2.4.3: The Functional Element removes the logical data view.

3: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.2.2.2 Alternative Flows

1: Data View Already Exists.

1.1: If in the basic flow 2.1.2, the data view is already defined, Functional Element returns an error message and the use case ends.

2: Data View Cannot Be Deleted.

2.1: If in the basic flow 2.4.3, the data of the logical data view is stored in Data Repository, Functional Element returns an error message and the use case ends.

3: Data View Not Found.

3.1: If in the basic flow 2.2.2, 2.3.2 and 2.4.2, the data view does not exist, Functional Element will return an error message and the use case ends.

4: Data View Cannot Be Updated.

4.1: If in the basic flow 2.4.3, the data of the logical data view is stored in Data Repository, Functional Element returns an error message and the use case ends.

5: Persistency Mechanism Error.

5.1: If in the basic flow 2.1.2, 2.1.3, 2.2, 2.3.2, 2.3.3, 2.4.2 and 2.4.3, the Functional Element cannot perform data persistency, Functional Element will return an error message to the user and the use case ends.

2.1.7.2.3 Special Requirements

None.

2.1.7.2.4 Pre-Conditions

None.

2.1.7.2.5 Post-Conditions

None.

2.1.7.3 Manage Transformation Rules

2.1.7.3.1 Description

This use case allows the user to manage the data transformation rules that are used by the Data Integrator to perform the data transformation before passing data back to users.

2.1.7.3.2 Flow of Events

2.1.7.3.2.1 Basic Flow

The use case begins when the user wants to create/retrieve/update/delete a data transformation rule.

1: The user sends request to manage data transformation rule together with the definition of transformation rule and operation.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Define Data Transformation Rule’, the sub-flow 2.1 is executed.

If the operation is ‘Retrieve Data Transformation Rule’, the sub-flow 2.2 is executed.

If the operation is ‘Update Data Transformation Rule’, the sub-flow 2.3 is executed.

If the operation is ‘Delete Data Transformation Rule’, the sub-flow 2.4 is executed.

2.1: Create Data Transformation Rule.

2.1.1: The Functional Element gets the definition of the data transformation rule, i.e. name, description, rule type, function name, data view name, and applied data fields.

2.1.2: The Functional Element checks whether the data transformation rule exists.

2.1.3: The Functional Element creates the data transformation rule.

2.2: Retrieve Data Transformation Rule.

2.2.1: The Functional Element gets name of the data transformation rule and retrieve condition.

2.2.2: The Functional Element retrieves the data transformation rule’s information according to the condition.

2.3: Update Data Transformation Rule.

2.3.1: The Functional Element gets the name of data transformation rule.

2.3.2: The Functional Element checks whether data transformation rule exists.

2.3.3: The Functional Element updates the definition of the data transformation rule.

2.4: Delete Data Transformation Rule.

2.4.1: The Functional Element gets the name of data transformation rule.

2.4.2: The Functional Element checks whether the data transformation rule exists.

2.4.3: The Functional Element removes the data transformation rule from the Functional Element

3: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.3.2.2 Alternative Flows

1: Data Transformation Rule Already Exists.

1.1: If in the basic flow 2.1.2, the data transformation rule is already defined, Functional Element returns an error message and the use case ends.

2: Data Transformation Rule Cannot Be Deleted.

2.1: If in the basic flow 2.4.3, the data of the logical data view, on which the data transformation rule is applied, is stored in Data Repository, Functional Element returns an error message and the use case ends.

3: Data Transformation Rule Not Found.

3.1: If in the basic flow 2.2.2, 2.3.2 and 2.4.2, the data transformation rule does not exist, Functional Element will return an error message and the use case ends

4: Data Transformation Rule Cannot Be Updated.

4.1: If in the basic flow 2.3.3, the data of the logical data view, on which the data transformation rule is applied, is stored in Data Repository, Functional Element returns an error message and the use case ends.

5: Logical Data View Not Exist.

4.1: If in the basic flow 2.1.3, the data of the logical data view, on which the data transformation rule is applied, dose not exist, Functional Element returns an error message and the use case ends.

6: Persistency Mechanism Error.

2.1.7.3.3 Special Requirements

None.

2.1.7.3.4 Pre-Conditions

None.

2.1.7.3.5 Post-Conditions

None.

2.1.7.4 Manage Batch Data Extraction

2.1.7.4.1 Description

This use case allows the user to define and disable the batch data extraction.

2.1.7.4.2 Flow of Events

2.1.7.4.2.1 Basic Flow

The use case begins when the user wants to define, remove, enable and disable a batch data extraction.

1: The user sends request to manage batch data extraction together with the definition of batch data extraction and operation.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Define Batch Data Extraction’, the sub-flow 2.1 is executed.

If the operation is ‘Remove Batch Data Extraction Definition’, the sub-flow 2.1 is executed.

If the operation is ‘Enable Batch Data Extraction’, the sub-flow 2.2 is executed.

If the operation is ‘Disable Batch Data Extraction’, the sub-flow 2.3 is executed.

2.1: Define Batch Data Extraction.

2.1.1: The Functional Element gets batch data extraction definition, i.e. name, description, XML schema for the XML data format, the mapping of data fields from logical data view to XML data file, and extraction schedule.

2.1.2: The Functional Element checks whether the batch data extraction exists.

2.1.3: The Functional Element creates the batch data extraction.

2.2: Remove Batch Data Extraction Definition.

2.2.1: The Functional Element gets name of the batch data extraction.

2.2.2: The Functional Element checks whether the batch data extraction exists.

2.2.3: The Functional Element removes the batch data extraction from the Functional Element.

2.3: Enable Batch Data Extraction.

2.3.1: The Functional Element gets name of the batch data extraction.

2.3.2: The Functional Element checks whether the batch data extraction exists.

2.3.3: The Functional Element enables the batch data extraction.

2.4: Disable Batch Data Extraction.

2.4.1: The Functional Element gets name of the batch data extraction.

2.4.2: The Functional Element checks whether the batch data extraction exists.

2.4.3: The Functional Element disables the batch data extraction.

3: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.4.2.2 Alternative Flows

1: Batch Data Extraction Exist.

1.1: If in the basic flow 2.1.2, the batch data extraction is already defined, Functional Element returns an error message and the use case ends.

2: Batch Data Extraction Not Found.

2.1: If in the basic flow 2.2.3, 2.3.3 and 2.4.3, the batch data extraction does not exist, Functional Element will return an error message and the use case ends

3: Persistency Mechanism Error.

3.1: If in the basic flow 2.1.2, 2.1.3, 2.2.2, 2.2.3, 2.3.2, 2.3.3, 2.4.2 and 2.4.3, the Functional Element cannot perform data persistency, Functional Element will return an error message to the user and the use case ends.

2.1.7.4.3 Special Requirements

None.

2.1.7.4.4 Pre-Conditions

None.

2.1.7.4.5 Post-Conditions

None.

2.1.7.5 Retrieve Data

2.1.7.5.1 Description

This use case allows the user to perform data retrieval based on the logical data view defined.

2.1.7.5.2 Flow of Events

2.1.7.5.2.1 Basic Flow

The use case begins when the user wants to perform data retrieval based on a logical data view.

1: The user sends request to retrieve data by providing the name of logical data view and SQL query statement.

2: The Functional Element checks whether the logical data view exists.

3: The Functional Element retrieves the definition of logical data view specified.

4: The Functional Element verifies the correctness of the SQL statement by checking the syntax of statement and the data fields used.

5: The Functional Element retrieves the definition of data transformation rule related with the data view.

6: The Functional Element performs the data retrieval from data sources

7: The Functional Element performs the data transformation to the data retrieved and fill up the data according to the definition of the logical data view.

8: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.5.2.2 Alternative Flows

1: Query Statement Is Invalid.

1.1: If in the basic flow 4, the SQL statement is not valid, Functional Element returns an error message and the use case ends.

2: Data View Not Found.

2.1: If in the basic flow 3, the specified data view is not found, Functional Element returns an error message and the use case ends.

3: Data Source Not Available.

3.1: If in the basic flow 6, the data sources are not available for retrieving data, Functional Element returns an error message and the use case ends.

4: Data Transformation Rule Not Found.

4.1: If in the basic flow 5, the data transformation rule is not available, Functional Element returns an error message and the use case ends.

5: Data Repository Are Not Available.

5.1: If in the basic flow 6, the data of the logical data view is stored in Data Repository and the Data Repository is not available, Functional Element returns an error message and the use case ends.

2.1.7.5.3 Special Requirements

None.

2.1.7.5.4 Pre-Conditions

None.

2.1.7.5.5 Post-Conditions

None.

2.1.7.6 Manipulate Data

2.1.7.6.1 Description

This use case allows the user to insert, update, and delete data based on a logical data view defined.

2.1.7.6.2 Flow of Events

2.1.7.6.2.1 Basic Flow

The use case begins when the user wants to insert, update, and delete data based on a logical data view.

1: The user sends request to manipulate data by providing the name of the logical data view and SQL statement.

3: The Functional Element retrieves the definition of logical data view specified.

4: The Functional Element verifies the correctness of the SQL statement by checking the syntax of statement and the data fields used.

5: The Functional Element checks the violation of operations based on the definition of logical data view.

6: The Functional Element performs the operation specified in SQL statement.

7: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.6.2.2 Alternative Flows

1: Manipulation Statement Is Invalid.

1.1: If in the basic flow 4, the SQL statement is not valid, Functional Element returns an error message and the use case ends.

2: Data View Not Found.

2.1: If in the basic flow 3, the specified data view is not found, Functional Element returns an error message and the use case ends.

3: Data Source Are Not Available.

3.1: If in the basic flow 6, the data sources are not available for retrieving data, Functional Element returns an error message and the use case ends.

4: SQL Error.

4.1: If in the basic flow 6, there is any error of SQL statement execution, Functional Element returns an error message and the use case ends.

2.1.7.6.3 Special Requirements

None.

2.1.7.6.4 Pre-Conditions

None.

2.1.7.6.5 Post-Conditions

None.

2.1.7.7 Extract Data in Batch

2.1.7.7.1 Description

This use case allows the user to perform batch data retrieval in a scheduled approach based on a logical data view defined.

2.1.7.7.2 Flow of Events

2.1.7.7.2.1 Basic Flow

The use case begins when the user wants to perform batch data retrieval or the time is up for scheduled batch data retrieval.

1: The user sends request to retrieve data by providing the name of the batch data retrieval or the Functional Element clock generates a trigger.

2: The Functional Element retrieves the definition of batch data retrieval according to the name.

3: The Functional Element prepares the parameters for invocation of Retrieve data use case

4: The Functional Element invokes the Data Retrieve use case

5: The Functional Element formats the data according to the format defined in the batch data retrieval definition

6: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.7.2.2 Alternative Flows

1: Definition of Batch Data Retrieval Not Found.

1.1: If in the basic flow 2, the definition of batch data retrieval is not found, Functional Element returns an error message and the use case ends.

2: Error Returned From Data Retrieve Use Case.

2.1: If in the basic flow 4, the use case Retrieve data returns an error, Functional Element returns an error message and the use case ends.

2.1.7.7.3 Special Requirements

None.

2.1.7.7.4 Pre-Conditions

None.

2.1.7.7.5 Post-Conditions

None.

2.1.7.8 Manage Data Repository

2.1.7.8.1 Description

This use case allows the user to manage data repository.

2.1.7.8.2 Flow of Events

2.1.7.8.2.1 Basic Flow

The use case begins when the user wants to persistent a logical data view in the data repository, or the user wants to dispose the persistency of a data view from the data repository.

1: The user sends request to manage data repository by providing the name of the logical data view.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Persistent Data View’, the sub-flow 2.1 is executed.

If the operation is ‘Dispose Data View’, the sub-flow 2.1 is executed.

2.1: Persistent Data View

2.1.1: The Functional Element retrieves the definition of the logical data view.

2.1.2: The Functional Element forms the SQL statement according to the definition of the logical data view.

2.1.3: The Functional Element performs the data retrieval from data sources.

2.1.4: The Functional Element performs the data transformation according to the transformation rule.

2.1.5: The Functional Element creates table in Data Repository and fill in the table with data generated in previous step.

2.2: Dispose Data View

2.1.1: The Functional Element forms the SQL statements of deleting the table

2.1.3: The Functional Element deletes the table in Data Repository.

3: The Functional Element returns the results of the operation to the user and the use case ends.

2.1.7.8.2.2 Alternative Flows

1: Data View Not Found

1.1: If in the basic flow 2.1.1, the definition of batch data retrieval is not found, Functional Element returns an error message and the use case ends.

2: Data Exist

2.1: If in the basic flow 2.1.3, there is data in the table, Functional Element returns an error message and the use case ends.

3: Data Repository Error

3.1: If in the basic flow 2.1.5 and 2.2.3, there is an error in Data Repository, Functional Element returns an error message and the use case ends.

4: Data Source Not Available

4.1: If in the basic flow 2.1.3, the data sources related is not available, Functional Element returns an error message and the use case ends

2.1.7.8.3 Special Requirements

None.

2.1.7.8.4 Pre-Conditions

None.

2.1.7.8.5 Post-Conditions

None.

2.1.7.9 Synchronize Data

2.1.7.9.1 Description

This use case allows the user to synchronize data in Data Repository with the data from data sources.

2.1.7.9.2 Flow of Events

2.1.7.9.2.1 Basic Flow

The use case begins when the user wants to synchronize data of a logical data view in data repository with the data in data sources, or the time is up for synchronization of data.

1: The user sends request to synchronize data repository or the Functional Element clock generates a trigger.

2: The Functional Element gets or finds those data views that are required to be synchronized with data sources.

3: The Functional Element retrieves data view definitions.

4: The Functional Element retrieves data from data sources according the definition of logical data view.

5: The Functional Element performs the data transformation on the data retrieved.

6: The Functional Element updates the table in Data Repository with the data generated in previous step.

7: The Functional Element returns the result of the operation and the use case ends.

2.1.7.9.2.2 Alternative Flows

1: Data View Definition Not Found

1.1: If in the basic flow 3, the definition of batch data retrieval is not found, Functional Element returns an error message and the use case ends.

2: Data Repository Error

2.1: If in the basic flow 6, there is an error in updating the Data repository, Functional Element returns an error message and the use case ends.

3: Data Source Not Available

3.1: If in the basic flow 4, the data sources related is not available, Functional Element returns an error message and the use case ends

2.1.7.9.3 Special Requirements

None.

2.1.7.9.4 Pre-Conditions

None.

2.1.7.9.5 Post-Conditions

None.

2.2 Error Management Functional Element (new)

2.2.1 Motivation

Error management is an important aspect in any software application development. In particular, it is important to know the cause of error in the Service Oriented Architecture (SOA) environment as an application can consume any service provided from any domain space spans across the Internet space. When an error occurs, it can be from within the same application domain or from different domain space. Hence, it is important to know the system state when the error occurred in the SOA environment. For example, when an error occurred, what services were used; which services’ interfaces were used; the passed in parameters and its associated values used for the interfaces, the time when the error occurred, API or SOAP invocation, etc are the important information for managing the application in the SOA environment.

The Error Management Functional Element is a framework designed to capture the system state at which the error occurred. The variables that governed the system state when an error occurred are defined as follows:

· The time at which the error occurred.

· The class/object name that the error occurred.

· The method name of the said class/object at which the error occurred.

· The input parameters, parameters types and its associated values of the said method at which the error occurred.

· The expected output type of the mentioned method name.

· The error category, error code and error severity assigned by the application.

· The name of the consumed service/component.

· The name of the interface used for the said service/component.

· The input parameters and types defined for the said interface.

· The values used for the mentioned input parameters.

· The Universal Resource Location (URL) of the consumed service endpoint.

· The SOAP Fault message <Fault> element returned from the consumed service.

· The type of invocation whether it is a Web Service call or Application Programming Interfaces (APIs) call.

· The domain controller information includes :

o Name of the domain controller

o Contact Information, .e. Email Id, Short Message Services (SMS), Telephone, Mobile phone, etc.

o Means of Notification

The main motivation of the Functional Element is to provide a snapshot and capture all the system state information for an application when an error occurred. It assists system administrator to manage the system fault better for the necessary actions required for tracking the fault.

Figure 3 illustrates the perspective usage of Error Management Functional Element. When an error occurred in an application, the Functional Element will be used to capture the system state into a data store which can either be a database or a flat file.

Figure 3: Error Management Functional Element Usage

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

· Primary Requirements

· MANAGEMENT-340 to MANAGEMENT-346

· Secondary Requirements

· None

2.2.2 Terms Used

Terms	Description
Error Category	The Category or classification of error. For example, the category of error can be classified as: Database error à DATABX, Transaction error à TRANSX, Authentication error à AUTHEX, System error à SYSTEMX, Application-specific error à APPLSX, Third-party service error à THIRDPX, etc.
Error Code	The Error Code defined for each Error Category. For example, 001, 002, 003, etc
Error Severity	The Error Severity defined for each Error Code. For example, the severity could be in the order of Critical, Major, Minor, Warning, For Information Only.
External Application Error	The External Application Error is defined as an error / fault / exception occurred by consuming external Web Services / Components providers. For example, customized exception, SOAPException and SOAP Fault resulted from APIs or SOAP invocation to external components or Web Services.
Internal Application Error	The Internal Application Error is defined as error / fault / exception raised resulted from an internal processing or run time error. For example, exceptions such as Null Pointer Exception, Class Type Casting, Array Out of Bound, etc. that occurred due to processing or run time error.

Figure 4 is an example illustrating the error hierarchy in terms of Error Category, Error Code and Error Severity.

Figure 4: An Example of Error Hierarchy

For example, a database could give rise to a number of errors. For example, database not found, invalid username and password, no data found, null field, duplicate key etc are the common database errors. Each database error could have different severity. For example, database not found or invalid username and password are critical to business logic. An illustration of the resultant error code is defined as DATABX0001-CRITICAL.

2.2.3 Key Features

Implementations of the Error Management Functional Element are expected to provide the following key features:

1. The Functional Element MUST provide the ability to create new Error Category.

2. The Functional Element MUST provide the ability to modify and delete defined Error Category.

3. The Functional Element MUST provide the ability to all the information stored in the Error Category. This includes the capability to:

3.1 Add new Error Code(s) and descriptions into a Error Category

3.2 Retrieve, modify and delete error code and descriptions

3.3 Support Error Code(s) in numeric, alpha-numeric or string format

4. The Functional Element MUST provide a mechanism to capture the defined system state at which an error occurred.

In addition, the following key features could be provided to enhance the Functional Element further:

1. The Functional Element MAY provide the ability to manage Error Severity by enabling the capability to:

1.1. Tag/Add to Error Code defined,

1.2. Retrieve, modify and delete Severity tag to Error Code, and

1.3. Retrieve information based on either Error Code or Severity.

2.2.4 Interdependencies

Direct Dependency
Log Utility Functional Element	The Log Utility Functional Element helps to log the audit trial.
Notification Functional Element	The Notification Element helps to notify the target user via email, or short messaging service.

2.2.5 Related Technologies and Standards

Specifications	Specific References
XML Version 1.0	Extensible Markup Language (XML) 1.0 (Third Edition) W3C Recommendation 04 February 2004.
XML Schema	XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October 2004 XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004 XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October 2004
WSDL Version 1.1	Web Services Description Language (WSDL) 1.1 W3C Note 15 March 2001
SOAP Version 1.1	Simple Object Access Protocol (SOAP) 1.1 W3C Note 08 May 2000
Functional Elements Specification	OASIS Functional Elements Specification Committee Specifications 1.0, 16-Dec-2004

2.2.6 Model

Figure 5: Model Of the Error Management Functional Element

2.2.7 Usage Scenarios

2.2.7.1 Manage Error Category

2.2.7.1.1 Description

This use case allows the error management administrator to manage Error Category.

2.2.7.1.2 Flow of Events

2.2.7.1.2.1 Basic Flow

The use case begins when the user wants to create/retrieve/update/delete an Error Category.

1: The user sends a request to manipulate an Error Category.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Create Error Category’, the sub-flow 2.1 is executed.

If the operation is ‘Retrieve Error Category’, the sub-flow 2.2 is executed.

If the operation is ‘Update Error Category’, the sub-flow 2.3 is executed.

If the operation is ‘Delete Error Category’, the sub-flow 2.4 is executed.

2.1: Create Error Category.

2.1.1: The Functional Element gets category definition.

2.1.2: The Functional Element checks whether the category exists.

2.1.3: The Functional Element creates the category and save it in the error database.

2.2: Retrieve Error Category.

2.2.1: The Functional Element gets the Error Category name.

2.2.2: The Functional Element checks whether the category exists.

2.2.3: The Functional Element retrieves the Error Category’s information from the Error Management Data sources.

2.3: Update Error Category.

2.3.1: The Functional Element gets the Error Category name.

2.3.2: The Functional Element checks whether the Error Category exists.

2.3.3: The Functional Element updates the category definition and save it in the Error Management Data sources.

2.4: Delete Error Category.

2.4.1: The Functional Element gets the Error Category name.

2.4.2: The Functional Element checks whether the Error Category name exists.

2.4.3: The Functional Element checks whether the Error Code associated to the Error Category name exists.

· If Error Codes associated to the Error Category name exists, then basic sub-flow 2.4.4 is executed.

· If Error Codes associated to the Error Category name does not exist, then the basic sub-flow 2.4.7 is executed.

2.4.4: Error Codes associated to the Error Category name exists.

· If the Error Severity associated to the respective Error Codes exists, the basic sub-flow 2.4.5 is executed.

· If the Error Severity associated to the respective Error Code does not exist, then the basic sub-slow 2.4.6 is executed.

2.4.5: The Error Severity Exist.

2.4.5.1: The Functional Element removes the error severities associated to the respective Error Code from sub-flow 2.4.4.

2.4.6: The Error Severity Does Not Exist.

2.4.6.1 The Functional Element removes the respective Error Codes from sub-flow 2.4.3 from the Error Management Data sources.

2.4.7: The Error Codes Associated to the Error Category Name Does Not Exist.

2.4.7.1: The Functional Element removes the respective Error Codes associated to the Error Category name (from sub-flow 2.4.3) from the Error Management Data sources.

2.4.8: The Functional Element removes the Error Category name from the Error Management Data sources.

3: The Functional Element returns the results of the operation to the end user and the use case ends.

2.2.7.1.2.2 Alternative Flows

1: Error Category Already Exists.

1.1: If in the basic flow 2.1.2, the error category is already defined, the Functional Element writes the system state variables into the Error Management Data Sources using Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

1.2: If in the basic flow 2.1.2, the error category is already defined, the Functional Element writes the system state variables into the Error Management Data Sources using Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2: Error Category Not Found.

2.1: If in the basic flow 2.2.2, 2.3.2 and 2.4.2, the error category does not exist, the Functional Element writes the system state variables into the Error Management Data Sources using Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2.2.7.1.3 Special Requirements

None.

2.2.7.1.4 Pre-Conditions

None.

2.2.7.1.5 Post-Conditions

Once the Error Category is deleted, all the associated Error Code and its Error Severity will be removed.

2.2.7.2 Manage Error Code

2.2.7.2.1 Description

This use case allows the user to manage Error Code.

2.2.7.2.2 Flow of Events

2.2.7.2.2.1 Basic Flow

The use case begins when the user wants to create/retrieve/update/delete an error code associated to an error category.

1: The user sends a request to manipulate an error code.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Create Error Code’, the sub-flow 2.1 is executed.

If the operation is ‘Retrieve Error Code’, the sub-flow 2.2 is executed.

If the operation is ‘Update Error Code’, the sub-flow 2.3 is executed.

If the operation is ‘Delete Error Code’, the sub-flow 2.4 is executed.

2.1: Create Error Code.

2.1.1: The Functional Element gets the Error Category name

2.1.2. The Functional Element gets Error Code definition for the Error Category.

2.1.3: The Functional Element checks whether the Error Code exists.

2.1.4: The Functional Element creates the Error Code for the Error Category name and saves it into the Fault Management database.

2.2: Retrieve Error Code.

2.2.1: The Functional Element gets the Error Category name

2.2.2. The Functional Element gets the Error Code name.

2.2.3: The Functional Element checks whether the Error Code exists.

2.2.4. The Functional Element retrieves the Error Code’s information from the error database.

2.3: Update Error Code.

2.3.1: The Functional Element gets the Error Category name.

2.3.2. The Functional Element gets the Error Code name.

2.3.3: The Functional Element checks whether the Error Code exists.

2.3.4: The Functional Element updates the error code definition associated to the Error Category and save it in the Error Management Data sources.

2.4: Delete Error Code.

2.4.1: The Functional Element gets the Error Category name.

2.4.2. The Functional Element gets the Error Code name.

2.4.3: The Functional Element checks whether the Error Code exists.

2.4.4: The Functional Element checks whether the Error Severity associated to the Error Category and Error Code exists. Depending on whether the Error Severity exists, one of the following sub-flows will be executed.

· If the Error Severity exists, then basic sub-flow 2.4.5 is executed.

· If the Error Severity does not exist, the basic sub-flow 2.4.6 is executed.

2.4.5: Error Severity Exists.

2.4.5.1: The Functional Element removes the Error Severity associated to the Error Category and Error Code from the Error Management Data sources.

2.4.5.2: The Functional Element removes the Error Code associated to the Error Category name from the Error Management Data sources.

2.4.6: Error Severity Does Not Exist

2.4.6.1: The Functional Element removes the Error Code associated to the Error Category name from the Error Management Data sources.

3: The Functional Element returns the results of the operation to the end user and the use case ends.

2.2.7.2.2.2 Alternative Flows

1: Error Code Already Exists.

1.1: If in the basic flow 2.1.3, the Error Code associated to the Error Category name is already defined, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2: Error Code Not Found.

2.1: If in the basic flows 2.2.3, 2.3.3 and 2.4.3 the Error Code associated to the Error Category name does not exist, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2.2.7.2.3 Special Requirements

None.

2.2.7.2.4 Pre-Conditions

None.

2.2.7.2.5 Post-Conditions

None.

2.2.7.3 Manage Error Severity

2.2.7.3.1 Description

This use case allows the user to manage error severity.

2.2.7.3.2 Flow of Events

2.2.7.3.2.1 Basic Flow

The use case begins when the user wants to create/retrieve/update/delete an Error Severity associated to an Error Category and Error Code.

1: The user sends a request to manipulate an error severity.

2: Based on the operation it specifies, one of the following sub-flows is executed:

If the operation is ‘Create Error Severity’, the sub-flow 2.1 is executed.

If the operation is ‘Retrieve Error Severity, the sub-flow 2.2 is executed.

If the operation is ‘Update Error Severity’, the sub-flow 2.3 is executed.

If the operation is ‘Delete Error Severity’, the sub-flow 2.4 is executed

2.1: Create Error Severity.

2.1.1: The Functional Element gets Error Category name.

2.1.2: The Functional Element gets Error Code name.

2.1.3: The Functional Element gets Error Severity definition.

2.1.4: The Functional Element checks whether the Error Severity associated to the Error Category and error Code name exists.

2.1.5: The Functional Element creates the Error Severity associated to the Error Category name and Error Code name and saves it into the Error Management Data sources.

2.2 Retrieve Error Severity.

2.2.1: The Functional Element gets the Error Category name.

2.2.2: The Functional Element gets the Error Code name.

2.2.3. The Functional Element gets the Error Severity name.

2.2.4: The Functional Element checks whether the Error Severity exists associated to the Error Category and Error Code names.

2.2.5. The Functional Element retrieves the Error Severity’s information associated to the Error Category and Error Code names from the Error Management Data sources.

2.3: Update Error Severity.

2.3.1: The Functional Element gets the Error Category name.

2.3.2: The Functional Element gets the Error Code name.

2.3.3. The Functional Element gets the Error Severity name.

2.3.4: The Functional Element checks whether the Error Severity exists associated to the Error Category and Error Code names.

2.3.5: The Functional Element updates the Error Severity definition associated to the Error Category and Error Code names and saves it into the Error Management Data sources.

2.4: Delete Error Severity.

2.4.1: The Functional Element gets the Error Category name.

2.4.2: The Functional Element gets the Error Code name.

2.4.3. The Functional Element gets the Error Severity name.

2.4.4: The Functional Element checks whether the Error Severity exists associated to the Error Category and Error Code names.

2.4.5: The Functional Element removes the Error Severity associated to the Error Category and Error Code names from the Error Management Data sources.

3: The Functional Element returns the results of the operation to the end user and the use case ends.

2.2.7.3.2.2 Alternative Flows

1: Error Severity Already Exists.

1.1: If in the basic flow 2.1.4, the Error Severity associated to the Error Category and Error Code names is already defined, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2: Error Severity Not Found.

2.1: If in the basic flows 2.2.4, 2.3.4 and 2.4.4, the Error Severity associated to the Error Category and Error Code names does not exist, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2.2.7.3.3 Special Requirements

None

2.2.7.3.4 Pre-Conditions

None

2.2.7.3.5 Post-Conditions

None

2.2.7.4 Manage Fault

2.2.7.4.1 Description

This use case allows an application to manage error/fault depicted from a consumed service.

2.2.7.4.2 Flow of Events

2.2.7.4.2.1 Basic Flow

The use case begins when the user wants to manage an application’ fault arises.

If it is the ‘Internal Application Error, then basic flow 1 is executed.

If it is the ‘External Application Error, the basic flow 2 is executed.

1. Internal Application Error.

1.1. User sends the internal error detail information that needs to be tracked, together with Error Category, Error Code and Error Severity, which is an optional parameter, to the Functional Element. The internal error detailed information is described by Table 1.

1.2 The Functional Element logs the System State Information as defined in Table 1 using the Log Utility Functional Element into the Error Management Data sources.

S/N	Attributes of System State	Description	Mandatory / Optional
1	Time	The time where the fault occurred.	Mandatory
2	Class Name	The name of class where the fault occurred	Mandatory
3	Method Name	The name of the method where the fault occurred.	Mandatory
4	Input Parameters Names	The list of input parameters names for the said method name.	Mandatory
5	Input Parameters Types	The list of input parameter types associated to each of the input parameters names of the said method name.	Mandatory
6	Input Parameters Values	The list of input parameters values associated to each of the input parameters names of the said method name.	Mandatory
7	Expected Output Type	The expected output type of the said method name.	Optional
8	Fault	The fault that causes the exception.	Mandatory
9	Error Category	The Error Category assigned to the said Fault.	Mandatory
10	Error Code	The Error Code assigned to the said Fault.	Mandatory
11	Error Severity	The Error Severity assigned to the said Fault, if any.	Optional
12	Domain Controller Contact	The contact information of the domain controller. The contact information entails: Name of domain controller Email Id / Short Messaging Services (SMS) / Telephone / Mobile Phone Means of Notification	Mandatory

Table 1 System State Information for Internal Application Error

2. External Application Error

2.1 User sends error information that needs to be tracked, as well as Error Category, Error Code and optional Error Severity to the Functional Element. The external error information includes System State Information for Internal Application Error defined in Table 1.

2.2 The Functional Element logs the System State Information as defined in Table 2 using the Log Utility Functional Element into the Error Management Data sources.

S/No.	Attributes of System State	Description	Mandatory / Optional
1	Time	The time where the fault occurred.	Mandatory
2	Class Name	The name of class where the fault occurred	Mandatory
3	Method Name	The name of the method where the fault occurred.	Mandatory
4	Input Parameters Names	The list of input parameters names for the said method name.	Mandatory
5	Input Parameters Types	The list of input parameter types associated to each of the input parameters names of the said method name.	Mandatory
6	Input Parameters Values	The list of input parameters values associated to each of the input parameters names of the said method name.	Mandatory
7	Expected Output Type	The expected output type of the said method name.	Optional
8	Fault	The fault that causes the exception.	Mandatory
9	Error Category	The Error Category assigned to the said Fault.	Mandatory
10	Error Code	The Error Code assigned to the said Fault.	Mandatory
11	Error Severity	The Error Severity assigned to the said Fault, if any.	Optional
12	Domain Controller Contact	The contact information of the domain controller. The contact information entails: Name of domain controller Email Id / Short Messaging Services (SMS) / Telephone / Mobile Phone Means of Notification	Mandatory
13*	Web Services Endpoint URL	The URL for the consumed web service.	Mandatory
14*	Invocation Type	The invocation type used for interface invocation, i.e. API or SOAP invocation.	Mandatory
15*	Consumed Web Service Name	The name of the consumed web service from within the application.	Mandatory
16*	Used Interface Name	The name of the interface used	Mandatory
17*	Used Interface Input Parameters Name	The list of input parameters names required for the said interface.	Mandatory
18*	Used Interface Input Parameters Types	The list of input parameters names types defined for the said interface.	Mandatory
19*	Used Interface Input Parameters Values	The list of input parameters values passed in for the said interface.	Mandatory
20*	SOAP Fault <Fault> Element	The content of the received SOAP Fault message <Fault> element.	Mandatory

Table 2. System State Information for External Application

Items indicated by the symbol “*” are the additional System State Information attributes which are applicable to External Application Error only.

3. The Functional Element returns the result of the operation to the user and the use case ends.

2.2.7.4.2.2 Alternative Flow

1: Error Category Does Not Exist

1.1: If in the basic flows 1.1 and 2.1, the Error Category Name is not defined, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller and the use case ends.

2. Error Code Does Not Exist

2.1. If in the basic flows 1.1 and 2.1, the Error Code associated to the Error Category is not defined, the Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

3. Error Severity Does Not Exist

3.1. If in the basic flows 1.1 and 2.1, the Error Severity associated to the Error Category, and Error Code is not defined, the Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

4. Log Utility Functional Element Not Available.

4.1. If in the basic flows 1.2 and 2.2, the Log Utility Functional Element writes the system state variables into the Error Management Data sources using the Log Utility Functional Element and notifies the system domain controller using the Notification Functional Element and the use case ends.

2.2.7.4.3 Special Requirements

None

2.2.7.4.4 Pre-Conditions

None

2.2.7.4.5 Post-Conditions

None

2.3 Event Handler Functional Element

2.3.1 Motivation

Information is in abundance in a service-oriented environment. However, not all information is applicable to a particular enterprise and there lies the need to control information flow in an organization. In a Web Service-enabled implementation, the Event Handler Functional Element can help to fulfill this need by:

· Managing the information flow through a subscription based mechanism,

· Streamlining information into meaningful categories so as to improve relevancy to a potential consumer of the information, and

· Refining information flow via a filtering mechanism

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

· Primary Requirements

· MANAGEMENT-111,

· PROCESS-005, and

· PROCESS-100 to PROCESS-117.

· Secondary Requirements

· None

2.3.2 Terms Used

Terms	Description
Active Event Detection	Active Event Detection refers to the capability to periodically detect the occurrence of an external Event.
Channel	A Channel is a logical grouping of similar event types generated by the suppliers. When an Event is routed to a channel, all the Event Consumers who have subscribed to that Channel will be notified.
Event	An Event is an indication of an occurrence of an activity, such as the availability of a discounted air ticket. In such a case, it will trigger a follow-up action such as the URL where the ticket can be bought. Interested event consumer can then proceed with the purchase at the designated URL.
Event Consumer	An Event Consumer is a receiver of the events generated by an Event Supplier.
Event Supplier	An Event Supplier generates Event. It can be an application or a service, or even a person. Note that Event Suppliers are typically external to the Event Handler.
Filter	A Filter is a mechanism for defining Event that is of value to the Event Consumer.
Routing Rule	A Routing Rule defines how an Event is routed. An Event can be routed to a Channel or directly to an Event Consumer.

Figure 6: An Overview of the Event Handler Functional Element

Figure 3 depicts the basic concepts of how the participating entities collaborate together in the Event Handler Functional Element. Beginning with the event supplier who generates an event, the event is subsequently routed to the routing rules engine. Depending on the rules specified by the event administrator on the engine, the event could be routed to an appropriate channel, for example, the airfreight channel. In this case, a notification message will be sent to the subscribing event consumers. In between that, there is a filtering engine to determine if a particular event is meaningful to the intended recipients and this is configurable by the recipients themselves.

2.3.3 Key Features

Implementations of the Event Handler Functional Element are expected to provide the following key features:

1. The Functional Element MUST provide the capability to manage the creation (or registration) and deletion of instances of the following concepts based on a pre-defined structure:

1.1. Event Supplier,

1.2. Event Consumer,

1.3. Event,

1.4. Filter,

1.5. Channel, and

1.6. Routing Rule.

2. The Functional Element MUST provide the capability to manage all the information (attribute values) stored in such concepts. This includes the capability to retrieve and update attribute’s values belonging to the concepts mentioned in Key Feature (1).

3. The Functional Element MUST provide the capability to enable Event Suppliers to trigger relevant Events.

4. The Functional Element MUST provide a mechanism to associate/unassociate Routing Rules to an Event.

Example: As shown in Figure 1, where an event can be routed to Air Freight or Financial Channel or even to all channels based on the Routing Rules that are associated with the Event.

5. As part of Key Feature (3), the Routing Rules must be able to route an event to all, specified Channels or individual Event Consumers.

6. The Functional Element MUST enable Event Consumers to execute the following tasks to improve the relevancy of the incoming events”

6.1. Subscribe/Unsubscribe to relevant Channel(s), and

6.2. Apply a filter to the appropriate channel or event, which helps to refine the criteria of a useful event further.

7. The Functional Element MUST provide the capability to notify relevant Event Consumers when an event occurs.

Examples of notification types include SMS, email and Web Services invocations.

8. As part of Key Feature (6), the notification must be able to handle differing requirements arising from different notification formats.

Example: If the incoming event contains 2 important attributes, the order or position of these 2 attributes must be configurable to suit the convenience of the Event Consumer. This is extremely important in the case of Web Service Invocations.

9. The Functional Element MUST provide a mechanism for managing the concepts specified across different application domains.

Example: Namespace control mechanism

In addition, the following key features could be provided to enhance the Functional Element further:

1. The Functional Element MAY provide a mechanism to enable active event detection.

2. If Key Feature (1) is implemented, then the Functional Element MUST provide the following capabilities also:

2.1. Non-intrusive detection

Example: The detection of a new event through periodic inspection of the audit log.

2.2. Configurable event detection schedule

Example: To inspect the audit log every 2 hours, where the duration between inspections is configurable.

2.3. Ability to retrieve relevant data from external source(s) for further event processing by Event Handler

Example: To retrieve Error Type and Message from audit log.

3. The Functional Element MAY provide the capability to record event processing within the Event Handler. The logging of event processing includes the occurrences of event, sending of notifications, warning and error messages generated in the processing of events.

4. The Functional Element MAY provide the capability scheduled-based event notification.

2.3.4 Interdependencies

Direct Dependency
Log Utility Functional Element	The Log Utility Functional Element helps to log the audit trial.

Interaction Dependency
Notification Functional Element	The Notification Functional Element helps to send SMS and email to the appropriate Event Consumer.

2.3.5 Related Technologies and Standards

None

2.3.6 Model

Figure 7: Model Of the Event Handler Functional Element [[5]]

2.3.7 Usage Scenarios

2.3.7.1 Register Supplier/Consumer

2.3.7.1.1 Description

This use case allows the user to register itself to the Event Handler Functional Element as an event supplier or an event consumer.

2.3.7.1.2 Flow of Events

2.3.7.1.2.1 Basic Flow

The use case begins when the user of the Event Handler wants to register an event supplier or event consumer with the Event Handler.

1: The user sends a request to Event Handler together with its profile data and operation.

2: Based on the operation it specified, one of the following sub-flows is executed:

If the operation is ‘Register as supplier’, then sub-flow 2.1 is executed.

If the operation is ‘Register as consumer’, then sub-flow 2.2 is executed.

If the operation is ‘Un-register as supplier’, then sub-flow 2.3 is executed.

If the operation is ‘Un-register as consumer’, then sub-flow 2.4 is executed.

If the operation is ‘Update supplier’, then sub-flow 2.5 is executed.

If the operation is ‘Update consumer’, then sub-flow 2.6 is executed.

If the operation is ‘Retrieve supplier’, then sub-flow 2.7 is executed.

If the operation is ‘Retrieve consumer’, then sub-flow 2.8 is executed.

2.1: Register as Supplier.

2.1.1: The Functional Element gets the user profile data, i.e. namespace, name, description and type.

2.1.2: The Functional Element registers the user as event supplier.

2.1.3: The Functional Element returns the Supplier Id to the user.

2.2: Register as Consumer.

2.2.1: The Functional Element gets the user profile data, i.e. namespace, name, description and type.

2.2.2: The Functional Element registers the user as event consumer.