e-Framework Definitions and Terminology
Introduction
This document presents proposed terms with their definitions, and processes for describing and documenting the
technical elements of the e-Framework. It focuses on the definitions and descriptions of reference models and
“services”, i.e., service genres, service expressions and service patterns. Document content includes:
 An overall presentation of the elements of the e-Framework using the presented terminology (a
metamodel), including an outline of how to develop the technical elements of the e-Framework (reference
models, service genres, service expressions) and how to design, implement and deploy applications and
systems that are built using the e-Framework.
 A proposed (normative) format for a narrative (non normative) description of a service genre.
 A proposed (normative) format for a narrative (non normative) description of a service expression.
 A proposed (normative) format for a narrative (non normative) description of a service pattern.
 A proposed (normative) format for a narrative (non normative) description of a reference model.
 Guidelines for designing and factoring service genres, service expressions, and service implementations.
 A collection of (normative) principles, practices and constraints applicable to the design of service genres,
and service expressions and to the development of service implementations and applications.
 A set of concise definitions of terms.
 A simplified semantic model of the e-Framework in a graphical representation.
 A collection of issues.
 An annotated bibliography.
NB: this document is not intended to be publicly released as a single entity. Planned derivative works corresponding to most
of the elements above will be developed and released through the e-Framework web site. These derivative works will
incorporate additional contextual content and will be living documents, updated as the e-Framework evolves.
NB: because of ambiguity, the word “service” is avoided throughout. “Service” is used as an adjective as in service genre,
service expression, service pattern, service implementation, etc. When used without an adjective and otherwise unqualified,
“service” implies a concept encompassing all of the qualified and unqualified terms used.
A collection of explanatory notes are distributed throughout the document tagged NB. Recommendations to the
stakeholders are presented as notes tagged REC.
The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED,
MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].
NB: need to review this document for consistency in applicability and use of these words.
Stakeholders and Audience
Stakeholders:
e-Framework Operations Group, the e-Framework Development and Maintenance Group, and the JISC
e-Framework Working Group.
Audience:
Listed stakeholders as written. Planned derivative works include materials to appear on the e-Framework web
site.
NB: this document SHOULD NOT be released as a whole.
REC: develop a glossary for the web site.
REC: derive individual documents (e.g., describing reference models, describing service genres and service expressions,
service factoring, semantic model, etc.), and post as individual entries on the web site.
A Metamodel for the e-Framework: Fitting the Pieces Together
The metamodel presents the overall e-Framework in terms of it elements (reference models, service genres, service
expressions, service patterns), the overall process used to build the elements of the e-Framework, and an explanation
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
1
of how the e-Framework is translated into the design and development of service implementations, service toolkits
and applications.
NB: this presentation is incomplete. It contains only a basic explanation of the metamodel. Additional illustrations and more
explanations are needed before this material is presented to the public.
NB: the core elements of service genre, service expression, service implementation, service instance are inspired by the
elements of the FRBR [FRBR] model: work, expression, manifestation, copy.
REC: develop a more comprehensive presentation of the overall metamodel, including contextual examples. Create
additional illustrations, including showing how the various service elements fit into the metamodel and the process of
developing applications from services, etc.
e-Framework Technical Description
The basic schematic view of the e-Framework is illustrated below [e-Framework Overview]. This diagram does not
illustrate all of the technical elements of the e-Framework. A more comprehensive narrative that outlines the
relationships between the pieces of the model (including their multiplicities) follows. A more formal semantic
model of the e-Framework is presented separately.
REC: review the use of “service” in the diagram.
The technical description of the e-Framework focuses on the overall design and description of the service-oriented
approach and elements of the e-Framework, not e-Framework governance or policies. The collection of element
descriptions are then used to document, build, deploy and operate service implementations that in turn support tools,
systems and applications for the provisioning of SERVICES or capabilities to the user community within the specific
domains of the e-Framework.
NB: the formatted term SERVICES above has a very specific meaning, i.e., a general operational capability (e.g., a JISC
production service), not an element (e.g., service genre, service expression) of the e-Framework.
NB: the presentation is informal; formal multi-value dependency statements could be developed. Dependency statements
must be clearly specified to understand the “many” versus the “one” side of the relationships.
NB: the presentation does not detail the elements to the same level as the web services ontology [WS OWL].

e-framework:
o a service-oriented approach to the planning, management, design, development and deployment of
applications and systems
o covers a limited, enumerated set of domains:
 e-learning, e-research, e-libraries, e-administration, etc.
REC: for consistency in other documents, develop a precise list of domains.
o
enables the development and deployment of applications:
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
2


o
o
o

each application may span one or more domains
the nature of each application, its design, deployment, etc., are not specified within the
e-Framework
consists of a collection of core elements (has many of each):
 reference models
 service patterns
 service genres
 service expressions
enables the development of additional elements, included in the e-Framework by reference (has
many of each):
 service implementations
 service toolkits
has non technical elements:
 governance, policies, community, etc.
reference model:
o a service-oriented description of a collection of processes and workflows supporting at least one
application
o documented by a reference model description
o may cover one or more domains
o may be related to one or more other reference models
o may be incorporated into other reference models
o may overlap with the domains of one or more other reference models
o is defined in terms of service genres XOR service expressions
NB: XOR is “exclusive or”. A single reference model is defined either exclusively in terms of service genres
or exclusively in terms of service expressions, but never a mix of both.
o
o
o
o
may be defined in terms of one or more service patterns
may be supported by one or more service toolkits
references one or more open standards
a core element of the e-Framework

service pattern:
o a reusable service-oriented design for a narrowly-scoped technical or business process
o documented by a service pattern description
o may be used in multiple reference models
o may be related to one or more other service patterns
o may overlap with other service patterns
o is defined in terms of (composed from) one or more service genres XOR service expressions and
their relationships
o a core element of the e-Framework

service genre:
o a generic or abstract capability to provide a set of related behaviours in support of a process
o documented by a service genre description
o may be used in multiple reference models
o may be used in multiple service patterns
o may be used in multiple applications
o may be related to other service genres
o may be dependent upon other service genres
o should not overlap in functionality with other service genres
o is realised via a service expression through a service expression description
 many possible independent service expression
o a core element of the e-Framework
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
3

service expression:
o a specific set of related behaviours in support of a process that can be implemented with a defined
set of technologies, interfaces and open standards
o a specialisation of a single service genre
o documented by a service expression description
o defined by a service expression definition
 behaviours and operations
 interfaces
o may be used in multiple reference models
o may be used in multiple service patterns
o may be used in multiple applications
o may be related to other service expressions
o may be dependent upon other service expressions
o should not overlap in functionality with other service expressions
o is implemented via a service implementation through a design
 many possible equivalent, independent designs
o a core element of the e-Framework

service toolkit:
o a reusable collection of service implementations
o is not deployed
o may be distributed with auxiliary software (sample applications, sample data)
o may not correspond to a service pattern
o may not correspond to a service genre
o may be used with multiple reference models
o may be used in multiple applications
o should not overlap in purpose with other service toolkits
o may use service implementations used in other service toolkits
o may be included in the e-Framework by reference

service implementation:
o operational code providing the complete functionality specified in a service expression definition
o not unique
o is not deployed
o may be used in multiple applications (i.e., a common service)
o instantiated and deployed through a service instance
o may be instantiated or deployed one or more times
o derived from a design
 based on a service expression description
 defined by the service expression definition
 many equivalent, independent service implementations
o may be included in the e-Framework by reference

service instance:
o a deployed, operational service instance
o functionally identical to all other service instances for the service implementation
o operates under a set of policy rules
o may be managed
o not documented in the e-Framework

application:
o an ICT system that provides end-user functionality
o built from a collection of deployed service implementations (service instances) and other
components
o follows zero or more reference models
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
4
o
o
o
o
may follow a specific application design
may be instantiated and deployed one or more times
each instance operates under a set of policy rules
not documented in the e-Framework
The problem space that the e-Framework encompasses is covered by a set of overlapping reference models, some of
which may lie partially outside of the problem space. The reference models are defined from a set of service genres
and service expressions. If the service genres and their corresponding service expressions are properly factored,
they should not overlap. Structured collections (including compositions) of service genres and service expressions
used within many different reference models are identified as service patterns.
Users interact with applications, built from service implementations, following reference models. Applications may
be deployed multiple times within an overall ICT computing fabric, and are governed and managed by identified
policies.
e-Framework Technical Development Processes
The basic schematic view of the e-Framework technical development process is illustrated in the figure, inspired by
[SOA RM]. A narrative that presents the process elements and their relationships follows. Additional actions not
present in the diagram are included in the narrative.
NB: the technical development process explicitly excludes governance, policies, management or community participation.
NB: there are overlaps between the technical description and the development process. The technical description focuses on
descriptive statements. The development process focuses on actions.
NB: a formal methodology for developing the elements of the e-Framework is not presented.
NB: service implementations, service instances, service toolkits, and applications are not core elements e-Framework, and
thus are not listed below. These elements are used when applying the e-Framework to build and deploy systems and ICT
applications.

e-Framework is:
o defined in terms of:
 reference models, service patterns, service genres, service expressions
o may include by reference:
 service toolkits
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
5
o
 service instances
described in a collection of documents:
 methodology, definitions, descriptions, planning, service factoring, implementation
guidance, and service implementation and application design and

reference model is:
o derived from:
 user requirements, processes, data objects, workflows, standards
o expressed in terms of:
 service genres, service expressions, service patterns, other reference models
 standards, application profiles
o used to identify:
 new service genres, service expressions
o used to design:
 applications
 service toolkits
o documented:

following e-Framework standards and practices
o maintained and published through:

the e-Framework

service pattern is:
o identified through abstraction from:
 service genres XOR service expressions used in reference models
o used to refactor:
 service genres XOR service expressions
o used to design:
 reference models
 applications
 service toolkits
o documented:
 following e-Framework standards and practices
o classified using:
 service classifications
o maintained and published through:
 the e-Framework

service genre is:
o derived from:
 reference models
o refactored from:
 existing service genres
 existing service patterns
o used to design:
 reference models
 service expressions
 applications
 service patterns
o documented:
 following e-Framework standards and practices
o classified using:
 service classifications
o maintained and published through:
 the e-Framework
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
6

service expression is:
o derived from:
 service genres
o refactored from:
 existing service expressions
 service patterns
o used to design:
 service implementations
 applications
 reference models
 service toolkits
o documented:
 following e-Framework standards and practices
o classified using:
 service classifications
o maintained and published through:
 the e-Framework
