Potential Functional Elements

1
Potential Functional Elements

• Towards FE Specs 2.0

For FESC Discussion 18 May 2005
Tan Puay Siew
2
Proposed New Sub-Areas
Not Defining New FEs, too infrastructural level
3
List of Potential FEs Identified

• Management
• Error Management
• Service Level Management
• Service Compliance Monitoring
• Service Tester (refinement/addition)
• Process (Integration)
• Service Router
• Data Integrator
• Catalogue Service

• Delivery (Messaging)
• Reporting Service
• Web Service Document Parser
• Transformer
• Security
• Key Management
• Policy Management
• Policy Enforcement

4
Management

• Error Management
• Service Level Management
• Service Compliance Monitoring
• Service Tester (refinement/addition)

5
Error Management - 1

• Motivation
• Enable error and exception management arising out
  of Web Services applications to be reported and
  traced
• Identify the root cause of the faulty web
  service that causes other aggregated/composed web
  services to throw exceptions respectively
• Generate a fault report (e.g. in the form of
  notification) to inform the actual web service
  provider that causes the fault
• To achieve the highly robust web service-enabled
  applications
• Fulfilling Requirements

6
Error Management 2a

• Features - 1
• The functional element MUST provide the ability
  to create new Error Category
• to add Error Category details?
• The functional element MUST provide the ability
  to modify and delete defined Error Categories
• The functional element MUST provide the
  capability to manage all the information stored
  in the error categories. This includes the
  capability to
• Add new error code(s) and descriptions into a
  Error Category
• Retrieve, modify and delete error code and
  descriptions
• Support error code in the numeric, alpha-numeric
  or string formats
• The functional element MAY provide the ability to
  manage error severity by enabling the capability
  to
• Tag/Add severity into error codes defined
• Retrieve, modify and delete severity tag to error
  codes
• Retrieve information based on either error code
  or severity code

7
Error Management 2b

• Features - 2
• The functional element MUST provide the ability
  to create system-level fault or
  application-specific fault as SOAP faults based
  on the defined error category.
• E.g.
• faultcode ? using the existing faultcode values
  defined in SOAP version 1.1 or user defined error
  category. If the standard faultcode values are
  used, it MUST be namespace-qualified with
  http//schemas.xmlsoap.org/soap/envelope/. If
  the user-defined error category, it MUST be
  application-specific namespace-qualified.
• faultstring ? It MUST be able to assign with
  short error message
• faultactor ? It MUST be able to assign URI of the
  fault source
• detail ? It MUST be able to assign the details
  fault/error message thrown by an application
• The functional element MUST provide the ability
  to parse the received SOAP message response
  containing the fault elements for application to
  handle fault/error
• The functional element MUST provide the ability
  to generated the fault report in language
  supported. multiple-language supported.
• Web Service exists in UDDI The functional
  element MUST provide the ability to send a SMS or
  email notification to the service provider that
  owns the faulty service.
• Web Service does not exist in UDDI NO
  notification will be sent to the service provider
  that owns the fault service.

8
Error Management - 3

• Interdependencies
• Reporting
• Log Util
• Notification
• Parser
• Technologies and Standards
• XML version 1.0
• SOAP version 1.1
• WSDL version 1.1
• UDDI version 2.0

9
Service Level Management - 1
(was Pricing/Billing/Subscription)

• Motivation
• Enable the management of Service Level Agreements
  (SLAs)
• A SLA represents a joint agreement between the
  service customer and provider based on a set of
  service offerings
• Service offerings typically expressed as SLA
  templates.
• With customisation capabilities to the SLAs
• Enable the management of a SLA lifecycle, broadly
  classified into
• Creation,
• Deployment provisioning,
• Enforcement and monitoring for service invocation
  under a SLA, and
• SLA termination
• Fulfilling Requirements

10
Service Level Management - 2

• Features
• The Functional Element MUST provide the ability
  to create Service Offering and associated service
  levels
• The Functional Element MUST provide the ability
  to manage defined Service Offerings, including
  the ability retrieve, modify and delete.
