Unit iv function and service oriented designs 9

UNIT IV FUNCTION AND SERVICE ORIENTED DESIGNS 9
Structural decomposition – Detailed Design – Function oriented design Case study – Services –
Service identification – Service design – Service composition – choreography and orchestration
– Service oriented design Case study
182
Objectives
• To explain how a software design may be represented as a set of functions which share system
state information.
• To introduce notations which may be used to represent a function oriented design.
• To develop an example which illustrates the process of function oriented design.
• To compare, using a common example, sequential and concurrent function-oriented design and
object-oriented design.
Contents
 Data-flow design
 Structural decomposition
 Detailed design
 A comparison of design strategies
INTRODUCTION
A function-oriented design strategy relies on decomposing the system into a set of
interacting functions with a centralised system state shared by these functions (Figure 15.1).
Functions may also maintain local state information but only for the duration of their execution.
Function-oriented design has been practised informally since programming began. Programs
were decomposed into subroutines which were functional in nature. In the late 1960s and early
1970s several books were published which described ‘top-down’ functional design. They
specifically proposed this as a ‘structured’ design strategy (Myers, 1975; Wirth, 1976;
Constantine and Yourdon, 1979). These led to the development of many design methods based
on functional decomposition.
Function-oriented design conceals the details of an algorithm in a function but system
state information is not hidden. This can cause problems because a function can change the state
in a way which other functions do not expect. Changes to a function and the way in which it uses
the system state may cause unanticipated changes in the behaviour of other functions.
A functional approach to design is therefore most likely to be successful when the
amount of system state information is minimised and information sharing is explicit. Systems
whose responses depend on a single stimulus or input and which are not affected by input
histories are naturally functionally-oriented. Many transaction-processing systems and business
data-processing systems fall into this class. In essence, they are concerned with record
processing where the processing of one record is not dependent on any previous processing.

183
An example of such a transaction
processing system is the software which
controls automatic teller machines (ATMs)
which are now installed outside many
banks. The service provided to a user is
independent of previous services provided
so can be thought of as a single transaction.
Figure 15.2 illustrates a simplified
functional design of such a system. Notice
that this design follows the centralized
management control model introduced in
Chapter 13.
In this design, the system is implemented as a continuous loop and actions are triggered
when a card is input. Functions such as Dispense_cash, Get_account_number, Order_statement,
Order_checkbook, etc. can be identified which implement system actions. The system state
maintained by the program is minimal. The user services operate independently and do not
interact with each other. An object-oriented design would be similar to this and would probably
not be significantly more maintainable.
As object-oriented design has become more widely used, some people have suggested that
function-oriented design is obsolete. It should be superseded by an object-oriented approach.
There are several good reasons why this should not and will not happen:
1. As discussed above, there are classes of system, particularly business systems, where object-oriented
design does not offer significant advantages in terms of system maintainability or
reliability. In these cases, an objectoriented approach may result in a less efficient system
implementation.
2. Many organisations have developed standards and methods based on functional
decomposition. They are understandably reluctant to discard these in favour of object-oriented
design. Many design methods and associated CASE tools are functionally oriented. A large
capital and training investmentin these systems has been made.
3. An enormous number of systems have been developed using a functional approach. These
legacy systems will have to be maintained for the foreseeable future. Unless they are radically re-engineered,
their design structure will remain functional. It is not sensible to view the function-oriented
and object-oriented approaches as competing design strategies. Rather, they are
applicable in different circumstances and for different types of application. Good designers
chose the most appropriate strategy for the application that is being developed rather than use a
single approach.

184
loop
loop
Print_input_message (” Welcome - Please enter your card”) ;
exit when Card_input ;
end loop ;
Account_number := Read_card ;
Get_account_details (PIN, Account_balance, Cash_available) ;
if Validate_card (PIN) then
loop
Print_operation_select_message ;
case Get_button is
when Cash_only =>
Dispense_cash (Cash_available, Amount_dispensed) ;
when Print_balance =>
Print_customer_balance (Account_balance) ;
when Statement =>
Order_statement (Account_number) ;
when Check_book =>
Order_checkbook (Account_number) ;
end case ;
Eject_card ;
Print (“Please take your card or press CONTINUE”) ;
exit when Card_removed ;
end loop ;
Update_account_information (Account_number, Amount_dispensed) ;
else
Retain_card ;
end if ;
end loop ;
Figure 15.2 The functional design of software for an ATM
In this chapter, I illustrate a function-oriented design process using a numberof examples.
The activities in that process are:
1. Data-flow design Model the system design using data-flow diagrams. This should show how
data passes through the system and is transformed by each system function. This model may be
derived from data-flow models developed during the analysis process.
2. Structural decomposition Model how functions are decomposed into subfunctions using
graphical structure charts.
3. Detailed design description Describe the entities in the design and their interfaces. These
descriptions may be recorded in a data dictionary. Also describe the control structure of the
design using a program description language (PDL) which includes conditional statements and
looping constructs. As with all design processes, these activities are not carried out in sequence
but are interleaved during the design process.

185
Data-flow design
Data-flow design is concerned with designing a sequence of functional transformations that
convert system inputs into the required outputs. The design is represented as data-flow diagrams.
These diagrams illustrate how data flows through a system and how the output is derived from
the input through a sequence of functional transformations.
Data-flow diagrams are a useful and intuitive way of describing a system. They are
normally understandable without special training, especially if control information is excluded.
They show end-to-end processing. That is, the flow of processing from when data enters the
system to where it leaves the system can be traced.
Data-flow design is an integral part of a number of design methods and most CASE tools
support data-flow diagram creation. Different methods may use different icons to represent data-flow
diagram entities but their meanings are similar. The notation which I use is based on the
following symbols:
1. Rounded rectangles represent functions which transform inputs to outputs. The transformation
name indicates its function.
2. Rectangles represent data stores. Again, they should be given a descriptive name.
3. Circles represent user interactions with the system that provide input or receive output.
4. Arrows show the direction of data flow. Their name describes the data flowing along that path.
5. The keywords ‘and’ and ‘or’. These have their usual meanings as in boolean expressions. They
are used to link data flows when more than one data flow may be input or output from a
transformation. This notation is illustrated in Figure 15.3 which shows a data-flow design of a
design report generator. The
report generator produces a
report which describes all of
the named entities in a data-flow
diagram. The user inputs
the name of the design
represented by the diagram.
The report generator then
finds all the names used in the
data-flow diagram. It looks up
a data dictionary and retrieves
information about each name.
This is then collated into a
report which is output by the
system. Data-flow diagrams
show functional
transformations but do not
suggest how these might be implemented. A system described in this way might be implemented
as a single program using functions or procedures to implement each transformation.
Alternatively, it could be implemented as a number of communicating tasks.

186
STRUCTURAL DECOMPOSITION
As well as a data-flow model of a system, it is also useful to develop a structural system
model. This structural model shows how a function is realised by a number of other functions
which it calls. Structure charts are a graphical way to represent this decomposition hierarchy.
Like data-flow diagrams, they are dynamic rather than static system models. They show how one
function calls others. They do not show the static block structure of a function or procedure.
A function is represented on a structure chart as a rectangle. The hierarchy is displayed by
linking rectangles with lines. Inputs and outputs (which may be implemented either as
parameters or shared variables) are indicated with annotated arrows. An arrow entering a box
implies input, leaving a box implies output. Data stores are shown as rounded rectangles and user
inputs as circles. Converting a data-flow diagram to a structure chart is not a mechanical process.
It requires designer insight and creativity. However, there are several ‘rules of thumb’ which
may be applied to help designers assess if their decomposition is likely to be a reasonable one:
1. Many systems, particularly business systems for which functional design is most appropriate,
can be considered as three-stage systems. These are input some data, perhaps with validation and
checking, process the data then output the data, perhaps in the form of a report or perhaps to
some other file. A master file may also be updated. The first-level structure chart may therefore
have 3 or 4 functions corresponding to input, process, master-file update and output. Figure 15.4
illustrates this structure although, in this case, there is no master file processing.
2. If data validation is required, functions to implement these should be subordinate to an input
function. Output formatting, printing and writing to disk or tape should be subordinate to an
output function.
3. The role of functions near the top of the structural hierarchy may be to control and coordinate
a set of lower-level functions.
4. The objective of the design process is to have loosely coupled, highly cohesive components
(cohesion and coupling were discussed in Chapter 10). Functions should therefore do one thing
and one thing only.
5. Each node in the structure chart should have between two and seven subordinates. If there is
only a single subordinate, this implies that the unit represented by that node may have a low
degree of cohesion. The component may not be single function. A single subordinate means that
another function has been factored out. If a node has too many subordinates, this may mean that
the design has been developed to too low a level at that stage. Three process steps, which follow
these guidelines, can be identified for the transformation process from data-flow diagram to
structure chart:
1. Identify system processing transformations These are the transformations in the diagram
which are responsible for central processing functions. They are not concerned with any input or
output functions such as reading or writing data, data validation or filtering or output formatting.
Group these transformations under a single function at the first-level in the structure chart.