Reference models are intentionally created de novo from requirements or identified from existing external sources.
Service genres are intentionally designed de novo, identified as existing service genres or refactored from existing
service genres. Service expressions are intentionally designed de novo, identified as existing service expressions or
refactored from existing service expressions.
Service patterns are identified from the use and structure of collections of service genres XOR service expressions
within reference models and applications, and are abstracted and generalised from these reference models and
applications; they are not created de novo outside of existing examples. They are based on multiple, independent
uses of a set of service genres XOR service expressions.
All elements of the e-Framework are developed iteratively with refinements made from actual use and community
feedback. Multiple deployments and applications are encouraged to provide broad feedback.
e-Framework Application Design, Implementation and Deployment
Processes
Developing the e-Framework results in a set of documents that describe the process and methodology used in its
development. It also includes (normative) documents that are the technical descriptions of the collection of
reference models, service patterns, service genres and service expressions that comprise the e-Framework. These
descriptions, guided by the design, implementation and deployment processes and methods, are used to design,
implement, deploy and operate applications. A schematic of this development and deployment process is presented
below, followed by a narrative presentation of the process used to create service implementations and service
toolkits, and to deploy service instances and applications following the e-Framework’s service-oriented approach.
NB: need a parallel version of the figure illustrating just services. Layers would illustrate where services and service patterns
are used, e.g., service genres in reference models, service expressions in application designs, service implementations and
service toolkits in application implementations, and service instances in deployed application instances. Additional
illustrations may be needed.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
7

service implementation is:
o designed from:
 a service expression description and service expression definition
o implemented from:
 the service implementation design
o available for:

deployment

service instance is:
o a deployment of:
 a service implementation
o bound to:
 a network end point
 a collection of resources
o deployed within:
 managed environments:
 as part of an application
 under operational policies
o uniquely identified in each deployment

(ICT) application is:
o designed from:
 an application design
 multiple reference models
 multiple service patterns
o implemented using:
 the application design
 service implementations
 service toolkits
o deployed:
 one or more times
 in one or more operational environments
 under governance rules per environment
 using physical entities (computational, storage, network)
o bound to:
 a network end point
 a collection of resources
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
8

service toolkit is:
o designed from:
 a collection of service expression descriptions and service expression definitions
o implemented from:
 the service implementation designs
 the service toolkit designs
o associated with:
 sample applications
 supporting materials (test cases, sample data)
o available for:

deployment
NB: the model does not permit a standalone service implementation. Service implementations are always integrated into an
application, even if the application is only the proxy for a single service implementation, or if the application is deployed
only once in the entire ICT computing fabric.
Neither the design and deployment of applications, systems and service toolkits, nor the use of service
implementations and service instances within these designs are defined within the e-Framework. The e-Framework
documents the elements of a service-based infrastructure for others to use to design, develop, deploy and operate
applications using a service-oriented approach. An application developer will identify one or more reference models
and one or more service expressions (and their service implementations) that are relevant to the domain. The
application developer is not constrained by the e-Framework in the selection of a particular approach to the design
(software architecture) of the application or system, i.e., the e-Framework is silent on issues such as using a
particular middleware approach (e.g., service bus, MOM). Multiple software designs may be developed for a
particular application; design choices and external requirements will influence specific characteristics of an
individual design.
NB: the discussion focuses on the design, development and deployment of applications. While the e-Framework does not
prescribe processes, it will include operational guidance and supporting documents. These are not considered in the above
technical discussion of using the metamodel to create applications.
A design of the application is then implemented as an operational system (software plus hardware). Once
implemented, the application may be deployed one or more times in one or more environments, e.g., a VLE
application may be deployed at different institutions. An application might have multiple deployed instances, e.g.,
an administrative application might have both a production and a backup system operational instance deployment.
The technical characteristics of the e-Framework do not dictate which applications have multiple deployments or
instances, or when a particular application is provided as single computational entity that can be utilised by all other
applications and institutions across the ICT computing fabric.
Describing and Documenting Service Genres
The e-Framework encompasses a collection of service genres that are used within reference models and service
patterns. These service genres are specialised into service expressions which in turn are used to design service
implementations. The resulting service implementations (and their service instances) are then combined into
applications and an overall ICT computing fabric.
Each service genre in the e-Framework SHALL be described and documented in a common format, presented below.
NB: the format is derived from the format used to describe design patterns [GoF].
NB: unless otherwise stated, all elements in the service genre description SHALL be presented in natural language.
NB: service genre descriptions themselves are not normative. The service genre description format is normative.
NB: there are no formal processes to define or document a service genre. The narrative presents the description format used
to document a service genre.
Service genre descriptions are created directly, either as new elements of the e-Framework or as refactorings of
existing structures. Service genre descriptions need not be based on existing service implementations, i.e., they are
not deduced from practice except through refactoring. A service genre described through a service genre description
is abstract, and needs to be realised through a service implementation.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
9
The e-Framework Service Genre Description Format
The (ordered) elements of the service genre description are:
NB: the ordering is subject to revision.
NB: the items are currently presented as a flat list. Items might be reorganised into a structured collection.
name: [REQUIRED, ONE]
a simple, meaningful, concise, descriptive name or label for the service genre. The name is critical in letting
others understand and discover the service genre.
NB: The software developer need not use this name to identify the deployed service implementation.
classification: [REQUIRED, MANY]
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.
REC: develop an appropriate service classification scheme for service genres.
descriptive metadata: [REQUIRED, ONE, COLLECTION]
core metadata for the service genre description, including author, date and version. 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.
NB: it is critical to differentiate between versions of the service genre (technical changes, changes in capabilities) and
versions of the description (editorial, descriptive changes).
REC: provide a recommended practice for labelling versions.
description: [REQUIRED, ONE]
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.
NB: this is not a technical description. The target audience is not programmers or developers.
use cases: [OPTIONAL, MANY]
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.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicability: [OPTIONAL, ONE]
how and when the service genre should (or should not) be used.
behaviours and requests: [RECOMMENDED, MANY]
an overview of the behaviours exposed by the service genre, i.e., all functionality 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 type (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 operation provided
REC: formalise the behaviour and request specification format.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
10
use and interactions: [RECOMMENDED, ONE]
how the behaviours, requests and the service genre are combined to provide 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)? What are the use patterns?
NB: the pre- and post-conditions and description 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 description needed to understand how to use the service genre either alone, or in combination with other
service genres.
NB: this is a precise technical description. It details conforming and non-conforming interactions that span multiple requests.
structure: [OPTIONAL, ONE]
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.
NB: 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.
NB: structure information should not include design choices.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicable standards: [RECOMMENDED, MANY]
a list of domain and technical standards (standards, specifications, application profiles) used in implementing the
functionality of the service genre (behaviours, data models). Provide names and versions. Indicate conformance
requirements or exclusions.
NB: list only those standards needed to provide the behaviour and functionality. Technical standards used to implement the
service implementation derived from the service genre are excluded.
design decisions and tradeoffs: [OPTIONAL, MANY]
design decisions, design choices, alternative considerations, tradeoffs. What are the implications of the choices
on key factors, e.g., implementation, performance, reuse, extensibility, portability, security, data privacy, ...
NB: include “why”, not just what choices were made.
NB: all of the aspects listed in the section titled Aspects of Service Design SHOULD be considered for inclusion.
NB: 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.
implementation guidance and dependencies: [RECOMMENDED, ONE]
potential issues in implementing a service implementation or in using a service implementation designed from a
service expression specialised from the service genre. Are there assumptions about design, middleware, data
structures, behaviours, etc., that are not described elsewhere? Are there any implementation- or deploymentspecific considerations (e.g., technology dependencies)?
NB: whenever possible, implementation decisions and choices SHOULD be deferred to the service implementation design.
known uses: [OPTIONAL, MANY]
reference models and service patterns 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.
NB: the known uses SHOULD document actual uses, not potential uses.
service genre dependencies: [RECOMMENDED, MANY]
a list of other service genres (service genre description names) that this service genre is dependent upon.
Dependencies are useful in understanding how service genres relate. Dependencies are requirements indicating
the other service genre(s) that must be available to use this service genre. Dependencies on a specific version of
a service genre SHOULD be indicated.
related reference models: [OPTIONAL, MANY]
a list of reference models (reference model names) that use this service genre. Reference model relationships are
useful in understanding how the service genre is used in designing applications that use the reference model.
Dependencies on a specific version of a reference model SHOULD be indicated.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
11
related service patterns: [OPTIONAL, MANY]
a list of service patterns (service pattern names) that use this service genre. Service pattern relationships are
useful in understanding how the service genre is used in designing applications that use the service pattern.
Dependencies on a specific version of a service pattern SHOULD be indicated.
Describing and Documenting Service Expressions
The e-Framework encompasses a collection of (domain-specific and common) service expressions that are used
within reference models and service patterns. These service expressions are implemented through service
implementations that are then combined into applications and an overall ICT computing fabric.
Each service expression in the e-Framework SHALL be described and documented in a common format, presented
below.
NB: the format is derived from the format used to describe design patterns [GoF].
NB: unless otherwise stated, all elements in the service expression description SHALL be presented in natural language.
NB: service expression descriptions themselves are not normative. The service expression description format is normative.
NB: there is no formal process to define or document a service expression. The narrative presents the description format
used to document a service expression.
Service expression descriptions are created directly, either as new elements of the e-Framework or as refactorings of
existing structures. Service expression descriptions need not be based on existing service implementations, i.e., they
are not deduced from practice except through refactoring. A service expression described through a service
expression description is abstract, and needs to be realised through a service implementation. A service expression
does have a specific set of behaviours and a single, machine-processible service expression definition. Thus the
different service implementations will vary only in design choices, not in functionality or interfaces.
NB: different service expression definitions, i.e., different interfaces to the same functionality, require different service
expression descriptions.
The e-Framework Service Expression Description Format
The (ordered) elements of the service expression description are:
NB: the ordering is subject to revision.
NB: the items are currently presented as a flat list. Items might be reorganised into a structured collection.
name: [REQUIRED, ONE]
a simple, meaningful, concise, descriptive name or label for the service expression. The name is critical in
letting others understand and discover the service expression.
NB: The software developer need not use this name to identify the service implementation.
classification: [REQUIRED, MANY]
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.
REC: develop an appropriate service classification scheme for service expressions.
service genre: [REQUIRED, ONE]
the service genre (service genre name) that has been specialised to yield this service expression.
descriptive metadata: [REQUIRED, ONE, COLLECTION]
core metadata for the service expression description, including author, date and version. 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.
NB: it is critical to differentiate between versions of the service expression (technical changes, changes in capabilities) and
versions of the description (editorial, descriptive changes).
REC: provide a recommended practice for labelling versions.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
12
description: [REQUIRED, ONE]
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.
NB: this is not a technical description. The target audience is not programmers or developers.
use cases: [OPTIONAL, MANY]
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.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicability: [OPTIONAL, ONE]
how and when the service expression should (or should not) be used.
behaviours and requests: [REQUIRED, MANY]
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 type (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)
 functionality and operations provided