• The Functional Element MUST provide the ability
  to create of a SLA via customer subscription
  based on defined Service Offerings
• The Functional Element MUST provide the ability
  to generate billing service level reports based
  on defined SLAs
• The Functional Element MUST provide the ability
  to notify who? of SLA termination
• The Functional Element MUST provide the ability
  to delete SLAs upon termination
• The Functional Element MUST provide the ability
  to renegotiate new SLAs automatically?
• The Functional Element MAY provide the ability to
  customise SLAs. This include the capability to
• Alter service offerings parameters
• Add and delete different service offerings into a
  SLA

11
Service Level Management - 3

• Interdependencies
• Technologies and Standards

12
Process (Integration)

• Service Router
• Data Integrator
• Catalogue Service

13
Data Integrator - 1

• Motivation
• Enable capability for 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
• Performing data processing or transformation
  before presenting data view
• Generating reports based on the data view
• Fulfilling Requirements

14
Data Integrator 2a

• Features (1)
• The Functional Element MUST provide capability
  to manage the available data sources. This
  includes capability to
• Add new data source to the pool of available data
  sources.
• When adding new data sources into the pool, the
  information of data source name, data source
  location for connection, login id and password
  of the user who has the privileges to manipulate
  the data source is required
• Remove data source from the pool of available
  data sources.
• Removing data source from the pool can only
  happen if there is no logical data view defined
  on this data source.
• The Functional Element MUST provide capability
  to define a logical data view based on the pool
  of available data sources.
• A logical data view is defined by its name,
  owner, created date, the data fields of data
  view, the sources of data fields, the constraints
  of data view, and the transformation rule.
• The Functional Element MUST provide capability
  to manage the updating and deletion of a logical
  data view

15
Data Integrator 2b

• Features (2)
• The Functional Element MUST provide capability to
  manage the creation, updating and deletion of
  data transformation rules.
• 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
• The Functional Element MUST provide capability
  to retrieve data based on the logical data view
  defined
• The Functional Element MUST provide a unified way
  to query data based on defined logical data views
• 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

16
Data Integrator 2c

• Features (3)
• The Functional Element MAY provide capability to
  insert, update and delete data based on a logical
  data view (where applicable).
• The Functional Element MAY provide the capability
  to enable user to define Batch Data Retrievals
  (BDR).
• The definition of such batch retrievals 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
• to include target presentation format of
  retrieved data
• The Functional Element MAY provide the capability
  to schedule BDRs
• The Functional Element MAY provide the capability
  to manage the definition of BDRs. This includes
  capability to
• Enable/Disable the schedule of batch data
  retrieval
• Remove the definition of batch data retrieval
• 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
• The Functional Element MAY provide a mechanism to
  synchronize data between data repository and data
  sources if data repository is provided
• The Functional Element MAY provide a mechanism to
  allow user to define the formats of reports based
  on the logical data view
• The Functional Element MAY provide capability to
  generate reports according the pre-defined report
  formats

17
Data Integrator - 3

• Interdependencies
• Technologies and Standards
• RDBMS, LDAP, XML Database

18
Catalogue Service - 1

• Motivation
• Provide a framework that will enable the ability
  to harness and access huge amount of
  product-related information and present them as
  catalogue for
• Quick and easy definition of product/information
  catalogues
• Customisation of catalogues for specific needs or
  marketing niche
• Easy maintenance of storefronts/catalogues over
  the network
• Outsourcing of catalogue management together with
  multilingual support

19
Catalogue Service - 2

• Features
• The Functional Element MUST be able to provide
  the ability to define and maintain Catalogue
  Structures
• Eg Basic Catalogue Structure could include Code,
  Name, Description, Price, Unit, Qty, Category,
  Keywords, etc.
• The Functional Element MUST be able to provide
  the capability to manage all the information
  stored in the Catalogue Structures
• The Functional Element MUST provide the
  capability to execute basic searches like
  categorical, names, keywords on the catalogue
  information