187
Figure 15.4 Initial structure chart for the design report generator
2. Identify input transformations These are concerned with reading data, checking it, removing
duplicates, etc. These should also be grouped under a single function at the first-level in the
structure chart.
3. Identify output transformations These are transformations which prepare and format output or
write it to the user’s screen or other device. However, there are several ‘rules of thumb’ that can
be applied to help designers in this process.
In the design report generator data-flow diagram (Figure 15.3), the processing functions are
those which sort the input, look up the data dictionary and sort the information retrieved from the
data dictionary. In the structure chart (Figure 15.4) these are collected together into a single
function called Collate entities. This initial structure chart can be decomposed to show
subordinate functions which also reflect transformations in the data-flow diagram (Figure 15.5).

188
Figure : Second-level structure chart for the design report generator
The input transformations stop at the function Sort entity names. In this case they are simply
concerned with reading information. No data checking is required. They are represented as a
function called Get design entity names. The output transformations are concerned with
producing reports for link and node type, report integration and printing. These are all concerned
with the formatting and organisation of design entity descriptions. These are grouped under the
function Generate report.
Figure 15.6 Final structure chart for the design report generator

All the principal routines in the design report generator have now been identified. It only
remains to add a final level of more detailed routines and to show how the system data stores are
accessed. The final structure chart is shown in Figure 15.6. This chart does not show the access
functions to the data dictionary and the design database. I assume that these data stores are like
abstract data types and have their own access functions.
Other components may be included in a structure chart which are not directly concerned
with data transformation. Because they do not transform data, they do not appear on the data-flow
diagram. For example, components which are concerned with logging-in and logging-out a
user, system initialisation and any other components concerned with system control rather than
data processing may be included at the structural decomposition level.
189
DETAILED DESIGN DESCRIPTION
At this stage in the design process, the designer should know the organisation of the
design and what each function should do. Design entity description is concerned with producing
a short design specification (sometimes called a minispec) of each function. This requires
describing the function, its inputs and its outputs.
Making this information explicit usually reveals flaws in the initial decomposition or
functions which have been
omitted. The data-flow
diagrams and structure charts
must be re-visited and
modified to incorporate the
improved understanding of
the design.
The best way to
manage these functional
descriptions is to maintain
them in a data dictionary.
Data dictionaries were
introduced in Chapter 6 as a
way of recording
information in system
models developed as part of
the requirements analysis
process. They can also be used to record information about design entities. Maintaining names
and descriptions in a data dictionary reduces the chances of mistakenly reusing names and
provides design readers with insights into the designer’s thinking. Data dictionary entries can
vary in detail from a short informal description to a specification of the function in a design
description language. Figure 15.7 shows
some of the data dictionary entries that might be made for the design report generator. As you
can see, it includes information about data as well as the functions in the system. Some CASE
tools may include facilities which allow data dictionaries to be accessed at the same time as a
design diagram. This allows information about individual entities to be viewed at the same time

190
as the diagram showing all
entities and their
relationships. The tool may
allow a design entity to be
selected then display the
corresponding information
from the data dictionary.
Figure 15.8 is an example
of this facility. It shows a
pop-up window which
includes a form describing
the selected transform in the
data-flow diagram.
The next stage of the
functional design process is
to produce detailed designs
for each part of the design.
These detailed designs should include control information and more precise information about
the data structures manipulated.
Figure 15.8 Information about design entities from a data dictionary
.
Figure 15.9 TheOIRS user interface
These detailed designs may be expressed using some program description language, in
some more detailed graphical notation or directly in a programming language. I have already
shown examples of how a PDL may be used to describe a design in Figure 15.2. Further
examples are shown in Figures 15.11, 15.14 and 15.16.

191
A comparison of design strategies
In Chapter 14, I introduced an example of an office information system. This was used to
illustrate object identification using a grammatical analysis of a system description. In this
section, this example will be expanded and used to compare functional and object-oriented
approaches to design. I will also show how a design can be developed for the same system using
concurrent processes.
The Office Information Retrieval System (OIRS) is an office system which can file
documents in one or more indexes, retrieve documents, display and maintain document indexes,
archive documents and delete documents. Users request operations from a menu-based interface
and the system always returns a message to the user indicating the success or failure of the
request.
The interface to this system is a form which has a number of fields (Figure 15.9). Some of
these fields are menu fields where the user can choose a particular option. Other fields allow user
textual input. Menu items may be selected by pointing with a mouse or by moving a cursor using
keyboard commands. The fields displayed in the form are as follows:
1. The operation field Selecting this field causes a menu of allowed operations to be displayed as
shown in Figure 15.9.
2. The known indexes field Selecting this field causes a menu of existing index names to be
displayed. Selecting an item from this list adds it to the current index list.
3. The current indexes field Selecting this field displays a list of the indexes where the current
document is to be indexed.
4. The document name field This specifies the name of the document to be filed or the name of
the document to be retrieved. If this name is not filled in, the user is prompted for a value.
5. The qualifier field This is a pattern which is used in searching. For example, the pattern ‘A-K’
may be specified with a command to look up the names of documents in the current index lists.
The qualifier causes only those names which begin with a letter from A to K to be listed.
Alternatively, the qualifier field might contain a keyword such as ‘Software Engineering’. An
index search retrieves all documents which contain this keyword.
6. The current workspace Documents are retrieved to the current workspace that may contain
several documents. The user may choose a document in the workspace by selecting its name
from the workspace menu. Clicking on the Clear button in the workspace control bar removes
the selection from the workspace. Moving the cursor into the workspace causes the system to
enter document edit mode.

192
Figure 15.10 Inputs and outputs of the OIRS
When developing a functional design, the initial stage should treat the system as a black
box. It should simply show the inputs and outputs of the system with the system itself
represented as a single transformation (Figure 15.10). The arc annotated with ‘or’ joining the
output data flows means that one or the other but not both of these data flows occur. Notice that
the document database and the current workspace are both inputs and outputs. Functional designs
of interactive systems often follow a common detailed architectural model . This is a command
‘fetch and execute’ loop. Figure 15.11 describes the general form of a fetch-execute loop. The
ATM design, described in Figure 15.2, is an example of this model.
Figure 15.11 Fetch-execute model of an interactive
In this design, the Get command function has been separated from the Execute command
function to allow for different types of user interface and user interface evolution. If the system
is moved from a computer without a mouse to a computer with a mouse (say) only the Get
command function need be changed. It is generally good design practice to separate, as far as
possible, the user interface of a system from the data processing functions. This is discussed in
Chapter 17.

A data-flow diagram for the OIRS based on this model is shown in Figure 15.12. The
central transform is concerned with command execution and further functions are incorporated to
manage the database and the workspace.
193
Figure 15.12 Top-level data-flow design for the OIRS
The Execute Command transformation can now be considered in isolation and can be
decomposed into simpler transformations (Figure 15.13). Figure 15.13 shows that there are three
different classes of command in the OIRS. These are commands to update the workspace (Get
document, Search database, Clear workspace and the implicit Edit command), commands to
update the database (Put document, Delete document) and index commands (Add index, Delete
index, Display index lists).
For brevity, I have skipped the structural decomposition and entity description stages in
the functional design process and have gone straight to detailed design description. Figure 15.14
is a design, expressed in a PDL, for the top-level of the OIRS. As discussed in the previous
section, additional functions have been included for login and initialisation which are not shown
in the data-flow diagram.
Note that the control structure design shown in Figure 15.14 is not a syntactically
correct program. It does not include declarations of the entities which are used. As discussed
above, these names should be entered in a data dictionary along with a description of the entities
which they identify.

194
Figure 15.14 High-level design description of the OIRS
The design process continues by decomposing each of the design components in more
detail. This decomposition should stop when the design has been described at a sufficiently
detailed level that a program can be developed in the chosen implementation language. This
level of detail will obviously vary depending on the language used. The lower level the
implementation language, the more detail is required in the design.
Figure 15.13 Data-flow diagram for Execute command

195
Concurrent systems design
The above functional design models the OIRS as a sequential system with a single
control loop which fetches and executes commands in sequence. An alternative approach to the
detailed design is to implement the system as a number of concurrent process. As data-flow
diagrams explicitly exclude control information, they can also be the starting point for a
concurrent design. A standard implementation technique for real-time systems (see Chapter 16)
is to take a dataflow diagram and to implement each of its transformations as a separate process.
In this case, implementing each data-flow transformation as a separate process would not be an
efficient way of designing the system. There is a scheduling overhead involved in starting and
stopping processes and managing process communications. Unless it is absolutely necessary
because of real-time requirements, it is best to avoid decomposing a system into many small
processes.
However, to improve real-time response in window-based systems, it is often necessary
to identify those parts of the system which must respond to user events and implement these as
separate processes. This allows the system to be responsive to time-critical user events such as
mouse movements. The strict sequence which is forced by a fetch-execute cycle can be avoided.
In the OIRS, there are two situations where user actions cause an event to be generated:
1. When a command is selected. The user moves the cursor into a menu and makes a choice. An
event is generated informing the system that a command has been chosen.
2. When the cursor is moved into the workspace and the user starts to type. The user can move
the cursor between these areas at any time so the system must be able to cope with the change.
This can be handled in a fetch-execute system by making sure that the workspace editor keeps
track of the cursor but some code duplication in such a situation is inevitable. Given that the
input processing (commands and text) is to be implemented using separate processes, it then
makes sense to identify corresponding processes to handle command execution and output
processing. This leads to a set of four processes as shown in Figure 15.15. Control passes from
process to process in response to events such as a cursor being positioned in a workspace, a
command menu being selected, etc.
Figure5.15 Process decomposition of the OIRS