REC: formalise the behaviour and request specification format.
use and interactions: [REQUIRED, ONE]
how the behaviours, requests, algorithms, resources, state representations, etc., are combined to provide the
defined 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 expressions)? What are the use
patterns?
NB: 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.
NB: this is a precise technical description. It details conforming and non-conforming interactions that span multiple requests.
structure: [OPTIONAL, ONE]
the conceptual internal structure and operations of the service expression. Service expressions access data,
resources or 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.
NB: the information about structure SHOULD NOT be needed or need to be exposed to use or understand the service
expression or its use. The description provides critical details needed to consistently design service implementations.
NB: structure information should not include design choices.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
13
interface definition: [RECOMMENDED, ONE]
formal definition of the interfaces to the service expression: WSDL, document XSDs, vocabularies, etc.
NB: there SHALL be only one set of interface definitions. Alternative interface definitions SHALL correspond to an
alternative service expression.
NB: the restriction of one set of interface definitions per service expression is an intentional design choice for the
e-Framework.
NB: the service expression interface definition is a machine-processible representation.
NB: the interface definition is REQUIRED to develop a service implementation that corresponds to the service expression.
applicable standards: [RECOMMENDED, MANY]
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.
NB: list only those standards needed to provide the behaviour and functionality. Technical standards used in the service
implementation derived from the service expression are excluded.
design decisions and tradeoffs: [OPTIONAL, MANY]
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, ...
NB: include “why”, not just what choices were made.
NB: all of the aspects listed in the section titled Aspects of Service Design SHALL be considered for inclusion.
NB: 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.
implementation guidance and dependencies: [RECOMMENDED, ONE]
potential issues in developing a service implementation or in using a service implementation designed from the
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)?
NB: whenever possible, implementation decisions and choices SHOULD be deferred to the service implementation design.
known uses: [OPTIONAL, MANY]
reference models or service patterns 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.
NB: the known uses SHOULD document actual uses, not potential uses.
service expression dependencies: [RECOMMENDED, MANY]
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.
related service expressions: [OPTIONAL, MANY]
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.
related reference models: [OPTIONAL, MANY]
a list of reference models (reference model names) that use this service expression. Reference model
relationships are useful in understanding how the service expression is used in designing applications that use the
reference model. Dependencies on a specific version of a reference model SHOULD be indicated.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
14
related service patterns: [OPTIONAL, MANY]
a list of service patterns (service pattern names) that use this service expression. Service pattern relationships are
useful in understanding how the service expression is used in designing applications that use the service pattern.
Dependencies on a specific version of a service pattern SHOULD be indicated
Describing and Documenting Service Patterns
The e-Framework encompasses a collection of service patterns that are identified from collections of service genres
XOR service expressions (re)used in applications and reference models. Service patterns are used in the design and
implementation of applications that are part of the overall ICT computing fabric. Service patterns are similar to
reference models in terms of structure and use, and thus their descriptions are similar. Service patterns are typically
smaller than reference models. They are often composed from the combination of a service genre XOR service
expression and an infrastructure component. They focus on a problem, process or workflow that is common to
several domains or are reused in many different reference models or applications, i.e., while they are domainspecific to the major domains of the e-Framework, they are common or domain-independent within these domains.
The objective is to identify common structures of service genres XOR service expressions and resources for reuse.
NB: service patterns are identified from actual uses of collections of service genres XOR service expressions within
reference models or applications.
NB: XOR is “exclusive or”. A single service pattern is defined either exclusively in terms of service genres or exclusively in
terms of service expressions, but never a mix of both.
Each service pattern in the e-Framework SHALL be described and documented in a common format, presented
below.
NB: the format is derived from the format used to describe design patterns [GoF] and enterprise patterns [e-Biz Patterns].
NB: unless otherwise stated, all elements in the service pattern description SHALL be presented in natural language.
NB: service pattern descriptions themselves are not normative. The service pattern description format is normative.
NB: there is no formal process to define or document a service pattern. The narrative presents the description format used to
document a service pattern.
Service pattern descriptions are never created directly as new elements of the e-Framework. They are identified
from structures used in reference models and applications and then abstracted and generalised into the service
pattern.
The e-Framework Service Pattern Description Format
The (ordered) elements of the service pattern description are:
NB: the ordering is subject to revision.
name: [REQUIRED, ONE]
a simple, meaningful, concise, descriptive name or label for the service pattern. The name is critical in letting
others understand and discover the service pattern.
classification: [REQUIRED, MANY]
categorisation of the service pattern using the e-Framework service classification scheme. Select the
classifications that are most appropriate and useful in service pattern discovery and cataloguing. Service patterns
with similar characteristics SHOULD have similar classifications.
REC: develop an appropriate service classification scheme for service patterns.
descriptive metadata: [REQUIRED, ONE, COLLECTION]
core metadata for the service pattern description, including author, date and version. Service pattern descriptions
SHOULD be versioned, i.e., each revision of the service pattern or the service pattern description should have a
new version label.
NB: it is critical to differentiate between versions of the service pattern (technical changes, changes in capabilities) and
versions of the description (editorial, descriptive changes).
REC: provide a recommended practice for labelling versions.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
15
description: [REQUIRED, ONE]
a brief, informal narrative explanation of the service pattern. What problem does it address or solve? What does
it do (business problem or processes, organisation, technical problem)? What are its purpose, rationale and
intent? What are the context and conditions of use? The goal is to describe the service pattern so that others will
be able to gain a basic understanding without further exploration.
NB: this is not a technical description. The target audience is not programmers or developers.
applicability: [OPTIONAL, ONE]
how and when the service pattern should (or should not) be used.
functionality: [REQUIRED, ONE, COLLECTION]
the functionality of the service pattern in terms of workflows, data (documents) and processes, i.e., the businessoriented or domain-oriented view of the service pattern. How are these elements combined to provide the
functionality? Include explanations of all workflow patterns (valid and invalid). List the constraints and
conditions in the workflows (e.g., transactions, state changes). Illustrations of workflows and related data and
processes SHALL be included. The information SHALL include sufficient detail to understand the structure and
organisation of the service pattern in terms of resources, service genres XOR service expressions and messages.
NB: this is a precise technical description. It details all conforming and non-conforming functions and workflows or
dataflows without detailing how these are implemented through a collection of service genres XOR service expressions.
REC: formalise the structure and format for describing the workflows and functionality of a service pattern.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
structure and organisation: [REQUIRED, ONE]
the structure and organisation of the service pattern in terms of resources, service genres XOR service
expressions, messages, i.e., the service-oriented view of the service pattern. Include an illustration of the
organisation of the elements, their relationship and the message flows. The information SHALL include
sufficient detail to describe the interactions between the service genres XOR service expressions and resources in
the service pattern, and to design applications using the service pattern.
NB: this is a precise technical description of the service pattern.
NB: this differs from the functional description. The functional description is technology agnostic. The structural
description is based on interactions of service genres XOR service expressions and resources.
NB: the information about structure and organisation SHOULD NOT be needed to understand the service pattern. The
description provides critical details needed to consistently implement systems using the service pattern.
REC: formalise the structure and format for describing the structure and organisation of a service pattern.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicable standards: [RECOMMENDED, MANY]
a list of domain-specific standards (standards, specifications, application profiles) used in the service pattern.
Provide names and versions. Indicate conformance requirements or exclusions.
NB: list only those standards needed to provide the domain-specific behaviour and functionality. Technical standards used in
implementing applications based on the service pattern are excluded.
design decisions and tradeoffs: [OPTIONAL, MANY]
design decisions, design choices, alternative considerations, tradeoffs, etc., present in the service pattern. What
are the implications of the choices on key factors, e.g., implementation, performance, reuse, extensibility,
portability, security, data privacy, ...
NB: include “why”, not just what choices were made.
NB: aspects from the list in the section titled Aspects of Service Design SHOULD be considered for inclusion.
NB: the service pattern is based on actual use of service genres XOR service expressions in reference models. The design
decisions are based on those service genres XOR service expressions taken from the source reference models, abstracted and
generalised as appropriate to create the service pattern.
NB: these are decisions that influence the overall design, structure, organisation and use of the service pattern. They do not
include design decisions that only affect the internal structure and organisation of any application that is based upon the
service pattern or of the service genres XOR service expressions used within the service pattern.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
16
implementation guidance and dependencies: [RECOMMENDED, ONE]
potential issues in implementing applications using this service pattern. Are there assumptions about design,
performance, middleware, data structures, behaviours, policies, etc., that are not described elsewhere? Are there
any implementation- or deployment-specific considerations (e.g., technology dependencies)?
NB: whenever possible, implementation decisions and choices SHOULD be deferred to application or service
implementation design. Service pattern descriptions SHOULD be abstract, general descriptions, not models for
implementing applications.
known uses: [REQUIRED, MANY ≥ 2]
reference models or applications that use the service pattern. As appropriate, indicate how or why the service
pattern is used. Identify any special cases or considerations in using the service pattern. An illustration of the
use within an application or collection of interacting service implementations SHOULD be included.
NB: the known uses MUST document actual uses, not potential uses.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
REC: a service pattern MUST be used in at least two different reference models before it is considered for publication in the
e-Framework.
related service patterns: [OPTIONAL, MANY]
a list of service patterns (service pattern names) related to this pattern. Service pattern dependencies are useful
in understanding how the service pattern relates to other service patterns and knowing what service patterns are
needed to use this service pattern. A diagram illustrating the relationships between the service patterns and their
service genres XOR service expressions SHOULD be included. Dependencies on a specific version of a service
pattern SHOULD be indicated.
services used: [RECOMMENDED, MANY]
a list of service genres XOR service expressions (service genre description names XOR service expression
description names) that the service pattern is dependent upon (uses). Service dependencies are useful in
understanding how service genres XOR service expressions relate to each other within the pattern. Dependencies
are requirements indicating the service genres XOR service expressions that must be available to use this service
pattern. Dependencies on a specific version of a service genre XOR service expression SHOULD be indicated.
Describing and Documenting Reference Models
The e-Framework encompasses a collection of reference models that are built upon collections of service genres
XOR service expressions (or service patterns). Reference models are used in the design and implementation of
applications that are part of the overall ICT computing fabric.
NB: XOR is “exclusive or”. A single reference model is defined either exclusively in terms of service genres (including
service patterns of service genres) or exclusively in terms of service expressions (including service patterns of service
expressions), but never a mix of both.
Each reference model in the e-Framework SHALL be described and documented in a common format, described
below.
NB: the format is derived from the format used to describe design patterns [GoF] and enterprise patterns [e-Biz Patterns].
NB: unless otherwise stated, all elements in the reference model description SHALL be presented in natural language.
NB: reference model descriptions themselves are not normative. The reference model description format is normative.
NB: there is no formal process to define or document a reference model. The narrative presents the description format used
to document a reference model.
Reference model descriptions are created directly as new elements of the e-Framework or are identified from
existing reference models.
The e-Framework Reference Model Description Format
The (ordered) elements of the reference model description are:
NB: the ordering is subject to revision.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
17
name: [REQUIRED, ONE]
a simple, meaningful, concise, descriptive name or label for the reference model. The name is critical in letting
others understand and discover the reference model.
domains: [OPTIONAL, MANY]
the domains within the e-Framework where the reference model MAY be used.
descriptive metadata: [REQUIRED, ONE, COLLECTION]
core metadata for the reference model description, including author, date and version. Reference model
descriptions SHOULD be versioned, i.e., each revision of the reference model or reference model description
should have a new version label.
NB: it is critical to differentiate between versions of the reference model (technical changes, changes in capabilities) and
versions of the description (editorial, descriptive changes).
REC: provide a recommended practice for labelling versions.
description: [REQUIRED, ONE]
a brief, informal narrative explanation of the reference model. What problem does it address or solve? What
does it do (business problem, processes, workflow)? What are its purpose, rationale and intent? What are the
context and conditions of use? How does it support the development of applications in the stated domain? The
goal is to describe the reference model so that others will be able to gain a basic understanding without further
exploration.
NB: this is not a technical description. The target audience is not programmers or developers.
use cases: [OPTIONAL, MANY]
brief, informal presentations of how the reference model is used. An illustration of the reference model showing
an overall set of business processes involving workflow and service genres XOR service expressions, or an
illustration of the use within an application or collection of interacting service genres XOR service expressions
SHOULD be included.
NB: detailed diagrams illustrating all components, flows, etc., are not required. Diagrams should be illustrative (1 page),
showing only high-level components and flows.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicability: [OPTIONAL, ONE]
how and when the reference model should (or should not) be used.
functionality: [REQUIRED, ONE, COLLECTION]
the functionality of the reference model in terms of workflows, data (documents) and processes, i.e., the
business-oriented or domain-oriented view of the reference model. How are these elements combined to provide
the functionality? Include explanations of all workflow patterns (valid and invalid). List the constraints and
conditions in the workflows and use patterns (e.g., transactions, state changes). Illustrations of workflows and
related data and processes SHALL be included. The information SHALL include sufficient detail to develop the
structure and organisation of the reference model in terms of resources, service genres XOR service expressions
and messages.
NB: this is a precise technical description. It details all conforming and non-conforming functions and workflows or
dataflows without detailing how these are implemented through a collection of service genres XOR service expressions (or
service patterns).
REC: formalise the structure and format for describing the workflows and functionality of a reference model.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
structure and organisation: [REQUIRED, ONE]
the conceptual structure and organisation of the reference model in terms of resources, service genres XOR
service expressions, messages, i.e., the service-oriented view of the reference model. Include an illustration of
the organisation of the elements, their relationship and the message flows. The information SHALL include
sufficient detail to identify needed service genres XOR service expressions and resources and their interactions,
and to design applications using the reference model.
NB: this is a precise technical description of the reference model.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
18
NB: this differs from the functional description. The functional description is technology agnostic. The structural
description is based on interactions of service genres XOR service expressions and resources.
NB: the information about structure and organisation SHOULD NOT be needed to understand the reference model. The
description provides critical details needed to consistently implement systems using the reference model through a collection
of interacting service implementations.
REC: formalise the structure and format for describing the structure and organisation of a reference model.
REC: provide a recommended practice for diagrams. Formal UML notation is not required.
applicable standards: [RECOMMENDED, MANY]
a list of domain-specific standards (standards, specifications, application profiles) used in the reference model.
Provide names and versions. Indicate conformance requirements or exclusions.
NB: list only those standards needed to provide the domain-specific behaviour and functionality. Technical standards used to
implement applications based on the reference model are excluded.
design decisions and tradeoffs: [OPTIONAL, MANY]
design decisions, design choices, alternative considerations, tradeoffs, etc., present in the reference model. What
are the implications of the choices on key factors, e.g., implementation, performance, reuse, extensibility,
portability, security, data privacy, ...
NB: include “why”, not just what choices were made.
NB: aspects from the list in the section titled Aspects of Service Design SHOULD be considered for inclusion.
NB: these are decisions that influence the overall design, structure, organisation and use of the reference model. It does not
include design decisions that only affect the internal structure and organisation of any application that is based upon the
reference model or of the service genres XOR service expressions used within the reference model.
implementation guidance and dependencies: [OPTIONAL, ONE]
potential issues in implementing applications based on this reference model. Are there assumptions about
design, performance, middleware, data structures, behaviours, policies, etc., that are not described elsewhere?
Are there any implementation- or deployment-specific considerations (e.g., technology dependencies)?
NB: whenever possible, implementation decisions and choices SHOULD be deferred to application or service
implementation design. Reference model descriptions SHOULD be abstract, general descriptions, not models for
implementing applications.
known uses: [OPTIONAL, MANY]
applications or systems that use the reference model. As appropriate, indicate how or why the reference model is
used. Identify any special cases or considerations in using the reference model or developing and deploying the
application using the reference model.
NB: the known uses SHOULD document actual uses, not potential uses.
related reference models: [OPTIONAL, MANY]
a list of references models (reference model names) related to this reference model, or reference models that this
reference model uses or is dependent upon (in all or in part). Reference model dependencies are useful in
understanding how the reference model relates to other reference models and knowing what other reference
models are used in designing applications that use this reference model. A diagram illustrating the relationships
between the reference models SHOULD be included. Dependencies on a specific version of a reference model
SHOULD be indicated.
services used: [RECOMMENDED, MANY]
a list of service genres XOR service expressions (service genres description names XOR service expressions
description names) that the reference model is based upon. Service dependencies are useful in understanding
how service genres XOR service expressions relate to the reference model and knowing what service genres XOR
service expressions must be available for designing applications using the reference model. Dependencies on a
specific version of a service genre XOR service expression SHOULD be indicated.
service patterns used: [RECOMMENDED, MANY]
a list of service patterns (in terms of service genres XOR service expressions) (service pattern description names)
that the reference model is based upon. Service dependencies are useful in understanding how service patterns
relate to the reference model and knowing what service genres XOR service expressions must be available for
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
19
designing applications using the reference model. Dependencies on a specific version of a service pattern
SHOULD be indicated.
The e-Framework Service Classification Scheme
The service genre, service expression, and service pattern description formats include a classification entry (the
service classification) that is used to label and tag these elements for discovery, organisation, and to aid in
understanding an element’s purpose and use. Having a standard vocabulary of terms for classifying service genres,
service expressions, and service patterns provides consistency in labelling.
NB: a single service classification scheme is used for all elements: service genres, service expressions, service patterns. The
same classification scheme can be used for reference models.
No definitive service classification scheme is presented. Classification facets might include:
 purpose: how the service is used, what it does
 domain: list of all domains from the e-Framework where the element is used.
 scope: range of domains, e.g., single (just one domain), multiple (many domains), common (any domain),
