[OPTIONAL, one]

Technical Definition:

How and when the service expression should (or should not) be used.

Commentary:

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

[REQUIRED, many]

Technical Definition:

A list of domain and technical standards (standards, specifications, application profiles) used in implementing the functionality of the service expression. Provide names and versions. Indicate conformance requirements or exclusions. List only those standards needed to provide the behaviour and functionality; technical standards used in service implementation derived from the service expression are excluded. (The list may be empty because a service might not have any applicable standards.)

Commentary:

A list of the names and versions of all the domain and technical standards, specifications and application profiles needed to provide the functionality of the Service Expression. The list should not include standards only used for the derived implementations.

[REQUIRED, many]

Technical Definition:

A list of all behaviours exposed by the service expression, i.e., all functionality that can be used by applications or service implementations. Each behaviour or request specification SHALL include sufficient technical information to develop a design for a service implementation that implements the service expression, describing what the behaviour does and how it manipulates state. The information SHALL include:

• a name for the behaviour or request
• the classification (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)
• post-conditions
• functionality and operations provided

Commentary:

Detailed technical information about the functions and operations of the Service Expression, including what the behaviours do and how they change state. These are the critical items for designing an implementation of the service expression: 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 expression using the e-Framework service classification scheme. Select the classifications that are most appropriate and useful in service expression discovery and cataloguing. Service expressions with similar characteristics SHOULD have similar classifications.

Commentary:

Choices are provided for each classifier listed in the e-Framework Service Expression CLASSIFICATION Scheme. Similar Service Expressions 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 expression.
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 expression 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 Expression’s behaviours. It should not be written for programmers. The DESCRIPTION should minimally cover the process or problem the service expression addresses and how it does it, the rationale, and any limitations on use of the Service Expression.

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

[OPTIONAL, many]

Technical Definition:

Design decisions, design choices, alternative considerations, tradeoffs, etc., present in the service expression. What are the implications of the choices on key factors, e.g.,implementation, performance,reuse, extensibility, portability, security, data privacy, etc., including "why", not just what choices were made. All of the aspects listed in the Aspects of Service Design [URL] SHALL be considered for inclusion. These are decisions that influence the overall design of the service expression and what is exposed to users of the service expression. It does not include design decisions that only affect the internal structure, organisation or operations of the service expression.

Commentary:

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

[REQUIRED, many]

Technical Definition:

The capabilities provided by the Service Expression. An (abstract) description of *what* the Service Expression 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 Expression, 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.

Note: 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.

[RECOMMENDED, one]

Technical Definition:

A list of the potential issues in developing a service implementation or in using a service implementation designed from a service expression. Are there 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 issues that may affect the development or use of implementations based on the Service Expression, including any assumptions about the design or technology DEPENDENCIES. Whenever possible, implementation decisions and choices should be deferred to the service implementation design.

[RECOMMENDED, one]

Technical Definition:

A formal definition of the interfaces to the service expression: WSDL, document XSDs, vocabularies, etc. Components may be included by reference. There SHALL be only one set of interface definitions; alternative interface definitions SHALL correspond to alternative service expressions. (The restriction of one set of interface definitions per service expression is an intentional design choice for the e-Framework.) The service expression interface definition is a machine-processible representation that is REQUIRED to develop a service implementation that corresponds to the service expression.

Commentary:

Formal representation of the interfaces to the Service Expression in a machine-processible format. The INTERFACE DEFINITION is essential for creating an implementation of the Service Expression.

[OPTIONAL, many]

Technical Definition:

A narrative about the service usage models or Core SUMs that use the service expression. As appropriate, indicate how or why the service expression is used. Identify any special cases or considerations in using the service expression. The e-Framework SHOULD document actual uses (implemented, deployed), not potential or proposed uses. If necessary, uses may be classified as implemented, deployed, proposed, etc.

Commentary:

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

[REQUIRED, one]

Technical Definition:

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

Commentary:

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

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 Expression. Core SUMs relationships are useful in understanding how the service expression is used in designing applications that use the Core SUMs. Relationships 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 Expression.

[OPTIONAL, many]

Technical Definition:

A list of Service Expressions (Service Expression Names) related to this Service Expression. Related Service Expressions should include those that provide the same behaviours and requests but have a different interface definition. Relationships to a specific version of a Service Expression should be indicated.

Commentary:

A list of the Service Expression Description Names of all Service Expressions that provide the same requests and behaviours but have a different interface.

[OPTIONAL, many]

Technical Definition:

A list of Service Usage Models (SUM Names) that use this Service Expression. Service Usage Model relationships are useful in understanding how the service expression is used in designing applications that use the Service Usage Model. Relationships 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 Expression.

[RECOMMENDED, many]

Technical Definition:

A list of other Service Expressions (Service Expression Description Names) that this Service Expression is dependent upon. Dependencies are useful in understanding how Service Expressions relate.
Dependencies are requirements indicating the other Service Expression(s) that must be available to implement applications that use this Service Expression. Dependencies on a specific version of a Service Expression SHOULD be indicated.

Commentary:

A list of the Service Expression Description Names of all other Service Expressions that must be available in order to use this Service Expression.

[REQUIRED, one]

Technical Definition:

The Service Genre (Service Genre Name) that has been specialised to yield this Service Expression.

Commentary:

The name of the SERVICE GENRE from which the Service Expression was derived. Service Genres currently registered in the e-Framework are listed at Service Genre Registry.

[OPTIONAL, one]

Technical Definition:

The conceptual internal structure and operations of the service expression. Service expressions access data or resources, or they manipulate state. They are often transactional. The structure describes the data, state and interactions within the service expression (e.g., objects, classes, messages [in the object-oriented sense]) 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 expression or its use. While Description provides critical details needed to consistently design service implementations, the structure information should not include design choices.

Commentary:

A conceptual illustration of the elements and data flows within the Service Expression that elucidates the interactions between the data and state to help implementation designers more readily grasp the complex relationships.

[OPTIONAL, many]

Technical Definition:

Brief informal descriptions of how the Service Expression is used. An illustration of the Service Expression within a workflow or overall set of business processes SHOULD be included.

Commentary:

An illustration of how this Service Expression is used in a workflow, or where it fits in a set of business processes.

[REQUIRED, one]

Technical Definition:

How the behaviours, requests, algorithms, resources, state representations, etc., are combined to provide the functionality. What are the constraints in sequencing behaviours and requests (both of this Service Expression itself and the interactions of this Service Expression with other service expression)? 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 Expression; this separate entry combines the disparate and disconnected behaviours into a more comprehensive presentation needed to understand how to use the Service Expression either alone, or in combination with other Service Expressions.

Note: 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 Expression can be used either by itself or in combination with other Service Expressions.

[REQUIRED, one]

Technical Definition:

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

Commentary:

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

Examples: v1.1, Version 2.0