196
Figure 15.16 Detailed process design in Ada
The Get command task tracks the mouse and responds to low-level mouse events. When a
command area is selected, it initiates the command execution process. Similarly, the command
execution process produces status messages which are processed by the output task. Workspace
editing is also implemented as a parallel task. The editor is initiated and suspended as the cursor
is moved in and out of the workspace window.

The detailed design of the overall system and the Get command process is shown, in Ada,
in Figure 15.16. This uses Ada’s facilities (tasks) for implementing parallel systems. Ada task
entries correspond to procedure calls. Therefore, calling an entry Display indexes in Execute
command is like calling a function of that name. Details of Ada tasking can be found in Ada
textbooks (Burns and Wellings, 1990; Barnes, 1994).
197
Object-oriented design
Both the sequential and concurrent designs of the OIRS are functional because the
principal decomposition strategy identifies functions such as Execute command, Update index,
etc. By contrast, an object-oriented design focuses on the entities in the system with the
functions part of these entities. There is not enough space here to develop a complete object-oriented
design but I show the entity decomposition in this section. Notice that this is quite
different from the functional system decomposition.
Figure 15.17 Initial decomposition of the OIRS into classes and objects
We have already seen an initial object identification for the OIRS in Chapter 14. The
objects identified from that description are shown in Figure 15.17. This object decomposition
leaves out entities such as the database, the workspace, etc. The reason for this is that this
decomposition was based on a simple description. This description did not describe all system
facilities. Nor did it describe how these facilities are presented to users. We therefore need to
define further system objects as shown in Figure 15.18.
Documents which are being used are held in a workspace and referenced in indexes. We
therefore need objects which correspond to the workspace and each index. Index list is an object
class used to create different lists of indexes. The document database is also represented as an
object. The initial object decomposition was based on a simple system description. With further
information we now have to revisit this decomposition and see if it is still appropriate. We know
that the user interface is a graphical interface with various fields and buttons so this should be
represented as an object. It can serve as a replacement for the User object so this can now be
discarded and its operations incorporated into Display. As a general design guideline, displays
map onto objects.
Object attributes represent fields on the display. We can see an example of this in Figure
15.19 which should be compared with Figure 15.9 which shows the OIRS display. The Retrieval
system object is also modified to add attributes representing the workspace and the indexes used.
This object does not have any associated operations. The object is an active object which

controls other objects but does not provide services to them. All its functionality is therefore
concealed. The principal objects in the OIRS have now been identified. The next stage of the
design process is to set out object aggregation hierarchies and how these objects interact as
discussed in Section 14.3. In essence, the fetch-execute loop as
198
Figure 15.18 operations> Additional OIRS system objects
Figure 15.19 Modified OIRS objects
discussed above is still part of the design. Commands are fetched from the display object.
Services provided by the workspace, document and index objects are called on to execute these
commands.
Given the limited information here, it is impossible to say which design strategy is the best
one for this system. The functional approach to design using data-flow diagrams is probably a
more intuitive way to describe the overall design. However, the focus on function means that the
reader of the design finds it more difficult to understand the entities which are manipulated by
the system.

The object-oriented approach solves this difficulty as it is very good for entity description.
Because of information encapsulation, object-oriented design generally leads to more robust
systems where system data is less likely to be corrupted in the event of a program error. It may
also be easier to change although this depends on the nature of the change. However, as
Fichman and Kemerer (Fichman and Kemerer, 1992) point out, decomposing a system into
loosely coupled objects often means that there is no overall picture of end-to-end processing in
the design.
Designers must use the most appropriate approach to design. They should not be forced
into the straitjacket of any particular design method or strategy. My own preference in this
instance is to take a heterogeneous approach to the design. The basic functional fetch-execute
loop should be retained and data-flow diagrams used to illustrate and understand the system’s
processing. The display management should be implemented as a separate process. The objects
identified in this section should be used and referenced from the fetch-execute loop.
199
KEY POINTS
 Function-oriented design relies on identifying functions which transform their inputs to
create outputs. In most systems, functions share some global system state.
 Many business systems which process transactions are naturally functional. Furthermore,
there is a huge amount of legacy code which has been designed
using this approach. For these reasons, function-oriented design will continue alongside object-oriented
design as an important design strategy.
• The functional design process involves identifying data transformations in the system,
decomposing functions into a hierarchy of sub-functions, describing the operation and interface
of each system entity and documenting the flow of control in the system.
• Data-flow diagrams are a means of documenting end-to-end data flow through a system. They
do not include control information. Structure charts are a way of representing the hierarchical
organisation of a system. Control may be documented using a program description language
(PDL).
• Data-flow diagrams can be implemented directly as a set of cooperating sequential processes.
Each transform in the data-flow diagram is implemented as a separate process. Alternatively,
they can be realised as a number of procedures in a sequential program.
• Functional design and object-oriented design usually result in totally different system
decompositions. However, the most appropriate design strategy is often a heterogeneous one
where both functional and object-oriented approaches are used.

200
SERVICE ORIENTED DESIGN
Overview
The key to getting the most out of SOA lies within the knowledge of how to create
"truly" service-oriented solution logic. That knowledge has been documented as part of the
service-orientation design paradigm. As with object-orientation, service-orientation represents a
distinct approach to designing solution logic in support of a very specific set of goals.
This site introduces the design principles that comprise the service-orientation design
paradigm and further explores various aspects and effects of applying service-orientation in the
real world. Becoming proficient with the concepts and principles of service-orientation equips
you with an understanding of what is and is not considered "service-oriented" within the world
of solution design. This understanding leads to a clear comprehension of how to shape solution
logic specifically in support of the strategic goals and benefits associated with SOA and service-oriented
computing.
Furthermore, this comprehension provides you with a great deal of clarity when
surveying the current SOA marketplace. It allows you to see past the (sometimes questionable)
"SOA" branding used to market products and professional services, and enables you to assess
which of the available technologies, features, and resources are truly compatible with your
business requirements and with how you plan to position SOA and build service-oriented
solutions within your organization.
The criteria for this type of assessment no
longer is whether something claims to provide
SOA support, but whether its actual features will
help you realize the desired level of service-orientation
within your solution designs. With
such a clear perspective, you may discover that
some of the most suitable products and
technologies for building service-oriented
solutions may not be branded with "SOA" at all.
Services
Service-orientation is a design paradigm comprised of a specific set of design principles.
The application of these principles to the design of solution logic results in service-oriented
solution logic. The most fundamental unit of service-oriented solution logic is the service.
Services exist as physically independent software programs with specific design
characteristics that support the attainment of the strategic goals associated with service-oriented
computing. The following figure introduces the symbols used by this site and the book series to
represent a service from an endpoint perspective.

Figure 1 - The yellow sphere symbol (left) is used to represent a whole service and the chorded
201
circle symbol (right) is used to express a service and its capabilities.
Each service is assigned its own distinct functional context and is comprised of a set of
capabilities related to this context. Those capabilities suitable for invocation by external
consumer programs are commonly expressed via a published service contract (much like a
traditional API).
Figure 2 - The individual description documents that can comprise a service contract for a Web
service.
In the every day world around us services are and have been commonplace for as long as
civilized history has existed. Any person carrying out a distinct task in support of others is
providing a service. Any group of individuals collectively performing a task in support of a
larger task is also demonstrating the delivery of a service.
Figure 1 - Three individuals, each capable of providing a distinct service.

Similarly an organization that carries out tasks associated with its purpose or business, is
also providing a service. As long as the task or function being provided is well defined and can
be relatively isolated from other associated tasks it can be distinctly classified as a service.
Figure 2 - A company that employs these three people can compose their capabilities to carry out
202
its business.
Certain baseline requirements exist to enable a group of individual service providers to
collaborate in order to collectively provide a larger service. The above figure, for example,
displays a group of employees that each provide a service for ABC Delivery. Even though each
individual contributes a distinct service, for the company to function effectively, its staff also
needs to have fundamental, common characteristics, such as availability, reliability, and the
ability to communicate using the same language. With all of this in place, these individuals can
be composed into a productive working team. Establishing these types of baseline requirements
is a key goal of service-orientation.
Services in Business Automation
In the world of SOA and service-orientation the term "service" is not generic. It has
specific connotations that relate to a unique combination of design characteristics. When solution
logic is consistently built as services and when services are consistently designed with these
common characteristics, service-orientation is successfully realized throughout an environment.
For example, one of the primary service design characteristics explored as part of this
study of service-orientation is reusability. A strong emphasis on producing solution logic in the
format of services that are positioned as highly generic and reusable enterprise resources
gradually transitions an organization to a state where more and more of its solution logic
becomes less dependent on and more agnostic to any one purpose or business process.
Repeatedly fostering this characteristic within services eventually results in wide-spread reuse
potential.