infrastructure (), shared (???).
 structure: composition, e.g., individual, composed/composite.
 visibility: who can see it, e.g., public, private, internal, external.
 behaviour: how the service operates, e.g., transactional.
 community: which community develops or uses, e.g., JISC, DEST, commercial.
 status: development status, e.g., candidate, prototype, deployed.
 other: what else?
NB: this is a tentative placeholder list.
REC: the list of facets and the vocabulary of values for each facet should be developed and made available to those creating
service genre, service expression, and service pattern descriptions.
Service Design and Factoring Guidelines
The services within the e-Framework are designed, specifying behaviours and functionality from requirements. This
design is then documented in the format described. Services in the service-oriented approach and in a web
environment (not necessarily web services) differ from other programming models. Design guidelines for creating
and (re)factoring services in the service-oriented approach follow, including:
 General characteristics of services (service implementations) within the service-oriented approach.
 A process and guidelines for service design and factoring (service genres, service expressions, service
implementations).
 Design concepts for services (service implementations) and applications built upon and using these services
and service implementations.
 Aspects of service and design (focusing on service expressions).
General Characteristics of Services
Applications built following the e-Framework are used to access and manipulate a set of (managed) resources that
are distributed over the network. The application’s (idealised) model of the real world is represented through and
encoded in the set of (stateful) resources, the state model. The resources are key information assets of the
organisations that own, manage and maintain them. These organisations permit access to these resources via service
implementations. This access provides a way of obtaining the information contained within the resources, or the
means to specify how the service implementation is to manipulate the information, i.e., how a service
implementation changes the resource’s state. Key characteristics of the service-oriented approach that are important
for designing these resources and the service implementations that access them follow.
NB: since this section describes operational capabilities, it is presented in terms of service implementations, not service
expressions. The concepts, however, extend to the service expressions.
NB: by implication, what applies to a service implementation also applies to a service instance.
NB: the qualified use of “service” needs to be verified for the proper adjective throughout.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
20
stateful resources:
resources (web resources) are stateful, i.e., they have a state. Resource values change over time through a series
of events; each change is a transformation from one state to the next; the order of operations is meaningful; and
the effect of the operations is reflected by the current value or state of the resources.
service implementations manipulate state:
service implementations provide the means used to manipulate the state of the resources. The service
implementations essentially own the (access to) the resources. Manipulations change the resources, reflected by
a change in their state.
NB: state may be manipulated independently by other means. There are no means to limit such state changes.
service implementations provide interfaces to resources:
each resource is accessed and manipulated through the interface provided by the service implementation. The
service implementation’s messages provide the interface used to access and manipulate the resources.
resource representations are unknown:
clients do not know how resources are represented or manipulated. Representations and details of processing are
generally private to the service implementation and hidden from view.
communications are “by value”:
resources are not passed between service implementations; they remain under the control and access of the
service implementations. The information that is passed to a service implementation through a message may
include (1) control information (queries, actions) that specifies access or controls state manipulation and (2)
documents (data). This data represents the values of some resource in some representation. In the serviceoriented approach, the data is a copy or subset of the resource, not the resource itself. Alternatively, the message
may include the identifier of the resource or data, not the resource. The service implementations must still then
resolve and access the resource to manipulate its state; the actual resource is not passed to the service
implementation.
NB: the resource value passed need not use the same representation or encoding as the resource itself.
NB: this differs from the object-oriented approach where resources, as objects, are passed in messages between methods.
resource locations are unknown:
clients do not know where resources are located in the network.
NB: in this use, services are themselves a type of resource.
communications are via messages:
messages provide the only way to communicate with a service implementation and for a service implementation
to communicate with other service implementations.
behaviours support transactions:
individual messages and message sequences describe transactions that manipulate state. Transactions must
either suceed and modify the state of the resources, or fail and leave the resource state unchanged. Transactions
may be implemented through synchronous communications (the request and response are bundled in the
communications model), or asynchronous communications (call backs, publish/subscribe). The service-oriented
approach focuses on transactional manipulations of state, not the methods used to implement the required
transactional model.
stateless network infrastructure:
at the application or service implementation level, network communication protocols, e.g., HTTP, are often
stateless.
These characteristics are combined to yield a service-oriented approach that uses transactional behaviours,
implemented over stateless communications protocols, to provide stateful manipulations of private representations
of resources where the resources are distributed over the network.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
21
Service Design and Factoring Process Guidelines
Service design, decomposition and factoring are complex and involve many tradeoffs. Decisions are often made
under uncertainty. This is further complicated by conflicting goals (price, performance, capabilities) and the desire
to build systems that are adaptable and long-lived, but function in an ever-changing implementation and deployment
environment. Service design includes requirements gathering processes, design, implementation, deployment and
refactoring. Key guidelines that cover each of these activities are listed below.
NB: these guidelines SHALL NOT be interpreted as a prescriptive software design methodology. Designers are free to
choose any method or approach.
NB: by implication, what applies to a service implementation also applies to a service instance.
NB: the qualified use of “service” needs to be verified for the proper adjective throughout.
Develop requirements and constraints:
 Have target goals and metrics for price, performance (including QoS), capabilities.
 Differentiate required features from desired features.
 Identify known (not possible) future requirements and extensions.




NB: design for the known requirements only.
Differentiate domain-specific from domain-independent concepts, context and content.
Work from real-world (not theoretical) analyses.
Know what entity has responsibilities and which are collaborators, i.e., what a service genre XOR service
expression does versus what service genre XOR service expression it uses.
Use nouns and verbs that correspond to documents and business functions, respectively, in the serviceoriented approach to develop requirements.
Design the appropriate service genres and service expressions:
 Determine the appropriate granularity of service genres and service expressions, data, resources and
