[OPTIONAL, one]

Technical Definition:

How and when the Service Genre should (or should not) be used.

Commentary:

An explanation of how the Service Genre should be used that also points out the situations in which it should not be used.

[OPTIONAL, many]

Technical Definition:

A list of candidate domain and technical standards (standards, specifications, application profiles) that might be developed into Service Expressions when implementing the functionality of the Service Genre (behaviours, data models). Provide names and versions.

Commentary:

A list of the names and versions of all the domain and technical standards, specifications and application profiles needed to develop Service Expressions that when implemented will provide the functionality of the Service Genre. The list should not include standards only used for the derived implementations.

Note: List only those standards needed to provide the behaviour and functionality; technical standards used to implement the Service Expressions derived from the Service Genre are excluded.

[RECOMMENDED, many]

Technical Definition:

An overview of the behaviours exposed by the Service Genre, i.e., what the functionality is that can be used by applications or service implementations. Each behaviour or request should include sufficient technical information to specialise the Service Genre to one or more Service Expressions. The information may include:

• a name for the behaviour or request
• the classifications (e.g., transactional)
• form and format of the message or request (including data models, document descriptions)
• responses (normal and abnormal)
• pre-conditions
• post-conditions
• side effects and state changes (including algorithms)
• a description of the functionality and operations provided

Commentary:

A summary of the functions that can be used by applications or implementations. The information for specialising the Service Genre into one or more Service Expressions may include: name of the behaviour or request; classification; function and operation provided; format of message or request; normal and abnormal responses; pre- and post-conditions; algorithms, changes in state and side effects.

[REQUIRED, many]

Technical Definition:

Categorisation of the Service Genre using the e-Framework service classification scheme. Select the classifications that are most appropriate and useful in service genre discovery and cataloguing. Service Genres with similar characteristics SHOULD have similar classifications.

Commentary:

Choices are provided for each classifier listed in the e-Framework Service Genre CLASSIFICATION Scheme. Similar service Genre should have similar classifications for cataloguing and discovery purposes. The e-Framework may add to or revise the classifier choices.

[REQUIRED, one]

Technical Definition:

A brief, informal narrative explanation of the Service Genre. What problem does it address or solve?
What does it do (business problem or processes)?
What are its purpose, rationale and intent?
What are the context and conditions of use?
Where does it fit within the overall ICT computing fabric?
The goal is to describe the service genre so that others will be able to gain a basic understanding without further exploration.

Commentary:

A narrative that explains in plain language the basic purpose and capabilities of the Service Genre. It should not be written for programmers. The DESCRIPTION should minimally cover the process or problem the Service Genre addresses and how it does it, the rationale, and any limitations on use of the Service Genre.

Note: this is not a technical description. The target audience is not programmers or developers.

[OPTIONAL, many]

Technical Definition:

Factoring considerations, design decisions, design choices, alternative considerations, tradeoffs. High level information on the implications of the choices on key factors, e.g., implementation, performance, reuse, extensibility, portability, security, data privacy, etc.

Commentary:

A description of the decisions involved in creating the Service Genre and explanations of the rationale behind the choices. All Aspects of Service Design guidelines [URL] should be considered for inclusion in the discussion. Also:

• include "why", not just "what" choices were made
• these are decisions that influence the overall design of the Service Genre. It does not include design decisions that only affect the internal structure and organisation of the Service Genre.

[REQUIRED, many]

Technical Definition:

The capabilities provided by the Service Genre. An (abstract) description of "what" the Service Genre does independent of describing "how" to interact with the < xxx > or how the < xxx > implements the capability. Each function is described independently.

Commentary:

A list of all the capabilities of the Service Genre, including types of applications or implementations that can be based on it. This list is not the same as the Requests & Behaviours; FUNCTIONALITY may require multiple requests while a request may provide different, unrelated functions.

This is not a technical description, but it should be more precise than the description. The functionality augments the information in the behaviours and requests. Behaviours and requests may be mapped to operations and messages. The functionality provided by the < xxx > may require multiple interactions with the < xxx >. The mapping between the functionality and the behaviours and requests is many-to-many.

[OPTIONAL, one]

Technical Definition:

Potential high level issues in implementing a service implementation or in using a service implementation designed from a service expression specialised from the Service Genre. Are there high level assumptions about design, middleware, data structures, behaviours, etc., that are not described elsewhere? Are there any implementation- or deployment-specific considerations (e.g., technology dependencies)?