Consistently realizing specific design characteristics requires a set of guiding principles.
203
This is what the service-orientation design paradigm is all about.
Services are Collections of Capabilities
When we discuss services, it is important to remember that a single service can provide a
collection of capabilities. They are grouped together because they relate to a functional context
established by the service. The functional context of the service illustrated in the figure below,
for example, is that of "shipment." Therefore, this particular service provides a set of capabilities
associated with the processing of shipments.
Figure 3 - Much like a human, an automated service can provide multiple capabilities.
A service can essentially act as a container of related capabilities. It is comprised of a
body of logic designed to carry out these capabilities and a service contract that expresses which
of its capabilities are made available for public invocation.
Note that when we make reference to service capabilities on this site, we are specifically
focused on those that are defined as part of the service contract. When services are implemented
as components these capabilities are typically referred to as "methods," and when they are
expressed as part of a Web service contract, they are called "operations."
In Chapter 12, I introduced the notion of service-oriented architectures as a means of
facilitating inter-organisational computing. Essentially, service-oriented architectures (SOA) are
a way of developing distributed systems where the components of these systems are stand-alone
services. These services may execute on geographically distributed computers. Standard
protocols have been designed to support service communication and information exchange.
Consequently, services are platform and implementation-language independent. Software
systems can be constructed using services from different providers with seamless interaction
between these services. Figure 31.1 illustrates how web services are used. Service providers
design and implement services and specify these services in a language called WSDL (discussed
later). They also publish information about these services in a generally accessible registry using
a publication standard called UDDI. Service requestors (sometimes called service clients), who
wish to make use of a service, search the UDDI registry to discover the specification of that
service and to locate the service provider. They can then bind their application to that specific
service and communicate with it, usually using a protocol called SOAP.

Service-oriented architecture is now generally recognised as a significant development,
particularly for business application systems. It allows flexibility as services can be provided
locally or outsourced to external providers. Services may be implemented in any programming
language. By wrapping legacy systems (see Chapter 21) as services, companies can preserve
their investment in valuable software and make this available to a wider range of applications.
SOA allows different platforms and implementation technologies that may be used in different
parts of a company to inter-operate. Most importantly, perhaps, building applications based on
services allows companies and other organisations to cooperate and to make use of each other’s
business functions. Thus, systems that involve extensive information exchange across company
boundaries, such as supply chain systems, where one company orders goods from another, can
easily be automated.
204
Figure 31.1 Service-oriented architecture
Perhaps the key reason for the success
of service-oriented architectures is the fact
that, from the outset, there has been an active
standardisation process working alongside
technical developments. All of the major
hardware and software companies are
committed to these standards. As a result,
service-oriented architectures have not
suffered from the incompatibilities that
normally arise with technical innovations,
where different suppliers maintain their
proprietary version of the technology. Hence,
problems, such as the multiple incompatible
component models in CBSE that I discussed
in Chapter 19, have not arisen in service-oriented
system development. Figure 31.2 shows the stack of key standards that have been
established to support web services. In principle, a service-oriented approach may be applied in
situations where other protocols are used; in practice, web services are dominant. Web services

do not depend on any particular transport protocol for information exchange although, in
practice, the HTTP and HTTPS protocols are commonly used. Web service protocols cover all
aspects of service-oriented architectures from the basic mechanisms for service information
exchange (SOAP) to programming language standards (WS-BPEL). These standards are all
based on XML, a human and machine-readable notation that allows the definition of structured
data where text is tagged with a meaningful identifier. XML has a range of supporting
technologies, such as XSD for schema definition, which are used to extend and manipulate XML
descriptions. Erl (Erl, 2004) provides a good summary of XML technologies and their role in
web services.
205
Briefly, the key standards for web service-oriented architectures are:
1. SOAP This is a message interchange standard that supports the communication between
services. It defines the essential and optional components of messages passed between services.
2. WSDL The Web Service Definition Language (WSDL) standard defines the way in which
service providers should define the interface to these services. Essentially, it allows the interface
of a service (the service operations, parameters and their types) and its bindings to be defined in
a standard way.
3. UDDI The UDDI (Universal Description, Discovery and Integration) standard defines the
components of a service specification that may be used to discover the existence of a service.
These include information about the service provider, the services provided, the location of the
service description (usually expressed in WSDL) and information about business relationships.
UDDI registries enable potential users of a service to discover what services are available.
4. WS-BPEL This standard is a standard for a workflow language that is used to define process
programs involving several different services. I discuss the notion of process programs in section
31.3. These principal standards are supported by a range of supporting standards that focus on
more specialised aspects of SOA. There are a very large number of supporting standards because
they are intended to support SOA in different types of application. Some examples of these
standards include:
1. WS-Reliable Messaging is a standard for message exchange that ensures messages will be
delivered once and once only.
2. WS-Security is a set of standards supporting web service security including standards that
specify the definition of security policies and standards that cover the use of digital signatures.
3. WS-Addressing defines how address information should be represented in a SOAP message.
4. WS-Transactions defines how transactions across distributed services should be coordinated.
Web service standards are a huge topic and I do not have space to discuss them in detail here. I
recommend Erl’s books (Erl, 2004; Erl, 2005) for an overview of these standards. Their detailed
descriptions are also available as public documents on the Web.
As I discuss in the following section, a service can be considered simply as a reusable
abstraction and hence this chapter complements Chapters 18 and 19 that discuss issues of
software reuse. There are therefore two themes to the chapter:

1. Service engineering. This concerns the development of dependable, reusable services.
Essentially, the concern is software development for reuse.
2. Software development with services. This concerns the development of dependable software
systems that use services either on their own or in conjunction with other types of component.
Essentially, the concern is software development with reuse. Service-oriented architectures and
service-oriented software engineering are, currently, a ‘hot topic’. There is an enormous amount
of business interest in adopting a service-oriented approach to software development but, at the
time of writing, practical experience with service-oriented system is limited. Hot topics always
generate ambitious visions and often promise more than they finally deliver. For example, in
their book on SOA, Newcomer and Lomow (2005) state:
Driven by the convergence of key technologies and the universal adoption of Web
services, the service-oriented enterprise promises to significantly improve corporate agility,
speed time-to-market for new products and services, reduce IT costs and improve operational
efficiency.
I believe that service-oriented software engineering is as important a development as
object-oriented software engineering. However, the reality is that it will take many years to
realise these benefits and for the vision of SOA to become a reality. Because service-oriented
software development is so new, we do not yet have well established software engineering
methods for this type of system. I therefore focus here on general issues of designing and
implementing services and building systems using service composition.
206
Services as reusable components
In Chapter 19, I introduced component-based software engineering (CBSE) where
software systems are constructed by composing software components that are based on some
standard component model. Services are a natural development of software components where
the component model is, in essence, the set of standards associated with web services. A service
can therefore be defined as:
A loosely coupled, reusable software
component that encapsulates discrete functionality,
which may be distributed and programmatically
accessed. A web service is a service that is accessed
using standard Internet and XML-based protocols.
A critical distinction between a service and a
software component as defined in CBSE is that
services should be independent and loosely coupled.
That is, they should always operate in the same way,
irrespective of their execution environment. Their
interface is a ‘provides’ interface that provides access
to the service functionality.
Services are intended to be independent and
usable in different contexts. Therefore, they do not
have a ‘requires’ interface that, in CBSE, defines the

other system components that must be present. Services may also be distributed over the Internet.
They communicate b y exchanging messages, expressed in XML, and these messages are
distributed using standard Internet transport protocols such as HTTP and TCP/IP. Figure:
synchronization interaction when ordering meal
A service defines what it needs from another service by setting out its requirements in a
message and sending it to that service. The receiving service parses the message, carries out the
computation and, on completion, sends a message to the requesting service. This service then
parses the reply to extract the required information. Unlike software components, services do not
‘call’ methods associated with other services.
To illustrate the difference between communication using method calls and
communication using message passing, consider a situation where you are ordering a meal in a
restaurant. When you have a conversation with the waiter, you are involved in a series of
synchronous interactions that define your order. This is comparable to components interacting in
a software system, where one component calls methods from other components. The waiter
writes down your order along with the order of the other people with you, then passes this
message, which includes details of everything that has been ordered, to the kitchen to prepare the
food. Essentially, the waiter service is passing a message to the kitchen service defining the food
to be prepared.
I have illustrated this in Figure 31.3, which shows the synchronous ordering process, and in
Figure 31.4, which shows a hypothetical XML message, which I hope is self-explanatory, that
defines an order made by the table of three people. The difference is clear—the waiter takes the
order as a series of interactions, with each interaction defining part of the order. However, the
waiter has a single interaction with the kitchen where the message passed defines the complete
order. When you intend to use a web service, you need to know where the service is located (its
URI) and the details of its interface. These are described in a service description expressed in an
XML-based language called WSDL (Web ServiceDescription Language). The WSDL
specification defines three things about a Web service. It defines what the service does, how it
communicates and where to find it:
1. The ‘what’ part of a WSDL document, called an interface, specifies what operations the
service supports, and defines the format of the messages that are sent and received by the
service.
207