behaviours.
 Decompose the problem space and factor service genres and service expressions using the service design
principles listed in the section titled Principles and Practices in Designing Services.
 Consider the service design aspects listed in the section titled Aspects of Service Design.
 Design for known requirements and extensions.
 Limit the complexity of service genres and service expressions.
 Map documents and business functions to the data objects and behaviours (messages) of the service
expressions.
 The state model is encapsulated by the resources accessed and manipulated through the service expressions
(and their service implementations).
 Behaviours are the only way to cause change in the state model.
 Messages to service implementations are the only way to invoke the behaviour.
 Specify interfaces (messages, documents).
 Specify constraints on the implementations, but do not specify the implementation itself.
 Clients use only the published interfaces, never information about the implementation.
 Design for reuse.
Design, develop, deploy and manage service implementations and applications [Marca].
 Identify the overall business processes, resources and workflows within the application.
 Identify the participants, their roles, rights and access requirements.
 Determine overall performance goals and metrics.
 Develop a service-oriented view of the processes.
 Factor the overall problem space into an overall service-oriented view.
 Identify (or design) appropriate service genres, service expressions and resources.
 Determine which service expressions will be open versus which will be closed.
 Reuse concepts, abstractions, resources, patterns, vocabularies, etc.
 Connect and compose the service expressions into the overall application design.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
22
Then gather feedback on deployment and operations, and refactor as needed. Triggers for refactoring include:
NB: the list is not exhaustive.
NB: the list is not ordered or prioritised.
NB: use proxy and adapter service patterns to address changes and version incompatibilities as needed.










change to the document(s) used by service expressions
change to the messages, i.e., the service expression interface
change to the format or structure of the document(s) passed in messages
extension of and addition to service expression behaviours
overly complex service expressions (or service genres)
change in algorithm when behaviours are tied to specific algorithms
change in underlying hardware, software, methodologies, etc., when the design is dependent on these
failure to meet performance goals
identification of tight couplings
transitioning closed service expressions to an open service expressions (or vice versa)
NB: a change in a design choice SHOULD NOT trigger refactoring.
Design Concepts for Services
Much modern software is designed according to principles borrowed from object-oriented systems. Some of these
key concepts can be applied and adapted to the service-oriented approach:
NB: by implication, what applies to a service implementation also applies to a service instance.
NB: the qualified use of “service” needs to be verified for the proper adjective throughout.
abstraction:
abstraction provides a means to hide details. The objective is to simplify the model, focusing only on key
aspects. Service implementations accessed through message interfaces abstract details of representation and
processing. Layering of service implementations upon middleware, binding to specific languages, binding to
communications protocols, etc., further abstracts the service genre and service expression concepts and models
from use in service implementations and applications.
encapsulation:
encapsulation groups data, resources, representations and behaviours into a single entity. A service genre or
service expression (and its service implementation) is an encapsulation.
polymorphism:
polymorphism defines how the same behaviour can be used with different data, e.g., polymorphic behaviour of
“+”: 1 + 2 yields 3; Monday + 2 yields Wednesday. Polymorphism has no direct analogy in the service-oriented
approach; service expressions (and their service implementations) and their messages are designed to work with
specific data or resources. However it is beneficial to develop a vocabulary of behaviours so that the same
named behaviours applied to different representations, or that a message used in different service expressions or
service implementations, are analogous.
inheritance:
inheritance defines a structured hierarchal representation, where properties or attributes defined at one level are
available to the lower levels directly, or these lower levels may override and change the properties. Inheritance
has no direct analogy in the service-oriented approach; there is no direct refinement of service genres, service
expressions or exposed representations.
These object-oriented concepts are augmented in the service-oriented approach with:
coupling:
coupling describes the dependencies among components and how components are connected to each other, i.e.,
what knowledge one component has of other components. Components may be tightly coupled, with many
dependencies, or loosely coupled, with minimum dependencies.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
23
transactions:
transactions join and coordinate multi-step processes into a single unit that either succeeds or fails.
Applying these key concepts to the service-oriented approach provides these guidelines:
abstraction:
 Hide details via abstractions.
 Describe service genres and service expressions in terms of the concepts, i.e., the kinds of documents or
resources they manipulate, the behaviours.
 Provide additional elements that map the abstract concepts to their implementation details (service
implementations, data models, resources, messages, bindings).
 Define interfaces, not implementations.
encapsulation and factoring:
 Encapsulate resources and their behavioural modifications in service expressions (and their service
implementations).
 Factor to provide multiple encapsulations.
 Factor to group related behaviours on the same document or resource from unrelated behaviours.
 Factor to group related behaviours on the same document or resource from the same behaviours on
different types of documents or resources.
 Factor those items that vary from those that remain the same.
 Factor to permit extensions without requiring modifications.
composition:
 Build service expressions (and their service implementations) through composition of other service
expressions (and their service implementations) and other resources.
 Use composition as a replacement for inheritance.
coupling:
 Use loose couplings between interacting service expressions (and their service implementations).
 Minimise dependencies between components.