• The Functional Element MUST provide the ability
  to return formatted results based on the
  Catalogue Structure
• The Functional Element MAY provide the ability to
  enable secured access to catalogue structure as
  well as catalogue information.
• The Functional Element MAY provide the ability to
  present catalogue information in different
  languages. i.e. multi-lingual support.
• The Functional Element MAY provide the ability to
  import catalogue structure and information from
  different data sources.
• The Functional Element MAY provide the ability to
  export catalogue structure and information to
  different data sources.

20
Catalogue Service - 3

• Interdependencies
• Search
• Localisation / Internationalisation
• User Management
• Role Access
• Transformation
• Technologies and Standards
• To be determined

21
Delivery (Messaging)

• Reporting Service
• Web Service Document Parser
• Transformer

22
Reporting Service - 1

• Motivation
• Enable reporting capability that is able to
  provide a generic interface to generate reports
  based on configuration information and outputs in
  different reporting formats and protocols
• Reporting formats would include static and
  on-the-fly (dynamic) formats

23
Reporting Service 2a

• Features (1)
• The Functional Element MUST be able to provide
  the ability to define and manage Report Formats.
• Eg. A basic Report Format could include elements
  like headers, footers, titles, sub-titles,
  totals, sub-totals, counts, maximums, minimums,
  averages, placeholders.
• The Functional Element MUST provide the
  capability to define, manage and generate static
  information listing based on static report
  formats
• Eg. Companies List, Employees List, Products
  List, etc.
• The Functional Element MUST provide the
  capability to define, and execute queries.
• Queries include conditional, range or periodic,
  computational, statistical and analytical types.
• Able to generate dynamic information based on
  dynamic report formats?
• Eg. Purchase Orders Summary, Maximum/Minimum
  Stock Prices, Daily/Weekly/Monthly Sales, Annual
  Sheet, KPI(s) Count, etc.

24
Reporting Service 2b

• Features (2)
• The Functional Element MAY provide the ability to
  store and retrieve queries that have been
  executed
• The Functional Element MAY provide the ability to
  store and retrieve reports that have been
  generated.
• The Functional Element MAY provide secured access
  to reported information
• The Functional Element MAY provide the ability to
  export reports to different electronic file
  formats

25
Reporting Service - 3

• Interdependencies
• User Management
• Role Access
• Transformation
• Technologies and Standards
• To be determined

26
Web Service Document Parser - 1

• Motivation
• Enable the provisioning for a multi-purpose
  parser (XML based) that is able to extract
  information into an organised requested structure
  
• Parser is very useful in programming tasks, as
  application becomes more information centric
• Easier to construct of web service clients also

27
Web Service Document Parser 2

• Features
• The Functional Element MUST be able to parse WSDL
  documents and SOAP messages.
• The Functional Element will parse based on a user
  specified XML Schema
• The Functional Element MUST be able to provide a
  mechanism for definition of target format
  template.
• This template will be used for the storage of
  extracted and reorganised information
• The Functional Element MUST be able to read or
  write to a file and/or network stream.
• The Functional Element MAY provide the ability to
  parse BPEL, UDDI documents/messages also.
• The Functional Element MAY provide an option for
  the user to retrieve all the elements of a
  document.

28
Web Service Document Parser - 3

• Interdependencies
• None
• Technologies and Standards
• WSDL
• SOAP
• BPEL
• UDDI
• to include exact version

29
Transformer - 1

• Motivation
• To provide a framework for the easy configuration
  and transformation of different formats of files
  or messages
• Different applications support different formats.
  
• Information needs to represented in different
  formats in different situation.

30
Transformer 2a

• Features - 1
• The Functional Element MUST provide the ability
  for the management of supported file formats
  schema or file types
• The Functional Element MUST provide the ability
  for users to manage transformation handlers that
  are used for the transformation and linked these
  handlers to the supported formats
• The Functional Element MUST support both API and
  web service types of transformation handlers
• The Functional Element MUST provide a mechanism
  to enable the definition and management of
  transformation handlers in a transformation
  chain.