208
Figure 31.4 A restaurant order expressed as an XML message
2. The ‘how’ part of a WSDL document, called a binding, maps the abstract interface to a
concrete set of protocols. The binding specifies the technical details of how to communicate with
a Web service.
3. The ‘where’ part of a WSDL document, called (confusingly) a service, describes where to
locate a specific Web service implementation. The WSDL conceptual model (Figure 31.5) shows
all the parts of a service description. Each of these is expressed in XML and may be provided in
separate files. These parts are:
1. An introductory part which, usually, defines the XML namespaces used and which
may include a documentation section providing additional information about the
service.
2. An optional description of the types used in the messages exchanged by the service.
3. A description of the service interface, i.e. the operations that it provides.
4. A description of the input and output messages processed by the service.
Figure 31.5 Organisation of a WSDL specification
5. A description of the binding used by the service, i.e. the messaging protocol that will be used
to send and receive messages. The default is SOAP but other bindings may also be specified. The
binding sets out how the input and output messages associated with the service should be
packaged into a message, and specifies the communication protocols used. The binding may also
specify how supporting information, such as security credentials or transaction identifiers, is
included.
6. An endpoint specification which is the physical location of the service, expressed as a
Uniform Resource Identifier (URI)—the address of a resource that can be accessed over the
Internet. Complete service descriptions, written in XML, are long, detailed and tedious to read.

They usually include definitions of XML namespaces, which are qualifiers for names. A
namespace identifier may precede any identifier used in the XML description. It means that it is
possible to distinguish between identifiers with the same name that have been defined in
different parts of an XML description. I do not want to go into details of namespaces here. To
understand this chapter, you need to know only that names can be prefixed with a namespace
identifier and that the namespace:name pair should be unique. I have included an example of a
complete service description on the book website. However, as this is very long, I focus here on
the description of the abstract interface. This is the part of the WSDL that equates to the
‘provides’ interface of a software component. Figure 31.6 shows details of the interface for a
simple service that, given a date and a place (town and country), returns the maximum and
minimum temperature recorded in that place on that date. These temperatures may be returned in
degrees Celsius or in degrees Fahrenheit, depending on the location where they were recorded.
In Figure 31.6, the first part of the description shows part of the element and type definition
that is used in the service specification. This defines the elements PlaceAndDate, MaxMinTemp
and InDataFault. I have only included the specification of PlaceAndDate, which you can think of
as a record with three fields—town, country and date. A similar approach would be used to
define MaxMinTemp and InDataFault.
209
Figure 31.6 Part of a WSDL description for a web service

The second part of the description shows how the service interface is defined. In this
example, the service weatherInfo has a single operation, although there are no restrictions on the
number of operations that may be defined. The weatherInfo operation has an associated in-out
pattern, meaning that it takes one input message and generates one output message. The WSDL
2.0 specification allows for a number of different message exchange patterns such as in-only, in-out,
out-only, in-optional-out, out-in, etc. The input and output messages, which refer to the
definitions made earlier in the types section, are then defined. The major problem with WSDL is
that the definition of the service interface does not include any information about the semantics
of the service or its non-functional characteristics, such as performance and dependability. It is
simply a description of the service signature and it relies on the user of the service to deduce
what the service actually does and what the different fields in the input and output messages
mean. While meaningful names and service documentation helps here, there is still scope for
misunderstanding and misusing the service.
210
Service engineering
Service engineering is the process of developing services for reuse in service-oriented
applications. It has much in common with component engineering. Service engineers have to
ensure that the service represents a reusable abstraction that could be useful in different systems.
They must design and develop generally useful functionality associated with that abstraction and
must ensure that the service is robust and reliable so that it operates dependably in different
applications. They have to document the service so that it can be discovered by and understood
by potential users.
Figure 31.7 The service engineering process
There are three logical stages in the service engineering process (Figure 31.7). These are:
1. Service candidate identification where you identify possible services that might be
implemented and define the service requirements.
2. Service design where you design the logical and WSDL service interfaces.
3. Service implementation and deployment where you implement and test the service and make it
available for use.

211
SERVICE CANDIDATE IDENTIFICATION
The basic notion of service-oriented computing is that services should support business
processes. As every organisation has a wide range of processes, there are therefore many
possible services that may be implemented. Service candidate identification involves
understanding and analysing the organisation’s business processes to decide which reusable
services are required to support these processes. Erl identifies three fundamental types of service
that may be identified:
1. Utility services These are services that implement some general functionality that may be used
by different business processes. An example of a utility service is a currency conversion service
that can be accessed to compute the conversion of one currency (e.g. dollars) to another (e.g.
euros).
2. Business services These are services that are associated with a specific business function. An
example of a business function in a university would be the registering of students for a course.
3. Coordination or process services These are services that support a more general business
process which usually involves different actors and activities. An example of a coordination
service in a company is an ordering service that allows orders to be placed with suppliers, goods
accepted and payments made.
Figure 31.8 Service classification
Erl also suggests that services can be considered as task-oriented or entityoriented. Task-oriented
services are those associated with some activity whereas entity-oriented services are like
objects—they are associated with some business entity such as, for example, a job application
form. Figure 31.8 suggests some examples of services that are task or entity-oriented. While
services can be utility and business services, coordination services are always task-oriented.
Your goal in service candidate identification should be to identify services that are
logically coherent, independent and reusable. Erl’s classification is helpful in this respect as it
suggests how to discover reusable services by looking at business entities and business activities.
However, just as the processes of object and component identification are difficult, so too is
service candidate identification. You have to think of possible candidates then ask a series of

questions about them to see if they are likely to be useful services. Possible questions that help
you to identify reusable services are:
1. For an entity-oriented service, is the service associated with a single logical entity that is used
in different business processes? What operations are normally performed on that entity that must
be supported?
2. For a task-oriented service, is the task one that is carried out by different people in the
organisation? Will they be willing to accept the inevitable standardisation that occurs when a
single support service is provided?
3. Is the service independent, i.e. to what extent does it rely on the availability of other services?
4. For its operation, does the service have to maintain state? If so, will a database be used for
state maintenance? In general, systems that rely on internal state are less reusable than those
where state can be externally maintained.
5. Could the service be used by clients outside of the organisation? For example, an entity-oriented
212
service associated with a catalogue may be accessed both internally and externally?
6. Are different users of the service likely to have different non-functional requirements? If they
do, then this suggests that more than one version of a service should perhaps be implemented.
The answers to these questions help you select and refine abstractions that can be
implemented as services. However, there is no formulaic way of deciding which are the best
services and so service identification is a skill and experience-based process. The output of the
candidate selection process is a set of identified services and associated requirements for these
services. The functional service requirements should define what the service should do. The non-functional
requirements should define the security, performance and availability requirements of
the service.
Assume that a large company, which sells computer equipment, has arranged special
prices for approved configurations for some customers. To facilitate automated ordering, the
company wishes to produce a catalogue service that will allow customers to select the equipment
that they need. Unlike a consumer catalogue, however, orders are not placed directly, through a
catalogue interface, but are made through the web-based procurement system of each company.
Most companies have their own budgeting and approval procedures for orders and their own
ordering process must be followed when an order is placed. The catalogue service is an example
of an entity-oriented service that supports business operations. The functional catalogue service
requirements are:
1. A specific version of the catalogue shall be provided for each user company. This shall include
the configurations and equipment that may be ordered by employees of the customer company
and the agreed prices for catalogue items.
2. The catalogue shall allow a customer employee to download a version of the catalogue for off-line
browsing.

3. The catalogue shall allow users to compare the specifications and prices of up to six catalogue
items.
213
4. The catalogue shall provide browsing and searching facilities for users.
5. Users of the catalogue shall be able to discover the predicted delivery date for a given number
of specific catalogue items.
6. Users of the catalogue shall be able to place ‘virtual orders’ where the items required will be
reserved for them for 48 hours. Virtual orders must be confirmed by a real order placed by a
procurement system. This must be received within 48 hours of the virtual order.
In addition to these functional requirements, the catalogue has a number of nonfunctional
requirements:
1. Access to the catalogue service shall be restricted to employees of accredited organisations.
2. The prices and configurations offered to one customer shall be confidential and shall not be
available to employees of any other customer.
3. The catalogue shall be available without disruption of service from 0700 GMT to 1100 GMT.
4. The catalogue service shall be able to process up to 10 requests per second peak load.
Notice that there is no non-functional requirement related to the response time of the
catalogue service. This depends on the size of the catalogue and the expected number of
simultaneous users. As this is not a time-critical service, there is no need to specify it at this
stage.
SERVICE INTERFACE DESIGN
Once you have selected candidate services, the next stage in the service engineering
process is to design the service interfaces. This involves defining the operations associated with
the service and their parameters. You also have to think carefully about how the operations and
messages of the service can be designed to minimize the number of message exchanges that must
take place to complete the service request. You have to ensure that as much information as
possible is passed to the service in a message rather than require synchronous service
interactions.
You should also remember that services are stateless and managing a service specific
application state is the responsibility of the service user rather than the service itself. You may
therefore have to pass this state information to and from services in input and output messages.
There are three stages to service interface design:
1. Logical interface design where you identify the operations associated with the service, the
inputs and outputs of these operations and the exceptions associated with these operations.
2. Message design where you design the structure of the messages that are sent and received by
the service.