transactions:
 Enforce proper transactional controls and workflows.
 Minimise transaction dependencies and coupling between service expressions (and their service
implementations).
Aspects of Service Design
When designing a service expression or its service implementation, the following aspects should be considered and
incorporated into the resulting design and documented in the service expression description. Where appropriate, the
design decisions and design choices around these aspects SHOULD be included in the service expression description.
NB: the list is not exhaustive. Designers SHALL augment the list of aspects as necessary.
NB: while this list focuses on service expression design, many of the same aspects SHOULD be considered when developing
a service genre, reference model or service pattern.
NB: there are additional aspects of software design that are not specific to service design that are not included here (e.g., use
of declarative models, consistency in approach, symmetric models).
NB: the list is not ordered or prioritised.
NB: the qualified use of “service” needs to be verified for the proper adjective throughout.
granularity and document orientation:
service expressions (and their service implementations) may vary in size (number of behaviours) and complexity
(of interfaces and of the behaviours provided). The service-oriented approach favours a smaller number of
larger-grained service expressions, each providing a collection of related, meaningful (complex) business
functions. Service expressions may provide behaviours that operate on and at the level of (complex or complete)
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
24
documents, or lower-level operations on individual fields and elements of the data representations of resources.
The service-oriented approach favours a document-oriented functional model. Service expressions (and service
genres) SHOULD be designed around manipulating document-oriented resources through business-oriented
functions and behaviours. Service expressions SHOULD NOT be designed to provide direct manipulations of
(underlying, internal) data representations. Service expressions SHOULD NOT be used to implement CRUD
interfaces (create, retrieve, update, delete) on data representations.
interoperability:
interoperability between service implementations or between clients and service implementations motivates the
service-oriented approach. In an open, loosely connected system, interoperability is achieved through the use of
standards (standards, specifications and application profiles). Identify, use or adapt standards when feasible.
Selection of, and conformance to, these standards SHALL BE documented.
NB: conformance statements include exceptions, extensions, non conformance.
scale:
service expressions (and their service implementations) may be required to function over a range of use (scale).
The underlying resources may range in scale (e.g., size, number, complexity). For example, will the service
implementation have limited deployment or it will be widely deployed and accessible? Will the expected
number of resource instances be small or very large? How might the service implementation need to change as
scale of use and deployment change? Assumptions about the scale of service implementation deployment
SHOULD be documented. The design of the service implementation SHALL consider scalability.
latency:
responses to messages and requests are not instantaneous. While the e-Framework is not designed for real-time
applications, latency should be considered in the design of service expressions, service implementations and
applications. What is the impact of a delay in response? What response times are acceptable? Expected and
acceptable performance criteria SHOULD be documented, including information about behaviours when criteria
are not met. Alternative strategies to meet performance criteria SHOULD be documented.
incremental update of components:
individual components (resources, applications, service implementations, standards) may be incrementally
updated or versioned. A service expression (and its service implementation) SHOULD be designed so that other
components or elements can be updated without breaking any service implementation. When a service
expression or service implementation is dependent on a particular version or feature such that an update to that
one component will break the service implementation, this dependency SHALL be documented.
NB: an acceptable behaviour MAY be that the service implementation indicates that it cannot interoperate with a particular
version of a document, resource or other service implementation. A service implementation SHOULD NOT fail when
components are updated.
reliability:
there are many sources of unreliability in a service-oriented approach. Communications and messaging may be
unreliable (messages may not be delivered); service instances may be unreliable (they may fail to respond, not be
accessible); hardware may fail. A requestor SHALL be designed assuming the provider will not be reliable.
Target performance goals for service expressions (and their service implementations) and providers SHOULD be
documented. Single points of failure SHOULD be avoided, but identified when present.
lack of shared state between requestor and provider:
the entire state model is hidden. Service expressions (and their service implementations) expose behaviours that
may not directly map to the underlying representations or state. State is accessible only via service
implementations and it is difficult to obtain all of the state with large-grained service expressions. Thus different
service instances and applications may have different models of state or assumptions about the current values in
the state model. Service expressions (and their service implementations) SHALL be designed without relying on
a shared state model. Service expressions (and their service implementations) SHOULD be designed assuming
limited and potentially faulty state information. Approaches to providing shared state SHOULD be documented.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
25
transactions:
business operations and workflow processes require coordinated series of messages, each of which changes the
state model. Different concurrent access patterns are performing independent and potentially conflicting and
incompatible changes to the state model. Transactions provide the mechanism to coordinate these messages and
provide consistency in the state model. Reliability concerns imply that transaction patterns are not failsafe. The
distributed network model and network latency implies that transactions may be long-lived. Transactional
behaviours SHOULD be ACID (atomic, consistent, isolated, durable). Transactional behaviours and assumptions
SHOULD be documented. Approaches to supporting transactional behaviour SHOULD be documented.
concurrent access:
service implementations (providers) may be accessed concurrently from many clients (requestors). Service
expressions (and their service implementations) SHALL be designed for concurrent access. Different design
solutions will impact latency, reliability and requirements to support data transactions. Independent of how the
service expression is designed for concurrent access, the design of the service implementation SHALL consider
concurrency. Approaches to providing concurrent access SHOULD be documented.
message orientation:
service expression interactions (and their service implementation interactions) are defined in terms of messages,
not in terms of how the service expression is implemented or structured. Implementation details SHOULD NOT
be exposed via message interfaces. Clients SHOULD NOT be dependent upon knowledge of internal structure
and behaviour of the service implementation.
unreliability of transport:
messages and service implementation interactions are implemented upon a network transport layer that is
inherently unreliable. Service expressions (and their service implementations) SHOULD be designed assuming
unreliable transport.
security:
access to resources and to service implementations may need to be secure and controlled. Service expression
descriptions SHALL describe security requirements, e.g., what to secure, what are the policies for control, what
are the authentication requirements and models, what are roles and permissions, what is confidential, where is
nonrepudiation required, what needs to be encrypted, when audit controls and records are needed, where rights
need to be managed, etc. Security solutions and approaches SHOULD be documented.
privacy:
service expressions (and their service implementations) may have access to private or confidential data. Privacy
concerns SHALL be documented. Approaches to ensure privacy SHOULD be documented.
policy:
service expressions (and their service implementations) are managed under a collection of policies, including
security, trust, privacy, availability. All governing policies SHALL be documented. Approaches for describing
and enforcing policies and managing service implementations SHOULD be documented.
QoS:
quality of service addresses target performance goals, including reliability, availability, latency, response time.
All QoS goals and measurement metrics SHOULD be documented. QoS constraints (goals that must be met)
SHALL be documented. Approaches to meet QoS requirements SHOULD be documented.
trust:
service expressions may have or assume trust relationships with other service expressions. Trust requirements
and assumptions shall be documented. Approaches to supporting trust relationships SHOULD be documented.
provenance:
requirements for provenance of data and resources SHOULD be documented. When required, approaches to
support data and resource provenance SHOULD be documented.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
26
discoverability and description:
service expression descriptions SHOULD be complete in exposing all public information needed to use and
understand the service expression. Formal, machine-processible service expression definitions SHALL be
provided.
operations and sustainment:
deployed service implementations, particularly those that are used by multiple applications, may require
production-level support and operations (reliability, system and data backup, scale, operational procedures).
Requirements for sustainment and operational plans for service implementations SHOULD be included in the
service expression and service implementation design. Sustainment and operations SHALL be considered in
designing and deploying applications.
service complexity:
service expressions SHOULD have realistic complexity and extensibility. Factor service expressions to limit
complexity. Limit extensibility to known requirements. It may be useful to factor special cases into separate
service expressions.
Principles and Practices in Designing Services
A list of considerations in designing reference models, service genres, service expressions, service patterns, service
implementations, service toolkits, resources and applications. Principles, practices and constraints are based in part
on [WWW Arch, HLA].
NB: the list of issues is incomplete and unordered.
NB: a structured organisation may be needed.
NB: this is a more formal (normative) list than presented in the section Service Design and Factoring Process Guidelines.
NB: by implication, what applies to a service implementation also applies to a service instance.
NB: the qualified use of “service” needs to be verified for proper adjective throughout.
unique identification of resources:
resources SHOULD have unique identifiers. [PRINCIPLE]
identifier opacity:
anyone using an identifier SHOULD NOT infer properties of the identified resource from the identifier.
[PRACTICE]
version information:
descriptions and specifications (reference models, service genres, service expressions, service patterns, data
models, schemata) SHOULD include version information. [PRACTICE]
extensibility mechanisms:
descriptions and specifications (reference models, service genres, service expressions, service patterns, data
models, schemata) SHOULD include extensibility information. [PRACTICE]
extensibility conformance:
extensions to a specification (reference models, service genres, service expressions, service patterns, data
models, schemata) MUST NOT interfere with conformance to the base specification. [ PRACTICE]
separation of content from presentation:
specifications (reference models, service genres, service expressions, service patterns, data models, schemata)
SHOULD separate content from both presentation and interaction. [ PRACTICE]
communications reliability:
network communications may be unreliable. All designs and implementations MUST consider communications
reliability. [CONSTRAINT]
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
27
service communications:
within an application, all communications with service implementations SHALL be through their message
interfaces. [PRINCIPLE]
abstractions:
implementation and representation details SHOULD be hidden through the use of abstraction. [ PRINCIPLE]
coupling:
components SHOULD be loosely coupled. [PRACTICE]
granularity:
service expressions and service implementations SHOULD be large grained. [PRACTICE]
document orientation:
service expressions and service implementations SHOULD be document oriented. [PRACTICE]
transactions:
within an application, transactional behaviour SHALL be provided and enforced. [PRINCIPLE]
Glossary / Definitions / Terminology
Definitions are given in alphabetical order. Terms are capitalized when meaningful; otherwise terms are presented
in lowercase. Inspirational sources for definitions are noted in brackets [ ]. Definitions have been generalised from
sources and then specialised for the context of the e-Framework; they are not literal from the cited source except
when quoted.
NB: the list of terms is incomplete.
NB: core terms used to describe and define the e-Framework are labelled CORE. Terms used in describing how the
e-Framework is used or terms analogous to the core terms from other areas are labelled CONTEXT.
NB: some terms defining services and the service-oriented architecture concepts are included but not used in other parts of
the document.
NB: all terms are nouns.
REC: stakeholders need to review the entire document and identify terms to be added to the list.
While the e-Framework documents should be consistent and rigorous in their use of terminology, there is no existing
universal set of terms to use. Terms should be defined within the context of the e-Framework, but assume they will
be misapplied and misinterpreted.
Authoritative definitions for many terms do not exist. Different organisations and authors create or modify
definitions to meet their needs. Many terms are used as jargon or buzzwords without any significant contextual
relationship. Collections of terms may have circular definitions. Some key terms (e.g., architecture, pattern,
framework) define a set of concepts, and the qualifying adjective is often omitted (e.g., software architecture, system
architecture). Some terms have a long history of use within specific communities and have definitions that are
specific to those communities, e.g., pattern and framework have specific meanings in defining object-oriented
software. The use of Java both as an object-oriented programming language and to develop web services may make
some of these overlaps in meaning particularly confusing to different audiences.
abstract service: [CONTEXT]
see service genre or service expression.
NB: Clearly distinguishing services and service descriptions as conceptual items from service implementation as actual
implementations and elements of operational systems is critical, independent of the terminology used.
REC: do not use. Use service genre or service expression for abstract service definitions and service implementation for
concrete service implementations, respectively. This follows practice in [WS Arch].
agent: [CONTEXT]
a deployed service implementation. A service instance.
REC: do not use. Use service implementation or service instance.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
28
agent design (specification): [CONTEXT]
software specification used to guide implementation of an agent (a service implementation).
REC: do not use. Use service implementation design (specification).
application: [CORE]
a deployed ICT software system or program designed to carry out tasks or solve problems that are specific to a
given use or requirement. [OED]
NB: in the e-Framework, an application can be either an application system or an application service.
application area: [CONTEXT]
a problem area or business specialty.
REC: do not use. Use domain.
application service: [CORE]
an application that is a service implementation. A machine-to-machine interface to the implementation of a
service genre or service expression, possibly composed with infrastructure service implementations.
NB: since development and deployment are outside of the scope of the e-Framework, the term application is used throughout.
application system: [CORE]
an application deployed for end-users.
application profile: [CONTEXT]
customization of a standard(s) (de facto or de jure) or specification(s) for a community. The customization may
be through the specification of constraints on how features are used (or not used), through the definition of
extensions, or through definitions of how elements of the standard(s) are interpreted and used within the
community.
NB: standard or specification can be used as a generic term for any de factor standard, de jure standard, or specification.
(software) architecture: [CONTEXT]
the overall structure of a software system, including software components, the externally visible properties of
those components, their behaviours, the relationships among them and the constraints on their use. [Ref Arch,
OPF]
NB: architecture has not been used as a term in the e-Framework.
NB: distinct from system architecture that includes physical components, e.g., hardware, or from business/process
architecture.
REC: do not use.
artifact: [CONTEXT]
an operational collection of software without regard to its use or function. A collection of service
implementations and other deployed software components.
NB: this term has been used in the stack diagram.
REC: do not use.
behaviour: [CONTEXT]
a named, defined function or capability provided by a service via its interface. Behaviour is implemented
through operations on data models. [WS Gloss]
blueprint: [CONTEXT]
a collection of reference models that establishes the description of a framework. [SOA Blueprint]
NB: the definition is a transliteration of the definition for an SOA blueprint, replacing the OASIS terminology with
e-Framework terminology.
NB: the OASIS SOA Reference Model [SOA RM] and Blueprint [SOA Blueprint] terminology of service, pattern, blueprint
and architecture map to the e-Framework terms of service genre or service expression, service pattern, reference model and
framework.
NB: in architecture, a non unique graphical representation of a design, used to convert the design into an artifact; an instance
of a design drawing.
REC: do not use. Use reference model.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
29
classification: [CONTEXT]
see service classification.
REC: use the qualified term. The unqualified term is for contextual use only.
client: [CONTEXT]
an application or service implementation (or its service instances) that uses other service implementations (or
their service instances).
NB: see requestor.
common service: [CONTEXT]
a service genre or service expression that supports or is implemented across a wide collection of applications or
domains. [e-Framework Overview]
NB: there may be multiple service instances deployed for a common service. The specification of when the infrastructure
must only contain a single service instance to provide the common service is part of the service description.
NB: types of services are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
composed service: [CONTEXT]
a service implementation that combines elements from different service expressions, typically a domain-specific
service expression with an infrastructure service expression.
NB: types of services are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
composed services model: [CONTEXT]
a modelling approach for building (web) services from other services based on their interactions. Compositions
are defined through (work)flow, choreography, orchestration and composition specifications (WSFL,
BPEL4WS).
NB: I was unable to find any references to the use of the term “composed services model”. Composite web services, service
composition are used as described.
REC: do not introduce.
concrete service: [CONTEXT]
see service implementation or service instance.
NB: Clearly distinguishing services and service descriptions as conceptual items from service implementation as actual
implementations and elements of operational systems is critical, independent of the terminology used.
REC: do not use. Use service genre or service expression for abstract service definitions and service implementation for
concrete service implementations, respectively. This follows practice in [WS Arch].
constraint: [CONTEXT]
a restriction on behaviour or interaction. Constraints may be imposed for technical, policy, or other reasons, e.g.,
accessibility, scope, ease of evolution, efficiency, extensibility. [WWW Arch]
definition: [CORE]
see service definition.
REC: use the qualified term. The unqualified term is for contextual use only.
description: [CORE]
see service description.
REC: use the qualified term. The unqualified term is for contextual use only.
design: [CONTEXT]
a description (typically represented in a collection of documents in different forms) used by developers as the
basis to convert a concept into an artifact. [OED]
design choice: [CONTEXT]
an arbitrary selection from equivalent alternatives. [WWW Arch]
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
30
design pattern: [CONTEXT]
“systematically names, explains, and evaluates an important and recurring design in object-oriented systems.” A
design pattern formally identifies key aspects of a common design useful in creating reusable object-oriented
designs. [GoF].
NB: in terms of architectural design [Alexander], the collection of design patterns covers the entire design space and can be
used in a generative fashion to develop a complete design for an artifact. Software design patterns are neither exhaustive nor
generative.
document: [CONTEXT]
data represented in a defined, known format. [WS Gloss]
domain: [CORE]
a problem area, business specialty area, or supporting area.
NB: the domains for the e-Framework include: learning, teaching, academic administration, research, e-science, information
management.
REC: domain has been selected (versus application area) as the term to use consistently throughout.
domain-specific service: [CONTEXT]
a service genre or service expression that supports or is implemented within only a single domain.
[e-Framework Overview]
NB: types of services are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
e-Framework: [CORE]
an “evolving and sustainable, open standards based service-oriented technical framework to support the
education and research communities.” [e-Framework]
expression: [CONTEXT]
see service expression.
REC: use the qualified term. The unqualified term is for contextual use only.
framework: [CONTEXT]
a collection of cooperating service genres within a domain. [GoF]
a vocabulary of components (e.g., service genre, service expression and reference model) used to model concepts
and behaviours within a domain or to create a particular type of infrastructure (system or environment).
Associated with the vocabulary is the grammar or language used to describe how the elements are combined or
constrained to create systems and environments.
NB: in object-oriented software, a framework is a “set of cooperating classes that make up a reusable design for a specific
class of software” [GoF].
NB: the grammars and languages are used to describe the reference models and service descriptions.
genre: [CONTEXT]
see service genre.
REC: use the qualified term. The unqualified term is for contextual use only.
identifier: [CONTEXT]
an unambiguous name for a resource. [WWW Arch]
REC: do not specify an identifier implementation or scheme (e.g., URI) in the overall e-Framework.
implementation: [CONTEXT]
see service implementation.
REC: use the qualified term. The unqualified term is for contextual use only.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
31
infrastructure service: [CONTEXT]
a service implementation that is widely used to provide capabilities in support of another service
implementation.
NB: use instead of shared service.
NB: types of service are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
instance: [CONTEXT]
see service instance.
REC: use the qualified term. The unqualified term is for contextual use only.
managed service: [CONTEXT]
a service expression with associated semantics, policies, monitoring and management controls accessible via
service interfaces. [WS Gloss]
NB: is there confusion between a managed service expression and a managed service instance?
NB: types of services are indicated through service classifications.
message: [CONTEXT]
a unit of data sent from one service implementation or service instance to another. [WS Arch]
messaging: [CONTEXT]
transmission of messages through a network via protocols. [WS Arch]
metamodel: [CORE]
the overall technical description of the e-Framework elements, the overall process used to build and document
these elements and the processes used to translate these elements into designs and deployed applications within
the domains of the e-Framework. The model of the conceptual service-oriented approach to the e-Framework.
middleware: [CONTEXT]
communications software used to link requestors to providers or link support software to integrate service
implementations into an application.
open standard: [CONTEXT]
a standard (de jure or de facto) or specification, developed collaboratively through an open, consensus-building
process, that is platform independent, vendor neutral, extensible, reusable, publicly accessible, and not
encumbered by royalties, licenses or constraints on use and implementation. [e-Framework Overview]
pattern: [CONTEXT]
see service pattern.
REC: use the qualified term. The unqualified term is for contextual use only.
policy: [CONTEXT]
a constraint on the behaviour of an service implementation (and its service instance). [WS Arch]
principle: [CONTEXT]
a fundamental rule that applies to a large number of situations. [WWW Arch]
protocol: [CONTEXT]
a set of formal rules describing how to transmit data, especially across a network. [WS Gloss]
provider (agent): [CONTEXT]
see provider (service implementation).
REC: do not use agent. Use provider or provider service implementation.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
32
provider (service implementation): [CONTEXT]
a service implementation (or its service instances) used by other service implementations that provides the
functionality and behaviour of the provider. [WS Arch, WS Gloss]
reference architecture: [CONTEXT]
a generalisation of the common functions, features, capabilities, and design of a software system based on
multiple implemented examples. A reference architecture is instantiated to create the software architecture or
design of a specific software system. [Ref Arch]
REC: do not use.
reference implementation: [CONTEXT]
a software system illustrating the normative implementation of a standard.
REC: do not use.
reference model: [CORE]
a description of the needs, requirements, workflows, management policies and processes within a domain and
the mapping of these to a design of a structured collection of service genres and service expressions, resources,
associated standards, specifications, data formats, protocols, bindings, etc., that can be used to implement
software applications within the domain. [e-Framework Overview]
requestor (agent): [CONTEXT]
see requestor (service implementation).
REC: do not use agent. Use requestor or requestor service implementation.
requestor (service implementation): [CONTEXT]
an application or service implementation (or its service instances) that interacts with other (provider) service
implementations (or their service instances) requesting that the providers perform some function for the
requestor. [WS Arch, WS Gloss]
resource: [CORE]
something that has a representation, is owned, controlled (by policy) and is uniquely identified. [WS Arch]
SERVICE: [CONTEXT]
a general operational capability (e.g., a JISC production service), not an element of the e-Framework.
NB: the formatted term SERVICES is used to denote general capabilities, not service elements of the e-Framework.
service: [CONTENT]
a resource characterised by the functionality (performance of tasks) it provides. To be used, a service must be
implemented. A definition of function and scope is specified through statements of behaviour and data
representation. A service is a type of resource. [WS Arch]
NB: the narrow technical terms used in the e-Framework should not be confused with the broader contextual terms of
“service” or SERVICE.
REC: avoid the use of “service”. Do not use as a definition of an element of the e-Framework to describe capabilities. Use
specific terms, e.g., service genre, service expression.
REC: when used, service is an adjective for other nouns, or as a type of service classification.
shared service: [CONTEXT]
no definition provided.
NB: types of service are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
service artifact: [CONTEXT]
see service instance.
REC: do not use. Use service instance.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
33
service description: [CORE]
an informal narrative and graphical description of a service genre or a service expression presented in a
normative format. It documents all aspects and characteristics of the service genre or service expression.
NB: the service description is informal, human readable. The service definition is formal, machine processible.
NB: description is also applied to other elements, e.g., service pattern, reference model.
REC: use the qualified terms: service genre description, service expression description, reference model description, service
pattern description.
service definition: [CORE]
a machine-processible definition or specification of the interface to a service expression and the semantics of the
service expression. It defines the message formats, datatypes, transport protocols, and transport serialisation
formats that should be used between the requester service implementation and the provider service
implementation. Formats, datatypes, protocols, etc., should be based on defined standards and specifications.
The service definition represents an agreement governing the mechanics of interacting with the service
expression. [WS Arch]
REC: use the qualified term service expression definition.
service expression: [CORE]
a specific set of functionality and behaviours described in terms on interfaces, messages, standards and
technologies. A specialisation of a single service genre by specification of exact interfaces and standards used.
NB: different choices of interfaces, standards or technologies for a single service genre yield different service expressions.
service genre: [CORE]
a generic or abstract capability expressed in terms of behaviours in support of a process. Related classes of
behaviour. The overall concept of a service without regard to how it is converted into an operational capability.
A service genre is independent of specific interfaces, technologies and standards.
service implementation: [CORE]
operational code providing the complete functionality specified in a service expression definition. A component
of the computational infrastructure that implements the functionality defined by a service expression. A
computational resource. [WS Arch]
service implementation design (specification): [CONTEXT]
software specification used to guide development and programming of a service implementation, derived from a
service expression description. The design is created by selecting and specialising elements from the service
expression description, combined with design choices and the addition of constraints imposed by a particular
community or from the technologies that will be used to implement and develop the service implementation.
NB: multiple different designs can be derived from the same service expression description, but all will have the same
behaviour, interfaces and functionality. Differences will be internal to the service implementation and not exposed.
service instance: [CORE]
a deployed, operating service implementation. Code bound to an identified network end point (e.g., a network
address). The service implementation may also be bound to specific resources.
NB: the same service implementation may be deployed multiple times.
service pattern: [CORE]
description of the key aspects of a common design for an operation, behaviour or communication used in
creating a reusable service-oriented design. Patterns are identified from examples, not created. [GoF]
NB: Patterns may be composed of service genres XOR service expressions.
NB: distinct from architectural, application, domain, design, business process, enterprise, organisation, or user interface
patterns.
NB: the definition is a transliteration of the definition for design patterns, replacing object-oriented terminology with serviceoriented terminology.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
34
service toolkit: [CORE]
a reusable collection of service implementations designed to be used in any application or with any reference
model. [GoF]
NB: a service toolkit is typically distributed with auxiliary software (sample applications, data).
NB: the JISC-specific definition “a service-oriented interface (adapter, façade, proxy) for a legacy application” conflicts with
the use of toolkit in object-oriented software and other areas.
shared service: [CONTEXT]
no definition provided.
NB: shared service is a specific JISC term.
NB: types of service are indicated through service classifications.
REC: do not use. Use appropriate service classifications in the service description.
soa (service-oriented approach): [CORE]
a software design methodology using networks of loosely-coupled, communicating services. [WS Arch]
SOA (Service-Oriented Architecture): [CONTEXT]
software architecture for a service-oriented approach implemented using a particular technology, e.g., CORBA,
web services. SOAs enable domain-oriented operations through message exchange within a network of services.
Services and messages have platform-independent formal definitions, based on open standards. They define
standard interfaces and protocols to encapsulate information tools as services that clients can access without
knowledge or control of their inner workings. [WS Arch, Foster]
NB: soa is a generic concept. SOA is that concept implemented using a particular technology, typically web services.
state: [CONTEXT]
the representation of a resource (attributes, values, properties) at some point in time. [WS Gloss]
state model: [CONTEXT]
an idealised model of the real world represented through resources, each of which has state.
toolkit: [CONTEXT]
see service toolkit.
NB: in object-oriented software, a toolkit is “a set of related and reusable classes designed to provide useful, general purpose
functionality”. [GoF]
REC: use the qualified term. The unqualified term is for contextual use only.
web service: [CONTEXT]
“a software system designed to support interoperable machine-to-machine interaction over a network. It has an
interface described in a machine-processible format (specifically WSDL). Other systems interact with the web
service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an
XML serialisation in conjunction with other Web-related standards.” [WS Arch, WS Gloss]
web service definition: [CONTEXT]
a service definition for a web service. A WSDL document. [WS Arch]
workflow: [CONTEXT]
the paths through a networked structure of tasks and activities. The steps in a business process.
Simplified Semantic Model of the e-Framework
A diagrammatic representation of the relationships between the elements of the e-Framework: frameworks,
reference models, service genres, service expressions, service implementations, service toolkits, applications,
etc. The semantic model is inspired by those used to define the Web Services Architecture [WS Arch].
REC: while a formal semantic model (e.g., an OWL representation) could be developed, this is premature and should be
deferred until there is feedback and consensus that the model is correct.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
35
The diagrams below are placeholders and need to be generalised from [WS Arch] and the [SOA RM] to just soa and
the e-Framework.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
36
Issues
This section outlines a set of issues identified during the development of this document and provides preliminary
recommendations for their resolution.
NB: the order of presentation is not significant.
NB: the list of issues in incomplete.
NB: issues that have been discussed or resolved in whole or part have not been eliminated from the list.
Terminology:
What is the final resolution for terminology and definitions? Will any terms be changed? Are additional terms
needed?
NB: the document is structured so that core terms are placeholder text and the actual terms used can be substituted
automatically.
REC: circulate and discuss among the key stakeholders (e-Framework Operations Group, the e-Framework Development
and Maintenance Group, and the JISC e-Framework Working Group) and finalise terminology and definitions before public
circulation of the document or production of derivative works.
Service Classification:
To minimise the number of elements and layers of descriptions, service classifications are used to characterise all
core elements of the e-Framework (reference model, service genre, service expression and service pattern
descriptions). A set of formal service classifications to be used in the descriptions is needed. The same service
classification scheme is proposed for use with all elements, i.e., there is not a separate service pattern
classification scheme. Significant examples may not exist to develop a complete service classification scheme at
this time.
REC: develop a service classification scheme by examining actual descriptions.
REC: while a complex structured classification scheme could be developed, start with a simple flat list of classification
facets and defined values. While a simple flat list is less descriptive, it is easier and less costly to develop and maintain.
Simple classifications should be sufficient for service discovery.
REC: review the service classification scheme to determine if classification facets should be developed or specialised for
different elements.
Conformance:
Is conformance measured for any elements of the e-Framework? If so, how? Are the e-Framework descriptions
or processes normative?
REC: defer any consideration of conformance or making the descriptions and processes normative.
Open Standards and Specifications:
While the focus of the e-Framework is open standards, this document does not identify either domain-specific
open standards used within the domains of the e-Framework or underlying technology standards used in
documenting service descriptions or in developing service implementations or applications. Should there be an
identified set of (recommended) standards?
REC: identifying standards should be deferred to actual reference model, service genre, service expression or service pattern
descriptions. Consider maintaining a list of standards and usage recommendations for developers. Service implementation
designs and application designs will need to refer to appropriate standards.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
37
Registries:
Will there be a registry of reference model, service genre, service expression and service pattern descriptions,
service toolkits, service implementations, etc.?
REC: develop a simple registry for the core descriptive elements of the e-Framework (reference model, service genre, service
expression and service pattern descriptions). Develop separate registries for service implementations, service toolkits and
machine-processible elements used to implement applications.
Service versus SERVICES:
Current background documents [e-Framework, e-Framework Overview] focus on the concept of a service.
There may be confusion over service as a technical element of the e-Framework and the broader provisioning of
SERVICES to the community, independent of how these are implemented or deployed. Terminology such as
user services (tool, application, portal) may not be sufficient to explain how the service implementations are
deployed to develop systems and applications. The distinction between service as a concept (service genre,
service expression) and service implementation as its implementation may further confuse the e-Framework
stakeholders.
REC: provide additional overview documents presenting how the e-Framework is used in building ICT systems for learning,
teaching, research, etc.
REC: avoid the unqualified use of service in the formal documentation.
REC: use service only as an adjective to another noun.
Application Design:
The e-Framework is a service-oriented approach. It does not describe or dictate a particular approach to building
applications from service implementations, e.g., use or type of middleware. Is the collection of reference model,
service genre, service expression and service pattern descriptions sufficient to build interoperable applications
and systems? Can such decisions be deferred to application designers and developers?
REC: discuss among the key stakeholders the scope of the e-Framework and what additional information needs to be
provided to application developers and what is needed to manage application deployment.
Implementation Guidance:
Will the e-Framework include implementation guidance (to aid in interoperability) for designing web services
and XML-based document formats?
REC: provide recommendations on designing web services and XML-based document formats.
Formal Description Formats:
Should the formal description of a core element of the e-Framework (reference model, service genre, service
expression, service pattern) be specified in a formal way, i.e., should there be a formal description format for
these elements of the e-Framework?
REC: consider developing an XML document format (e.g., an XSD) for use in describing the elements of the e-Framework.
Reference Model Description Format:
Is the reference model description format sufficiently detailed and precise? Are all critical items included? Is
there sufficient guidance to develop consistent descriptions?
REC: attempt to describe several existing (ELF) reference models in the proposed format. Have independent individuals or
teams develop the reference model descriptions. Refine the description format based on results of this process.
Other Modelling Approaches:
Should the descriptions, formats, etc., be refined based on considerations from other modelling approaches, e.g.,
the Rational Unified Process (RUP), OMG’s Model Driven Architecture (MDA), or the OASIS Business Process
Modelling (BPM)?
REC: defer any consideration of other approaches until there is sufficient feedback and consensus to the overall approach
outlined herein.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
38
Prescriptive Development Methodologies:
How prescriptive should the e-Framework be in terms of describing a methodology or process for designing
(identify, create, document) service genres, service expressions, service patterns and reference models? This
document prescribes the description and document format for each, but not the process used to create same.
REC: this document and the e-Framework are descriptive and definitional (it is “what”). The document does not define
“how” to apply any of the definitions or descriptions within an overall development and deployment process. The
e-Framework should not be prescriptive in processes, only in documents. Methods defined herein are offered as guidance.
REC: best practices of how to use the e-Framework should be gathered and documented to provide additional guidance on
its use.
What is a Resource:
The term resource denotes a generic concept. It is not the same as the concept of an information asset within the
information or library community, or the concept of a resource wrapped by a web service from the grid
community. In the e-Framework, access to resources is defined through service genres, service expressions and
controlled and managed by service implementations.
REC: in supporting material, provide a clear presentation of how resources are modelled and used in the e-Framework.
Domain Complexity:
The e-Framework formally covers a fixed set of major domains. The concepts can be applied to smaller problem
areas. The elements of the e-Framework can be applied independently of granularity or size of domain.
Reference models can be at the domain or subdomain level.
REC: in supporting material, provide a clear presentation of the applicability of the elements of the e-Framework to domains
of different sizes and complexities.
Annotated Bibliography
[Alexander] Alexander, C., et al., A Pattern Language: Towns, Buildings, Construction, Oxford University Press,
1977, ISBN: 0195019199
The source of “pattern” in software engineering.
[e-Biz Patterns] Adams, J., Koushik, S., Vasudeva, G., Galambos, G., Patterns for e-business: A Strategy for Reuse,
IBM Press, 2001, ISBN: 1931180027
[e-Framework] The e-Framework for Education and Research
http://www.e-framework.org/
The e-Framework web site.
[e-Framework Overview] Olivier, B., Roberts, T., Blinco, K., The e-Framework for Education and Research:
An Overview, Version R1, July 2005
http://www.e-framework.org/resources/eframeworkrV1.pdf
[FRBR] Functional Requirements for Bibliographic Records, International Federation of Library Associations and
Institutions, 1998, ISBN: 359811382X
http://www.ifla.org/VII/s13/frbr/frbr.pdf
Presentation of the FRBR model.
[Foster] Foster, I., “Service-Oriented Science” Science 6 May 2005
Vol. 308, no. 5723, pp. 814 – 817, DOI: 10.1126/science.1110411
A general discussion of how to build a “soa” information architecture for e-science. The discussion focuses on going from
manual processes to automated ones. Critical problems to address are: interoperability (services and data), scale,
management (including sustainment), QC (for data, metadata [including provenance], services), and the separation of
concerns (domain-specific services, domain-independent services [management, registries, orchestration] and physical
infrastructure).
[GoF] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented
Software, Addison-Wesley, 1995, ISBN: 0201633612
The classic book on design patterns. It introduces the notation used to describe design patterns and includes a catalogue of
patterns. The focus is on object-oriented software.
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
39
[HLA] IEEE Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) — Framework and
Rules, IEEE Std 1516-2000, The Institute of Electrical and Electronics Engineers, Inc., 21 September 2000, ISBN:
0-7381-2620-9
HLA defines a model of interacting simulation service implementations (federates) that operate within an overall simulation
environment with a corresponding management and communications infrastructure (federation). Rules for federates and
federations have applicability to services and applications.
[Marca] Marca, D., Open Process Frameworks: Patterns for the Adaptive e-Enterprise, Wiley-IEEE Computer
Society Press, 18 August 2005, ISBN: 0471736112
Describes a process that can be used to map business requirements and workflows to a net-centric model.
[OED] Oxford English Dictionary, Oxford University Press, 2005
http://dictionary.oed.com/
General definitions.
[OPF] Open Process Framework
http://www.opfro.org/
OPF is a framework for defining software development; an alternative to the Rational Unified Process (RUP). The site
contain an interesting glossary of terms, focusing on software modelling (in the OO sense) and a descriptive template for
describing components and processes similar to the format used to describe design patterns.
[RFC 2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997
http://ietf.org/rfc/rfc2119.txt
Definitions of normative terms used such as SHALL, SHALL NOT, etc.
[Ref Arch] Gallagher, B., Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A
Case Study, Technical Report, CMU/SEI-2000-TN-007, June 2000
http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.html
Contains working definitions of architecture, reference architecture and presents an overview of a case study of how they are
used in software engineering.
[SOA Blueprint] SOA Blueprints, OASIS Draft, 19 December 2005
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-blueprints
Presents a model for using patterns (reference models in e-Framework terms) to define systems based on service-oriented
architectures.
TODO: incorporate definitions, etc., into the rest of the document.
[SOA RM] MacKenzie, C. M., et al., Reference Model for Service-Oriented Architectures, OASIS Working Draft
11, 15 December 2005
http://www.oasis-open.org/committees/download.php/15966/wd-soa-rm-11.pdf
OASIS’s model of a set of concepts and their relationships to enable designers and developers to understand and describe
service-oriented systems.
TODO: incorporate definitions, etc., into the rest of the document
[WS Arch] Booth, D., et al., Eds., Web Services Architecture, W3C Working Group Note, 11 February 2004
http://www.w3.org/TR/ws-arch/
W3C’s conceptual model of web services and their role within a larger SOA. It includes a set of definitions of components
and conceptual models of the relationships among these components. Many of the core concepts are independent of a web
orientation and can be applied to more general service-oriented architectures.
[WS Gloss] Hass, H., Brown, A., Web Services Glossary, W3C Working Group Note, 11 February 2004
http://www.w3.org/TR/ws-gloss/
A concise set of definitions used by W3C in describing their Web Services Architecture [WS Arch].
[WS OWL] Paolucci, M., Srinivasan, N., Sycara, K., OWL Ontology of Web Services Architecture Concepts
http://www.w3.org/2004/02/wsa/
Formal OWL ontologies of the W3C Web Services Architecture [WS Arch].
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
40
[WWW Arch] Jacobs, I., Walsh, N., Architecture of the World Wide Web, Volume One, W3C Recommendation, 15
December 2004
http://www.w3c.org/TR/webarch/
A summary of the core components and key constraints, principles and design choices underlying the web. The principles
and practices can be applied in designing services.
Change Log
Version
0.5
0.6
0.7
Release Date
2006-01-12
2006-01-16
2006-02-06
Comment
First partial release for internal review by RM group.
First complete release for internal review by RM group.
Document reordered, terminology changed.
The document uses Word autotext field codes for all core terms. The field code names and their values are defined
below. Changing the autotext value (change the text value, select it, insert/autotext/new, enter the tag name) and
performing a document update (Alt-a, F9) will change the text throughout the document. Setting
tools/options/views/field codes:always will shade in gray all autotext in the document.
NB: codes are not case sensitive.
NB: individual codes and values must be defined for each case of the value in the document.
NB: values in the list below are not field codes.
Code
Value
ef-rm
ef-rmic
ef-rmac
ef-sg
ef-sgic
ef-sgac
ef-sx
ef-sxic
ef-sxac
ef-si
ef-siic
ef-siac
ef-sn
ef-sp
ef-spic
ef-spac
ef-st
ef-sclass
ef-sclassic
ef-sclassac
ef-mm
ef-mmic
ef-dom
ef-domic Domain
ef-bs
ef-bss
ef-bigs
ef-bigss
ef-app
ef-appic
ef-des
ef-desic
ef-def
ef-defic
ef-res
ef-resic
reference model
Reference model
Reference Model
service genre
Service genre
Service Genre
service expression
Service expression
Service Expression
service implementation
Service implementation
Service Implementation
service instance
service pattern
Service pattern
Service Pattern
service toolkit
service classification
Service classification
Service Classification
metamodel
Metamodel
domain
SERVICE
SERVICES
service
Service
application
Application
description
Description
definition
Definition
resource
Resource
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
41
Additional Diagrams for Inclusion / Adaptation
[SOA Blueprint]
[SOA Blueprint]
e-Framework Definitions and Terminology
V0.7 2016-05-31 02:38:46 AM
42