Functional Elements Specification
Committee Draft 2.0,
Document identifier:
fwsi-fe-2.0-guidelines-spec-cd-01.doc
Location:
http://www.oasis-open.org/apps/org/workgroup/fwsi/documents.php
Editor:
Contributor(s):
Andy Tan, Individual (andytan@intrinix.net)
Shawn Cheng Hua-Shan, XMLBoss (shawn@xmlboss.net)
Kenneth Lim, Crimson Logic Pte Ltd (kennethlim@crimsonlogic.com)
Viren Baraiya, Crimson Logic Pte Ltd (viren@crimsonlogic.com)
Jagdip Talla, Crimson Logic Pte Ltd (jagdip@crimsonlogic.com)
Roberto Pascual, Infocomm Development Authority (IDA) of
Lee Eng Wah, SIMTech (ewlee@simtech.a-star.edu.sg)
V.Ramasamy, SIMTech (rama@simtech.a-star.edu.sg)
Abstract:
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 (F
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 F
Table of Contents
2.1 Data
Integrator Functional Element (new)
2.1.5 Related
Technologies and Standards
2.2 Error
Management Functional Element (new)
2.2.5 Related
Technologies and Standards
2.3 Event
Handler Functional Element
2.3.5 Related
Technologies and Standards
2.4 Group
Management Functional Element
2.4.5 Related
Technologies and Standards
2.5 Identity Management Functional Element
2.5.5 Related Technologies and Standards
2.6 Information Catalogue Functional Element (new)
2.6.5 Related
Technologies and Standards
2.7 Information
Reporting Functional Element (new)
2.7.5 Related
Technologies and Standards
2.8 Key
Management Functional Element (new)
2.8.5 Related
Technologies and Standards
2.9 Log Utility
Functional Element
2.9.5 Related
Technologies and Standards
2.10 Notification
Functional Element
2.10.5 Related
Technologies and Standards
2.11 Phase and
Lifecycle Management Functional Element
2.11.5 Related
Technologies and Standards
2.12 Policy
Management Functional Element (new)
2.12.5 Related Technologies
and Standards
2.13 Policy
Enforcement Functional Element (new)
2.13.5 Related
Technologies and Standards
2.14 Presentation
Transformer Functional Element (Deprecated)
2.15 QoS Functional Element (new)
2.15.5 Related
Technologies and Standards
2.16 Role and
Access Management Functional Element
2.16.5 Related
Technologies and Standards
2.17 Search
Functional Element
2.17.5 Related
Technologies and Standards
2.18 Secure
SOAP Management Functional Element
2.18.5 Related
Technologies and Standards
2.19 Sensory
Functional Element
2.19.5 Related
Technologies and Standards
2.20 Service
Level Management Functional Element (new)
2.20.5 Related
Technologies and Standards
2.21 Service
Level Enforcement Functional Element (new)
2.21.5 Related
Technologies and Standards
2.22 Service
Management Functional Element
2.22.5 Related
Technologies and Standards
2.23 Service
Registry Functional Element
2.23.5 Related
Technologies and Standards
2.24 Service
Router Functional Element (new)
2.24.5 Related
Technologies and Standards
2.25 Service
Tester Functional Element (Deprecated)
2.26 Transformer Functional Element (new)
2.26.5 Related
Technologies and Standards
2.27 User
Management Functional Element
2.27.5 Related
Technologies and Standards
2.28 Web
Service Aggregator Functional Element
2.28.5 Related
Technologies and Standards
3 Functional
Elements Usage Scenarios
3.3 Decoupled
User Access Management
3.4 Single-Sign-On
for Distributed Services (Applications)
The purpose of OASIS Framework for Web Services
Implementation (F
One of the F
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
·
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 3rd party services. As a typical 3rd partys 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.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 . |
|
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.
The Functional Element MUST provide the capability to define a logical data view based on the pool of available data sources
1. .
The Functional Element MUST provide capability to manage the updating and deletion of a logical data view
2. .
The Functional Element MUST provide capability to manage the creation, updating and deletion of data transformation rules
3. .
The Functional Element MUST provide capability to retrieve data based on the logical data view defined
4. .
The Functional Element MUST provide a unified way to query data based on defined logical data views
5. .
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
6. .
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. 5 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. 6 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 views 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 rules 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.
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.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 th definition of logical
data view.
5: The Functional
Element performs the data transformation on the data retrieved.
6: The Functional
Element update 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:
Primary Requirements
·
MANAGEMENT-340 to MANAGEMENT-346
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 |
|
XML Schema |
XML
Schema Part 0: Primer Second Edition W3C Recommendation XML
Schema Part 1: Structures Second Edition W3C Recommendation XML
Schema Part 2: Datatypes Second Edition W3C Recommendation |
|
|
Web Services Description Language ( |
|
SOAP Version 1.1 |
Simple Object Access Protocol (SOAP) 1.1
W3C Note |
|
Functional Elements Specification |
OASIS Functional Elements Specification Committee Specifications 1.0, |
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 Categorys 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.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.
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 Codes 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.
1. 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 Severitys 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 |
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
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 |
Description |
Mandatory / |
|
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.
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, Working Draft 01a:
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 attributes 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.
10. 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. |
|
|
|
|
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 [[4]] |
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.
2.2.3: The Functional Element returns the Consumer Id to the user.
2.3: Un-register as Supplier.
2.3.1: The Functional Element gets the user namespace and name or User Id.
2.3.2: The Functional Element checks whether the user is a supplier.
2.3.3: The Functional Element removes the user as supplier.
2.4: Un-register as Consumer.
2.4.1: The Functional Element gets the user namespace and name or User Id.
2.4.2: The Functional Element checks whether the user is a consumer.
2.4.3: The Functional Element removes the user as consumer.
2.5: Update Supplier.
2.5.1: The Functional Element gets the user namespace and name or User Id together with the user profile.
2.5.2: The Functional Element checks whether the user is a supplier.
2.5.2: The Functional Element updates the user profile.
2.6: Update Consumer.
2.6.1: The Functional Element gets the user namespace and name or User Id together with the user profile.
2.6.2: The Functional Element checks whether the user is a consumer.
2.6.3: The Functional Element updates the user profile.
2.7: Retrieve Supplier.
2.7.1: The Functional Element gets the user namespace and name or User Id.
2.7.2: The Functional Element checks whether the user is a supplier.
2.7.3: The Functional Element returns the user profile.
2.8: Retrieve Consumer.
2.8.1: The Functional Element gets the user namespace and name or User Id.
2.8.2: The Functional Element checks whether the user is a consumer.
2.8.3: The Functional Element returns the user profile.
2.3.7.1.2.2 Alternative Flows
1: Supplier Already Registered.
1.1: If in the basic flow 2.1.2, the user already registered as supplier, Functional Element will return an error message to the user and the use case ends.
2: Consumer Already Registered.
2.1: If in the basic flow 2.2.2, the user already registered as consumer, Functional Element will return an error message to the user and the use case ends.
3: Supplier or Consumer Not Registered.
3.1: If in the basic flow 2.3.2, 2.4.2, 2.5.2, 2.6.2, 2.7.2, and 2.8.2, the user specified is not registered, Functional Element will return an error message to the user and the use case ends.
4: Persistency Mechanism Error.
4.1: If in the basic flow 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2,7 and 2.8, the Functional Element cannot perform data persistency, Functional Element will return an error message to the user and the use case ends.
2.3.7.1.3 Special Requirements
None.
2.3.7.1.4 Pre-Conditions
None.
2.3.7.1.5 Post-Conditions
None.
2.3.7.2 Manage Channel
2.3.7.2.1 Description
This use case allows the user to manage channels.
2.3.7.2.2 Flow of Events
2.3.7.2.2.1 Basic Flow
The use case begins when the user wants to create/retrieve/update/delete a channel
1: The user sends request to manipulate a channel.
2: Based on the operation it specifies, one of the following sub-flows is executed:
If the operation is Create Channel, the sub-flow 2.1 is executed.
If the operation is Retrieve Channel, the sub-flow 2.2 is executed.
If the operation is Update Channel, the sub-flow 2.3 is executed.
If the operation is Delete Channel, the sub-flow 2.4 is executed.
2.1: Create Channel.
2.1.1: The Functional Element gets channel definition, i.e. namespace, channel name and description.
2.1.2: The Functional Element checks whether the channel exists.
2.1.3: The Functional Element creates the channel.
2.2: Retrieve Channel.
2.2.1: The Functional Element gets namespace, channel name and retrieve condition.
2.2.2: The Functional Element retrieves the channels information according to the condition.
2.3: Update Channel.
2.3.1: The Functional Element gets namespace, channel name and description.
2.3.2: The Functional Element checks whether the channel exists.
2.3.3: The Functional Element updates the channel definition.
2.4: Delete Channel.
2.4.1: The Functional Element gets namespace and channel name.
2.4.2: The Functional Element checks whether the channel exists.
2.4.3: The Functional Element removes the channel from the Functional Element.
3: The Functional Element returns the results of the operation to the user and the use case ends.
2.3.7.2.2.2 Alternative Flows
1: Channel Already Exists.
1.1: If in the basic flow 2.1.2, the channel is already defined, Functional Element returns an error message and the use case ends.
2: Conditional Retrieving.
2.1: In the basic flow 2.2.2:
2.1 1: If the condition is the retrieval by channel name and the channel does not exist, then it will go to Alternative Flow 3.
2.1.2: If the condition is the retrieval of one channel definition, it returns the definition of that channel and the use case ends.
2.1.3: If the condition is the retrieval of all channels information, it returns all channels definition and the use case ends.
2.1.4: If the condition is the retrieval of channel through channel description, it will return all matched channels and the use case ends.
2.1.5: If the condition is the retrieval of registered consumers, it returns the list of consumer registered on the channel and the use case ends.
3: Channel Not Found.
3.1: If in the basic flow 2.2.2, 2.3.2 and 2.4.2, the channel does not exist, Functional Element will return an error message and the use case ends.
4: Consumer Not Found.
4.1: If in the basic flow 2.1.3, 2.5.3 and 2.6.3, the event consumer does not exist, Functional Element will return an error message and the use case ends.
5: Extension Point.
5.1: If in the basic flow 2.1.3, and 2.3.3, the event consumers that subscribed to the channel are provided, the use case Subscribe/un-subscribe channel will be extended.
2.3.7.2.3 Special Requirements
None.
2.3.7.2.4 Pre-Conditions
None.
2.3.7.2.5 Post-Conditions
None.
2.3.7.3 Subscribe/Un-subscribe To Channel
2.3.7.3.1 Description
This use case performs the subscription or un-subscription on a channel for an event consumer.
2.3.7.3.2 Flow of Events
2.3.7.3.2.1 Basic Flow
The use case begins when the user wants to subscribe or un-subscribe to a channel.
1: The user sends the request.
2: Based on the operation it specifies, one of the following sub-flows is executed:
If the operation is Subscribe to Channel, then sub-flow 2.1 is executed.
If the operation is Un-Subscribe to Channel, then sub-flow 2.2 is executed.
2.1: Subscribe To Channel.
2.1.1: The Functional Element gets event consumer Id, or consumer namespace and consumer name, together with channel namespace and channel name.
2.1.2: The Functional Element checks whether the channel exists.
2.1.3: The Functional Element adds the subscription of the consumer to the channel.
2.2: Un-Subscribe To Channel.
2.2.1: The Functional Element gets event consumer Id, or consumer namespace and consumer name, together with channel namespace and channel name.
2.2.2: The Functional Element checks whether the channel exists.
2.2.3: The Functional Element removes the subscription of the consumer to the channel.
3: The Functional Element returns the results of the operation to the user and the use case ends.
2.3.7.3.2.2 Alternative Flows
1: Channel Not Found.
1.1: If in the basic flow 2.1.2 and 2.2.2, the channel specified does not exist, Functional Element will return an error message to the user and the use case ends.
2: Event Consumer Not Found.
2.1: If in the basic flow 2.1.2 and 2.2.2, the event consumer related does not exist, Functional Element will return an error message to the user and the use case ends.
2.3.7.3.3 Special Requirements
None.
2.3.7.3.4 Pre-Conditions
None.
2.3.7.3.5 Post-Conditions
None.
2.3.7.4 Manage Event
2.3.7.4.1 Description
This use case describes the scenarios of managing events.
2.3.7.4.2 Flow of Events
2.3.7.4.2.1 Basic Flow
The use case begins when the user wants to manage events.
1: The user sends a request to the Functional Element.
2: Based on the operation it specifies, one of the following sub-flows is executed:
If the operation is Create Event, then sub-flow 2.1 is executed.
If the operation is Retrieve Event Information, then sub-flow 2.2 is executed.
If the operation is Update Event Definition, then sub-flow 2.3 is executed.
If the operation is Delete Event, then sub-flow 2.4 is executed.
If the operation is Assign Flow, then sub-flow 2.5 is executed.
If the operation is Un-Assign Flow, then sub-flow 2.6 is executed.
2.1: Create Event
2.1.1: The Functional Element gets event definition including namespace, event name, event description, event routing rule, and event attributes definition.
2.1.2: The Functional Element verifies the parameters.
2.1.3: The Functional Element verifies the routing rule through use case verify routing rule.
2.1.4: The Functional Element creates event definition by recording the definition of event.
2.2: Retrieve Event.
2.2.1: The Functional Element gets namespace, event name, and condition.
2.2.2: The Functional Element retrieves the event definition according to the condition.
2.3: Update Event Definition
2.3.1: The Functional Element gets event definition including namespace, event name, event description, event routing rule, and event attributes definition.
2.3.2: The Functional Element verifies the parameters.
2.3.3: The Functional Element verifies the routing rule through use case verify routing rule.
2.3.4: The Functional Element updates the event definition.
2.4: Delete Event.
2.4.1: The Functional Element gets namespace and event name.
2.4.2: The Functional Element checks whether the event exists.
2.4.3: The Functional Element deletes the event definition.
2.5: Assign Flow.
2.5.1: The Functional Element gets namespace, event name and flow name.
2.5.2: The Functional Element checks whether the event exists and flow defined.
2.5.3: The Functional Element assigns the flow to the event.
2.6: Un-assign Flow.
2.6.1: The Functional Element gets namespace, event name and flow name.
2.6.2: The Functional Element checks whether the event exists and flow defined.
2.6.3: The Functional Element un-assigns the flow to the event.
3: The Functional Element returns the results of the operation to the user and the use case ends.
2.3.7.4.2.2 Alternative Flows
1: Event Already Exist.
1.1: If in the basic flow 2.1.2, the event already exists, Functional Element will return an error message to the user and the use case ends.