3. WSDL development where you translate your logical and message design to an abstract
interface description written in WSDL.
The first stage, logical interface design, starts with the service requirements and defines
the operation names and parameters associated with the service. At this stage, you should also
define the exceptions that may arise when a service operation is invoked. Figures 31.9 and 31.10
show the operations that implement the requirements and the inputs, outputs and exceptions for
each of the catalogue operations. At this stage, there is no need for these to be specified in
detail—you add detail at the next stage of the design process. Defining exceptions and how these
can be communicated to service users is particularly important. Service engineers do not know
how their services will be used and it is usually unwise to make assumptions that service users
will have completely understood the service specification.
Input messages may be incorrect so you should define exceptions that report incorrect
inputs to the service client. It is generally good practice in reusable component development to
leave all exception handling to the user of the component—the service developer should not
impose their views on how exceptions should be handled. Once you have established an informal
logical description of what the service should do, the next stage is to define the structure of the
input and output messages and the types used in these messages. XML is an awkward notation to
use at this stage. I think it better to represent the messages as objects and either define them
using the UML or in a programming language, such as Java. They can then be manually or
automatically converted to XML. Figure 31.11 is a UML diagram that shows the structure of the
input and output messages for the getDelivery operation in the catalogue service.
Notice how I have added detail to the description, by annotating the UML diagram with
constraints. These define the length of the strings representing the company and the catalogue
item, specify that the number of items must be greater than zero and that delivery must be after
the current date. The annotations also show which error codes are associated with each possible
fault.
214

The final stage of the service design process is to translate the service interface design
into WSDL. As I discussed in the previous section, a WSDL representation is long and detailed
and hence it is easy to make mistakes at this stage. Most programming environments that support
service-oriented development (e.g. the ECLIPSE environment) include tools that can translate a
logical interface description into its corresponding WSDL representation.
215

216
Service implementation and deployment
Once you have identified candidate services and designed their interfaces, the final stage
of the service engineering process is service implementation. This implementation may involve
programming the services using a standard programming language such as Java or C#. Both of
these languages now include libraries with extensive support for service development.
Alternatively, services may be developed by using existing components or, as I discuss
below, legacy systems. This means that software assets that have already proved to be useful can
be made more widely available. In the case of legacy systems, it may mean that the system
functionality can be accessed by new applications.
New services may also be developed by defining compositions of existing services. I
discuss development by service composition in section 31.3. Once a service has been
implemented, it then has to be tested before it is deployed. This involves examining and
partitioning the service inputs (as discussed in Chapter 23), creating input messages that reflect
these input combinations and then checking that the outputs are expected. You should always try
to generate exceptions during the test to check that the service can cope with invalid inputs.
Various testing tools are now available that allow services to be examined and tested and that
generate tests from a WSDL specification. However, these can only test the conformity of the
service interface to the WSDL. They cannot test that the service’s functional behaviour is as
specified.
Service deployment, the final stage of the process, involves making the service available
for use on a web server. Most server software makes this very simple. You only have to install
the file containing the executable service in a specific directory. It then automatically becomes
available for use. If the service is intended to be publicly available, you then have to to write a
UDDI description so that potential users can discover the service. Erl (2004) provides a useful
summary of UDDI in his book.
There are now a number of public registries for UDDI descriptions and businesses may
also maintain their own private UDDI registries. A UDDI description consists of a number of
different types of information:
1. Details of the business providing the service. This is important for trust reasons. Users of a
service have to be confident that it will not behave maliciously. Information about the service
provider allows users to check a provider’s credentials.
2. An informal description of the functionality provided by the service. This helps potential users
to decide if the service is what they want. However, the functional description is in natural
language, so it is not an unambiguous semantic description of what the service does.
3. Information on where to find the WSDL specification associated with the service.
4. Subscription information that allows users to register for information about updates to the
service.

A potential problem with UDDI specifications is that the functional behavior of the
service is specified informally as a natural language description. As I have discussed in Chapter
6, which covers software requirements, natural language descriptions are easy to read but they
are subject to misinterpretation. To address this problem, there is an active research community
concerned with investigating how the semantics of services may be specified. The most
promising approach to semantic specification is based on ontology-based description where the
specific meaning of terms in a description is specified in an ontology. A language called OWL-S
has been developed for describing web service ontologies (OWL_Services_Coalition, 2003). At
the time of writing, these techniques for semantic service specification are still immature but
they are likely to become more widely used over the next few years.
217
Legacy system services
In Chapter 18, I discussed the possibility of implementing reusable components by
providing a component interface to existing legacy systems. In essence, the functionality of the
legacy systems could be reused. The implementation of the component was simply concerned
with providing a general interface to that system. One of the most important uses of services is to
implement such ‘wrappers’ for legacy systems. These systems can then be accessed over the web
and integrated with other applications.
To illustrate this, imagine that a large company maintains an inventory of its equipment
and an associated maintenance database. This keeps track of what maintenance requests have
been made for different pieces of equipment, what regular maintenance is scheduled, when
maintenance was carried out, how much time was spent on maintenance, etc. This legacy system
was originally used to generate daily job lists for maintenance staff but, over time, new facilities
have been added.
These provide data about how much has been spent on maintenance for each piece of
equipment and information to help to cost maintenance work to be carried out by external
contractors. The system runs as a client–server system with specialpurpose client software
running on a PC.
The company now wishes to provide real time access to this system from portable
terminals used by maintenance staff. They will update the system directly with the time and
resources spent on maintenance and will query the system to find their next maintenance job. In
addition, call centre staff require access to the system to log maintenance requests and to check
their status.
It is practically impossible to enhance the system to support these requirements so the
company decides to provide new applications for maintenance and call centre staff. These
applications rely on the legacy system, which is to be used as a basis for implementing a number
of services. This is illustrated in Figure 31.12, where I have used a UML stereotype to indicate a
service. New applications simply exchange messages with these services to access the legacy
system functionality. Some of the services provided are:
1. A maintenance service This includes operations to retrieve a maintenance job according to its
job number, priority and geographical location and to upload details of maintenance that has

been carried out to the maintenance database. It also supports an operation to allow maintenance
that has started but is incomplete to be suspended.
2. A facilities service This includes operations to add and delete new equipment and to modify
the information associated with equipment in the database.
3. A logging service This includes operations to add a new request for service, delete
maintenance requests and query the status of outstanding requests. The existing legacy system is
not simply represented as a single service. Rather, the services that are developed are coherent
and support a single area of functionality. This reduces their complexity and makes them easier
to understand and reuse in other applications. I do not have space to discuss the details of the
messages that might be exchanged by these services—their design is left as an exercise for the
reader.
218
Software development with services
The development of software using services is based around the idea that you compose
and configure services to create new, composite services. These may be integrated with a web
user interface to create a web application or may be used as components in some other service
composition. The services involved in the composition may be specially developed for the
application, may be business services developed within a company or may be services from
some external provider.
Many companies are now concerned with converting applications that are used within an
enterprise into service-oriented systems. This opens up the possibility of more widespread reuse
within the company. The next stage will be the development of inter-organisational applications
between trusted suppliers. The final realisation of the long-term vision of service-oriented
architectures will rely on the development of a ‘services market’. I think it is unlikely that this
will emerge during the lifetime of this book. At the time of writing, only a relatively small
number of business services that might be included in business applications are publicly
available. Service composition may be used to integrate separate business processes to provide
an integrated process offering more extensive functionality. Say an airline wishes to provide a
complete vacation package for travellers. As well as booking their flights, travellers can also
book hotels in their preferred location, arrange car hire or book a taxi from the airport, browse a

travel guide and make reservations to visit local attractions. To create this application, the airline
composes its own booking services with services offered by a hotel booking agency, car hire and
taxi companies and the reservation services offered by the providers of the local attractions. The
result is a single service that integrates these different services from different providers. You can
think of this process as a sequence of separate steps as shown in Figure 31.13. Information is
passed from one step to the next—for example, the car hire company is informed of the time that
the flight is scheduled to arrive. The sequence of steps is called a workflow—a set of activities
ordered in time, with each activity carrying out some part of the work. You can think of a
workflow as a model of a business process—the steps involved in reaching some goal that is
important for a business. In this case, the business process is the vacation booking service,
offered by the airline.
Workflow is a simple idea and the above scenario of booking a vacation seems to be
straightforward. In reality, service composition is much more complex than this simple model
implies. For example, you have to consider the possibility of service failure and incorporate
mechanisms to handle these failures. You also have to take into account exceptional demands
made by users of the application. For example, say a traveller was disabled and required a
wheelchair to be rented and delivered to the airport.
You must to be able to cope with situations where the workflow has to be changed
because the normal execution of one of the services results in an incompatibility with some other
service execution. For example, say a flight is booked to leave on 1 June and return on 7 June.
The workflow then proceeds to the hotel booking stage. However, the resort is hosting a major
convention until 2 June so no hotel rooms are available. The hotel booking service reports this
lack of availability. This is not a failure: lack of availability is a common situation.
You then have to ‘undo’ the flight booking and pass the information about lack of
availability back to the user. He or she then has to decide whether to change their dates or their
resort. In workflow terminology, a ‘compensating action’ is used to undo actions that have
already been completed.
The process of designing new services by composing existing services is, essentially, a
process of software design with reuse (Figure 31.14). Design with reuse inevitably involves
requirements compromises. The ‘ideal’ requirements for the system have to be modified to
reflect the services that are actually available, whose costs fall within budget and whose quality
of service is acceptable. In Figure 31.14, I have shown six key stages in the process of service
construction by composition:
219