Commentary:

The IMPLEMENTATION GUIDE is a discussion of high-level issues that may affect the development or use of implementations based on the Service Genre, including any assumptions about the design or technology DEPENDENCIES. Whenever possible, implementation decisions and choices should be deferred to the service implementation design.

[OPTIONAL, many]

Technical Definition:

Narrative about the Service Usage Models and Core SUMs that use the Service Genre. As appropriate, indicate how or why the Service Genre is used. Identify any special cases or considerations in using the Service Genre.

Commentary:

A description of the KNOWN USES of this Service Genre by any Service Usage Models and Core SUMs that tells how the Service Genre is used and its status: implemented, deployed, proposed, etc.

Note: the e-Framework SHOULD document actual uses (implemented, deployed), not potential or new proposed uses. If necessary, uses may be classified, e.g., implemented, deployed, proposed, etc.

[REQUIRED, one]

Technical Definition:

A simple, meaningful, concise, descriptive label for the Service Genre. The name is critical in letting others understand and discover the Service Genre.

Commentary:

A simple and informative NAME for the Service Genre that helps people understand what the service does. The NAME should also facilitate discovery of the Service Genre. (Software developers do not have to use this name when implementing a service that is based on this Service Genre.)

Note: The software developer need not use this name to identify the service implementation.

[OPTIONAL, many]

Technical Definition:

A list of CORE SUMs (CORE SUM Names) that use this Service Genre. CORE SUM relationships are useful in understanding how the Service Genre is used in designing applications that use the CORE SUM. Relationship to a specific version of a CORE SUM SHOULD be indicated.

Commentary:

A list of the CORE SUMs (names and specific versions) that use this Service Genre.

[OPTIONAL, many]

Technical Definition:

A list of Service Usage Models (SUM Names) that use this Service Genre. Service Usage Model relationships are useful in understanding how the Service Genre is used in designing applications that use the service usage model. Relationship to a specific version of a Service Usage Model SHOULD be indicated.

Commentary:

A list of the Service Usage Models (names and specific versions) that use this Service Genre.

[OPTIONAL, one]

Technical Definition:

The conceptual structure and operations of the Service Genre. Service Genres access data or manipulate state. They are often transactional. The structure describes the data, state and interactions within the service genre and their relationships. Include an illustration of the relationships of the elements and the data flows. The information about structure SHOULD NOT be needed or need to be exposed to use or understand the service genre or its use. The information provides critical details needed to specialise the service genre and to develop service expressions. The structure information should not include design choices.

Commentary:

A conceptual illustration of the elements and data flows within the Service Genre that elucidates the interactions between the data and state to help specialise the Service Genre and develop Service Expressions.

[OPTIONAL, many]

Technical Definition:

Brief, informal explanations of how the Service Genre is used. An illustration of the service genre within a workflow or overall set of business processes SHOULD be included.

Commentary:

Illustrations of how this Service Genre is used in a workflow, or where it fits in a set of business processes.

[RECOMMENDED, one]

Technical Definition:

How the behaviours, requests and the Service Genre are combined to provide the functionality. What are the constraints in sequencing behaviours and requests (both of this Service Genre itself and the interactions of this Service Genre with others)? How do they interact? What are the use patterns? The pre- and post-conditions and specification of side effects and state changes are sufficient to deduce this information for a single Service Genre; this separate description combines the disparate and disconnected behaviours into a more comprehensive presentation needed to understand how to use the Service Genre either alone, or in combination with other Service Genres. This is a precise technical description; it details conforming and non-conforming interactions that span multiple requests.

Commentary:

A precise, technical explanation of how the Requests & Behaviours combine to produce the desired functions, including any constraints on the sequencing of Requests and Behaviours that govern how the Service Genre can be used either by itself or in combination with other Service Genres.

[REQUIRED, one]

Technical Definition:

Service Genre descriptions SHOULD be versioned, i.e., each revision of the Service Genre or the Service Genre description should have a new version label. It is critical to differentiate between versions of the Service Genre (technical changes, changes in capabilities) and versions of the description (editorial, descriptive changes).

Commentary:

VERSION information keeps track of editorial changes to the Service Genre Description; the version of the descriptive document may be different from the version information that reflects technical revisions or altered capabilities in the Service Genre itself.

Examples: v1.1, Version 2.0