GENERAL GUIDANCE


I.                       What is the scope of a Statistical Service (Nature of a Service), including the GSBPM element?

 1.         A Statistical Service will perform one or more tasks in the statistical process. Statistical Services will be at different levels of granularity. An atomic or fine grained Statistical Service encapsulates a small piece of functionality.  An atomic service may, for example, support the application of a particular methodological option or a methodological step within a GSBPM sub process. Coarse grained or aggregate Statistical Services will encapsulate a larger piece of functionality, for example, a whole GSBPM sub process. These may be composed of a number of atomic services.  The granularity of Statistical Services should be based on a balanced consideration between the efficiency of the Statistical Service and the flexibility required for sharing purposes - larger Statistical Services will usually enable greater efficiency, whereas a finer granularity will allow greater flexibility for supporting sharing and reuse. Services, regardless of their granularity, must meet the architectural requirements and be aligned with CSPA principles.

2.         CSPA outlines that the structure of a service should align to GSBPM sub processes and that CSPA-services can cover a broader type of services with multiple “capabilities” and therefore multiple sets of related inputs and outputs.  Further development of services will show if the current architecture and templates for services need adjustments before providing good support for statistical services that are larger in scope.

"The Statistical Service Definition is at a conceptual level. In this document, the capabilities of a Statistical Service are described in terms of the GSBPM sub process that it relates to, the business function that it performs and GSIM information objects which are the inputs and outputs" CSPA

Guidance

3.         The GSBPM element in the Service Definition should be used to convey the context of the GSBPM the author believes this service is targeting/addressing.  This is not intended to be a restrictive statement; it should not be interpreted as a limiting of the services possible use.  However IF the service could increase the risk of information disclosure or decrease information accuracy for example; under such circumstances these scenarios should be listed to inform the user.

4.         Note that CSPA will refer to GSBPM for context in order to improve understanding and allow greater alignment.  However CSPA is not modelled directly within the scope of GSBPM steps and sub-steps and as such some services will operate with a larger scope than a single GSBPM step; and some services will operate in multiple GSBPM sub-steps.

Examples

II.                    What is the relationship between GSBPM, and the CSPA Service Definition, Service Specification and Service Implementation Description?

Guidance

5.         Below is a layered model for the documentation and traceability of a CSPA Service.

The lower numbered layers (presented at the top) describe more conceptual aspects of the service and each layer becomes more concrete moving down the diagram (toward higher numbered layers)

6.         The top layer describes the broad business function in GSBPM terms. The second layer describes the functional aspects of the services for this business function. The third layer describes the methodological aspects of the services and the fourth layer describes the implementational aspects of the (methods implemented in the) services

7.         There are also cross-cutting definitions of non-functional aspects that can be applied at each layer.

8.         It is also possible that a service will support multiple processes or sub-processes of the GSBPM, in such cases the definition will reference each process or sub process.  Where more than one GSBPM process or sub-process is referenced it is recommended that the primary GSBPM process or sub-process is bolded in the Service Definition.  It means that the documentation starts to resemble more of a graph than a static single focus document.  Hence thought will need to be spent on the appropriate format, be it conventional with hyperlinks, a web based Wiki style or an alternative content managed representation.

9.         The intention is where multiple services are targeting the same area and have similar characteristics, users should be able to easily identify this.

10.       Effectively from a user’s perspective, all available Statistical Services should be exposed via a catalogue and with extra drills up and down to allow greater understanding and ultimately selection.

11.       Functional areas could be categorized broadly aligning with the types of data-centric activities that are performed for example:

  • Orchestration
  • Storage
  • Manipulation
  • Search & Discovery
  • Logging & Audit
  • Visualization
  • Access

12.       It is recommended that extra work be completed to ascertain the architectural styles in existence and then propose further perspectives to greater explain and contrast service granularities.

III.                Where do I include the Non Functional Requirements?

Guidance

13.       Please include non functional requirements in the Service Specification Template

IV.                 Where can I find examples of completed templates

Guidance

14.       Please refer to the listing of CSPA services on the CSPA wiki: http://www1.unece.org/stat/platform/display/CSPA/Implementing+CSPA+Projects

V.                     Where do I go if I need additional help?

Guidance

15.       Please post an issue or question to the CSPA Implementation Group via the CSPA Discussion Forum on the UNECE wiki http://www1.unece.org/stat/platform/display/CSPA/CSPA+Discussion+Forum


SERVICE DEFINITION TEMPLATE

VI.                 GSIM Inputs and Outputs

Guidance

16.       When creating a Service Definition it is important to ensure that the use of input and output objects are clearly explained and justified.  The documentation should annotate each input and/or output with the following details:

  • Why that object has been chosen.
  • What the service is (conceptually) intended to do with the object
  • Whether that object carries or relays any potential context to steps of the process beyond this specific service. This helps with the lineage of information integration across processes; the implementer can then understand that such context is available if needed.

17.       It is advised that for increased understanding and to increase multiple possible implementations, objects in the GSIM Concepts group are favoured over more specific objects in more technical groups.

SERVICE IMPLEMENTATION TEMPLATE

VII.              Is local invocation of statistical services supported?

Guidance

18.       The preference is for remote invocation

VIII.          Are there any defined common message parameters?

Guidance

19.       It is recognized that within each implementing organization the role of process orchestration will exist in some form; be it an orchestration product or the configuration and coupling of services and components as integrated.

20.       It is assumed that standard patterns will be followed when creating services, as such it is assumed that identifiers will be implemented within services to support orchestration needs such as tracking, logging/audit and correlation for result re-integration.

21.       Generally services should allow the initiating component (requester) to provide, as input, an externally generated ID if required.  This ID should be included in the response for any request; if the initial request results in multiple responses, this ID should be passed back as a correlation ID to the requester or onward to the next component.  Where possible services should provide as much context as possible to facilitate the requester making efficient processing decisions about the result of the request.

22.       Services should assume that they are running within a larger logical orchestration environment and as such support the needs of that orchestration role.

23.       It is expected that specific implementation examples and patterns will be provided to further define these needs; currently this category of inputs and outputs to support orchestration fall beyond the logical business activity and as such may be more explicitly grouped as such at a later stage.

IX.                 Should I encapsulate service orchestration (queuing and scheduling) within the statistical service?

Guidance

24.       It is important that there is separation of logic between the service and the calling environment (like an orchestration engine).  Please refer to VI. Technology Architecture.

X.                 What do Service Builders and Service Assemblers need to understand about handling data transferred to/from the statistical service?

Guidance

25.       Ensure descriptions are clear on how each service handles data and the associated clean-up, exactly what it does (which should be minimal) and what requirements are put on the local environment (orchestration).

26.       Ensure the statistical service receives, as part of its input, the location where it can deliver output data.


  • No labels