1. Formulate outline workflow In this initial stage of service design, you use the requirements for
the composite service as a basis for creating an ‘ideal’ service design. You should create a fairly
abstract design at this stage with the intention of adding details once you know more about
available services.
2. Discover services During this stage of the process, you search service registries to discover
what services exist, who provides these services and the details of the service provision.
3. Select possible services From the set of possible service candidates that you have discovered,
you then select possible services that can implement workflow activities. Your selection criteria
will obviously include the functionality of the services offered. They may also include the cost of
the services and the quality of service (responsiveness, availability, etc.) offered. You may
decide to choose a number of functionally equivalent services, which could be bound to a
workflow activity depending on details of cost and quality of service.
4. Refine workflow On the basis of information about the services that you have selected, you
then refine the workflow. This involves adding detail to the abstract description and, perhaps,
adding or removing workflow activities. You then may repeat the service discovery and selection
stages. Once a stable set of services has been chosen and the final workflow design established,
you move on to the next stage in the process.
5. Create workflow program During this stage, the abstract workflow design is transformed to an
executable program and the service interface is defined. You can use a conventional
programming language such as Java or C# for service implementation or you can use a more
specialised workflow language such as WS-BPEL. As I discussed in the previous section, the
service interface specification should be written in WSDL. This stage may also involve the
creation of web-based user interfaces to allow the new service to be accessed from a web
browser.
6. Test completed service or application The process of testing the completed, composite service
is more complex than component testing in situations where external services are used. I discuss
testing issues in section 31.3.2. In the remainder of this chapter, I focus on workflow design and
testing. As I discussed in the introduction, a market for services has not yet developed. Although
a number of public UDDI registries are available, these are sparsely populated and the service
descriptions are sometimes vague and incomplete. For these reasons, service discovery is not yet
a major issue. Most services will be discovered within organisations where services can be
discovered using internal registries and informal communications between software engineers.
220

221
Workflow design and implementation
Workflow design involves analysing existing or planned business processes to
understand the different stages of these processes then representing the process being designed in
a workflow design notation. This shows the stages involved in enacting the process and the
information that is passed between the different process stages. However, existing processes may
be informal and dependent on the skills and ability of the people involved—there may be no
‘normal’ way of working. In such cases, you have to use process knowledge to design a
workflow that achieves the same goals as current business processes.
Workflows represent business process models and are usually represented using
a graphical notation such as BPMN (White, 2004) or YAWL (van der Aalst and ter Hofstede,
2005) At the time of writing, the process modelling language which seems most likely to emerge
as a standard is BPMN. This is a graphical language which is reasonably easy to understand.
Mappings have been defined to translate the language to lower-level, XML-based descriptions in
WS-BPEL. BPMN is therefore conformant with the stack of web service standards that I showed
in Figure 31.2. I use BPMN here to illustrate the notion of business process programming. Figure
31.15 is an example of a simple BPMN model of part of the above vacation package scenario.
The model shows a simplified workflow for hotel booking and assumes the existence of a Hotels
service with associated operations called GetRequirements, CheckAvailability, ReserveRooms,
NoAvailability, ConfirmReservation and CancelReservation. The process involves getting
requirements from the customer, checking room availability then, if rooms are available, making
a booking for the required dates. This model introduces some of the core concepts of BPMN that
are used to create workflow models:
1. Activities are represented by a rectangle with rounded corners. An activity can be executed by
a human or by an automated service.
2. Events are represented by circles. An event is something that happens during a business
process. A simple circle is used to represent a starting event and a darker circle to represent a end
event. A double circle (not shown) is used to represent an intermediate event. Events can be
clock events, thus allowing workflows to be executed periodically or timed out.
3. A diamond is used to represent a gateway. A gateway is a stage in the process where some
choice is made. For example, in Figure 31.15, there is a choice made on the basis of whether
rooms are available or not.
4. A solid arrow is used to show the sequence of activities; a dashed arrow represents message
flow between activities—in Figure 31.15, these messages are passed between the hotel booking
service and the customer. These key features are enough to describe the essence of most
workflows. However, BPMN includes many additional features that I do not have space to
describe here. These add information to a business process description that allows it to be
automatically translated into an executable form. Therefore, web services, based on service
compositions described in BPMN can be created from a business process model. Figure 31.15
shows the process that is enacted in one organisation, the company that provides a booking
service. However, the key benefit of a service-oriented approach is that it supports inter-

organisational computing. This means that the total computation involves services in different
companies. This is represented in BPMN by developing separate workflows for each of the
organisations involved with interactions between them. To illustrate this, I use a different
example, drawn from grid computing. A serviceoriented approach has been proposed to allow
resources such as high-performance computers to be shared. In this example, assume that a
vector processing computer (a machine that can carry out parallel computations on arrays of
values) is offered as a service (VectorProcService) by a research laboratory. This is accessed
through another service called SetupComputation. These services and their interactions are
shown in Figure 31.16. In this example, the workflow for the SetupComputation service requests
access to a vector processor and, if a processor is available, establishes the computation required
and downloads data to the processing service. Once the computation is complete, the results are
stored on the local computer. The workflow for VectorProcService checks if a processor is
available, allocates resources for the computation, initialises the system, carries out the
computation and returns the results to the client service.
In BPMN terms, the workflow for each organisation is represented in a separate
pool. It is shown graphically by enclosing the workflow for each participant in the process in a
rectangle, with the name written vertically on the left edge. The workflows defined in each pool
are coordinated by exchanging messages; sequence flow between the activities in different pools
is not allowed. In situations where different parts of an organisation are involved in a workflow,
this can be shown by separating pools into named ‘lanes’. Each lane shows the activities in that
part of the organisation.
Once a business process model has been designed, this has to be refined
depending on the services that have been discovered. As I suggested in the discussion of Figure
31.14, the model may go through a number of iterations until a design that allows the maximum
possible reuse of available services is created. Once such a design is available, the next stage is
to convert this to an executable program. As services are implementation-language independent,
this can be written in any language and both Java and C# development environments provide
support for web service composition.
To provide direct support for the implementation of web service compositions,
several web service standards have been developed. The best known of these is WS-BPEL
(Business Process Execution Language) which is an XML-based ‘programming language’ to
control interactions between services. This is supported by additional standards such as WS-Coordination
(Cabrera, et al., 2005), which is used to speci fy how services are coordinated and
WS-CDL (Choreography Description Language) (Kavantzas, et al., 2004) which is a means of
defining the message exchanges between participants (Andrews, et al., 2003).
All of these are XML standards so the resulting descriptions are long and
difficult to read. Writing programs directly in XML-based notations is slow and errorprone. I
have therefore decided not to go into details of XML-based notations, such as WS-BPEL, as they
are not essential for understanding the principles of workflow and service-composition. As
support for service-oriented computing matures, these XML descriptions will be generated
automatically. Tools will parse a graphical workflow description and generate executable service
compositions.
222

223
Service testing
Testing is important in all system development processes to help demonstrate
that a system meets its functional and non-functional requirements and to detect defects that have
been introduced during the development process. As I have discussed in Chapters 22–24, a range
of different approaches to system validation and testing have been developed to support the
testing process. Many of these techniques, such as program inspections and coverage testing, rely
on analysis of the software source code. However, when services are offered by an external
provider, source code of the service implementation is not available. Service-based system
testing cannot therefore use proven, source code-based techniques.
As well as problems of understanding the operation of the service, testers may
also face further difficulties when testing services and service compositions:
1. External services are under the control of the service provider rather than the user of the
service. The service provider may withdraw these services at any time or may make changes to
them, which invalidates any previous testing experience. These problems are handled in software
components by maintaining different versions of the component. Currently, however, there are
no standards proposed to deal with service versions.
2. The long-term vision of service-oriented architectures is for services to be bound dynamically
to service-oriented applications. This means that, an application may not always use the same
service each time that it is executed. Therefore, tests may be successful when an application is
bound to some particular service but it cannot be guaranteed that that service will be used during
an actual execution of the system.
3. As, in most cases, a service is available to different customers, the nonfunctional behaviour of
that service is not simply dependent on how it is used by the application that is being tested. A
service may perform well during testing because it is not operating under a heavy load. In
practice, the observed service behaviour may be different because of the demands made by other
users.
4. The payment model for
services could make service
testing very expensive.
There are different possible
payment models—some
services may be freely
available, some paid for by
subscription and others paid
for on a per-use basis. If
services are free, then the
service provider will not
wish them to be loaded by
applications being tested; if
a subscription is required,
then a service user may be

