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. 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 List of Potential FEs Identified

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 capabilityto 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 service’s 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