• The Functional Element MUST provide the ability
  for inputs and transformed results to be
  specified either as either files or messages

31
Transformer 2b

• Features - 2
• The Functional Element MAY provide the ability to
  select transformation handlers if more than 1
  handlers are available.
• The Functional Element MAY provide the ability to
  collect statistical information for each
  transformation job performed
• To define/identify what kind of statistical
  analysis/info to provide
• The Functional Element MAY provide the ability to
  define and customise transformation rules to be
  used
• The Functional Element MAY provide the ability to
  automatically use different transformation
  handlers in order to ensure that a particular
  handler is not overloaded.

32
Transformer - 3

• Interdependencies
• None
• Technologies and Standards
• None

33
Security

• Key Management
• Policy Management
• Policy Enforcement

34
Key Management - 1

• Motivation
• Enable a easy to use framework for PKI and XKMS
  usage
• As clients to Certificate Authories (CAs)

35
Key Management 2

• Features
• The Functional Element MUST provide the
  capability to register a key or a key pair with
  an XKMS-compliant service.
• The Functional Element MUST provide the
  capability to revoke a registered key or key pair
  with an XKMS-compliant service.
• The Functional Element MUST provide the
  capability to recover a registered key or key
  pair with an XKMS-compliant service.
• The Functional Element MUST provide the
  capability to retrieve a public key registered
  with an XKMS-compliant service. The public key
  can in turn be used to encrypt a document or
  verify a digital signature.
• The Functional Element MUST provide the
  capability to ensure that a public key registered
  with an XKMS-compliant service is valid and has
  not expired or been revoked.
• The Functional Element MAY provide the capability
  to generate key pair.

36
Key Management - 3

• Interdependencies
• Secure SOAP Management
• Identity Management
• Technologies and Standards
• Public Key Infrastructure (PKI)
• XML-Signature Syntax and Processing, W3C
  Recommendation 12th Feb 2002
• XML-Encryption Syntax and Processing, W3C
  Recommendation 10th Dec 2002
• XML Key Management Specification (XKMS)

37
Policy Management - 1

• Motivation
• Enable the capability for providing security
  policy management that includes
• Definition and management of security policies
• Providing consolidated view(s) of security
  policies across applications
• Ability to adapt/configure security policies

38
Policy Management 2

• Features
• The Functional Element MUST provide the
  capability to define and manage Policy
  Categories.
• to add information about Policy Category
  structure
• The Functional Element MUST provide the
  capability to define and manage Policies.
• to add information about Policy structure
• The Functional Element MUST provide version
  control capability to defined Polices.
• The Functional Element MUST provide the ability
  to manage Policies within a Policy Category
  including insertion, update, retrieval and
  removal of attached Policies.
• The Functional Element MUST provide the ability
  to retrieve Polices that are attached to a Policy
  Category.
• The Functional Element MAY provide multi-lingual
  support for defined Policies.

39
Policy Management - 3

• Interdependencies
• Policy Enforcement?
• User Management?
• Role Access Management?
• Technologies and Standards
• XACML???

40
Policy Enforcement - 1

• Motivation
• Enable the capability for enforcing security
  policies
• Based on defined Policies
• Ability to identify Policies for enforcement and
  attachment of Policies to known Services/users

41
Policy Enforcement 2

• Features
• The Functional Element MUST provide the ability
  to identify Policy Categories and/or Policies
  that are to be enforced.
• The Functional Element MUST provide the ability
  to access enforced Policies for
  accepting/rejecting of policies
• The Functional Element MUST provide the ability
  to associate a policy to a service
• The Functional Element MUST provide the
  capability to associate a policy to its services
  access privileges through a pre-identified Access
  structure
• to explain access structure
• The Functional Element MUST provide a mechanism
  to enforce policy upon acceptance of the policy
• The Functional Element MUST provide the ability
  to enforce policies either based on individual
  and groups of services

42
Policy Enforcement - 3

• Interdependencies
• Policy Enforcement
• User Management
• Role Access Management
• Technologies and Standards
• XACML