reluctant to enter into a subscription agreement before testing the service; if the usage is based on
payment for each use, service users may find the cost of testing to be prohibitive.
5. I have discussed the notion of compensation actions that are invoked when some exception
occurs and previous
commitments that have been
made (such as a flight
reservation) have to be revoked.
There is a problem in testing
such actions as they may depend
on failures of other services.
Ensuring that these services
actually fail during the testing
process may be very difficult.
These problems are particularly
acute when external services are
used. They are less serious when
services are used within the same
company or where cooperating
companies trust services offered
by their partners. In such cases,
source code may be available to
guide the testing process and payment for services is unlikely to be a problem. Resolving these
testing problems and producing guidelines, tools and techniques for testing service-oriented
applications is currently an important research issue.
224
Choreography and orchestration

226
SERVICE COMPOSITION
Service-orientation design paradigm
Motivation: reuse services, services are made of composed services, themselves made of services
A business process is automated by combining multiple services
Choreography is a type of service composition
Orchestration is a type of service composition

227
Design considerations to encourage service reuse
• Different from “service providing a functionality” or different from “controller”
• Service contract

228
• Stateless
• Loose coupling
• Service autonomy
SERVICE CHOREOGRAPHY
Service choreography is a form of service composition in which the interaction protocol
between several partner services is defined from a global perspective. The intuition underlying
the notion of service choreography can be summarised as follows:
“Dancers dance following a global scenario without a single point of control"
That is, at run-time each participant in a service choreography executes its part of it (i.e.
its role) according to the behavior of the other participants. A choreography's role specifies the
expected messaging behavior of the participants that will play it in terms of the sequencing and
timing of the messages that they can consume and produce .
Service choreographies are not executed: they are enacted. A service choreography is
enacted when its participants execute their roles[5]. That is, unlike Service orchestration, service
choreographies are not run by some engine on the service infrastructure, but they “happen" when
their roles are executed. This is because the logic of the service choreography is specified from a
global point of view, and thus it is not realized by one single service like in service orchestration.
Service Choreography
 Roles
 Skeletons
 Realisable
 Examples
Principles
 Service choreographies specify message-based interactions among participants
from a global perspective. In the same way as programming languages can be
grouped into programming paradigms, service choreography languages can be
grouped in ``styles[19]:
 Interaction Modelling: the logic of the choreography is specified as a workflow in
which the activities represent the message exchanges between the participants
[20] (for example. Web Service Choreography Description Language (WS-CDL)
and Let's Dance[8])
 Interconnected Interfaces Modelling: the logic of the choreography is split across
its participants through the roles they play (i.e. their expected messaging
behavior). The roles are connected using message flows, channels, or equivalent
constructs[21] (this is for example the case of BPEL4Chor[9])

229
CHOREOGRAPHY VS ORCHESTRATION
Service choreography
• the logic of the message-based interactions among the participants are specified from a global
perspective.
• Language: WS-CDL
• Cf web site below to see how it works
Service orchestration
• logic is specified from the local point of view of one single participant, called the orchestrator
• language BPEL: the specification of the service orchestration (e.g. the BPEL process file) can
be deployed on the service infrastructure (for example a BPEL execution engine like Apache
ODE). The deployment of the service orchestration specification creates the composed service.
• Cf ws-bpel.pdf
Orchestration: Executable Process
Web Service Orchestration relates to the execution of specific business processes. WS-BPEL
is a language for defining processes that can be executed on an orchestration engine.
Choreography: Multi-party Collaboration
Web Service Choreography relates to describing externally observable interactions
between web services. WS-CDL is a language for describing multi-party contracts and is
somewhat like an extension of WSDL: WSDL describes web services interfaces, WS-CDL
describes collaborations between web services. From service choreography to orchestrations and
back
• The roles of a service choreography can be extracted as service orchestrations through a
process called projection [4]. Through projection it is possible to realize skeletons, i.e.
incomplete service orchestrations that can be used as baselines to realize the web services that
participate to the service choreography.
• On the other hand, already existing service orchestrations may be composed in service
choreographies.
SERVICE ORIENTED DESIGN CASE STUDY
Service Oriented Architecture Case Study 1 described how Roehampton University’s in-house
Identity Management System had become the key to the provisioning of students with
their network account names and passwords, their e-mail accounts and their access to buildings
and to borrowing facilities in the Library. The Case study also described, crucially, how the data
integration which drove these processes had become very complex and, because of this, the
Profiler had become a “risk to the business”.

Therefore, this was a perfect opportunity to do some testing of new ways of developing
the computer processes which carry out these key “services” for students following advice in the
well thumbed tome “Service Oriented Architecture for Dummies” (1) which declares “Often the
first thing a business does in adopting Service Oriented Architecture (SOA) is to take some older
applications and transform some of their business functions in to Web Services”.
230
Moving On
The early stages have now passed. We have discovered that there is, of course, a learning
curve associated with using the new development tools, that the development of the computer
“code” is no faster and no slower than development in other up-to-date development
environments. But testing the operation of a singular “service” is a simpler activity than testing
the operation of an element of a larger
“module”. Once tested and working,
that service will remain working
wherever it is deployed as long as the
data going into it is correct. What we
are left with for this effort is not a
singular integration between, for
example, the Student Record System
(SRS) and the Finance System
designed just for that purpose, or a bit
of “computer code” which passes data
from the SRS to the Timetabling
System. What we have a developed, in
fact, is a set (a still small set) of re-usable
“services”, carrying out
distinct, singular business processes,
which can be made available for use in
a wide variety of different business areas within web based applications. In reality, a set of “Web
Services”. These Web Services are : get new student : generate password : generate credentials :
generate barcode.
Most people are now familiar with the idea of a “URL” – Uniform Resource Locator,
which finds and, within a browser delivers, web pages to a PC. Now imagine that the web page
which the URL calls is not an HTML page but a request for data. Your request for that URL
could actually produce data from a database and offer it to you for “consumption” within any
application you require. It can also be designed, crucially, to offer the data in a standard format
which your application would understand implicitly. This format is usually, these days, XML
(Extensible Markup Language) which is now an industry standard for data interchange. Figure 1
shows how these web services are currently structured, “get new student” is a web service which
when requested by a URL will perform a data extract from the Student Record System. The data
is then passed along the chain of “web services using the URL’s of each service to generate the
student login credentials, to generate the student password and to generate the barcode. At this
point this new data is “offered “ to the “world”.

231
Realising the Potential
Suddenly, the potential of
this way of requesting, offering and
“consuming” data becomes
enormous. Having started in a
small way to explore this
opportunity in Roehampton, we are
now very quickly seeing the
potential for large scale gains in
simplicity and supportability of
existing systems and for the
development of additional
“services” to students and staff
alike.
Quite simply, the opportunities
offered by this type of development
architecture have not been ignored
by the computer industry or, for us
in particular, by our major system
suppliers.
Figure 2 shows the type of
systems architecture which is now
capable of becoming a reality in
Roehampton. Most major systems, whether bought from our vendors (Finance System, Student
Records System, Library System) or developed in-house (ID Management System, On-line
Module Selection) are now capable of offering and consuming data in the standard way
described above with the calls and transfers all managed through software which, in the figure,
has been called “The Conductor”.
Not all these opportunities are available to take just yet, some are ready and capable of
deployment, others are being designed, still others are merely thoughts. However the pace at
which the key functionality of the ID Management System was redeveloped and implemented
holds out great hopes that this really is an efficient and effective way to design, develop and
implement new systems.
New Problems
So far our internal deployment of Web Services has been simple and straightforward. We
are in control of the data which is “offered” from systems like the Student Record System. There
are only a few Web Services. We know how the data is defined, we know, for example, our
definition of a Registered Student! But it is possible to foresee that there will be a profusion of
Web Services and that they will need to be defined, documented and held in a place where they
are accessible to future system builders. In other words they will need a “Repository” in just the
same way that our business models need to be held in a repository for re-use.

As data is passed much more effectively around our systems then we will need to be sure
that the data is always “coherent”, that it is complete and accurate and so we will have to build
processes which check the data on the “way out” of databases and on the “way in” to databases.
We know what we use to define a “Registered Student” but do our system suppliers know that
also? Will we be able to “trust” the data which comes from such 3rd party Web Services?
We are now beginning to develop a “service” based architecture. That architecture is a close
blend of singular computer processes and singular business “services”. We must ensure ”that the
rules and processes are implemented correctly” (1). Therefore, we must now begin to consider
how we will control the growth and exploitation of this new way of doing business. We must
begin to explore “SOA governance”.
232

Unit iv function and service oriented designs 9

More Related Content

What's hot (18)

Viewers also liked (6)

Similar to Unit iv function and service oriented designs 9 (20)

Recently uploaded (20)

Unit iv function and service oriented designs 9