MOD SERVICE ORIENTED ARCHITECTURE (SOA)

HANDBOOK V1.0

Issued [31/10/2007]

MINISTRY OF DEFENCE
Director General Information
 RECORD OF CHANGES

CHANGE NO AMENDED BY DATE

 PREFACE

This handbook is intended to provide the latest guidance and information on Service
Oriented Architecture (SOA) to MOD planners, desk officers, IPTs and those specifically
responsible for ensuring best possible effect from available resources. It seeks to provide
enough relevant information from a rapidly developing technical area to enable readers to
make basic and sensible decisions or to understand what to ask of experts. This document
must therefore be considered as ”live”. This handbook supports a portfolio of projects
designed to demonstrate the effects and benefits of SOA and which will, if adopted on a
wider scale, form the vanguard of a coherent defence-wide programme. Guidance will be
updated regularly; the next revision will include security and ontology chapters.

SOA offers a mechanism for achieving the agility required for NEC. Whereas the current
stove-piped way of doing business is rigid and difficult to adapt because business functions
and the supporting IT are so tightly coupled, an SOA exploits newly available technology
software components and web standards that can be reconfigured easily and quickly. SOA
translates capabilities, processes and functions into services which can be invoked by a
user through an interface. This requires the services to be available and the user to know
the “what, how, how much and when” of accessing them. How the services work is of no
consequence to the user but is important to designers and architects. The underlying
principles are not new, but the web services and related technology to bring it to life are;
reinforced by wide acceptance of these technologies.

The predominant precept is that SOA is business driven. This puts designated defence
Process Owners in the driving seat because they place requirements for service provision.
If SOA is to be successful it means that they must truly understand what drives the
capability they are entrusted to deliver so that they are in a position to inform/drive
how it can be delivered to users in the most effective and efficient manner possible. New
technology enables much looser coupling between business processes and the IT systems
which support them and so overcome one of the key drivers of cost in most IT deployments
– tight coupling i.e. changes in one area requiring a cascade of other required changes in
order to work; with familiar cost, time and performance penalties. To support this, a high
level governance structure is essential to enforce data and quality of service standards,
which enable reuse of services.

There are many benefits to SOA. They include access to previously unavailable
information, the design of reusable services, the ability to make up new services from
existing ones, the ability for businesses to make changes without costly IT expenditure, and
so on. Moreover, the issues subtending from the use of legacy systems and the
requirement to leverage as much VFM as possible from their continued use, becomes
much less difficult by adopting a service perspective. For those who embrace SOA and see
it through, the prospect of a working NEC becomes realisable for the first time.

SOA is already here and any new major system provided by any one of the significant
vendors is likely to have an SOA capability embedded in it. This handbook, if used
together with the references and sources of advice available now, will provide a sound
basis for understanding and taking SOA forward to the advantage of MOD.
 TABLE OF CONTENTS

CHAPTER 1 ........................................................................................................................................................9
PRINCIPLES AND DEFINITIONS ......................................................................................................................9
SECTION I.......................................................................................................................................................9
GENERAL .......................................................................................................................................................9
Applicability of Policies................................................................................................................................9
Scope ........................................................................................................................................................10
SECTION II....................................................................................................................................................10
KEY CONCEPTS ..........................................................................................................................................10
Syntax .......................................................................................................................................................10
SOA...........................................................................................................................................................11
Elaboration on SOA ..................................................................................................................................11
Services ....................................................................................................................................................11
Elaboration on Services ............................................................................................................................13
SOA Characteristics..................................................................................................................................14
Service Reuse ...........................................................................................................................................16
Legacy Services ........................................................................................................................................16
SECTION III...................................................................................................................................................16
HOW IT ALL FITS TOGETHER ....................................................................................................................16
SOA Entities ..............................................................................................................................................16
The MOD Concept Model .........................................................................................................................17
Types of Service .......................................................................................................................................18
Service Definition ......................................................................................................................................18
Service Contracts......................................................................................................................................19
Business Function.....................................................................................................................................19
Service Orchestration ...............................................................................................................................20
Open Standards ........................................................................................................................................20
Automated Service....................................................................................................................................20
Software Service .......................................................................................................................................20
SECTION IV ..................................................................................................................................................20
MOD APPROACH TO SOA ..........................................................................................................................20
General Concept .......................................................................................................................................20
What Is Different About SOA? ..................................................................................................................20
Why SOA? ................................................................................................................................................21
Why Web Services?..................................................................................................................................22
MOD’s Approach.......................................................................................................................................22
Enterprise Service Bus .............................................................................................................................23
Federation .................................................................................................................................................23
SOA at The Tactical Level ........................................................................................................................24
SECTION V ...................................................................................................................................................24
PRINCIPLES OF MOD SOA .........................................................................................................................24
Basic Principles of SOA ............................................................................................................................24
Technical Characterisation of SOA ...........................................................................................................25
Build on Best Practice ...............................................................................................................................25
Service Enabling Legacy Systems ...........................................................................................................26
Understand What is Different About SOA.................................................................................................26
Keep Early Work Simple ...........................................................................................................................26
Identify Benefits ........................................................................................................................................26
Get Service Level Abstractions Right .......................................................................................................27
Some Thoughts From Implementations....................................................................................................27
Standardise The SOA ...............................................................................................................................28
Test the performance of SOA components ..............................................................................................28
Create a transition plan .............................................................................................................................29
Understand the security requirements SOA .............................................................................................29
Understand XML .......................................................................................................................................29
Align with governance ...............................................................................................................................29
Organisational agility.................................................................................................................................29
 Lower Through Life Costs .........................................................................................................................30
Architectural Partitioning ...........................................................................................................................30
Incremental Deployment and Maintenance ..............................................................................................30
Reuse of Services .....................................................................................................................................30
Improved integration and interoperability..................................................................................................30
Streamlined architectures and solutions ...................................................................................................31
Leveraging the legacy investment ............................................................................................................31
Establishing standardised XML data representation ................................................................................31
Alternatives ...............................................................................................................................................31
Organisational agility.................................................................................................................................31
Separation .................................................................................................................................................32
Consumption .............................................................................................................................................32
Service Design ..........................................................................................................................................32
Challenges to Adoption. ............................................................................................................................32
SECTION VI ..................................................................................................................................................33
SUMMARY ....................................................................................................................................................33
The SOA Stack .........................................................................................................................................33
CHAPTER 2 ......................................................................................................................................................35
STANDARDS AND SERVICES ........................................................................................................................35
SECTION I.....................................................................................................................................................35
OVERVIEW ...................................................................................................................................................35
Web Services ............................................................................................................................................35
SECTION II....................................................................................................................................................35
SOA AND WEB SERVICES TOOLS ............................................................................................................35
Why have SOA Standards? ......................................................................................................................36
SECTION III...................................................................................................................................................36
ENABLING STANDARDS ............................................................................................................................36
Standards for Automated Services ...........................................................................................................36
Web Services ............................................................................................................................................36
eXtensible Markup language (XML) .........................................................................................................36
Hypertext Markup Language (HTTP) ........................................................................................................36
Simple Object Access Protocol (SOAP) ...................................................................................................37
Business Process Execution Language (BPEL) .......................................................................................37
Universal Description Discovery and Integration (UDDI)..........................................................................37
Web Services Description Language (WSDL) ..........................................................................................37
MooD.........................................................................................................................................................38
SECTION IV ..................................................................................................................................................38
MOD CORE SOA SERVICES .......................................................................................................................38
What are MOD Core SOA Services? ........................................................................................................38
Discovery ..................................................................................................................................................39
Mediation ..................................................................................................................................................39
Security .....................................................................................................................................................40
Metadata Repository .................................................................................................................................41
Service Management. ...............................................................................................................................41
Messaging .................................................................................................................................................42
Service Orchestration ...............................................................................................................................42
Core and Business Services .....................................................................................................................43
SECTION V ...................................................................................................................................................44
MOD ENTERPRISE SERVICE BUS .............................................................................................................44
Best Practice .............................................................................................................................................44
Basic Operation ........................................................................................................................................44
Software Approach ...................................................................................................................................44
ESB Characteristics ..................................................................................................................................45
SECTION VI ..................................................................................................................................................45
FRED .............................................................................................................................................................45
The MOD’s Fred Concept .........................................................................................................................45
Components ..............................................................................................................................................46
Project Level – Fredlet ..............................................................................................................................46
 National Level ...........................................................................................................................................47
Issues to Develop .....................................................................................................................................47
ESB Functions ..........................................................................................................................................48
Exploitation ...............................................................................................................................................49
Security .....................................................................................................................................................49
SECTION VII .................................................................................................................................................49
BUSINESS SERVICES .................................................................................................................................49
Business Function Decomposition............................................................................................................49
Business Services are Information Services ............................................................................................50
Deriving Business Services ......................................................................................................................50
SECTION VII .................................................................................................................................................50
PRESENTATION SERVICES .......................................................................................................................50
What are Presentation Services? .............................................................................................................50
SECTION VIII ................................................................................................................................................50
STANDARDS ................................................................................................................................................50
Web Service Interoperability (WS-I) .........................................................................................................51
WS-I Basic Profile 2.0 (MANDATORY) ....................................................................................................51
The Standards (MANDATORY) ................................................................................................................51
SECTION IX ..................................................................................................................................................52
SOA DEVELOPED........................................................................................................................................52
SOA Evolution ...........................................................................................................................................52
Metadata ...................................................................................................................................................53
Scale and Granularity ...............................................................................................................................53
Key Requirements ....................................................................................................................................53
SOA Ground Rules ...................................................................................................................................54
The Service Contract Developed ..............................................................................................................54
SECTION X ...................................................................................................................................................56
IMPLEMENTATION POLICY ........................................................................................................................56
JSP 602.....................................................................................................................................................56
Information Retention in Applications .......................................................................................................56
Alternatives to Web Services ....................................................................................................................56
Design Patterns ........................................................................................................................................56
SECTION XI ..................................................................................................................................................57
SECURITY ....................................................................................................................................................57
Service Level Security ..............................................................................................................................57
HTTP .........................................................................................................................................................57
HTTPS ......................................................................................................................................................57
WS-Security ..............................................................................................................................................57
Security Assertion Mark up Language (SAML).........................................................................................57
CHAPTER 3 ......................................................................................................................................................59
MOD ARCHITECTURE FRAMEWORK (MODAF) ...........................................................................................59
SECTION I.....................................................................................................................................................59
AIM ................................................................................................................................................................59
Policy (MANDATORY) ..............................................................................................................................59
SECTION II....................................................................................................................................................59
MODAF .........................................................................................................................................................59
What is MODAF? ......................................................................................................................................59
MODAF’s Purpose ....................................................................................................................................59
MODAF and SOA .....................................................................................................................................60
DoDAF and MODAF .................................................................................................................................60
SECTION III...................................................................................................................................................60
MODAF VIEWS .............................................................................................................................................60
What are MODAF VIEWS? .......................................................................................................................60
The Six MODAF Viewpoints .....................................................................................................................60
Strategic Viewpoint ...................................................................................................................................61
Operational Viewpoint ...............................................................................................................................62
System Viewpoint .....................................................................................................................................62
Technical Standards Viewpoint ................................................................................................................63
 Acquisition Viewpoint ................................................................................................................................63
All-Views Viewpoint...................................................................................................................................63
SECTION IV ..................................................................................................................................................63
HOW MODAF WORKS .................................................................................................................................63
MODAF Views Most Relevant to SOA ......................................................................................................63
MODAF SOA Views ..................................................................................................................................64
MODAF and NATO Architectural Framework (NAF) ................................................................................65
Security .....................................................................................................................................................66
Transitional Architecture ...........................................................................................................................67
CHAPTER 4 ......................................................................................................................................................68
GOVERNANCE .................................................................................................................................................68
SECTION I.....................................................................................................................................................68
AIM ................................................................................................................................................................68
Guidance ...................................................................................................................................................68
SECTION II....................................................................................................................................................68
THE KEY GOVERNANCE ELEMENTS ........................................................................................................68
Introduction ...............................................................................................................................................68
Coherence ................................................................................................................................................68
Scope - Key Components .........................................................................................................................69
SECTION III...................................................................................................................................................70
THE MAIN PLAYERS ...................................................................................................................................70
Executive Sponsor ....................................................................................................................................70
The Executive Steering Group (ESG).......................................................................................................71
SOA Board ................................................................................................................................................71
Portfolio Management Committee ............................................................................................................72
Architecture Review Board .......................................................................................................................72
Business Operations Review Board .........................................................................................................73
SECTION IV ..................................................................................................................................................73
ORGANISATIONAL ROLES ........................................................................................................................73
The Defence Change Backdrop ...............................................................................................................73
NEC and SoSA .........................................................................................................................................73
Capability Architect ...................................................................................................................................74
Technical Architect....................................................................................................................................74
DG ISTAR .................................................................................................................................................75
Integration Authority (IA) ...........................................................................................................................75
DG ISS ......................................................................................................................................................75
DG Info ......................................................................................................................................................75
CM (IS) ......................................................................................................................................................75
SECTION V ...................................................................................................................................................76
CENTRE OF EXCELLENCE FOR DESIGN AUTHORITY............................................................................76
Introduction ...............................................................................................................................................76
The function of the CofE for Design Authority (DA) ..................................................................................76
Design Authority Roles .............................................................................................................................76
Chief Architect ...........................................................................................................................................77
Project Office Manager .............................................................................................................................77
Service Registrar ......................................................................................................................................77
Business Service Architect .......................................................................................................................78
Technical Service Architect.......................................................................................................................78
Method/Tool Architect ...............................................................................................................................78
Summary of Main Constructs. ..................................................................................................................78
SECTION VI ..................................................................................................................................................79
COMMUNITIES OF INTEREST ....................................................................................................................79
Roles of the COI .......................................................................................................................................79
External and Internal Information ..............................................................................................................79
The role of Business Process Owners......................................................................................................79
The role of Information Owners ................................................................................................................80
The role of Subject Matter Experts (SME) ................................................................................................80
The role of COI Leaders ...........................................................................................................................80
 The role of Equipment Capability Managers.............................................................................................81
The role of Procurement Managers (aka IPT Leaders) ............................................................................81
Compliance with CADMID/Acquisition Operating Framework ..................................................................81
SECTION VII .................................................................................................................................................82
SETTING UP COIS ........................................................................................................................................82
Aim ............................................................................................................................................................82
Step 1 ........................................................................................................................................................82
Step 2 ........................................................................................................................................................82
Step 3 ........................................................................................................................................................82
Step 4 ........................................................................................................................................................83
Step 5 ........................................................................................................................................................83
SECTION VIII ................................................................................................................................................83
COMPLIANCE ..............................................................................................................................................83
Responsibility for Implementing the Policy ...............................................................................................83
Procedure .................................................................................................................................................83
Relevant Links ..........................................................................................................................................84
ABBREVIATIONS .............................................................................................................................................85
GLOSSARY.......................................................................................................................................................87
ANNEX A THE BASIS FOR BUSINESS SERVICES ......................................................................................90
ANNEX B WS-I BASIC PROFILE 2.0 CONTENTS.........................................................................................96
 CHAPTER 1

PRINCIPLES AND DEFINITIONS

This chapter is for information and guidance. It introduces the key ideas of SOA. It is
intended for desk officers, project managers and architects engaged in SOA. The principles
described provide a basic introduction which is built up through the Handbook and in key
supporting references. The definitions are intended as “starters for ten” for those with a
more technical focus but there is substantial treatment of services. Most definitions are
coined from multiple sources and for the most part are simplifications; but they have been
adapted for the MOD. For many users what is in this chapter sits behind the service or
services they wish to access so there is no requirement to understand these in detail. The
chapter ends with a summary of the MOD’s Approach to SOA.

SECTION I

GENERAL

Applicability of Policies

0101. The policies within this publication apply to the development, supply, procurement,
or management of Information Systems or IT services. MOD has chosen to follow a Web
Services - based approach to SOA and compliance with specified parts of this Handbook is
required of all MOD personnel and contractors engaged in the above. The parts that are
mandatory are annotated. DG Info has the lead on policy for the Services and DInfoX is
the sponsor of this Handbook which is supported by the following related references:
1
a. MOD Information Management Handbook .

2
b. MOD SOA Roadmap .

3
c. MODAF V1.1 .

4
d. Systems of Systems Architect Responsibilities .

5
e. NEC/CBM Governance .

f. MODAF Logistics & Sustainment Deskbook Draft 2.2 dated 3 Apr 07.

g. JSP 602-1002 – SOA Policy.

1
MOD Information Management Handbook
2
MOD SOA Roadmap V dated 7 Aug 07 (Available from InfoXEA-1a)
3
MoD Architecture Framework Version 1.1 – frequently updated and downloadable from http://www.modaf.org.uk
4
System of Systems Architecting Responsibilities EC CCII (Sees 07-080) /DGISTAR/7/3/3/6 dated 07 June 07
5
NEC/CBM Governance
Scope

0102. The scope of this Handbook covers:

a. Creating an Service-Oriented Architecture (SOA).

b. Mandatory Standards to be adhered to.

c. Governance.

SECTION II

KEY CONCEPTS

This section introduces the key concepts and relevant definitions with, where necessary,
supporting elaboration. Working definitions are shown in italics.

Syntax

0103. The basic syntax that has been adopted for the Handbook is shown in Figure 1
below:

Basic Syntax

Composed
Capability
services

Coarse &
Function Satisfied by Composed
Services

Fine grade
Process
Services

Figure 1 Basic Syntax

0104. The syntax above is based on the following definitions (services are defined in
paragraph 0107 et seq):

a. Capability. Capability is enduring ability to generate operational outcome or

effect 6

b. Function. A function is an enduring business operation.

6
From Capability Management Handbook (Interim Edition) dated 26 Feb 07 V2.0
 c. Process. A process is a series of activities designed to achieve an outcome. It
is a real world activity consisting of logically related tasks which when performed in
the appropriate sequence and according to set down business rules produce a
business outcome such as process order fulfilment.

d. Service. Service refers to the provision of a discrete business or technology

function within a systems environment.

SOA

0105. An SOA is a way to design and provide an IT infrastructure to allow different

applications to exchange data and participate in business processes, irrespective of the
operating systems or programming languages which underpin them.

Elaboration on SOA

0106. SOA organises business and IT software components into providers and consumers
of services. An SOA approach loosely couples business processes to the supporting
business and IT components. This means that changes to one do not require large scale
changes in the other. In a MOD context, it means that it is possible to model processes and
services independently of their execution environment and create messages that can be
sent to any service. SOA harnesses the convergence of key technologies and the
widespread adoption of Web Services (explained in Chapter 2) that hitherto were too
immature, controversial or expensive for widespread uptake. These technologies cover or
enable:

a. An architectural focus encompassing governance, functions and processes,

modelling and tools;

b. The ability to use an appropriate level of service abstraction to allow business

needs and technical capabilities to interoperate i.e. solve interoperability issues
between applications but not necessarily build the business logic for applications;

c. An infrastructure on which new applications can be built (quickly and easily);

d. A reusable library of services of common business and IT functions (see Core

SOA services in this chapter and Chapter 2).

Services

0107. Service refers to the provision of a discrete business or technology function within a
systems environment; e.g. Business Service – “Manage Customer Address”; Technical
Service – “Create E-Mail Notification”. A basic instance of how a service might be invoked
in an SOA is represented in Figure 2 below.
 Basic SOA

Registry

e y via of
n

1. eb S rd in
int eg riptio

W nda
Pu er
sta

bli vic erfa

erf istr
a rd a R sc

sh e t ce
nd s vi de

es o
ac
sta ce sses

de Reg
t

sc
se cce

rip istry
tio
A
rvi

n o via
2.

f
Requester Provider
3. Requests execution of
service by sending message
via standard interface

Figure 2 SOA Basics

Figure 2 shows the essential Requester-Provider relationship. Services are executed by

exchanging messages according to specific exchange patterns e.g. “request-response” or
“publish-subscribe”. The diagram shows the basic operation of a service which is published
(not all services are published). The requester searches the Registry (or Service Broker) for
a service. If available, the requester will initiate the execution by sending a message to the
service provider. The service provider will execute the service on receipt of the message.
The provider may or may not send a message back to the requester. That describes the
basic service invocation loop.

Web Services

0108. Web services are used to implement a service-oriented architecture. A major focus
of Web services is to make functional building blocks accessible over standard Internet
protocols that are independent from platforms and programming languages. These
services can be new applications or just wrapped around existing legacy systems to make
them network-enabled. A service can rely on another service to achieve its goals. Each
SOA building block can play one or more of three roles 7 :

a. Service Provider. The service provider creates a Web service and possibly
publishes its interface and access information to the service registry. Each provider
must decide which services to expose, how to make trade-offs between security and
easy availability, or how to price the services. The provider also has to decide what
category the service should be listed in for a given broker service and what sort of

7
Taken from Wikipedia
 trading partner agreements are required to use the service.

b. Registry. The service registry, also known as service broker, is

responsible for making the Web service interface and implementation access
information available to any potential service requestor. The implementer of the
broker decides about the scope of the broker. Public brokers are available through
the Internet, while private brokers are only accessible to a limited audience, for
example, users of a company intranet. Furthermore, the amount of the offered
information has to be decided. Some brokers specialize in many listings. Others
offer high levels of trust in the listed services. Some cover a broad landscape of
services and others focus within an industry. There are also brokers that catalogue
other brokers. Depending on the business model, brokers can attempt to maximize
look-up requests, number of listings or accuracy of the listings. The Universal
Description Discovery and Integration (UDDI) specification defines a way to publish
and discover information about Web services.

c. Service Requestor. The service requestor or Web service client locates entries
in the broker registry using various find operations and then binds to the service
provider in order to invoke one of its Web services.

Elaboration on Services

0109. A service can be simple or complex. Figure below shows this simplicity
diagrammatically:

Requester Service Provider

The requester or The Service acts The Provider

user (or as a fascade to implements the
consumer) uses the provider and service
the service user independent of the
independent of the users
provider

The service separates the requester/user form the provider. Services

have greater longevity that either users or providers because generally,
they are based on enduring entities.

Figure 3 Service - simplicity itself 8

8
After Implementation of a SOA - NOSWG 070502
The above could refer to retrieval of a specific piece of information or to execution of a
complete business process e.g. creating a specific joint operational picture view or a
system capability such as authenticate user. Whatever the scope, it will be bounded and
will be limited to a single distinct business concept, function or process. Some of these
services are standardised 9 (i.e. based on standards) and provide the enabling mechanism
by which other services may be consumed – referred to as Core SOA Services and
Business Information Services respectively and defined in Chapter 2.

SOA Characteristics

0110. SOA exposes the functionality of applications in the form of services that can be
made available to other applications and/or users throughout the organisation. An SOA
treats elements of the business processes and their underlying IT services as standardised
components that can be combined to promote their reuse, to build new services and to
speed application development. Key aspects to understand about services are that:

a. Services are reusable. Services should be designed to be reusable in multiple

applications. This also means designing them for multiple invocation styles e.g.
batch driven, request-response or event-driven. Service reuse reduces duplication
and speeds up composition of new services (covered next).

b. Services are composable. Services should be designed to be combined with

others to form new services. This means that services which are developed in the
context of other services can be used in combination with them to build more
complex services or even applications. Deploying services within an SOA makes it
easier to compose new services which can be exposed either to IT systems or to
end-users 10 . This is the value of SOA – when new applications and services can be
developed from existing reusable services quickly and cost effectively. This
capability confers the agility, speed and flexibility to meet changing requirements.

c. Services are loosely coupled. The ability to model services independently of

their execution environment is important e.g. target acquisition could be by FOO,
UAV, satellite etc... This allows the business services e.g. travel administration, to
become the key organising principle for aligning IT with business requirements.
Unlike earlier approaches which often required the use of quite specific execution
environment, SOA enables clear focus on business issues, information and data.
What this means is that the overall IT environment closely matches the operational
characteristics of the business; and changes to one do not force a chain of changes
to the other. However, there are 3 aspects of loose coupling that should be
understood if common procurement or design mistakes are to be avoided:

i. The coupling between a service requester 11 and a service provider should be

kept to a minimum. The less dependencies there are between them, the looser
9
MoD SOA is based on WS* Services that are profiles through WS-I - these are explained in Chapter 2
10
End-User. In this context, end-user refers to a customer e.g. staff officer or section commander. For MoD purposes,
any IT component (machine-to-machine) that may be the user of a service will usually be referred to as an IT system,
component or application.
11
Service requester is used interchangeably with service user, noting that this may be either human or machine
 the coupling. The interface between them should render the details of the service
implementation opaque to the requester.

ii. Exclusive coupling between a service and any given business process should
be avoided unless it is absolutely essential e.g. physical based 3-D modelling of
satellite imagery. Close coupling between services and processes significantly
inhibits reuse and dilutes many of the advantages of the SOA approach (see
para 0111).

iii. Tight coupling to a particular technology, product, packaged application,

operating system, application server or middleware platforms should be avoided.
This also applies to the use anything that is proprietary to a particular vendor.
Even the specification of low-uptake open standards may result in reduced
access for requesters and may limit options for outsourcing of service provision.
These issues constitute some of the key drivers for MOD’s adoption of a widely-
accepted, standards-based approach to SOA.

d. Services are unique and do not overlap. In order to capitalise on some of the
benefits of SOA e.g. greater efficiency though quick and easy creation of new
services, services should not overlap and should only be designed and created
once.

e. Services are discoverable. Generally, services will be published. It should be

possible to discover and consume a service without intervention from the service
provider as long as the appropriate permissions and security provisions 12 are
complied with In some cases, provider intervention will be unavoidable, for instance,
access to Common Operating Picture services by a transient Agile Mission Group 13 .
Note that consumers of a service can be another service.

f. Services share a contract with the service-user. The service contract defines
what a service can do and how to invoke it. It is the “instrument” that sits between
the technical implementation of the service and the requester. This is discussed
more substantially in Chapter 2. For SOA to work well in MOD clear military
specifications and operational thinking need to be brought to bear when defining
contracts. This is important not only because military users will be able to access
operationally relevant services but also because changing specification (and
possibly the behaviours of many requesters) is likely to take longer and cost more
than changing service execution. Therefore, front end military input, namely the
ECC community, single service Front Line Commands and PJHQ (particularly
N/G/AJ3, 4, 5 and 7), is vital for accuracy and appropriateness. Key aspects of
defining contracts are:

i. There should be clear separation of the interface from service

implementation.

ii. Service contracts should be as general and abstract as practicable to enable

switching to alternative implementations. This is of particular relevance

12
Security is covered in outline in Chapter X. but will be the subject of the first substantial update to this Handbook.
13
After Network Enabled Capability JSP 777 Edn 1
 throughout the Joint Supply Chain where supply partners may have to be
changed without reduction in either logistic support or sustainability to operations.

g. (STO)Services abstract underlying logic. To a user, a service is in a black box

which conceals how it operates. One of the greatest benefits of service abstraction
is its ability to access different service types easily. This could be newly developed
services, wrapped legacy applications or applications composed of other services.

h. Services are interoperable. As previously noted, services abstracted to the right

level can overcome many interoperability issues. For the MOD, there are formal
coalition interoperability requirements (with NATO and the US) which must be
complied with. Without this, UK will reduce its ability to operate with NATO Allies in
network enabled interventions such as ongoing ISAF deployments. The implications
of this are covered Chapter 2.

i. Services are based on Open Standards. MoD has chosen to base its approach
to SOA on open web-standards. Interoperability is facilitated by implementing SOA
using widely-accepted open standards that are simple, pervasive, and both platform
and vendor-neutral. The use of open standards that are not widely accepted risks
lack of future development which will be needed to sustain the continued usability of
the standard. Chapter 2 covers this comprehensively.

j. The location of services is transparent to the user.

k. Services are transport and platform independent.

Service Reuse

0111. An SOA allows MOD to reuse business services and functions from new and
existing Agents in a simple and standardised way. SOA is a strategy which orchestrates
the discrete enterprise functions into interoperable, standards-based services which can be
reused and/or combined for business benefit. SOA is aimed at maximizing this re-use.

Legacy Services

0112. Legacy services are those provided by existing systems. They should be treated in
exactly the same way as other services. The reason for legacy.

SECTION III

HOW IT ALL FITS TOGETHER

This section introduces and defines a number of terms based around a representative
diagram.

SOA Entities

0113. Relationships between the SOA entities can be represented in many ways. Figure
3 below aims to simplify these to their barest elements and should be self-explanatory. The
entities are MODAF compliant (see Chapter 3) and will operate according to rules
produced under the auspices of the Governance structure detailed in Chapter 4.

SOA Entity Relationship Diagram

fulfil Business fulfil Business Presentation

Capability
e.g. Managed payroll Functions Processes Services
e.g. Payroll e.g. Pay employee

Orchestrated capture interact

into with
display

Business
Services
eg. Check employee pay,
send money to bank

enabled User
by

composed
of
Core SOA
Services

Figure 4 SOA Entity Diagram

The MOD Concept Model

0114. The model illustrated in Figure 4 below is a simple overview of how some of the
key SOA terms interrelate. It should be viewed as informative rather than definitive and is
intended as the vehicle for some definitions. Services work by exchanging messages.
These messages operate on the basis of one or more supported exchange patterns e.g.
request-response, and are therefore defined in these terms. The relationship among the
different parts are explained below:
 composes

Agent

Human Agent System Agent

provides consumes
Service
conducts Interface
composed
succession of Service
Level
Business Business conforms Service
supports supports Service
Function Process to Specification
Service
composed Policy
of
Service
Behaviour
Key:

entity
relationship
composition
SOA Core Presentation
generalisation Business Service
Service Service

Figure 5 - MOD SOA Concept Model

Types of Service

0115. Figure 5 shows two classifications of service that are relevant to MOD. Both are
covered in depth in Chapter 2:
”.
a. Core SOA Services. The core services are a single set of reusable technical,
generic enabling or foundation services which enable information to be shared.
These services enable the SOA to function. They comprise a single logical set of
services. Core SOA Services enable Business Services (defined next) to be
integrated, distributed, and accessed across organizational, geographical, and
technical platform boundaries. Core Services include: security services; discovery
services; a meta-data repository; mediation services; orchestration services;
messaging services; and Information management services. Where these are
delivered using several different physical implementations (dependant on role or
operation) this is known as federation.

b. Business Services. The bulk of MOD services that will be provided by SOA are
Business Services. The goal of SOA is to align the provision of business services
with business processes in such a way that they can be reorganised to match the
tempo of business change. It is important to confine services to those with a direct
counterpart in real business. Functions such as personnel management could then
be either a big service with lots of smaller ones; or a number of discrete services.
By keeping focus on real business scenarios and away from technology, business is
able to play an important part in identifying requirements. At any time, the technical
solution can always be mapped back to the business model. The derivation of these
is complex and how MOD will approach this is explained in Chapter 2 and Annex A.

Service Definition

0116. A service will have one or more machine-readable descriptions of the messages it
receives and returns. It is therefore defined in terms of the message exchange patterns it
supports. A schema of for the data contained in the message is used as the main part of
the contract between a service requester and provider. An important part of the definition
of the service is that the description is separated from its implementation. The description
may support multiple implementations and vice versa. What separates the description from
its execution is a transformation layer. The transformation layer accepts the message,
translates the data into a native format, and dispatches the data to the implementation
layer.

a. Service Specification. In order to enable re-use of services in an SOA, there

must be standardised service specifications that the producers of services can
conform to and that the consumers can request. Typical aspects of a service
specification are; the Service Interface, the Service Level, Service Policy, and the
behaviour of the service (its functionality, how it interacts with other services or
users, and output.

b. Service Interface. A key feature of a Service Specification is the Service

Interface - a formal description of how a service is to be invoked, what type of
information it requires, and what type of information it produces.

c. Service Level Performance/Behaviour A specification of the quality of a

service. Key service Performance attributes might be availability, timeliness,
response time, and accuracy.

d. Service Policy. A key feature of a Service Specification that defines the usage
policy of a service. A typical service policy would define access rights and conditions
for a type of service.

e. Agent. Any business unit or automated system (e.g. a software application) that
produces and/or consumes services. An agent can be human or machine.

f. Service Provider/Consumer. A service provider is an Agent (per para 0114)

that offers all or some of its functionality as a service, conforming to a published
Service Specification. A service consumer is an Agent that uses services. An agent
may provide and consume services.

Service Contracts

0117. As explained in para 0110f, every service has a well-defined interface call a service
contract. It clearly separates services internally from execution environment and from its
externally accessible interface. Contracts will enable formalisation of system boundaries
and minimising of dependencies.

Business Function

0118. Building on para 0104b, a business function is an activity conducted by an Agent in

support of the goals of the enterprise. This could be an operational activity in support of a
mission, or a management function supporting the day-to-day running of the MOD.
Capabilities will generally be made up of business functions.
Service Orchestration

0119. The sequencing of services, governed by the sequence of Business Functions they
support. In its simplest form it is collaboration in which a primary service directly invokes
other services.

Open Standards

0120. These are non proprietary and widely adopted standards for MOD SOA (e.g. SOAP
and XML). This topic is comprehensively covered in Chapter 3.

Automated Service

0121. A service which is provided with no requirement for human intervention under
normal operating circumstances.

Software Service

0122. An Automated Service which is provided by a software system.

SECTION IV

MOD APPROACH TO SOA

General Concept

0123. SOA allows Business processes, supporting applications and information to be

packaged as services in a loosely coupled environment and reduces the complexity of
providing and using those services. It facilitates the concepts of ‘Plug & Play’ and the agility
required to deliver Effects Based Operations 14 and network enabled defence. Within an
SOA environment a wide range of integration services provide the mechanism to rapidly
reconfigure common operational / business processes whilst minimising the constraints
currently imposed by stovepipe legacy Comms Info Systems (CIS). The SOA approach
helps manage the vast complexity of modern CIS services across all Lines of
Development 15 (LOD) simplifies CIS governance and improves achievement of
interoperability by making explicit relationship and interfaces. The emerging governance
structure which takes into account the developing role of DEC CC&II as the System of
System Architect 16 (SoSA) and the roles of DGISS, the IA, DG Info and ICAD are
developed in Chapter 4.

What Is Different About SOA?

0124. The major difference between service-oriented development and previous

14
Reference Latest EBO
15
Defence Lines of Development – use COS Briefing
16
System of Systems Architecting Responsibilities EC CCII (Ses 07-080) /DGISTAR/7/3/3/6 dated 07 June 07
approaches is that service orientation enables focus on the description of the business
problem. Previous approaches required more focus on the use of specific execution
technology. The way in which services are developed better aligns them to solving
business problems. SOA is not new. What is new is that the ability to mix and match
execution environments, clearly separating the service interface from the execution
technology, allowing organisations to choose the best execution environment for each job
and tying them together using a consistent architectural approach. For the MOD, it offers a
unique opportunity to align the needs of providing capability with the supporting IT. Over
time, this means more adaptable services, quick applications development, more freedom
to choose best fit technology and better economy i.e. more capability for the same outlay.

Why SOA?

0125. For MOD, there are many potential advantages to the SOA route to delivering
service. The top three are:

a. The ability to create new components and services from legacy applications –
potentially savings from new services based on existing applications and leveraging
of investment in legacy applications;

b. The increased choice in how to provide a specific functionality;

c. The ability to produce shared services.

0126. Like it or not – SOA is coming. Major vendors such as IBM and Oracle have fully
embraced SOA for development of their applications and others, such as IFS are service-
enabling key functions in their applications and procurement of non-SOA compliant IT
systems is likely to become less appealing on a VFM and functionality basis. SOA should
allow the MOD’s Business Services to be the key organising principle used to align IT
systems with the needs of the business. This is quite different to earlier approaches which
built IT systems which were wedded to specific implementation environments such as
procedure or object orientation and which resulted is systems that were locked into
functionality or features of a particular implementation technology e.g. CORBA, J2EE and
IMS 17 . Figure 6 below is a summary of the arguments that we used to inform the SOA
decision.

17
It is not necessary to understand these terms but for completeness they are in the Glossary
 SOA Vs Stove Pipe
SOA
Facilitates NEC
Adaptable software components
+ Re-useable software components
Builds an “information layer”
Connects to Allies services
Connects to industry services
Agile (quick & easy to change)
Lower long term costs
Open Web Standards
Higher up front cost
Higher “in-house” management
_ overhead
Information assurance risks
New Skills required
Procurement change required
Not suitable for Real-Time
Stove Pipe
Low Risk
“Over the fence” procurement
established
Information Assurance processes
established.
Lower short term cost
Hinders NEC
Costly and Slow to change
UORs Entrench problems
Limited information sharing
Duplication of information
Quality of information varies
Vendor lock-in

Figure 6 - SOA vs. Stove Pipe

Why Web Services?

0127. The attractions of implementing SOA using Web Services are their simplicity and
ease of use, their wide uptake, the fact that they are platform-neutral.

MOD’s Approach

0128. The conceptual outline of MOD’s approach is given below:

a. Incremental Delivery. MOD will employ, as best practice suggests, an

incremental approach to developing SOA. Projects with useable, relevant and
timely output will form a significant part of demonstrating SOA capability and
securing buy-in. New projects will automatically deliver Information Services as part
of their solution to the requirements. Legacy systems with enduring relevance will
be able to produce Business Services at the point technology refresh (usually by
wrapping elements with a service-enabled layer to provide an SOA interface).
These projects will validate policy and governance decisions and successively lead
to easier and more effective uptake.

b. Define Business Functions. SOA is a business driven architecture. The first

step is to get a clear and uncontested picture of the relevant MOD business
functions that will source the services. This provides the context for the services, a
 working syntax, and acts as the link between business and technology. It also is the
basis for Communities of Interest (which are explained in Chapter 4).

c. Develop Core SOA Services 18 . The core services are those services that enable
the SOA to operate e.g. messaging and discovery 19 (defined in Chapter 2). The
MOD’s core services have already been derived and agreed as the Core SOA
Services 20 and are discussed in Chapter 2.

d. Policy and Governance. Policy (as outlined in this Handbook and the associated
JSP 602) states the overall direction of SOA, the technical approach, and the
frameworks and standards to be adhered to. Governance states the structures,
roles and responsibilities and the mechanisms by which SOA is to be managed.
These are covered in more depth in Chapter 4.

e. Working MOD SOA. It is MOD’s intention to increase SOA-based capability as

projects mature and at appropriate intervention points.

f. Architecture will be in MODAF.

Enterprise Service Bus

0129. SOA provides an alternative to point-to-point connections between pairs of

applications. In the SOA paradigm, the Enterprise Service Bus (ESB) provides a common
connection infrastructure, housing the Core SOA Services, and which can be used by all.
This requires the design and mandate of a common connection infrastructure that will be
used by everyone, and which allow applications to connect to any other under the control of
a consistent security policy. This common connection is an ESB 21 , 22 . ESBs are covered in
more detail in Chapter 2. NB. ESBs and Core SOA Services are not exactly synonomous
but the engine of an ESB consists of Core SOA Services.

Federation

0130. Federation was introduced in para 0115a. SOA promotes federation of the
architecture and for MOD; this will be done through an ESB, which includes the Defence
Information Infrastructure and any future static or deployed systems. The implications of
this are important for the organisation of any technical architecture team (see Chapter 4
Governance). The central team should concentrate on the infrastructure and the definition
of the services. Decisions within each relevant military function should remain the
responsibility of the local Community of Interest, which includes military, financial and
technical representation. The implications are important for the business managers and
operational commanders. SOA allows direct control of the business processes and the
services from each domain have to be ‘orchestrated’ to create a work flow that supports the

18
Defence Core SOA Services
19
These are NOT common services such as Mapping or Transport which are Business Information Services.
20
DG Info/IX/DMF-05/01 dated 23 Mar 2006. NETWORK ENTERPRISE CORE SOA1 SERVICES (NECS) User
Requirements Document V0.43
21
ESB is an open standards (all components), message-based (using standard message notation, protocols and transport),
distributed, integrations solution that provides routing, invocation and mediation services to reliably facilitate
interactions of disparate IT resources. .
22
Based on “Service Oriented World” Cheat Sheet by Brenda Michelson June 2005 (Patricia Seybold Group)
business process. This means that it is vital to have a clear definition of what the business
processes are and a clear business model in order to get full value from SOA. ESBs and
their are requirements are covered in Chapter 2 from para 0235.

SOA at The Tactical Level

0131. This area is not well served with cogent advice. The technology used to implement
the SOA concept in the strategic and deployed environments, may not be the same as in
the tactical environment. Ironically, unless a transformation service can be provided, in
some circumstances, the high bandwidth or low speed of web services may predicate
adoption of other (perhaps point to point) technologies. Such performance limitations are
the key reason to adopt a non-WS SOA design. Development will have to be coherent with
DII/BOWMAN in the battle space. Tactical systems planners and designers should in the
first instance contact Info X EA 1 for the latest advice.

SECTION V

PRINCIPLES OF MOD SOA

Basic Principles of SOA

0132. The basic principles of SOA are listed below:

a. MOD Business Information Services will be Mutually Exclusive and Collectively

Exhaustive (no overlap and no gaps);

b. Only Services approved by the Governance Regime (Chapter 4)) will be

deployed onto the MOD SOA;

c. WS-I Interoperability Profile will be the technical standard adopted;

d. The MOD SOA will be able to interface with non MOD organisations such as
coalition partners, industry and OGDs;

e. Services are the central organising concept of SOA;

f. Every service is defined by a formal contract that clearly separates the

functionality being provided from the technical implementation i.e. execution
environment;

g. Services should only interact with other services through their well-defined public
interfaces;

h. Services should be accessible through standardised technologies that are

available across a wide range of environments – this includes their invocation
mechanisms;

i. Services should be defined at a level of abstraction that corresponds to real

business activities and recognisable business functions so as to align business
needs and technical capabilities;
 j. Services should be loosely coupled;

k. Services should perform discrete tasks and provide simple interfaces to access
their functionality to encourage reuse and loose coupling;

l. Services should provide metadata that defines their capabilities and constraints,
and this metadata should be available in a repository, which itself can be accessed
through services. This allows service definitions to be inspected without needing
access to the service itself. This also allows services requesters to dynamically
locate and invoke the service.

Technical Characterisation of SOA

0133. SOA is an architectural style, in which data, information or applications are

presented to the network as services and made available within security constraints. It
decouples the information support offered to business processes from individual systems,
and enables them to be integrated, distributed, and accessed across organizational,
geographical, and technical platform boundaries. SOA is further characterised thus:

a. Loose coupling 23 of business processes and supporting IT.

b Service Interfaces are heterogeneous, can be dynamically discovered and

invoked, self contained, asynchronous and stateless.

c. Web services are ‘orchestrated’ to support business processes 24 .

d. SOA Business Services can be invoked on demand by end users or other

services, or event driven by processes between users or between automated
processes or applications.

e. MOD SOA is based on Web Services.

Build on Best Practice

0134. Industry experience demonstrates that choice of a start point for SOA is the most
difficult step. Successful SOAs go forward in a series of small steps, using clear metrics
from the outset to demonstrate the business and technology benefits which build credibility
within both the business and the IT communities i.e. an incremental approach. MOD will
adopt an incremental approach, using low initial investment to tackle small projects that
build credibility through demonstrating business value. The key is to tightly link each project
to a rapid return of business value, making each business case easier to justify and
generating support for the approach. The Governance mechanism will aim to prescribe a
common flexible methodology across for projects to employ.

23
Loose coupling in this IT context is used to indicate that a software component has easily defined interfaces and can
easily be updated and/or replaced without major integration work.
24
SOA can provide benefit in orchestrating components to aid a human decision on the battlefield (assessing information
from a range of discrete applications and sensors). It is not clear that Web Services are yet capable of supporting real-
time battle space applications. It may well be that some services are implemented as messages, CORBA or RMI, etc.
“Web services” implies SOAP and WSDL.
Service Enabling Legacy Systems 25

0135. Web Services can be used to create a contract between disparate systems such as
CORBA and J2EE and packaged applications. Most software systems understand Web
Services and getting them to interoperate requires contracts that both sides can agree to.
It is possible to service –enable legacy systems by defining WSDL (see Chapter 2)
contracts for them and providing SOAP (see Chapter 2) applications that can receive
SOAP messages and convert them to message level invocations. This enables effective
reuse of legacy assets which can fulfil enduring requirements without wholesale
replacement. It is possible to service enable almost any legacy systems including
mainframe (e.g. IMS); distributed object applications (e.g. J2EE); transaction processing
systems (e.g. Tuxedo) as well a numerous packaged applications and B2B systems.

Understand What is Different About SOA

0136. There are good examples of organisations which get SOA wrong by failing to
understand the fundamental differences between SOA and their previous arrangements.
Achieving a disconnected architecture is often the outcome; and the danger of introducing
Web Services technology in such situations is that problems manifest themselves relatively
slowly. Examples of such problems include:

a. Creation of services which are not composable;

b. Creation of non-standardised services;

c. Faulty partitioning of functional boundaries within services;

d. Proliferation of non-standard service descriptions which lead to increased

message volumes;

e. Failure to achieve the correct balance between the Depth and Breadth of
functional services.

Keep Early Work Simple

0137. Early projects should use simple architectures and minimise up-front technology
investment. For example, use open standards, typically application servers and ESBs.

Identify Benefits

0138. Business benefits will be clearly understandable if simple and easily measurable
metrics can be applied to chosen projects. These should be communicated to all
stakeholders and leveraged to justify successive projects which should be either bigger or
more complex but which reutilise the skills and infrastructure deployed for the first project.
This will also enable the number of reusable services made available for later projects to
increase.

25
Derived from Understanding SOA with Web Service s by Newcomer and Lomow (Independent Technology Guide –
Addison-Wesley) p181 et seq.
Get Service Level Abstractions Right

0139. They define all the important service characteristics.

a. End user interface – used by business user;

b. Business processes;

c. Services – model and define services , platform neutral;

d. Components and objects – to implement and execute services;

e. Data storage – data warehouses.

f. Cross cutting interface definitions, and security.

g. Service Level Interface Definitions. Clearly separate externally accessible from

execution environment (WSDL);

h. Service Level Data Model. XML schema. Defines which XML constructs and
libraries should be used;

i. Service Level Interaction Model. Modes available e.g. request;

j. Service Level Security – approach to e.g. authentication, authority and

encryption – defines SL security;

k. Service Level Management – approach to managing services e.g. deploying,

starting and Service Level management model.

Some Thoughts From Implementations

0140. Building a military SOA is not new and there are a number of ongoing developments
from which good experience can be leveraged 26 . Below are some of the more useful
observations:

a. Keep it simple. Simple business designs are “good” designs (for a long list of
sound business reasons including cost of change and lower risk of early life failure:
reasons mainly to do with ability for “average” designers of new capability to
understand existing designs, and so use them successfully or avoid re-implementing
them).

b. Design for reuse. Most business processes use sub-systems that are common
(called ‘core’ services here). Business process design can be generalised if
common needs are pooled, leading to a more generic design that appears externally
to be simpler. This is the first practical aspect of SOA.

26
DODAF and the Swedish DOD implementations.
 c. Risk is inherent and cannot be removed. System design has an element of
judgement. When generalising there is a high risk of creating something that is too
abstract to be usable; when keeping something specific there is a danger of
duplicating something in an inconsistent way. Whatever conclusion is reached
about whether to generalise, the optimum solution is likely to change over time. It is
also important to maintain an audit trail of decisions.

d. Establish key Governance structures to ensure the SOA is acknowledged and

policed.

e. Understand the dependencies. Review existing programmes such as DII/F to

determine a relevant and timely convergence part for SOA.

f. Look at the information architecture. How information flows, how it is organised

and how it should be exploited (information exploitation) are all key factors in SOA
design. A populated information architecture is an essential part of the design
process.

Standardise The SOA

0141. Applications sourced from different designs hamper future integration effort and
generally lead to more expense and system fragility. If SOAs are to be properly exploited,
the laid down design standards in Chapter 2 must be followed - interoperability is the
eventual goal. MOD will use WS-I standards. WS-I is the main interoperability focus
across web service implementation. It sponsors several workgroups to resolve
incompatibilities and provides common interpretation of other specs and testing tools etc. to
help with conformance. These standards ensure there is consistency in design and
interaction of the services which encapsulate business logic. Failure to adhere to
standards could result in:

a. Differential implementation of service extensions;

b. Service descriptions with poor interfaces or semantics or both;

c. Different schema representing the same information because of incompatible

data representation.

0142. Services created by an SOA should directly support MOD services to FLCs and
other customers. The processes and methods defined must are services oriented. The
development tools must also be oriented to creating and deploying the services. Only then
can there be appropriate focus on defining and deploying business and technical services
that are reusable across multiple users, applications and channels. The aim is to end up
with applications which are easily built from internal and external sources.

Test the performance of SOA components

0143. MOD SOAs rely on Web services; this deepens the dependence on XML data
representation. In addition, as scope and functionality increase, the volume of message-
based communications as well the number of layers (e.g. encryption) increase. In the early
stages of planning SOA, it is important to have as accurate an estimate of the whole
system messaging capacity as possible, and to test the different components that will be
used e.g. processors for SOAP and XML (See Chapter 2 for detail on XML and SOAP).

Create a transition plan

0144. A comprehensive transition plan enables controlled migration of, and coherence
between technological, organisational and architectural changes. A standard People
Process Technology (PP&T) approach will work as long as it is basically thorough but also
covers issues such as:

a. Coherence between migrating and non-migrating elements;

b. Phased migration plan and transition architectures;

c. Impact analysis on PP&T;

d. Plan to keep pace with technology/standards development.

Understand the security requirements SOA

0145. A sound understanding of how security issues will affect the developing SOA is
essential. Interoperability of security is as important as functional considerations.
Agreement on how security rules are defined and enforced across the different services is
essential and must be planned from the start. Security will be covered in the next revision
of this Handbook.

Understand XML

0146. SOAs are based on XML or their derivatives. If the XML data structure and
validations are not standardised, the quality of processing may be severely affected e.g.
unnecessary validated multiple times. Early attention needs to be paid to the manner in
which the XML technologies represent process and validate data/information as they flow
through the architecture.

Align with governance

0147. It is especially important that the higher level of the governance mechanism (SOA
Board) is closely aligned with the existing MOD corporate governance processes. For
lower levels, a more unilateral mindset might be adopted – one which avoids being unduly
constrained by remainder of the MOD governance structures. Without this high level
alignment at the corporate planning level, a disconnect between business intent and both
service oriented development and delivery may well occur.

Organisational agility

0148. A service oriented approach will help the MOD create a more agile and responsive
organisation, by focusing on incremental capability. SOA more naturally aligns with
incremental capability delivery, than does the more traditional approach to system
development. An SOA can add new functionality, expose existing functionality to new
channels and adapt functionality according to requirement. Most importantly. The cost and
effort to respond and adapt to business or technology related change is reduced. Most
importantly, an SOA can compose business solutions from others.

Lower Through Life Costs

0149. Building reusable services may result in slightly increased development effort and
require the use of design standards by leveraging subsequent reuse lowers Through Life
costs. Such reuse of services reduces IT development and maintenance time and costs. In
addition, the cost and effort of application development is reduced as standardised XML
data representation is achieved. The cost of scaling communications infrastructure should
also reduce, as a single communications technology is required to support the federated
part of the enterprise.

Architectural Partitioning

0150. Treating software systems as reusable services and designing integration in a

service orientated manner is the best way to support diverse development life cycle
‘speeds’ caused by independent development teams operating according to external
constraints; with defined service interfaces agreed between different teams, they can act
more or less independently provided they continue to support the agreed service
specifications. Teams can also make use of the most appropriate technology and technical
skills available, including outsourcing or ‘off-shoring’. The Governance arrangements will
provide a vehicle for exploitation of this including collaboration with industry.

Incremental Deployment and Maintenance

0151. The SOA approach allows for a gradual adoption of service approaches, which will
allow the costs to be the spread across multiple projects. A wrapping legacy (and ‘future
legacy’ system as services is an effective way to preserve existing investments.

Reuse of Services

0152. Once the services infrastructure is established and services are available for wide
reuse, and the procurement strategy allows simpler procurements, it will then be possible
to deploy applications faster and at lower cost. Services based applications can also be
adapted and changed more easily. Service orientation promotes the design of services that
are inherently reusable. Designing services to support reuse from the start enables
increased opportunities for leveraging existing automation logic. Properly designed
services fulfil both immediate requirements whilst supporting a degree of reuse by future
requestors. This establishes a permissive investment environment for the future.

Improved integration and interoperability

0153. SOA solutions rely on ESB delivered across an Enterprise Architecture and consist
of inherently interoperable services. Vendor-neutral Web services communications
frameworks allow highly standardised service descriptions and message structures,
resulting in intrinsic interoperability that helps cross-application integration.
Streamlined architectures and solutions

0154. The concept of composition is fundamental to SOA. Whole platforms e.g. the WS-*
platform, can be built entirely on the principle of composability. This aspect of SOA can
lead to highly optimised automation environments, where only the technologies required
actually become part of the architecture.

Leveraging the legacy investment

0155. The acceptance of Web services technology has spawned a large adapter market.
This enables legacy environments to participate in service-oriented integration
architectures. This enables progress towards a state of federation, where previously
isolated environments now can interoperate without requiring the development of
expensive and sometimes fragile point-to-point integration channels. However, legacy
system adapters can be expensive and acquisition needs to part of an overall strategy to
incorporate legacy applications into an SOA.

Establishing standardised XML data representation

0156. At its most fundamental level, SOA is built upon and driven by XML. As a result, an
adoption of SOA leads to the opportunity to fully leverage the XML data representation
platform. A standardised data representation reduces the underlying complexity of all
affected application environments. Establishing XML data representation architecture
becomes a necessity, providing organisations with the opportunity to achieve a broad level
of standardisation. (NB. SOA doesn’t mean XML and vice versa)

Alternatives

0157. A key feature of service-oriented enterprise environments is the support of ‘best-of-

breed’ technology. Because it establishes a vendor-neutral communications network, it will
free the MOD from being chained to a single proprietary development and/or middleware
platform. For any given piece of automation that can expose an adequate service interface,
there is a choice as to build the service that implements it.

Organisational agility

0158. Much of service-orientation is based on the assumption that what is built today will
evolve over time. One of the primary benefits of a well designed SOA is to protect against
the impact of this evolution. When accommodating change becomes the norm in distributed
solution design, qualities such as reuse and interoperability become commonplace. The
predictability of these qualities within the enterprise leads to a reliable level of
organisational agility. However, this is only attainable through proper design and
standardisation. A standardised technical environment comprised of loosely coupled,
composable and interoperable and potentially reusable services establish a more adaptive
automation environment. By abstracting business logic and technology into specialised
service layers, SOA can establish a loosely-coupled relationship between these two
enterprise domains. This allows each domain to evolve independently and adapt to
changes imposed by the other, as required.
0159. Besides the core Web services (SOAP and WSDL), a wide array of extended Web
Services specifications for security, reliability, transactions, metadata management, and
orchestration are well on the way toward standardisation, providing SOA-based solutions
with the required enterprise qualities of service to support mission-critical programmes and
activities.

Separation

0160. The greater separation of interface from execution environment in Web Services
facilitates the separation of work responsibilities as well. Separating the service description
from its technology implementation means that businesses can think about and plan IT
investments around the realisation of operational business considerations more so than the
capabilities of any individual technology or product.

Consumption

27
0161. In SOA applications, common functions such as name look up or NSN validation
or security checks are implemented using services. Using services reduces the amount of
deployed code but also reduces the management, maintenance, and support burden by
centralising the code and managing its access. However, the performance implications of
accessing services instead of using internal functions must be assessed because using a
service can consume more computing resources that usable code libraries.

Service Design

0162. The key to successful SOA is determining the correct design and function of the
services in the reusable service library, which should ultimately reflect the operational
characteristics of the organisations such as how intermodal container transfer works.

0163. The operational characteristics of the business are what need to be automated, and
the SOA projects must ensure that the reusable software service is properly aligned with
the operational business processes. The successful alignment of business services and
their implementation in software that operational business processes can be changed
quickly and easily as external environmental changes allow an organisation to adapt and
evolve.

0164. It is easier to separate the presentation logic from the business logic if the latter is
service-enabled. It is easier to connect mobile devices and GUIs to applications when
business logic layer is service-enabled. Applications can exchange data easier because
Web Services represent a common standard across all types of software.

Challenges to Adoption.

0165. The main challenges to adoption of SOA include:

a. Training. There must be adequate staff training and maintaining the level of
discipline required to ensure the services develop are reusable.

27
NATO Stock Number
 b. Coherence. The existence of an individual service is of little value unless it fits
into a larger collection of services that can be consumed by multiple applications.

c. Applications may need to be modified in order to participate in SOA. Some may

not have a callable interface that can be service-enabled; others might not. Some
might only be accessible via file transfer and may need additional programs for
service enablement.

SECTION VI

SUMMARY

The SOA Stack

0166. Figure 7 is a simple stack model intended to help summarise this chapter; and to
put into context chapters that follow. The diagram is a simple representation of the key
concepts in an SOA arranged in a logical stack.

MOD SOA Stack Model

Business Process Orchestration

Systems & Service Management

Information Assurance

Presentation

Business Services
Services

MODAF
Core SOA Services

Applications

Infrastructure &
Communications

Figure 7 MOD SOA Stack Model

a. The Infrastructure and Communications Layer which is made up of networks,

computers etc (hardware). It provides the connectivity between systems.

b. The Applications layer contains those applications (software) that are deployed
and run on the infrastructure.

c. Information Assurance and Systems &Service Management are cross-cutting

vertical functions.

d. Business Process Orchestration refers to the operational activity based on the

services provided. Systems and tools, methodologies that reflect how organisations
identify, deploy such business processes. BPO can exploit the architectural work of
an SOA to better automate business processes. Leads to better alignment of
business processes with outcomes and ensuring that IT supports the processes.

e. Business Services, Core SOA Services (see Chapter 2) and Presentation

Services were introduced in this chapter.

f. MODAF. The entire SOA is modelled in MODAF which is the subject to Chapter
3.
 CHAPTER 2

STANDARDS AND SERVICES

This chapter has some technical content and compliance with parts of it is MANDATORY.
It introduces SOA standards and should be considered as Work in Progress. It is aimed
primarily at architects. It also introduces Core SOA Services i.e. those that are common to
all others and which enable the latter to be seen, found and accessed. They are the basis
of an SOA. Architects need to understand this chapter and although simplified, the core
service definitions are relatively technical. Users who seek to access services need not
understand Core SOA Services. A hierarchy of services based on a MOD Functional
Model is also described and this will become important as new services are added over
time.

SECTION I

OVERVIEW

Web Services

0201. The Services and the standards to which they are designed is what ultimately will
increase agility and reduce costs. It is an area of tremendous growth in industry and there
are a number of different paths that can be taken. Although one can implement SOA using
any service-based technology, the MOD policy is to use Web Services based on Open
Standards that are widely accepted. This chapter specifies the standards it has been
agreed to adopt, signposts some of the key future developments and issues, and provides
advice on what to do when faced with a gap in advice. It is accepted that standards are still
developing and will therefore change. This Chapter covers the basic web tools, a
description of the Core SOA Services and the Business Services, and further details of the
Enterprise Service Bus (ESB). This is an important chapter in laying the foundations for
the agility and flexibility required to support Network Enabled Capability within a receding
budget.

SECTION II

SOA AND WEB SERVICES TOOLS

This section describes some of the main (MANDATORY) tools to be used; some of which
have already been tested in MOD SOA pilot projects. SOAs are built on Web Services
standards have gained broad industry acceptance. These standards (also referred to as
web service specifications) also provide greater interoperability and some protection from
lock-in to proprietary vendor software. The versions to be used are also laid down in
Section 3. It does not cover the panoply of implementation methods which will also need to
be compliant with the standards herein.
Why have SOA Standards?

0202. Service-Oriented Architectures are intended to make the enterprise more agile and
reduce redundancy. Reuse is a key factor in SOA, and reuse of services in large
organisations like the MOD is only possible if there are standards. The supporting
standards need to ensure that ensure services are interoperable at an operational level.
These standards ensure there is consistency in design and interaction of the services
which encapsulate business logic. Failure to adhere to standards could result in:

a. Differential implementation of service extensions and therefore capability.

b. Service descriptions with poor interfaces or semantics or both and therefore poor
services delivery.

SECTION III

ENABLING STANDARDS

Standards for Automated Services

0203. Most services usually involve the exchange of information (even if the information is
simply an instruction to the provider to invoke the service) and it is important that the format
of this information is standardised to enable re-use of the service. In the case of System
Services, this is doubly important as the service consumer and provider may both be
automated systems with no ability to negotiate or infer meaning from improperly structured
information.

Web Services

0204. It is likely that most Automated Services will be implemented as Web Services. Web
Services detailed in para 0226 and 0227 are to be used for SOA. There follows a generic
description of the commonly used services.

eXtensible Markup language (XML)

0205. XML is a markup language for describing data in message payloads in document
format. It provides a flexible framework for organising and sharing data. XML is an open
standard. It represents a flexible framework for organising and sharing data. XML is used
heavily within the XML messaging, service description and service discovery layers of the
web service protocol stack. Interface creation and application development is speeded up
markedly by using XML. Systems no longer need to build complex one to one data
interfaces with other systems. They should be sharing XML-based information saving
significant effort in systems integration costs and enabling true agility.

Hypertext Markup Language (HTTP)

0206. HTTP and its derivatives are request/response protocols between clients and
servers used to transfer or convey information.
Simple Object Access Protocol (SOAP)

0207. SOAP is a protocol for exchanging XML-based messages over a computer network,
normally using HTTP. IT can be used in a variety of messaging systems and can be
delivered via a variety of transport protocols. SOAP enables applications to easily connect
to remote services and invoke remote methods. For example, a client application can
immediately add language translation to its set of features by locating the appropriate
SOAP service and invoking the appropriate method. SOAP represents a cornerstone of
web service architecture, enabling diverse applications to easily exchange services and
data.

Business Process Execution Language (BPEL)

0208. BPEL provides a standard way of describing business processes that are based on
web services. It provides the facilities that are required in complex business protocols,
such as the description of behaviour dependant on data sent between services, exception
management and recovery, and coordination between business partners for complex
processes of extended duration.

Universal Description Discovery and Integration (UDDI)

0209. UDDI is a technical specification for describing, discovering and integrating web
services. It is a critical part of the web services protocol toolkit, and enables organisations
to both publish and find web services. UDDI is a technical specification for building a
distributed directory of businesses and web services. Data is stored within a specific XML
format and the UDDI specification includes details for searching existing data and
publishing new data. It is also forms the UDDI Business Registry, which enables
organisations (or parts thereof) to search existing UDDI data, and to register them and their
services.

Web Services Description Language (WSDL)

0210. WSDL is a specification defining how to describe web services in a common XML
grammar. The XML-based service description describes the public interface, protocol
bindings and message formats required to interact with a web service in simple terms,
WSDL represents a contract between the service requestor and the service provider.
WSDL is platform and language independent and is used primarily to describe SOAP
services. Using WSDL, an agent can locate a web service and invoke any of its publicly
available functions. With WSDL-aware tools, this can be automated, enabling applications
to easily integrate new services with little or no manual code. WSDL therefore represents
another cornerstone of the web service architecture, because it provides a common
language for describing services and a platform for automatically integrating those
services. WSDL describes four critical pieces of data:

a. Interface information describing all publicly available functions.

b. Data types information for all message requests and message responses.

c. Binding information about the transport protocol to be used.

 d. Address information for locating the specific service.

MooD

0211. MooD is a modelling tool, widely used in MOD. In an SOA context it is useful
because it can be used to build architectures and it provides a model-driven capability
which maintains the integrity of the solution during change. MooD can provide a business-
driven, component-based approach which allows the enterprise model to be re-configured
to match new business developments. Business and technology designs can be
storyboarded, tested, re-arranged and re-orchestrated.

SECTION IV

MOD CORE SOA SERVICES

This section describes the first of two key categories of services – the Core SOA Services.
These services enable the Business Services to work. Core SOA Services have already
been trialled at Coalition Warrior Interoperability Demonstration (CWID) 07 28 . Core SOA
Services and the key instantiation of them, the Enterprise Service Bus, are the subject of
the next three sections.

What are MOD Core SOA Services?

0212. Core services are the enablers that are used by Business Services and users
across the whole enterprise. They are independent of business process and context; and
they are ubiquitous. It is therefore essential that the core services are standardised and
specified very precisely in order to facilitate their reuse. Core SOA Services are absolutely
vital in maintaining consistency within the technical environment. The next paragraphs
describe the MOD Core SOA Services 29 . It should be noted that this is an area infested
with confusing terminology and that care has been taken to ensure that the MOD Core
SOA Services here cover functionality demonstrated to be critical in both Defence
implementations and commercially. The MOD SOA Core Services are:

a. Discovery

b. Mediation

c. Security

d. Metadata Repository

e. Service Management

f. Messaging

g. Orchestration

28
In the first instance, contact Info IX EA1
29
Based on various US DOD/UK NECS definitions and UK MoD NECS (NCES) Definitions – Final Version dated Aug
2007
Discovery

0213. Discovery is the process of identifying required services. This can be design time
(at the point of design) or run time (when it is being used). Where one looks for a service
is the registry, which is based on commercial products that support the UDDI standard.
The registry provides a services directory for all MOD Core SOA Services and agents, and
the dynamic publishing and discovery of service definitions. The easiest way of
understanding this is to consider it as a book of Yellow Pages which organize businesses
according to their products or services. Discovery works by providing the
publishing/advertising of service definitions, descriptions, metadata, and accessibility –
from sources ranging from web services to devices and business functions. It is important
because:

a. It directs agents to the right information source;

b. It allows location of specific information in a service registry and uses it to reduce

time and effort, as well as promoting reuse;

c. It enables access to metadata for published services from centralized registries,

promoting interoperability across the MOD and a unified understanding of service
metadata;

d. It allows use of discoverable services without changing software, thereby

enabling true loose coupling among services, and collaborative development. This
assumes that the software is capable of working with the semantics and the syntax
of the service i.e. it may require mediation (see next paragraph).

e. It allows discovery and rediscovery of services whenever required and

irrespective of location (agent and the services).

Mediation

0214. Mediation refers to a set of services to overcome the fact that data and services in
any enterprise environment are represented in a variety of formats e.g. mils and
degrees/seconds, or Celsius/Kelvin. It is therefore a data conversion and format
translation capability. Mediation services help bridge information exchange between data
producers and consumers e.g. data transformation, aggregation, service orchestration
(see para 0219) and adaptation. The basic operation of the mediation services can be
described as follows: data transformation changes data from one form to another; service
orchestration and aggregation works on behalf of a consumer to coordinate a workflow;
and service adaptation solves the problem of converting between the rules used by one
service into that required by another whilst maintaining the integrity of the message being
sent. It is important because:

a. It hides the complexity of chaining multiple services (Service Orchestration and

Aggregation);

b. It allows entities in the enterprise to interoperate without either party having to

conform to the other's protocols or technologies – adaptation;
 c. It translates data between formats and supports legacy data throughout the
enterprise (transformation)

d. It provides data to mobile devices/ access devices with low connectivity

restrictions.

e. It provides for conversion and semantic interoperability.

Security

0215. The primary goal of Security is to ensure SOA services can be invoked securely i.e.
which agents may discover and consume services and under what conditions. For
example, an individual who is updating personal information will have full access to the HR
services on the Joint Personnel Administration systems as opposed to a colleague who
may only have partial read access. The capabilities encompassed by this service are wide
and include a Service Security interface and design specification, functional components
that enforce role-based access control, authorisation queries and responses, retrieval of
policies for service provider resources, policy administration and a certification validation
service. MOD SOAs will generally sit on the Defence Information Infrastructure or similar
secure communication infrastructure (non-DII programmes and infrastructure). The
underlying accredited security mechanisms will have be relied upon. This may not be as
simple as stated because of both compliance and design issues but all instances where
there are issues, need to be referred to the Governance mechanism covered in Chapter 4.
Security is important because:

a. It ensures that only authorized users (service consumers, services providers,

and applications) can access SOA Services (Authentication and Authorisation);

b. It protects messages or documents so that they cannot be made available to

those without authorisation (Confidentiality);

c. It provides protection against unauthorised alteration of messages/interference

during transit. (Data Integrity);

d. It ensures that a sender cannot deny a message already sent, and a receiver
cannot deny a message already received. (Non-repudiation);

e. It provides secure logging and auditing. (Accountability);

f. It provides the interfaces that enable each organization (or part) to implement its
own solution (interoperability).

g. It enables coalition interoperability through federated identity management. The

concept is that once a user has authenticated on their own system e.g. DII, that
authentication is trusted by other systems without the need for a centralised Global
Address List.
Metadata Repository

0216. A metadata repository refers to those definitions, mappings and other

characteristics used to describe, discover, and access services. It is a database of data
about data (metadata) 30 . The purpose of the metadata repository is to provide a consistent
and reliable means of access to data. The metadata repository contains data access rules
about what information is available from the data services. It also contains business and
transformation rules. The former involve conversion of data across systems or applying
business operations to data e.g. extracting items from an order. The latter involves
conversion fro reconciling different programmes and messaging systems e.g. converting
message headers. The repository itself may be stored in a physical location or may be a
virtual database, in which metadata is drawn from separate sources. Metadata may include
information about how to access specific data, or more detail about it. MOD uses several
types of metadata e.g. Descriptive, Structural, Semantic, Usage, and Administrative. These
services are important because:

a. They promote data visibility and reusability across the enterprise;

b. They identify data that is used frequently;

c. They allow data to be viewed by taxonomy;

d. They enable systems to interact.

Service Management.

0217. Service management supports deploying, monitoring, starting and stopping

services. Management of these services is a continuous process of managing, measuring,
reporting, and improving the service level (quality of service) of systems and applications.
As the number of services deployed increases, the ability to effectively manage them
becomes critical. Monitoring Web Services allows service providers and service
management administrators to collect and evaluate mission critical, service vital signs such
as service performance metrics and data. Service Management will integrate with several
other service management offerings to provide accurate system performance information.
The sorts of capabilities provided include the monitoring and measurement of service
performance; monitoring and enforcement of SLA compliance; service lifecycle
management; activity logging and audit; and the prediction and notification of service
problems and causes. Service Management is important because:

a. It monitors and ensures service levels of critical components, providing a report

about service health and notification of issues to service providers;

b. It monitors Service Level Agreement (SLA) compliance. It helps service

providers to achieve service promises by monitoring service-level objectives and
alerting service providers when performance is predicted to get close to threshold
values;

30
Definition from www.searchoracle.com
 c. It enables the detection and handling of exceptions by defining exception
conditions, detecting and alerting exceptions, and automatically taking corrective
actions to handle exceptions (in real-time);

d. It provides insight into the usage of services by capturing usage data; helping
with the evaluation of the usefulness of a services; and whether more services are
required;

e. It provides distributed management of services by providing the ability to

configure, manage, and track distributed services remotely. Don’t forget trust and
security.

Messaging

0218. This service provides a federated, distributed, and fault-tolerant SOA messaging
capability. It uses multiple message brokers which could be within different physical
implementation. This supports the distributed and federated MOD business and delivers
scalable and interoperable event notification to agents. The service leverages and
supports publish and subscribe, peer-to-peer and queuing. It supports the configuration of
service level parameters for a published message including its priority and precedence. In
addition, it provides guaranteed delivery of messages to disconnected users or applications
by queuing them for delivery on reconnection. It is important because:

a. It promotes decoupling of information among producers and consumers.

Asynchronous point-to-multipoint allows many end users to receive content as it is
published;

b. It provides guaranteed messaging which allows subscribers to receive queued

messages after reconnecting to the network. Producers and consumers do not need
to be continuously connected to the network to guarantee delivery capabilities;

c. It provides client-configurable Quality of Service parameters which allow users to

specify message properties that influence delivery. Messages can be ordered based
on user defined priority and precedence.

d. It provides Integration with other core services for enhanced security and
administration.

Service Orchestration

0219. Orchestration describes how web services can interact with each other at the
message level, including the business logic and execution order of the interactions. These
interactions may span applications and/or organizations, and result in a long lived,
transactional, multi-step process model 31 . It helps to state what services are required to
support business processes and the logical flows between them. Through this it is possible
to support the service “chaining” with continuity of information. The foci are implementation
and workflow. [NB. This is different to Choreography which tracks the sequence of

31
From “Web Service Orchestration – a review of emerging technologies, tools, and standards” Charles Peltz Hewlett
Packard Jan 2003
messages that may involve multiple parties and multiple sources, including customers,
suppliers, and partners. Choreography is typically associated with the public message
exchanges that occur between multiple web services, rather than a specific business
process that is executed by a single party. The focal points for choreography are
collaboration and protocols.]

Core and Business Services

0220. Figure 8 below outlines how the SOA Core Services fit with the MOD Business
Functions to provide the basis of an SOA. Users simply access services on the portal. The
Core SOA Services enable the Business services (which are based on the functional
breakdown) to be administered, created, seen, found, and accessed. The model depicted
will contribute to the implementation of SOA by identifying potential Communities of Interest
(COI) to exercise ownership and governance of specific information areas and associated
business rules and so develop the requisite service or services (These are covered in
depth in Chapter 4 – Governance). Services may well be made up from different functional
baskets and in such cases, the relevant COIs would be expected to co-develop them. How
these Functions will be transformed into services is the covered next and in Annex
A/Chapter 4.

Figure 8 Linkage of Core to Business Services

SECTION V

MOD ENTERPRISE SERVICE BUS

The next two sections detail the Enterprise Service Bus (ESB) – the engine of which are
the MOD Core SOA Services. A federated ESB was trialled on CWID 07 and is now being
developed further in the Joint Supply Chain. The MOD’s ESB Concept in known as Fred
(which is not an acronym).

Best Practice

0221. The ESB represents the “best practice” business-need-driven approach to

Capability Integration which the Information Technology and Services industry has found to
be more efficient, flexible and cost-effective than the previous vendor-system to vendor-
system “system of systems” approach 32 . The MOD is developing a federated ESB
approach which will effectively support the need for rapid creation and deployment of new
services, whilst maintaining vendor and platform neutrality. New services are likely to be in
continual demand for in order to adapt to evolving operational requirements.

Basic Operation

0222. The basic operation of the ESB is:

a. ESB accepts information requests from service requesters.

b. ESB locates and consults a metadata registry to determine assembly of

requested information from data services;

c. ESB invokes the data services - retrieves data from data service providers;

d. ESB aggregates the results - applies rules from data transformation service to
remove duplicate data and convert collected data into a format compliant with
service contract;

e. ESB sends results to service requester.

Software Approach

0223. The ESB lies between the business applications and enables communication
among them. It should be able to replace all direct contact with the applications on the bus,
so that all communication takes place via the bus. In order to do this, the bus must
encapsulate the functionality offered by its component applications in a meaningful way.
This is typically accomplished through the use of an enterprise message model. The
message model will define a standard set of messages that the ESB will both transmit and
receive. On receipt of a message, it routes it to the appropriate application. Where an
application was not built with the message model in mind, the ESB will have to transform
the message into a legacy format that is understandable by the application – this is done by
an adapter. If the message model does not completely encapsulate the applications'
32
UK MOD NECS (NECS) Definitions Final V1.5
functionality, then other applications that this functionality will bypass the bus and invoke
the applications directly and so negates some of the advantages of using an ESB. Using
Web Services means that the message exchange is almost always done in a platform-
independent manner. This allows the ESB to integrate applications that run on many
different systems.

ESB Characteristics

0224. An ESB usually exhibits the following:

a. usually operating-system and programming-language agnostic; for example, it

should enable interoperability between Java and .NET applications;

b. uses XML as the standard communication language;

c. supports web-services standards;

d. includes a standardised security model to authorize, authenticate and audit use

of the ESB;

e. facilitate the transformation of data formats and values, it includes transformation

services between the format of the sending application and the receiving application;

f. includes validation against schemas for sending and receiving messages;

g. can uniformly apply business rules, enriching messages from other sources, the
splitting and combining of multiple messages and the handling of exceptions;

h. can provide a unified abstraction across multiple layers;

i. can route or transform messages conditionally, based on a non-centralized

policy (i.e. no central rules-engine needs to be present;

j. is monitored for various Service Level Agreement threshold message latencies

and other SLA characteristics;

k. supports queuing, holding messages if applications are temporarily unavailable.

SECTION VI

FRED

The MOD’s Fred Concept

0225. The descriptive labels “Fredlet, Fred and Frederick” were selected during the
MOD/Industry workshops because they were simple, vendor neutral and neither acronyms
nor reserved words. Figure 9 below provides a conceptual construct within which MOD’s
and related ESBs will provide a defence SOA. Some parts of this were trialled in CWID 07
and will be further trialled in CWID 08. It demonstrates the potential scale and benefits of
the undertaking and sustains the requirement for vendor neutrality.
 GLOBAL DEFENCE AND SECURITY ENVIRONMENT

Coalition
Frederick - NATO
Users
equivalents –
e.g
Business Services NATO/OCCAR
Frederick - Nation
Enterprise Service Bus

Users

Core SOA Services

Business Services

Frederick - UK Fred – OGD

Users Enterprise Service Bus

Fred – OEM Business Services Core SOA Services Other nation

Users equivalents
Enterprise Service Bus

Business Services
Fred - MOD Core SOA Services
Users

Enterprise Service Bus

Business Services
UK federated
Core SOA Services

Enterprise Service Bus

ESB

Core SOA Services

ESB provided by
more than one vendor
for each org

Figure 9 - FRED Schematic

Components

0226. The components in the ESB schematic above are:

a. Project Level – this represents an individual SOA/ESB - sourced from various

vendors to meet specific COI project or programme needs –referred to as a Fredlet.

b. Organisational Level – this represents a heterogeneous SOA/ESB within an

organisation e.g. DE&S –referred to as a Fred.

c. National Level – this represents an integrated and interconnected set of Logical

SOA/ESBs at national or coalition level - referred to as a Frederick.

d. Global Level – the Global Defence and Security Environment encompassing

contributions worldwide.

Project Level – Fredlet

0227. The ESB has provided a programme-specific information and integration capability
for the JC2SP programme and has now been extended to two logistics pilot projects. This
will develop, test and prove the tenets for a wider SOA/ESB.
National Level

0228. The UK MOD SOA will comprise a hierarchy of Federated Enterprise Service Buses
(ESB) supplied by a number of different vendors utilising potentially different technologies.
Open standards will provide the required degree of flexibility, integration and
interoperability. UK MOD ESB will be a heterogeneous environment composed of new and
legacy systems within various parts of the MOD. This means end-to-end from partners and
suppliers to the front end of the battle space. It also includes the legacy environments of
Other Government Departments (OGDs), Agencies and Non Government Organisations
(NGOs) with whom the MoD must collaborate.

Development.

0229. The ESB may eventually be extended to encompass integration and interoperation
with the SOA environments of coalition partners. This means that the ESB may be required
to securely and reliably provide MOD Services to users and support reciprocal services e.g.
meteorological services and coalition Common Operating Picture. Once mature, the ESB
will enable MoD to effectively and efficiently change its operational processes and
organisational structure to meet new requirements. The initial deployments of the ESB will
enable MoD to do what it does today, better, and in a more agile fashion – future
deployments will enable MoD to do better things – in essence, the ESB will offer MoD a
robust NEC Transformational Capability.

Issues to Develop

0230. A number of issues require significantly more work. These are:

a. ESB must be secure. Security may be multi level, role-based or event–based.

The Security requirements associated with Secure Sharing of data and Information
will have a significant impact in this area. The next revision of this Handbook will
contain specific guidance.

b. Choreography. The ESB will be required to offer users the ability to search for a
particular service that may meet their immediate needs. It will also be required to
offer specific COIs the ability to change the connections between sets of services
(choreograph) to create support for other, higher or new business functionality.

c. Dynamic Registry. The ESB will contain a dynamic registry (and registry
management function) of all available Services in the ESB.

d. Front end manipulation. The degree to which military users in operational

theatres will be require the ability to adapt existing sets of services to meet new
requirements, will determine the level of sophistication of service registries and
repositories. These will need to be kept synchronised across the relevant
interconnected parties and systems. This advanced use of SOA will require the
Governance model to cover application creation and usage.

e. Quality of Service. QOS issues will become important as more E2E capability is
sought. Service levels between various interconnected ESB in MOD/UK may require
negotiation prior to deployment.
 f. The scope of many of SOA standards is further refined by the use of extensibility
points within the standard. Their use may impair integration or interoperability (they
allow leeway for standards implementations to be different) and will have to be
negotiated or documented in some fashion by the parties who create or consume or
extend the usage of a particular service within an SOA or a federation of SOAs.

ESB Functions

0231. In order to support an Enterprise-level SOA, it is widely held that an ESB must be
able to facilitate the following functions that are described in Table 1 below 33 .

Message processing Management of Autonomic Modelling

Functions
Encoded logic Administration capability Object modelling
Content-based logic Service provision and registering Common business object models
Message and data transformations Logging Data format libraries
Service/message aggregation and Metering Public versus private models for B2B
correlation Monitoring integration
Validation Integration to systems and Development and deployment tools
Intermediaries administration tools
Object identity mapping Self monitoring
Store and forward Self management
Infrastructure Intelligence Communications Service Interaction
Business rules Routing Service interface definition (WSDL)
Policy driven behaviour, particularly for Addressing Substitution of service
service level , security and quality of Protocols and standards (HTTP, implementation
service capabilities HTTPS) Service messaging models required
Pattern recognition Publish/subscribe for communication and integration
Response/request (SOAP and XML)
Fire and forget events Service directory and discovery
Synchronous and asynchronous
messaging
Integration Quality of Service Security
Database Transactions (WS-based) Authentication
Existing and application adapters Assured Delivery (WS-based) Authorisation
Connectivity to enterprise applications Non-repudiation
integration middleware Confidentiality
Service mapping Security Standards (WS-Based)
Protocol transformation
Data enrichment
Application server environments (.NET)
Language for service invocation (JAVA,
C#)
Service Level
Performance (response time,
throughput and capacity)
Availability
Other continuous measure that might
form the basis of contracts or
agreements

Table 1 ESB Requirements

33
Adapted from UK MoD NECS (NCES) Definitions Final V1.5 dated Aug 2007.
Exploitation

0232. By adopting this “style” of SOA operation, MoD will be better able to create Agile
IS/IT support that will enable it fully exploit the new ways of working offered by Service
Orientation.

Security

0233. Security will be covered in the next update of this Handbook. For services, as for
other information technologies, security consists of understanding the potential threats an
attacker may mount and applying operational, physical, and technological
countermeasures to reduce the risk of a successful attack to an acceptable level. Because
an "acceptable level of risk" varies hugely depending on the application, and because costs
of implementing countermeasures is also highly variable, there can be no universal "right
answer" for securing Services and access to Services. Choosing the absolutely correct
balance of countermeasures and acceptable risk can only be done on a case by case
basis. However, there are common patterns of countermeasures that experience shows
reduce the risks to acceptable levels for many services. The WS-I Profile adopts, but does
not mandate, use of the most widely used of these: HTTP secured with either TLS 1.0 or
SSL 3.0 (HTTPS). That is, conformant Web services may use HTTPS; they may also use
other countermeasure technologies or none at all. HTTPS is widely regarded as a mature
standard for encrypted transport connections to provide a basic level of confidentiality.
HTTPS thus forms the first and simplest means of achieving some basic security features
that are required by many real-world Web service applications.

SECTION VII

BUSINESS SERVICES

This section introduces the Business Function model which will form the basis of Business
Services.

Business Function Decomposition 34

0234. The underpinning precept is that business drives the SOA. The importance of this
is that the business functions are enduring and that the Business Services can be based
upon them. In order to ensure that there is as comprehensive a coverage of MOD activity
as possible, a business function model has been produced by comparing the three main
activity/process/output models 35 and the outputs in the Departmental Plan 36 . The resulting
functional breakdown will form the basis of the services to be produced and as each area
(or group of areas) is designated for further work, appropriate COIs will form and take
forward their development into services. Decisions on the level of any particular COI will be
made on a case by case basis by the Governance mechanism. It will also enable a
concurrent bottom up view of the technology currently supporting these functions in order
to determine the appropriate level of abstraction for the Business Services. The Level 0
and 1 outputs and their descriptions are reproduced at Annex A to this Handbook.

34
20070706 MOD Functional Model – BMS Update – carried out on behalf of IX EA AD1.
35
These are the Business Management System (BMS); Defence Activity Model (DAM) and the CBM Activity Model.
36
Departmental Plan 2005-2009.
Business Services are Information Services

0235. The Business Services are actually information services which directly support
business functions. This provides a vehicle for the MOD’s business end (FLCs, ECC
Community, Doctrine, Logs) to become intricately involved with the IT end of the business.
This is critical because in order to enable greater reuse across MOD, it will be essential to
govern the development of information services, and to enforce standard specifications for
those information services that are widely used. There may be a requirement for services
whose applicability is restricted to a well defined domain to make a case to opt out of
producing a “standard” Business Service. Under these circumstances, the governance may
be more relaxed – i.e. the services may be defined by their COI (See Chapter 4). As the
MOD’s SOA evolves, information services that were initially identified as “domain” may be
reclassified as “standard 37 ” to enable future interoperability.

Deriving Business Services

0236. Where a requirement for a business service arises, the Governance mechanism
will instigate the formation of a COI. The requirement may come from the Concepts and
Doctrine, Joint Capabilities Board (JCB) through the NEC/CBM Governance chain, the
Systems of Systems Architect responsibilities residing with CM (IS), FLCs, development of
other Services or indeed an intervention opportunity such as the requirement for
accelerated replacement of the casualty tracking system. The locus of the development
work; co-developed if it involves multiple areas of activity, will be the COI. Its formation and
operation is described in detail in Chapter 4. At the time of writing of this Handbook (Oct
2007), there are four 38 COIs overseeing the development of Business Services. These are
JC2SP, casualty tracking, demand management and Joint Supply Chain availability
transformation.

SECTION VII

PRESENTATION SERVICES

What are Presentation Services?

0237. Presentation Services are simply those services which present other services
(Business or Core SOA Services) to users – via number of channels ranging from browser
to portal. For example, overlay Link 16 XML tracks over a map and present to a human
user through a browser. There is no processing of business information.

SECTION VIII

STANDARDS

This section states the standards that must be used or complied with in designing,
developing and operating an MOA SOA. MOD has ensured coherence with NATO and the
US in its approach.

37
In this context, “standard” means subject to open, widely-accepted WS standards.
38
In the first instance, contact Info IX EA1 for details.
Web Service Interoperability (WS-I)

0238. Web service specifications are now being standardised across industry. MOD,
along with most its Allies, is to use the WS-I organisation. The WS-I aims to ensure
interoperability across Web service implementations and is proactive in resolving
incompatibilities among Web services. It produces profiles that provide a common
interpretation of other specifications as well testing tools to ensure conformance i.e. how to
conform to the specifications. The latter are called conformance targets. WS-I specifies
standards or elements thereof from bodies including World Wide Web Consortium (W3C),
the Organisation for the Advancement of Structured Information Standards (OASIS) and
the Object Management Group (OMG).

WS-I Basic Profile 2.0 (MANDATORY)

0239. MOD has selected WS-I Basic Profile 2.0 which consists of a set of non-proprietary
Web services specifications, along with clarifications, refinements, interpretations and
amplifications of those specifications which promote interoperability. The full specification
can be found at http://www.ws-i.org/Profiles/ BasicProfile-2.0.html and designers and
developers should access the site and become aware of its relationship to other profiles.
Any requests for deviation from this profile are to be lodged in the first instance with Info IX
EA1 who will either resolve it or input it to the Governance Chain. For convenience, the
contents table has been reproduced at Annex B.

The Standards (MANDATORY)

0240. Standardising the configuration of these standards and the associated extensibility
points is an important input at the Key User Requirement point for SOA projects. Out of
scope are a number of extensibility points the use of which may affect interoperability, and
which could require private agreement between the parties to a Web service. Issues should
be referred back to InfoX EA1 in the first instance. The relevant specifications from para
0226 are shown below for convenience.

‡ SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)

‡ SOAP Version 1.2 Part 2: Adjuncts (Second Edition)
‡ RFC2616: Hypertext Transfer Protocol -- HTTP/1.1
‡ RFC2965: HTTP State Management Mechanism
‡ WS-Addressing 1.0 - Core
‡ WS-Addressing 1.0 - SOAP Binding (except for sections 4, 5.1.1, 5.2.1 and 6.2)
‡ WS-Addressing 1.0 - Metadata (except for sections 3.1.1, 3.2.1, 3.3, 4.1.1, 4.4.2,
4.4.3 and 5.2)
‡ SOAP Message Transmission Optimization Mechanism
‡ XML-Binary Optimized Packaging
‡ SOAP 1.2, Section 5
‡ SOAP Version 1.2 Part 1, Section 2
‡ WS-Addressing 1.0 - Core
‡ WS-Addressing 1.0 - SOAP Binding
‡ WS-Addressing 1.0 - Metadata, Section 5.1
‡ SOAP Version 1.2 Part 2, Section 7
‡ HTTP/1.1
 ‡ HTTP State Management Mechanism
‡ SOAP Version 1.2 Part 1, Section 6
‡ Extensible Markup Language (XML) 1.0 (Fourth Edition)
‡ Namespaces in XML 1.0 (Second Edition)
‡ XML Schema Part 1: Structures
‡ XML Schema Part 2: Datatypes
‡ Web Services Description Language (WSDL) 1.1
‡ WSDL 1.1, Section 2.1
‡ WSDL 1.1, Section 2.2
‡ WSDL 1.1, Section 2.3
‡ WSDL 1.1, Section 2.4
‡ WSDL 1.1 Binding Extension for SOAP 1.2
‡ WSDL 1.1 Binding Extension for SOAP 1.2
‡ WSDL 1.1 Binding Extension for SOAP 1.2
‡ XML Schema Part 1: Structures
‡ XML Schema Part 2: Datatypes
‡ WS-Addressing 1.0 - Metadata
‡ UDDI Version 2.04 API Specification, Dated 19 July 2002
‡ UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002
‡ UDDI Version 2 XML Schema
‡ UDDI Version 2.03 Data Structure Reference, Section 7
‡ UDDI Version 2.03 Data Structure Reference, Section 8
‡ RFC2818: HTTP Over TLS
‡ RFC2246: The TLS Protocol Version 1.0
‡ The SSL Protocol Version 3.0
‡ RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

SECTION IX

SOA DEVELOPED

This section builds the explanation of SOA given in Chapter 1 in the light of the previous
discussion of services and standards. It looks at selected issues in further detail.

SOA Evolution

0241. SOA is an evolution of distributed computing and modular programming. New

applications can be built out of software services. Services are unassociated units of
functionality which have no calls to each other embedded in them. They typically implement
functionalities most would recognise as a service, such as placing an online airline ticket
order. Instead of services embedding calls to each other in their source code, protocols are
defined which describe how one or more services can talk to each other. This architecture
then relies on a business process to link and sequence services to meet a new or existing
business system requirement i.e. orchestration. In this process, services are associated in
a non-hierarchical arrangement using a software tool which contains a list of all of the
services, their characteristics, and a means to record the selections made; managed by the
designer and used at run-time.
Metadata

0242. Metadata underlies and enables all of this. It needs to be able to describe the
characteristics of these services and the data that drives them. XML is used to create data
which is wrapped in a description container. The services themselves are typically
described by WSDL, and communications protocols by SOAP. The SOA is dependent on
data and services that describe using some implementation of metadata which must be in a
form which software systems can consume and configure to maintain coherence and
integrity, and in a form which system designers can understand and use to manage that
metadata.

Scale and Granularity

0243. SOA allows large areas of functionality to be strung together to form ad-hoc
applications which are built almost entirely from existing software services. The larger the
chunks, the fewer the interface points required to implement any given set of functionality.
However, some may not be granular enough to be easily reused and since each interface
has some processing overhead there is a performance consideration in choosing the
granularity of services. SOA is economical in this respect as all of the software required
already exists to satisfy the requirements of other applications. Only orchestration is
required to produce a new application.

Key Requirements

0244. To efficiently exploit an SOA, the following are important:

a. Interoperability between different systems and programming languages.

The most important basis for a simple integration between applications on different
platforms is a communication protocol, which is available for most systems and
programming languages.

b. Clear and unambiguous description language. To use a service offered by a

provider, it is not only necessary to be able to access the provider system, but the
syntax of the service interface must also be clearly defined in a platform-
independent fashion

c. Retrieval of the service. To allow a convenient integration at design time or even

system run time, a search mechanism is required to retrieve suitable services. The
services should be classified as computer-accessible, hierarchical or taxonomies
based on what the services in each category do and how they can be invoked

d. Not tied to a specific technology. It may be implemented using a wide range of

technologies as long as they comply with laid down standards. The key is
independent services with defined interfaces that can be called to perform their
tasks in a standard way, without the service having foreknowledge of the calling
application, and without the application having or needing knowledge of how the
service actually performs its tasks
 e. Enables the creation of applications. Services interoperate based on a formal
definition that is independent of the underlying platform and programming language.
The interface definition hides the implementation of the language-specific service.
SOA-based systems can therefore be independent of development technologies and
platforms (such as.NET etc). Services written in C# running on .NET platforms and
services written in Java running on Java EE platforms, for example, can both be
consumed by a common composite application. Applications running on either
platform can also consume services running on the other as Web services, which
facilitates reuse.

SOA Ground Rules

0245. The following are ground rules for SOA development, maintenance, and use:

a. A strong and clear Governance regimen to control and manage all aspects of
developing and running an SOA;

b. Reuse, granularity, modularity, composability, componentisation (sorry), and

interoperability;

c. Compliance to standards;

d. Services identification, provisioning and delivery, and monitoring and tracking;

e. Service Encapsulation – ensure consolidation of Web services that may not

have been planned to be under SOA;

f. Service Loose coupling - maintain a service relationship that minimizes

dependencies and only requires that they maintain an awareness of each other;

g. Service contract - adhere to an agreement, as defined collectively by one or

more service description document;

h. Service abstraction - beyond what is described in the service contract, services

hide logic from the external world;

i. Reusability - logic is divided into services with the intention of promoting reuse;

j. Composability - collections of services can be assembled to form new services;

k. Autonomy – services have control over the logic they encapsulate;

l. Service discoverability – services are designed to be outwardly descriptive so

that they can be found and assessed via available discovery mechanisms.

The Service Contract Developed

0246. Every service has a well-defined, formal interface that clearly defines what the
service does and clearly separates its externally accessible interface from its execution
environment. The following components have to be present:
a. Name of the service - indicates in general terms what it does;

b. The version of this service contract ;

c. The person/team in charge of the service;

d. Pre conditions – what conditions must be satisfied prior to using the service e.g.
time, payment?

e. Post conditions – what signifies that the operation has been completed
successfully?

f. The role of the person/team responsible for the deliverables of this

contract/service;

g. Ultimate Decision Maker in terms of this contract/service;

h. Who must be consulted before action is taken on this contract/service?

i. Who must be informed that a decision or action is being taken?

j. Functional Requirement - indicates the itemised functionality of what exactly the

service accomplishes. The language should be such that it allows test cases to
prove the functionality is accomplished;

k. Service Operations - Methods, actions etc. Must be defined in terms of what part
of the functionality it provides;

l. Invocation Profile - Indicates the invocation means of the service. This includes
the URL, interface, etc. There may be multiple invocation paths for the same service
or the same functionality for internal and external clients each with a different
invocation means and interface;

m. Security Profile and Constraints - Defines who can execute this service in terms
and which invocation mechanism they can invoke;

n. Quality of Service - Determines the allowable failure rate;

o. Transactional – To what extent is this capable of acting as part of a larger

transaction and if so, how is it controlled?

p. Service Level Agreement - Determines the amount of latency the service is

allowed to have to perform its actions including availability guarantees, audit logging,
time to respond, time to live;

q. Semantics - Dictates or defines the meaning of terms used in the description and
interfaces of the service;
 r. Process - Describes the process, if any, of the contracted service;

s. SOA and web service protocols.

SECTION X

IMPLEMENTATION POLICY

JSP 602

0247. The accompanying JSP provides policy on implementation.

Information Retention in Applications

0248. Applications (user facing Graphical Interfaces) should not hold data of long term
importance nor contain business logic. Application and data/information should be
separated. Applications should only cache information to speed information retrieval or
ensure resilience, and should only contain detailed business logic when the performance of
web services will be too limiting. For example Deployed or Tactical domains may require
local caching in a distributed data architecture where reach back is intermittent. However,
if applications need to contain logic or data, then the design should still consider these
components as data or services. Application therefore needs to have a refresh strategy for
any cache it creates – the danger is that out of data information is used and/or latency
becomes an issue. In addition, the continual fetching of the same information is bandwidth
hungry and applications should be designed to get changes to update cached copies rather
than fetch new documents.

Alternatives to Web Services

0249. Performance limitations are the key reason to adopt a non-WS SOA design when
required - e.g. in the tactical domain, due to bandwidth or speed constraints. In these
circumstances interoperable SOA may still be implemented using a number of mechanisms
including but not exclusively Distributed Interface Oriented Architecture (DIOA) 39 . The
Information Dimension Working Group (IDSG) or the relevant COI will provide advice as
required (see Governance).

Design Patterns

0250. A developer’s best practice library of proven and proposed design patterns or
mandatory service extensions will be kept. This will include detailed joining rules which
may specify a particular approach, products or standards to ensure that semantic context
of information is maintained across the information architecture and between end-users.
The obvious locus for this is the Information Coherence Authority for Defence (IICAD) but
this will be decided through the Governance mechanisms (Chapter 4). For now, all
instances should be referred to Info IX EA1. There will also be a formal link between this
through to the DII Applications Design Guide. The adoption of differing technical

39
The DIOA is defined in the Telemanagement Forum Technology Neutral Architecture standard TMF053 Release 6
and above, and TMF053 Addendum Http://www.tmforum.org
implementations of SOAs is one of the root causes of new isolated stovepipes, which
increase integration risk and jeopardise achieving a workable NEC.

SECTION XI

SECURITY

Service Level Security

0251. Whilst security will be considered in the next revision of this handbook, basic
advice is available, and follows. Clearly, any SOA security solution would need to be
integrated with other security infrastructure such as Public Key Infrastructure, Identity and
Key Management and Directory services.

HTTP

0252. HTTP can provide basic authentication (user name and password). This helps to
establish that the sender or receiver of SOAP messages is who they say they are.

HTTPS

0253. HTTPS can help to provide data privacy and data integrity. The former ensures that
data in the SOAP message can only be viewed by those it was intended for. The latter
check for sat modification in transit. HTTPS can:

a. Provide certificate based authentication;

b. Provide transport level encryption – whole document encryption;

c. Provide transport level digital signatures – whole document signing.

WS-Security

0254. WS-Security can cover authentication, data privacy and data integrity as well as
non-repudiation. The latter can prove that a SOAP message was sent or received or that
some transaction actually occurred. WS-Security can:

a. Provide SOAP security headers capable of handling a number of tokens;

b. Can provide SOAP message integrity at element level – i.e. parts of document
(XML).

c. Can provide SOAP message privacy at element level (XML);

d. Can provide XML signature based non-repudiation.

Security Assertion Mark up Language (SAML)

0255. SAML allows Authentication, Authorisation and Single Sign-On. Authorisation

allows access to services based on user identity or role. Single Sign-On allows access to
authorised services across security domains once a requester has been authenticated
once. SAML can:

a. Support ( exchange of information) authentication and authorisation between

security domains;

b. Support manual and automated single sign on.

 CHAPTER 3

MOD ARCHITECTURE FRAMEWORK (MODAF)

This chapter is contains elements which are mandatory for SOA. It introduces MODAF
(MOD Architectural Framework) and explains what it is, how it works and how to build an
SOA using it. It establishes that SOAs in MOD will be compliant with MODAF. It is
relatively technical and is intended primarily as a primer for architects and technical
briefers. It provides background to the essential elements of MODAF, the working
representations of the model (views) and how to use them.

SECTION I

AIM

Policy (MANDATORY)

0301. The use of MODAF for all is mandated for all SOA definition, design and modelling.
Tools must be MODAF-compliant.

SECTION II

MODAF

What is MODAF?

0302. MODAF is the MOD’s Architecture Framework. It specifies a standard set of views of
the enterprise that are each intended to support a particular engineering or decision making
process – e.g. capability taxonomies, capability gap analyses, business process models,
data models, information exchange requirements, system functionality, system connectivity
& deployment. Each view is a window onto a particular aspect of the enterprise. MODAF
encourages a holistic approach to enterprise modelling – the views are simply ways of
publishing or creating architectural information that forms part of a coherent and contiguous
enterprise architecture model.

MODAF’s Purpose

0303. The principal purpose of MODAF is to facilitate the successful delivery of Network
Enabled Capability (NEC). By covering both the operational and technical aspects across
an organisation, MODAF-compliant Architectures enable all communities of interest (used
in the English sense) to gain the essential common understanding that will be required to
deliver the benefits to be derived from NEC. As an enabler for managing complexity,
MODAF provides a specification of how to represent an integrated model of an
organisation, from the operational / business aspects to the systems that provide capability,
together with appropriate standards and programmatic aspects. It assists in managing
complexity by providing a logical, standardised way to present and integrate models of the
enterprise.
MODAF and SOA

0304. MODAF (MODAF 1.1) contains a set of views for SOA. Some of these views are
being used to support of early MOD SOA pilots, and will evolve as lessons are learned
from those pilots. Hereafter, all relevant modelling is to be carried out using MODAF. In
order to ensure future compatibility all projects, programmes and organisations engaged in
SOA are to solicit advice from AD Info-XADEA1. MODAF is continually updated and
readers are directed to http://www.modaf.org.uk which provides comprehensive advice,
workarounds and the latest information and views. The entire model can be downloaded
http://www.modaf.org.uk/file_download/23/www.modaf.org.uk.zip. Note the release
information which is reproduced here: “This documentation release is Version 1.1. This
numbering aligns the documentation with the MODAF Meta Model (M3) release 1.1. This is
the current release of MODAF as at April 2007 and supersedes the MODAF Technical
Handbook and accompanying documentation which was published in August 2005”.
Selected elements have been adapted for this Chapter.

DoDAF and MODAF

0305. DoDAF (US) is rooted in the C4ISR community and is seen as a fundamental part
of the DoD drive towards Net-Centric Warfare (NCW). The MOD Architectural Framework
(MODAF) is based on the DoDAF specification and therefore retains compatibility with US
modelling initiatives. Like DoDAF, MODAF is specifically designed to support Architecture
Modelling for the MOD business. MODAF uses aspects of the existing DoDAF together
with additional Viewpoints that are required to support UK MOD processes, procedures,
and organisational structures. It provides a rigorous method for understanding, analysing,
and specifying: Capabilities, Systems, Systems of Systems (SoS), Organisational
Structures and Business Processes. It is therefore well placed to facilitate the successful
delivery of NEC. The major benefit delivered by MODAF is MODAF delivers are
improvements to the specification and implementation of interoperability between Systems.
MODAF supports a wide variety of MOD processes, including: capability management,
acquisition and sustainment.

SECTION III

MODAF VIEWS

What are MODAF VIEWS?

0306. Architectures are developed as coherent, contiguous models of the enterprise –

MODAF defines relationships which can be used to integrate the various architectural
elements. Producing an SOA is never the work of one person, so it is useful to be able to
logically divide architecture into domains. This also proves useful when publishing
architecture to different stakeholders. For this reason, MODAF defines a set of standard
viewpoints.

The Six MODAF Viewpoints

0307. The relationship between the six MODAF Viewpoints is show in Figure 10. It shows
that:
 a. The Strategic, Operational, and System Viewpoints have a layered relationship;

b. The Acquisition Viewpoint sits beneath the Strategic Viewpoint, and has a
supporting role across the Operational and System layers;

c. The All Views and Technical Standards Viewpoints sit alongside the others in
their role of providing a description and ontology for an architecture, plus information
on supporting standards.
architecture
Provide information pertinent to an
All Views

guidance, constraints & forecasts

Articulate policy, standards,
Technical Standards Views
STRATEGIC Views
Articulate high-level requirements for enterprise change
over time – capabilities, goals, enduring tasks

milestones and statuses

dependencies,
Articulate programme
Acquisition Views
OPERATIONAL Views
Capabilities Articulate operational scenarios,
activities, and information flows

SYSTEM Views
Articulate the solution specification –
resources, functions & interactions

Figure 10 - MODAF Viewpoints

0308. Each Viewpoint of the architectural model is from a different perspective. The
Operational Viewpoint, for example, considers the operational nodes that interact in
specified ways in order to achieve a desired outcome. Each of these viewpoints consists of
several views, which offer slightly different details within the viewpoint. For instance within
the Operational Viewpoint, OV-1 provides a high level conceptual graphic, whilst OV-2
considers the interactions between operational nodes and OV-3 details the information
flows. Although the data within each View adds to the description of an SOA, it is not
necessary for all of the MODAF Views to be completed at any particular point in time during
the MOD’s acquisition lifecycle. Indeed, each group of users within the MOD will have
different needs and will only populate and exploit those MODAF Views that are of
relevance to them. This means that most of the COIs will only be dealing with a subset of
MODAF Views, and few will need to understand and deal with all of the available MODAF
Views. The main use of each of the MODAF Viewpoints within the MOD is summarised
below.

Strategic Viewpoint

0309. Strategic Views (StVs) support the process of analysing and optimising the delivery
of military capability in line with the MOD’s strategic intent. The StVs achieve this by
capturing the capability policy/concepts, decomposing this into a capability taxonomy
supported by appropriate measures of effectiveness that can be used for capability audit
and gap/overlap analysis. The StVs further detail the dependencies between military
capabilities, enabling capability options to be built in a more coherent manner and effective
trade-offs to be conducted across the entire Equipment Programme/Short Term Plan. For
SOA, the StVs will mainly be developed and exploited by those within the policy/analytical
concepts areas and the Customer 1 function (DEC CC&II).

Operational Viewpoint

0310. The Operational Views (OVs) define the logical aspects of the architecture. A suite
of OV products may be used to describe a requirement for a to-be architecture in logical
terms, or as a simplified description of the key behavioural and information aspects of an
as-is architecture. The OVs reuse the capabilities defined in the StVs and put them in
context of an operation or scenario. The OVs can be used at a number of points through
the MOD lifecycle including the development of user requirements, capturing future
concepts and supporting the operational planning processes. A number of stakeholders will
develop and exploit OVs during the MOD acquisition lifecycle. For instance, Customer 2
will use OVs to support URD development and in conducting operational planning
processes.

System Viewpoint

0311. The System Views (SVs) are a set of views that describe resources that realise
capability. The Systems Views describe resource functions, interactions between
resources, and can also provide detailed system interface models. These views address
the involvement of humans in both the operation of systems and in carrying out functions.
The SVs can be used to specify solutions to requirements specified in the OVs, or simply to
provide more detail to the logical OV architecture. One of the primary uses of the SVs is in
the development of system solutions that satisfy the user requirements and hence the
development of appropriate system requirements. The SVs will primarily be developed and
exploited within the MOD’s acquisition community (DE&S). Figure 11 below shows how
the last three views interact together with some of the contingent detail (Ignore Ontology).

Figure 11 Interaction between Strategic, Operational and System Views

Technical Standards Viewpoint

0312. The Technical Standards Views (TVs) are tabular views containing standards, rules,
policy and guidance that are applicable to aspects of the architecture. Despite the name,
the contents of the TVs do not necessarily need to be of a technical nature and can apply
just as much to operational activities (e.g. doctrine, Standard Operating Procedures (SOPs)
and Tactics, Techniques and Procedures (TTPs)) as they do to systems (e.g. standards,
and protocols). The elements contained in the TVs will come from a number of sources
including the policy setting organisations in MOD and core interoperability standards from
Customer 1. The TVs will then be further detailed and managed throughout the acquisition
lifecycle by the standardisation officers within the IPTs.

Acquisition Viewpoint

0313. The Acquisition Views (AcVs) describe programme details, including dependencies
between projects and capability integration across the Defence Lines of Development
(DLODs). The Views identify interaction between programmes and projects, and integrate
acquisition activities across all of the DLODs. The AcVs provide important programmatic
information for those involved in capability management and acquisition. Since they also
address the maturity across all of the DLODs to deliver an integrated military capability, the
AcVs also form an important interface between the acquisition IPT and its Customer 2
community.

All-Views Viewpoint

0314. The All-Views (AVs) provide an overarching description of the architecture, its
scope, ownership, timeframe and all of the other meta data that is required in order to
effectively search and query architectural models. They also provide a place to record any
findings arising from the architecting process. The AVs include a dictionary of the terms
used in the construction of the architecture – which helps others fully understand it’s
meaning at a later date. Since the AVs provide critical information for the future access and
exploitation of an architectural model their population is essential whenever MODAF
architecture is created or modified. The AVs shall be produced by every community within
MOD that populates or alters MODAF architectures and they provide a critical input into the
processes that provide architectural governance.

SECTION IV

HOW MODAF WORKS

MODAF Views Most Relevant to SOA

0315. MODAF V1.1 contains a number of views which cover concepts relevant for any
architect designing an SOA. Those concepts are:

a. Change Management. MODAF includes the concept of “enterprise phases”,

allowing the architect to specify how the enterprise will be structured and function at
different times (Epochs). These phases are specified in the AV-1 View (All Views
part 1).
 b. Capabilities. The MOD SOA must take into account existing capability
taxonomies produced by the various Directors Equipment Capability. These are
documented in the MODAF Strategic Views (StV), specifically StV-2.

c. Organizational Structure. The MODAF OV-4 (Operational View part 4) specifies

an organizational structure for a specific enterprise phase (i.e. the structure may be
different as the enterprise evolves from phase to phase).

d. Business Functions. The MODAF Operational Activity View (OV-5) specifies

business processes, their decomposition and dependencies.

e. Logical Data Model. OV-7 specifies an information model for the architecture
Capability Configuration – SV-1 (Systems View part 1) specifies how people,
systems and platforms (with the appropriate training, doctrine, etc.) interact in order
to provide a given capability. In addition, the NATO SOA views (which are slated for
inclusion in a future MODAF release) define which services are implemented by the
capability configurations specified in SV-1. If incorporated into MODAF, this would
be part of the SV suite of views.

MODAF SOA Views

0316. SOA views which are being considered for inclusion in a future version of MODAF
are depicted in Figure 12. These will allow architects to express a services approach,
using standardised services to de-couple processes from the capability configurations that
support them. In the first instance, the advice of Info-XADEA1 should be solicited before
these are used. In summary, these views are:

a. SOAV-1 – Service Taxonomy. A hierarchy of specialising services in which child

services inherit the specification, policy and behaviour of the parent.

b. SOAV-2 – Service Specification. A formal description of the interfaces provided

by a service, and the interfaces it uses to consume other services. SOAV-2 also
specifies Service Policy – e.g. access rights, protective classification, security
issues, etc.

c. SOAV-3 – Service Composition. A specification of how one service may be

composed of other services (this may be removed from a future version of MODAF,
as it tends to suggest an implementation approach).

d. SOAV-4 – Service Orchestration. A mapping of services against the business

functions they support.

e. SOAV-5 – Service Behaviour. A specification of the exposed functionality of a

service, the state transitions it may undergo and its interactions with its environment.
 Whole-Life
Enterprise (AV-1)

phase of

Enterprise requires
Capability (StV-2)
Phase (AV-1)

represents

Enterprise Architecture

Logical Data Model (OV-7)

Organisation Business Process

Structure (OV-4) Model (OV-5)
supported functions
de-coupling
processes Service Orchestration (SOAV-4)
from capability
providers orchestrates

specified by Service Specification

Service Interface (SOAV-2),
(SOAV-1) Behaviour (SOAV-5)

provides consumes

Capability Configuration (SV-1)

delivers

Systems Infrastructure Posts / Roles

Figure 12 - MOD SOA Views

MODAF and NATO Architectural Framework (NAF)

0317. The NATO Architectural Framework (NAF) is based substantially on MODAF. NAF
has early versions of five SOA Views to cover service taxonomy, specification,
composition, orchestration and behaviour. These have not matured sufficiently for use in
MODAF without risk. One of the proposed future changes is the introduction of a number
of Service Views which will be based upon those defined by The NAF implements a
Viewpoint with five SOA Views and a System View (SV) to show implementation of
information services. The NAF SOA Views include:

a. NSOA-1 Service Taxonomy

b. NSOA-2 Service Specification

c. NSOA-3 Service Composition

d. NSOA-4 Service Orchestration

e. NSOA-5 Service Behaviour

MODAF and SOA SITREP

0318. The current version of MODAF (v1.1) does not support Service Oriented
Architectures. However, DG-Info have been working with NATO and the Swedish Armed
Forces to develop a set of extensions to MODAF to support SOA. These are currently
being tested at metamodel level but will not be available until the next release of MODAF
(v1.2 due in April 08). The next version of the NATO Architecture Framework will also
incorporate the SOA views. At this stage, only a general indication of how the SOA views
are to be used in an enterprise architecture can be provided. Their purpose is to provide
the link between the operational and technical architectures – i.e. to de-couple the
technology from the processes. However, more definitive guidance will be provided by
Info-XADEA1 on request.

0319. The key difference will be that instead of the architect being forced to think about
information flows, he/she can specify operational requirements in terms of the services
required to support operational activities (the orchestration). Services can be linked back to
capability taxonomies, to identify which capabilities they provide. From a solution
architecture point of view, the architect can specify how resources (systems, platforms,
people, etc.) are configured to implement a service. The method of developing a Service
Oriented Architecture in MODAF will differ depending on the nature of the work – e.g.
green-field or brown-field projects. The MODAF Primer (to be released with the next
version of MODAF) will outline the MODAF generic enterprise architecture process
(GEAP), and will include SOA approaches. In general though, any process is likely to
involve the following stages (order may alter depending on project):

f. Capability analysis (inc. gap / shortfall analysis.)

g. Business process design and analysis.

h. Service specification & governance – the logical design of the service, and the
interfaces it exposes.

i. Service orchestration – which business processes use which services.

j. Service implementation – the resources used to implement a service (systems,

people, platforms)

Security

0320. Security will be covered in the next update of this Handbook. For services, as for
other information technologies, security consists of understanding the potential threats an
attacker may mount and applying operational, physical, and technological
countermeasures to reduce the risk of a successful attack to an acceptable level. Because
an "acceptable level of risk" varies hugely depending on the application, and because costs
of implementing countermeasures is also highly variable, there can be no universal "right
answer" for securing Services and access to Services. Choosing the absolutely correct
balance of countermeasures and acceptable risk can only be done on a case by case
basis. However, there are common patterns of countermeasures that experience shows
reduce the risks to acceptable levels for many services. The WS-I Profile adopts, but does
not mandate use of, the most widely used of these: HTTP secured with either TLS 1.0 or
SSL 3.0 (HTTPS). That is, conformant Web services may use HTTPS; they may also use
other countermeasure technologies or none at all. HTTPS is widely regarded as a mature
standard for encrypted transport connections to provide a basic level of confidentiality.
HTTPS thus forms the first and simplest means of achieving some basic security features
that are required by many real-world Web service applications.

Transitional Architecture

0321. It is the MOD’s aspiration to implement a full SOA incrementally. For this reason,
some parts of the enterprise will be SOA and others point-to-point at given phases.
MODAF allows the architect to specify which aspects of the enterprise will be service-
oriented at each phase.

Typical MODAF SOA Architectural Process

0322. MODAF is not a methodology, but there are some key linkages between the
MODAF architectural elements (and therefore the views) which imply certain precedence
and therefore a general process, as indicated in Figure 13. Note that this is purely
informative, and may change as lessons are learned from the MOD SOA pilot projects.
There are MODAF compliant implementation methodologies such as TOGAF which are
being trialled through the SOA pilots. IN the fist instances, readers should seek advice from
Info-X EA AD1.

Figure 13- Indicative SOA Architecting Process

 CHAPTER 4

GOVERNANCE

This chapter outlines the governance arrangements for SOA. It will require updating as key
changes driven by new arrangements for NEC/CBM governance and emerging
responsibilities for the System of Systems Architect bed in. It is also an area that will
continue to develop as more SOA services become available. The key generic elements of
governance are introduced along with the developing CBM and NEC governance
arrangements which SOA must fuse with. The important concepts of a Centre of
Excellence for Design Authority, Capability and Technical Architect, and various other
governance roles are discussed. The role of Communities of Interest, how they are set up,
and how they might develop services based on the previously described functional model
are described. In addition, the role of current organisations in SOA governance is outlined.
Finally, there is a short treatment of compliance and AOF/CADMID issues. This chapter
should leave the reader with a good grounding on the main SOA governance issues and an
index of the extent to which these are a departure from business as usual.

SECTION I

AIM

Guidance

0401. This section provides direction on SOA Governance. MOD SOA will be based on
Web standards to ensure independence from any particular products so that any vendors’
products can be used. The Business Services will be designed to align to real world activity
or functions.

SECTION II

THE KEY GOVERNANCE ELEMENTS

Introduction

0402. The purpose of governance is to align business and IT governance. It recognises

Services as corporate assets that need to be managed through life. Services will become a
common unit of management of many activities e.g. resource utilisation. Early
establishment of SOA governance is vital to drive the right sorts of behaviour. Without it,
there is a high likelihood of developing redundant capabilities, regulatory non-compliance,
and costly implementations. Governance elements described in this chapter have been
derived from best practice and early SOA pilots. A key driver has been to construct
governance arrangements that do not duplicate pre-existing or emerging work. These are
described in the next paragraph and where relevant, in the rest of this chapter.

Coherence

0403. Particular care has been taken to ensure that the arrangements herein are coherent
with important Work In Progress and the effect of other major initiatives or programmes.
Most importantly, every attempt to avoid duplication has been made. In brief, these are:

a. NEC/CBM Governance 40 . The designation of DCDS (EC) as SRO for

NEC/CBM and requisite the governance structure will be adopted as the overarching
SOA governance architecture. This will provide Joint Capabilities Board provenance
and if successful will aid the communication of successes or otherwise. Where there
is a fit, roles and responsibilities are pegged to this structure.

b. System of Systems Architecting Responsibilities 41 . Emerging responsibilities

Capability Manager (Information Superiority) as the Capability Architect, and those
of the Systems Architect, are also taken into account and will be reflected in the
Roles and Responsibilities later in this chapter.

c. Defence Information Infrastructure (DII). DII will carry most (but not all) of the
SOA applications and infrastructure. The Application Hosting Environment
(Increment 2b due in Q4 of 2008) is due in late 2008 and every opportunity to liaise
with the developing teams will be taken over the currency of this Handbook and
subsequent iterations.

d. Defence Industrial Strategy (DIS) 42 . There are many aspects of DIS (V1) that
could impinge on SOA governance. The principal one however, is the formation of
Defence Equipment and Materiel and specifically the emerging roles of DG ISS and
DG ISTAR. Governance roles will take these developments into account.

Scope - Key Components

0404. Policy and governance is fundamental. An SOA governance body should be made
up of individuals from all areas of the organisation which will ensure a mixture of
technologists and architects, business experts, and other experts and specialists. This will
ensure that all areas of expertise required to direct a successful SOA implementation will
be involved. Accordingly, the governance policy given here will cover the following:

a. Who? The main individual and organisational players. Some of the proposals
require further ratification but as per other issues the first port of call should be Info-
XADEA1.

b. What? Their roles and responsibilities including how identifying, implementing,

deploying and versioning services is to be done in addition to monitoring
performance and ensuring Web Compliance.

c. How? The processes and tools for effective governance. This includes the tools
for project management, business/service and system modelling as well as data
management.

40
DCDS (EC)/07/01/14A dated 31 Jan 07.
41
EC CCII (Ses 07-080) /DGISTAR/7/3/3/6 dated 7 June. 1* Circulation of the System of Systems Architecting
Responsibilities. The paper recognises that the approach needs “to be extended to the complete NEC architecture
(including the Information and People aspects)” but that the concept would be implemented incrementally starting with
the C4I domain in direct support of the Networks and CIS steering group.
42
Defence Industrial Strategy, Defence White paper dated Dec 05.
 d. When? The key intervention points for governance.

SECTION III

THE MAIN PLAYERS

0405. The backdrop to this is the overall NEC/CBM Governance model shown in Figure
14 below. It will be referred to in the paragraphs that follow.

NEC/ CBM GOVERNANCE AND SOA

JCB (X)

NEC/CBM
Prog Office

SRO
DCDS EC

Sec
DCBM Executive Group

Stakeholders Network & CIS Information People Join Action User Group
CM (IS) DG Info DS Sec D Jt Cts

DG ISS ACNS
DG ISTAR Executive Group
ACGS
ACDS (RP) ACAS
DG (R&T) ACDS Log Ops
DG D&D DCJO

Steering Group

Network & CIS Information People Joint Action

Figure 14 - NEC and CBM Governance Mechanism 43

Executive Sponsor

0406. The 3* Executive Sponsor is the principal stakeholder. Per the NEC/CBM
governance provisions, this is DCDS (EC) as shown in Figure 14 above (SOA- relevant
aspects in orange). This individual provides guidance to the SOA Board on resolution of
exceptions and appeals for/against standards. The Executive Sponsor:

a. Champions SOA concept within the business;

43
Adapted from NEC/CBM Governance Paper DCDS(EC)/07/01/14A dated 31 Jan 07
 b. Is responsible to the JCB for articulating the ongoing strategic significance of
SOA strategy and its role in achieving NEC;

c. Is responsible for ensuring the participation of the right elements of the defence
business – probably taken from the extended members of the NEC/CBM Executive
Group;

d. Ensures appropriate industry involvement at the right levels.

e. Exercises command and control via the Executive Steering Group (para 0407).

The Executive Steering Group (ESG)

0407. This committee may be chaired by the Executive Sponsor or it may be delegated to
a 2*. The ESG carries out the executive management of SOA. In terms of the NEC and
CBM Governance Model, this committee will most probably be drawn from members or
representatives of the Executive Group in the NEC/CBM diagram 44 . It is accountable for
providing strategic direction goals and objectives for the SOA Board:

a. Approves SOA strategic projects;

b. Is the final arbitration point for non-conforming SOA projects;

c. Provides strategic direction to, and appoints, the SOA Board;

d. Prescribes and ratifies the extent collaboration between business, technical and
industry players;

e. Enforces the Standards in Chapter 2;

f. Provides the entry for non-C4I and ISTAR service requirements.

SOA Board

0408. This 1* board consists of representatives of the business and IT management,

appointed by the ESG. In terms of Figure 14, this board will most probably be drawn from
the Steering Groups and has roles and responsibilities closely aligned to the Information
Dimension Steering Group (IDSG). This board reports directly to Executive Sponsor with a
dotted line to the business and IT units that it represents.

a. Prioritises strategic projects/services for ESG review;

b. Provides estimates for overall resources required for SOA governance and
management;

c. Serves as an escalation point for conflict resolution for SOA compliance or

conformance related matters;

44
As a point of principle, there is nothing preventing SOA becoming an Agenda Item on pre-existing boards.
 d. Serves as an escalation point for review and approval of major architectural
changes and issues;

e. Serves as the working level focus for bringing together business, technical and
industry expertise in order to identify the right solutions for specific needs;

f. Lowest point for authorisation of COI formation.

Portfolio Management Committee

0409. This AD level committee provides the structure, principles and disciplines to
manage the portfolio of SOA projects and services. Its roles are aligned to the Information
Dimension Working Group (IDWG) and will work both as a formed body and provide SOA
representation to key project/programme WG.

a. Provides key input on business planning cycle(s);

b. Works to develop prioritisation and synchronisation of key SOA related projects;

c. Provides help and advice on funding mechanism (assume that no special

arrangements will be made for SOA funding outside of normal cyclical rounds);

d. Liaises with the DA Registrar role (para 0416) who fulfils the technical portfolio
management and classification role.

Architecture Review Board

0410. The ARB consists of SOA Board Director (Chair of IDWG), a Chief Architect input,
SOA Architects (technical and business). Others (business and technical) by invitation
when required. The roles are:

a. Identify the resources and skills required to set up and run a design authority;

b. Reviewing and approving / denying architectural exceptions / appeals;

c. When necessary, escalate to the SOA Board projects/services for approval, that
do not meet defined standards or pre-defined budget limits;

d. Developing the communicating strategy and championing the SOA across the
enterprise;

e. Quality and currency of the architecture and supporting infrastructure;

f. Quality and currency of the architecture management processes;

g. Developing and sponsoring the SOA education strategy for all aspects of the
business;

h. Provide a registration and classification system for services.

Business Operations Review Board

0411. This working level board consists of the representatives of the main business
operations. This is the main touch point for the business accepting and deploying the
provided services. This board plans operational readiness aspects of solution deployment.
Initially, it should be a priority to align any proposed governance mechanism with current
MOD governance mechanisms.

SECTION IV

ORGANISATIONAL ROLES

The Defence Change Backdrop

0412. A number of recent initiatives have created an opportunity to design a governance

structure that provides clear authority and accountability:

a. The Defence Industrial Strategy 45 confirmed the role of systems engineering in

maintaining the capability of complex systems through-life.

b. The Through-Life Capability Management (TLCM) initiative introduced as part of

the Defence Acquisition Change Programme (DACP).

c. The formation of DE&S with its reaffirmed emphasis on whole-life, capability

integration and skills.

d. The introduction of a new NEC governance regime with a single SRO for NEC
and steering groups for Networks & CIS, Information and People.

e. Recognition that the move towards Services Oriented Architecture (SOA) will
require clearly defined and mandated standards and coherent, common services to
be successful.

NEC and SoSA

0413. The NEC/CBM governance chain 46 and the System of Systems (SoS) architecting
approach 47 will shape the governance of SOA and organisational roles. The former has
already been introduced; the latter seeks to help DCDS (EC) deliver the C4I component of
NEC and support it through life in accordance with Through Life Capability Management. A
top-down architecture, covering all the Defence Lines of Development, set within a systems
engineering capability process will be adopted. Initial work will concentrate on delivering
consistent and coherent capability and technical architecture. The approach will be
extended to the complete NEC architecture including the information and people aspects.
In order for this to work DG Info, the ECC (particularly CM (IS) and DEC CC&II) and DE&S
(DG ISS and DG ISTAR) must act closely in partnership. In principle, the governance will
be exercised through existing structures and processes but for heavily influenced by the

45
Defence Industrial Strategy, Defence White paper dated Dec 05.
46
DCDS(EC)/07/01/14A dated 31 Jan 07
47
EC CCII (Ses 07-080)/DGISTAR/7/3/3/6 dated 07 Jun 07.
capability perspective. (Further discussion under Design Authority para 0422 et seq).

Capability Architect

0414. The principal interactions are in Networks & CIS. Here, CM (IS) in his role as the 2*
programme director of the Networks and CIS SG, would become the Capability Architect.
His primary tasks would be the creation and delivery of the Capability Architecture,
specifying capability requirements (including interoperability), resourcing the programme
and arbitrating or enforcing where necessary. Other specific roles include:

a. Working in support of DCDS (EC) to develop the C4ISTAR capability vision to

support NEC.

b. Responsible for extracting and owning the C4ISTAR networks and infrastructure
capability goals and key performance parameters.

c. Defining the command-led ‘Strategic Estimate’.

d. Defining flexibility and resilience requirements.

e. Endorsing the ISTAR and C4I CRDs.

f. Based on audit results, directing and flexing resources to best deliver the
C4ISTAR capability.

g. Ensuring capability coherence of C4I and ISTAR capability management

strategies and plans.

h. Risk ownership – owning the risk that capability definition of C4ISTAR is not
complete and does not deliver the architecture and system design drivers.

Technical Architect

0415. The Technical Architect role will be fulfilled by DGISTAR as the 2* sector lead within
DE&S. His responsibilities will be executed through the IA & DCTO to provide the technical
architecture, design guidance, measures of effectiveness and assurances for improved
specification and delivery of SoS capability. His specific roles include:

a. Responsibility for development of target C4ISTAR technical architecture in

support of capability architecture in accordance with DTS.

b. Providing a mandate and forum for industry engagement and consultation in

architecture development.

c. Publishing timetable to minister and ensuring that timetable is adhered to.

d. Enforcing mandate of IA on IPTs within DE&S.

e. Risk ownership – owning risk that target technical architecture, design patterns /
principles do not have emergent properties required for NEC and owning risk that IA
 is insufficiently resourced to deliver the required outputs (both meeting quality and
timescale requirements).

DG ISTAR

0416. DG ISTAR will be responsible for the overall coherence, consistency and
completeness of C4ISTAR architecture.

Integration Authority (IA)

0417. The IA will be responsible for “information service assurance” in support of all
projects with an information services element that use MOD networks. The IA will ensure
that the same service should not be created by 2 or more organisations, which would
otherwise undermine clarity in the information layer. Effectively, it holds the “As-Is” System
of Systems map and uses it to spot gaps between user specified requirements and the
Information Services required. The IA is also responsible for Information Service Creation
assurance. This will be dovetailed into the MODAF and NEC Integration Assurance Model.

DG ISS

0418. As the Test and Release Authority DGISS’s key roles are compliance and
conformance. Key roles include assurance of technical design patterns and authority for
functional services. The latter role is particularly important for compliance with GII and will
include the static and deployed environment. The role of DCTO is developing in
conjunction with IA. DG ISS also has an emerging E2E role of ensuring that SOA system
connectivity stretches from the fixed environment to the deployed over a number of bearer
systems.

DG Info

0419. The key roles of DG Info are to provide the central policy and strategy which guide
the SOA activities of other organisations and bodies. DG Info also provides the overall
architectural framework for SOA and related activities - MODAF. ICAD is also part of DG
Info. Its role is to act at the metadata repository – manage the XML schemas. Requests for
IX COIs to be formed should be lodged with ICAD.

CM (IS)

0420. The role of CM (IS) and DEC CC&II is to develop the overall NEC backdrop which
SOA has a part to play in. The SOSA 48 requirements underline the need for commonly
understood definition of the capability goals that the total set of systems, people and
processes are required to achieve. Part of this definition is to specify the minimum set of
mission threads to define NEC. This responsibility is delegated by DCDS (EC) to CM (IS)
and further articulated and defined by a capability architecture and capability plan operating
at the System of Systems level. The capability architecture will be supported by a technical
SoS architecture which will further define the system and provide a target technical
architecture to guide and constrain future systems and system upgrades. The design and

48
EC CCII (Ses 07-080) /DGISTAR/7/3/3/6 dated 7 June. 1* Circulation of the System of Systems Architecting
Responsibilities
development of the technical architecture is an IA/DCTO role.

SECTION V

CENTRE OF EXCELLENCE FOR DESIGN AUTHORITY

Introduction

0421. The Design Authority (DA) function is an integral function of governance but
warrants a separate section for clarity.

The function of the CofE for Design Authority (DA)

0422. The basic function of a DA is to ensure that a proposed solution to a requirement

will work and is implemented with integrity to achieve objectives. It facilitates decision
making on the options and tradeoffs needed to deliver the solution. It manages the
fundamental building blocks of governance to ensure alignment with Defence objectives
and strategy across Business, Technical, Test and Reference and ‘Live’ production
environments. SoSA should ensure that the solution is integrated into the existing
system/network without duplication, utilising (or able to utilise) information services and
most importantly, without creating isolated stove piped capabilities – hence the requirement
for open standards. The key functions are:

a. Compliance mechanisms. These are for review and approval/rejects against the
criteria established in the governance framework (i.e. principles, standards, roles,
and responsibilities etc.) and performed at various points during the life-cycle.

b. Vitality of the governance framework. It requires the governance framework to

be current, reflecting the business and CIS direction and strategy. It must also
refine the governance processes and mechanisms carried out by organisational and
supporting roles to ensure ongoing usage and relevance. There is also a linkage to,
and direction from proactive concepts and doctrine/TTP development - hence the
importance of the JC2 Capability Integration facility at the Defence Academy.

c. Exceptions and Appeals. Stakeholders must be allowed to appeal non-

compliance to established processes as defined within the governance framework,
such as service funding, service ownership, service identification, etc. and be
granted an exception as appropriate.

d. Communication. Communication is aimed at educating and communicating the

governance model across the organization. It includes ensuring that governance is
acknowledged and understood as well as setting up environments and tools to allow
easy access and use of the governance information.

Design Authority Roles

0423. Each SOA project on the MOD road map should be receive business, SOA and
MODAF advice as well as appropriate technical guidance from the architectural design
authority. The architects working to the SOA Board should look for opportunities to share
costs and develop commonly used services. The remit of the CofE for DA include
establishing and maintaining:

a. Business Architecture that drives the SOA. This includes the foundation industry
component business models, desired business services, critical success factors,
competitive factors, best practices, organisational structure, and locations.

b. Application Architecture. This identifies the various service oriented

applications/functions across the enterprise, and their relationship to legacy or non-
SOA application candidates.

c. Information Architecture. This defines the content, structure and management of

critical business information being processed by the business systems.

d. Technical Architecture. This defines the infrastructure needed to support the

service oriented processes, including networks, systems management processes,
security

e. Governance. This defines the charter, visioning, principles, roles,

responsibilities, processes, and metrics to support an SOA environment.

f. Capability. This ensures that equipment capability specifications are met.

Chief Architect

0424. The Chief Architect will work in concert with the Capability and Technical Architects
to provide intellectual leadership for the Design Authority. The Chief Architect is (currently)
unlikely to be an individual but a function sourced from a mixed-skills group working to the
SOA Board. The Chief Architect is responsible for the currency of the architectural and
design level deliverables, and the underlying Design Authority processes. The Chief
Architect attends the SOA Board, and provides management guidance and briefings when
required. The Chief Architect also project level SOA architectures are consistent with the
higher level policies and standards defined by the DA, and approved by the SOA Board.

Project Office Manager

0425. The Project Office Manager is responsible for the administration aspects of the
Centre of Excellence for DA. This will include the generation of any DA briefing packs or
agenda items that are required for external Board or Committee meetings. He will also be
the first point of contact for individual SOA development project teams when requesting
access to DA resources.

Service Registrar

0426. The Service Registrar will be the gatekeeper for the SOA metadata. This role will
involve the establishment of a repository to support the classification, and potentially
storage of service components and their metadata. These service components may be
sourced from internal legacy, newly developed and external sources such as industry and
vendors. SOA developers (internal and external) will require search, impact analysis and
assessment support when reviewing requirements for reuse opportunities
Business Service Architect

0427. The Business Service Architect(s) will provide the application (including data)
foundation for the SOA DA. They will provide the necessary application and data design
authority function within the DA. They will be responsible for the development and
communication of the SOA application and data architecture descriptions. These
architecture descriptions may be developed down to design pattern level

Technical Service Architect

0428. The Technical Service Architect(s) will provide the technical foundation for the SOA
DA. They will provide the necessary technical design authority function within the DA. They
will be responsible for the development and communication of the SOA technical
architecture descriptions. These architecture descriptions may be developed down to
design pattern level.

Method/Tool Architect

0429. There may be several of these individuals. The method / tool architect(s) is
responsible for the development and currency of the DA supporting methods, and
appropriate tools. The minimum mandatory methods required for the initial setup of the DA
would be a SOA lifecycle and SOA governance management method.

Summary of Main Constructs.

0430. Figure 15 summarises the key points from the previous 3 sections.
Executive
SOA GOVERNANCE CONSTRUCTS
Sponsor
DSDS (EC)
Para 0406/7

Steering Gp
Executive Steering Capability Technical E2E IS
Group Architect Architect Test and Release
NEC EG/IDSG CM (IS) DG ISTAR DG ISS
Para 0407 Para 0414 Para 0415/6 Para 0418

Working Gp
SOA Board Integration
DEC CC&II DCTO
IDSG/IDWG Authority
Para 0420 Para 0418/20
Para 0408 Para 0417/20

SOA PMO
Para 0425

Architecture
Business Ops Portfolio
Review Board ICAD
Review Board Management Group
IDSG/IDWG Para 0419
Para 0411 Para 0409
Para 0410

Service Business Service Technical Service Tool and Method

COIs
Registrar Architects Architects Architect
Section VI/VII
Para 0426 Para 0428 Section VI/VII Para 0429

Figure 15 Key SOA Governance Constructs

Note: Figure 15 is colour coded orange for (NEC CBM derivation) and mauve (for SoSA
derivation) and Blue for other.

SECTION VI

COMMUNITIES OF INTEREST

Roles of the COI

0431. The creation of new services must be controlled. COIs will do this. COIs work
within the governance structure and are appointed by the SOA Board or the ESG; both of
whom have the requisite visibility across the defence space to make such decisions. This
is important for waste avoidance where there are multi functional or cross cutting service
requirements. The COI will be responsible for defining the user requirement service,
modelling it in MODAF, testing, fielding, registration, performance, availability and SLA
management. There will be a requirement for close liaison with the service provider who
may provide caches or repositories of services to optimise across the DII or other
infrastructure if non-DII; and a security environment. COIs will be the primary source of
funding requirement data for budgetary areas. In addition:

a. COIs must follow Standards requirements laid down in Chapter 2 unless there
are compelling operational reasons for not doing so, in which case justifications
must be raised to the SOA Board;

b. IX COIs will be registered with DG Info, through IX.

c. COIs will be responsible for configuration management. ICAD can provide

advice on this.

d. COIs are responsible for stylesheet generation for conversion of data into other
formats where necessary. Stylesheets will also need to be registered with ICAD.

e. Once the location, type, quantity and availability, performance, agility etc. of
business services is agreed within the COI, agreed XML schema (including those
articulated within an associated intermediate standard) should be registered with
ICAD.

External and Internal Information

0432. External Information services are those services that are intended to be consumed
outside of the COI. Internal Information services will only consumed inside of the COI.
Orchestration of external information services is the responsibility of the service provider on
behalf of DG Info and the business process owner. Defence level External information
services will be managed as a high level COI through the NEC IDWG i.e. SOA Board.
Orchestration and choreography of low level services and functions will be the
responsibility of COIs.

The role of Business Process Owners

0433. Business process owners provide the requirement that services meet and
moreover confirm that their needs are met. They act as “problem owners” for the business
and:

a. Define business processes that require information support.

b. Confirm that information support satisfies their needs.

c. Refine business processes and information support needs (this need not be an
Information Needs Analysis).

The role of Information Owners

0434. Information owners have overall responsibility for defining, maintaining and
delivering the required information sources and services. These may belong to more than
one business process, and potentially across several COIs. They respond to the
information needs and feedback provided by all consumers of their products. They:

a. Define information sources and services (including metadata);

b. Maintain them and their availability to authorised users.

c. Adhere to information sharing and exploitation standards.

The role of Subject Matter Experts (SME)

0435. SMEs provide advice on technical, security, capability development, equipment

procurement and other training or doctrinal issues. They may be asked to provide advice
on specific business functions, or provide broader technical roles in confirming that the
agreed standards will lead to greater information sharing and exploitation. They:

a. Articulate information needs for specific processes.

b. Subscribe to information sources or services (authorised).

c. Adhere to information usage policies.

The role of COI Leaders

0436. COI leaders ensure that COIs achieve the expected results across defence. They
encourage agreement on standards for information sharing, promote best practices for
improved information re-use and ensure that COI activities are pursued with the necessary
support, funding and resources.

a. Ensure COI achieves objectives for info sharing & exploitation.

b. Interact with other COIs for greater semantic interoperability.

c. Share and publish best practices with other COIs.

The role of Equipment Capability Managers

0437. ECMs define the capability gaps that influence the selection of business foci for
various COIs. They have significant influence or in many cases direct control of budgets for
ensuring that the capability gap is filled.

a. Define equipment capability to meet military needs (fill gaps).

b. Ensuring capability meets its required objectives

The role of Procurement Managers (aka IPT Leaders)

0438. IPTLs ensure that the delivery of the specified equipment (information infrastructure
and systems) conforms to the standards required for supporting the relevant information
sources and services. Their primary role is to procure underlying equipment capability that
supports the Enterprise Architecture by providing Interoperability and ensures future
proofing by achieve SOA compliance in a programmed and cost effective process.

Compliance with CADMID/Acquisition Operating Framework

0439. The table below contains the requisite CADMID compliance points.

Stage Compliance Requirements

Initial Gate/DP1 Includes evidence pertaining to Initial Gate (in CADMID terms) or DP1/Authorising
Project Initiation (in PRINCE 2 terms) that must be presented by projects to
demonstrate their compliance with the policy. At this stage in a project the
requirements are typically implementation/technology independent (i.e. as defined
within the URD) Compliance with technical policy will therefore be general in
nature but ensuring that proper consideration is given at later project stages.
Ensure that new COI are only covering new services.

Main Gate/DP2 Includes evidence pertaining to Main Gate (in CADMID terms) or DP2/Authorising
A Project (in PRINCE 2 terms) that must be presented by projects to demonstrate
their compliance with the policy. At this stage in a project the requirements are
implementation/technology specific (i.e. as defined within the SRD) but
implementation details are unknown. Compliance with technical policy will
therefore be typically stated in terms of the policy categories that apply and the
standards to be used. This information will be typically captured within MODAF
technical standards views.

Release Includes evidence pertaining to Release Authority (in CADMID terms) or

Authority/DP5 DP5/Confirming Project Closure (in PRINCE 2 terms) that must be presented by
projects to demonstrate their compliance with the policy. The applicable policy
and/or standards will have been defined within the SRD and/or MODAF technical
standards views. Evidence will typically cover conformance with standards and be
gathered from Factory Acceptance Tests and tests carried out at the Defence Test
and Reference Facility.

Table 2 CADMID Compliance Points

SECTION VII

SETTING UP COIs

Aim

0440. This section provides general guidance on setting up COIs.

Step 1

0441. Identify appropriate business focus.

a. Satisfy clear need from a defence business perspective;

b. Business focus for each COI should be distinct from those for other COIs;

c. Clear objectives for business improvement should be identified (where possible)

with pragmatic measures of success to ensure that the COI provides the right level
of information support;

d. There is to be a strong mandate to pursue this business focus with a senior

responsible owner (or business process owner 49 ).

Step 2

0442. Identify specific business processes & functions.

a. Identify the specific business processes and functions that need information
support;

b. Relate to appropriate business functional model;

Define business processes that need information support.

Step 3

0443. Define information sources & services.

a. Identify existing information sources and services that are already supporting
parts of the existing business processes;

b. Clarity on ownership of specific information sources and services;

c. Maintain sources so that they are visible and available to those authorised to use
them. They should comply with data and information standards agreed within each
COI, so that they are understandable and exploitable (re-useable) across defence;

d. Manage modifications to sources or services.

49
The term “business process owner” comes from the MoD Business Management System (BMS).
Step 4

0444. Confirm membership and roles.

a. The main participants with day-to-day responsibility are the business process
owners;

b. Other stakeholders include equipment capability managers, procurement

managers and representatives for doctrine, training and whole-life support;
c. COI leaders ensure that the COIs are not treated as “talking shops”, but active
communities that focus on defining the right level of information support for the
specified business functions;

d. Get the membership right – cover COI lifecycle, so that all critical information
requirements are addressed.

Step 5

0445. Monitor & refine COI tasks & activities.

a. Complete action plan - metrics need to be defined, so that performance of COI

activities can be monitored and refined in response to both internal and external
feedback;

b. Review progress on COI activities regularly.

SECTION VIII

COMPLIANCE

Responsibility for Implementing the Policy

0446. The DG ISS (and DCTO), DG ISTAR (and IA) and DG Info (and ICAD) are
responsible for implementing the policy. However, this might also slip to an appropriately
empowered Board or Executive/Working group.

Procedure

0447. The following applies:

a. COI Creation. Business areas should display a business functional model in

BPM or MODAF notation along with suggested Communities of Interest. These
should be presented to Information Dimension WG. 50

b. Service Creation. Services and their associated schema should be presented to

ID WG for registration on the DII NECS Managed Service. Interim Guidance and

50
See NEC and CBM Governance earlier.
 Technical design notes have been issued by the Information Dimension WG, and
will become part of the DII Application Developers Guide.

c. Quality Assurance. Throughout projects, Project Review and assurance staff

should seek evidence that evolving solutions comply with the policy and that
deviations from SOA are adequately supported by rigorous evidence

d. Outstanding Issues. In the first instance, all unaddressed issues should be

taken up with Info-XADEA1 (see relevant links).

Relevant Links

Defence Enterprise Integration Website - http://headoffice.dii.r.mil.uk/sites/info/info-ix/dei-

soa/default.aspx.

Contacts

Post Email Telephone Address

Info-XStratDD Info-Xstratdd@mod.uk MB 84410 Main Building

Info-XADEA1 info-XADEA1@mod.uk MB 83443 Main Building

Info-XEA1a Info-XGov1@mod.uk MB 84561 Main Building

EC CCII-SOCBM OP ECCCII-SOCBMOP@mod.uk MB 88288 Main Building

 ABBREVIATIONS

Abbreviation Definition
BPM Business Process Modelling
BPEL Business Process Execution Language
CBM Command and Battle space Management
COI Community of Interest
CWID Coalition Warrior Interoperability Demonstrator
DA Design Authority
DEC CC&II Director of Equipment Capability – Command and Control, Information
Infrastructure
DG ISS Director General Information Systems and Services
DG Info Director General Information
D Info IX Director Information Exploitation
DLOD Defence Line of Development
EA Enterprise Architecture
ESB Enterprise Service Bus
ESC Executive Steering Committee
FLC Front Line Command
GFI Government Furnished Information
GII Global Information Infrastructure
HTTP Hypertext Markup Language
IA Integration Authority
IER Information Exchange Requirement
L&S Logistics and Sustainment
LEA Logistics Enterprise Architecture
LSOA Logistics Service Oriented Architecture
MODAF Ministry of Defence Architectural Framework
NAF NATO Architectural Framework
NEC Network Enabled Capability
NECS Networked Enabled Core Services
SAML Security Assertion Markup Language
SOA Service Oriented Architecture
SOAD Service Oriented Analysis and Design
SOAP Simple Object Access Protocol
Abbreviation Definition
TTOR Task Terms of Reference
UDDI Universal Description Discovery and Integration
UML Unified Modelling Language
WSDL Web Services Description Language
WSPF Web Services Policy Framework
XACML Extensible Access Control Markup Language
XML Extensible Markup Language
 GLOSSARY
(WIP)

Text Definition
Agent Any business unit or automated system (e.g. a software application)
that produces and/or consumes services. An agent can be human or
machine.
Business (BPEL)– describes business processes based on web services
Process
Execution
Language
Business These are information services with a direct counterpart in real
Services business or which contribute to real business
Capability Capability is enduring ability to generate operational outcome or
effect 51
Capability CM (IS) in his role as the 2* programme director of the Networks and
Architect CIS SG will be the Capability Architect. His primary tasks would be
the creation and delivery of the Capability Architecture, specifying
capability requirements (including interoperability), resourcing the
programme and arbitrating or enforcing where necessary
Community of Communities of Interest are groups of stakeholders with
Interest responsibility for defining the lifecycle of information services, in
particular: Ownership; Governance; Production; Consumption;
Delivery; Services definitions; Service creation; Service ownership;
Service level agreements/contracts; Agree XML schema definitions;
Change control; Service standards; Quality of Service.
Core SOA Core SOA Services enable Business Services to be integrated,
Services distributed, and accessed across organizational, geographical, and
technical platform boundaries. Core Services include: security
services; discovery services; a meta-data repository; mediation
services; orchestration services; messaging services; and
Information management services.
Discovery The process of identifying required services.
Function A function is an enduring business operation. A business function is
an activity conducted by an Agent in support of the goals of the
enterprise.
Services The means by which the needs consumers are brought together with
the capabilities of providers.
Information Information Services may be considered as process contracts which
Services provide or consume information.

51
From Capability Management Handbook (Interim Edition) dated 26 Feb 07 V2.0
Text Definition
Information An aggregation of information, often from different sources, as
Product required by consumers.
Information Item Information provided from a single source (producer).
Loose Coupling A key characteristic of SOA solutions that encourages minimal
dependencies among services. This allows the quick assembly of
different business solutions from different combinations of business
services from a variety of systems. Loose Coupling ensures that
changes to one component tend not to affect others, which is good. It
also means if Part A does not know about Part B directly, then they
can be reused independently. The less parts know about each other,
the more loosely coupled they are. Loose Coupling increases reuse
and simplifies maintenance and modification.
Mediation A data conversion capability
Metadata A metadata repository is a database of data about data (metadata) 52 .
Repository The purpose of the metadata repository is to provide a consistent
and reliable means of access to data.
Network A single set of reusable technical, generic enabling or foundation
Enterprise Core services which enable information to be shared based upon access
Services control lists (ACLs). Core Services will include: Security services;
Discovery services; A meta-data repository; Mediation services;
Orchestration services; Messaging services; Information
management services.
On-Line Services Server side applications, using web browsers and common data
sources.
Orchestration Orchestration describes how web services can interact with each
other at the message level, including the business logic and
execution order of the interactions. These interactions may span
applications and/or organizations, and result in a long-lived,
transactional, multi-step process model.
Process A process is a series of activities designed to achieve an outcome.
Security The primary goal of Security is to ensure SOA services can be
invoked securely i.e. which agents may discover and consume
services and under what conditions.
Service An entity which seeks to satisfy a particular need through the use of
Consumer capabilities offered by means of a service.
Service Contract A measurable assertion that governs the requirements and
expectations of two or more parties. Contracts may be expressed in
a form that permits automated interpretation. Among other purposes,
this facilitates automatic service composition. A contract will involve
an agreement on a process associated with the action required.

52
Definition from www.searchoracle.com
Text Definition
Service The information needed in order to use, or consider using, a service.
Description

Service Service management supports deploying, monitoring, starting and

Management stopping services. Management of these services is a continuous
process of managing, measuring, reporting, and improving the
service level (quality of service) of systems and applications.
Service Provider An entity that offers the use of capabilities by means of a service and
implements the service according to the contract.

Service Oriented Service Oriented Architecture is a paradigm for organizing and

Architecture utilising distributed capabilities that may be under the control of
different ownership domains. It provides a uniform means to offer,
discover, interact with and use capabilities to produce desired effects
consistent with measurable preconditions and expectations.
Service Invokes service from a provider to accomplish a task. It locates and
Requester communicates with the service interface
Simple Object SOAP – an XML based protocol used for exchanging information
Access Protocol between computers, using a variety of transfer protocols.
(SOAP)

Technical The Technical Architect role will be fulfilled by DGISTAR as the 2*

Architect sector lead within DE&S. His responsibilities will be executed
through the IA & DCTO to provide the technical architecture, design
guidance, measures of effectiveness and assurances for improved
specification and delivery of System of Systems capability
Universal A technical specification for describing, discovering and integrating
Description web services.
Discovery and
Integration
(UDDI)
eXtensible XML - provides a flexible framework for organising and sharing data.
Markup Heavily used within the XML messaging, service description and
Language service discovery layers of the web services protocol stack.
Web Services Web services are used for building distributed web applications.
They are made available over an intranet network or over the
Internet. They use a standardised XML messaging system; are not
tied to a single operating system or programming language. Web
services are self describing, using common XML grammar and are
discoverable via a simple find mechanism.
Web Services Web Services Description Language (WSDL) – is a specification
Description defining how to describe web services in a common XML grammar.
Language
(WSDL) –
ANNEX A THE BASIS FOR BUSINESS SERVICES

A-01. Business Function Decomposition. In order to ensure that there is as

comprehensive a coverage of MOD activity as possible, a business function model has
been produced by comparing the 3 main activity/process/output models 53 and the outputs
in the Departmental Plan 54 . The resulting functional breakdown will form the basis of the
services to be produced and as each area is designated for further work, appropriate COIs
will form and take forward their development into services. Decisions on the level of any
particular COI i.e. Level 0 or Level 1 will be made on a case by case basis by the SOA
Board. (QQ. There is nothing preventing the model and solutions evolving in parallel) The
Level 0 and 1 functions are shown below and enlarge upon those which were depicted in
Fig 8 (Chapter 2).

A-02. Capability Acquisition. Managing the delivery of planned objectives within

allocated resources. It includes the high level management of military activity, the provision
of crisis management support to Government and the operation of a corporate framework
for defence that meets statutory and legislative requirements.

a. Planning capability acquisition. Establishing a coherent equipment and

sustainment programme from a consideration of the capabilities required, the likely
cost and time to procure them, the priorities across defence and the resources
available. Comprehensive and coherent E2E service management without which
operational C2 will suffer – needs emphasis.

b. Managing acquisition delivery. Managing procurement against the equipment

plan and sustainability requirements, taking account of changing priorities and
requirements, to deliver the optimum capability within allocated resources.

c. Managing customer/supplier relations. Establishing intelligent customer and

supplier relationships to optimise requirements, trade-offs and accountability.

d. Managing technology choices in acquisition. Ensuring the acquisition of

appropriate technology through risk-mitigation programmes e.g. technology
demonstrators, R&D etc.

e. Managing suppliers. Identifying, assessing and developing potential suppliers,

managing supplier performance, ensuring risk is managed appropriately and driving
continuous improvement in the performance and availability of equipment, spares
and commodities.

A-03. Capability Sustainment. Sustaining existing capability. It covers the sustainment

of men and materiel to meet Departmental objectives

53
These are the Business Management System (BMS); Defence Activity Model (DAM) and the CBM Activity Model.
54
Departmental Plan 2005-2009.
 a. Maintenance and repair. Delivering maintenance and repair of military equipment
at depth, forward and deployed facilities in order to maximise availability for training
and operations.

b. Engineering and asset management. Managing fleets and assets to ensure

availability for training and operations.

c. Managing the supply chain. Managing the procurement, storage and distribution
of the inventory necessary to sustain training and operations.

d. Designing support solutions. Designing support solutions to sustain the cost-

effective delivery of through-life capability.

e. Medical support. Delivering medical support, including primary and secondary

care, communal health care and medical advice to commanders

A-04. Operational Readiness (including training for readiness). Generating force

elements at agreed levels of readiness for deployment on operations. It involves the
continuous design, conduct and assessment of collective training in line with current
operational doctrine.

a. Delivering force elements at graduated levels of readiness. Transforming groups

of trained individuals into effective force elements through successive levels of
further training with real equipment under simulated operational conditions to
achieve required levels of readiness.

b. Recently established JC2 Capability Integration facility at the defence Academy.

c. High Level Planning /Strategy. Specification of defence policy and objectives,

required military capability, departmental management policy and the strategic
direction of military operations. It includes the top-level planning and resource
allocation by which departmental objectives and performance targets are set.

d. Formulating UK Defence Policy. Defining at the highest level the military

capability and objectives required of the Department to meet Government policy
aims within allocated resources.

e. Planning the structure of defence. Designing a unified structure through which

the Department delivers military capability within allocated resources.

f. Planning the management of defence. Designing the principles, systems and

processes by which the Department delivers military capability within allocated
resources.

g. Advising the Government on defence. Providing advice to the Cabinet and other
Government departments on defence issues.

h. Setting departmental strategy. Setting the strategy by which the Department will
achieve its objectives
 i. Setting defence capability requirements. Setting requirements for the future
capabilities necessary to achieve defence objectives

j. Setting Departmental objectives. Translating defence strategy into detailed

objectives and targets

k. Directing operations at the strategic level. Providing strategic direction to UK

commanders on operations as necessary. Using the media to explain Government
defence policy, improving public and internal MOD support for defence and
enhancing the reputation of UK armed forces.

A-05. Human Resourcing. Providing sufficient, capable and motivated personnel, both
military and civilian, to the Department to fulfil its aims and objectives.

a. Developing and managing HR plans and strategies. Developing and managing

the recruitment, training, retention, outflow and reserve commitments of military and
civilian staff to meet departmental needs.

b. Managing the deployment of human resources. Managing the provision of

sufficient, capable and motivated personnel to the military and civilian MOD
structure to enable the delivery of defence outputs.

c. Developing and training employees. Providing basic, trade or specialism and

continuation training for individual military (regular, reserves, TA & cadets) and
civilian personnel.

d. Managing employee performance. Managing employee performance through

regular appraisals, ongoing development and selective use of reward and
disciplinary measures.

e. Providing welfare. Provide for the welfare of staff, military and civilian, through
healthcare, housing, social, sporting and recreational facilities.

f. Contributing to the Government’s wider Public Services Agenda. Ensuring the

department adheres to the targets associated with Government-wide personnel
policy

g. Managing the payroll. Managing the pay and benefits of members of the
Department.

h. Managing pensions. Managing the payment of pensions to former members of

the department.

A-06. Managing the MOD. Managing the utilisation of military capability to achieve
Government objectives. It includes determining and managing the defence response to
threats and crises.

a. Providing for department of State activities. Providing defence-related advice to

Ministers and OGDs.
 b. Projecting a national image of defence. Using the media to explain Government
defence policy, improving public and internal MOD support for defence and
enhancing the reputation of UK armed forces.

c. Managing knowledge and information. Managing knowledge and information to

enhance the delivery of defence capability

d. Managing legal affairs. Providing legal support to the delivery of defence

capability.

e. Administering management practice and policy. Establishing internal systems

and processes to support the core business and planning framework and ensure
effective management of the organisation, minimising risks to the delivery of outputs

f. Managing business operations. Monitoring and managing performance against

the targets and objectives set out in the Departmental plan.

g. Managing international relations/diplomacy. Engaging with NATO and allies to

reduce the causes and/or mitigate the effects of international conflict.

h. Managing corporate governance. Managing risks to the effective and efficient

achievement of Departmental objectives.

i. Managing defence protective security. Managing the implementation of security

policy and standards throughout defence.

j. Managing core defence processes. Managing the delivery of defence

intermediate outputs through the effective operation and coordination of core
business and enabling processes.

k. Managing scientific research and academic activity. Monitor scientific and

academic research to maintain awareness of potential improvements to the
effectiveness or efficiency of the delivery of defence

l. Managing Health & Safety. Manage all activities across the department in such a
way as to minimise unnecessary deaths or injuries.

m. Managing the MOD Estate. Supporting and enhancing military capability by

providing and maintaining the estate and its infrastructure, including service family
housing.

A-07. Military Operations. Managing the delivery of planned objectives within allocated
resources. It includes the high level management of military activity, the provision of crisis
management support to Government and the operation of a corporate framework for
defence that meets statutory and legislative requirements.
 a. Managing deployment to and recovery from operations. Planning and managing
the deployment and recovery from operations, including the provision of ships,
aircraft, rail, port facilities and staging areas.

b. Planning and directing military operations. Providing for the command and
control of military operations.

c. Providing communications for operations. Planning and managing the provision

of communications for deployed operations.

d. Providing a crisis-management facility. Providing to government facilities for

managing crises

e. Providing environmental support to operations. Providing specialist hydrographic,

topographical and meteorological support for operations.

f. Providing HQ architecture and infrastructure.

g. Providing intelligence support. Providing specialist intelligence support for

planning and operations

h. Managing interoperability with Nations/Allies. Enabling the UK to inter-operate

with other nations and allies, including by the definition and specification of common
standards and processes and through liaison and coordination.

i. Delivering military effects. The delivery of effects by military means

j. Protecting the force. Providing for the self-protection of the force in order to
preserve its capability to undertake effects-based operations.

k. Shaping the Theatre of Operations. Preparing the theatre of operations in ways

that favour the effectiveness of blue forces.

l. Targeting. Identifying and selecting targets for effects-based operations and

assessing the delivery of effects, post-strike.

m. Conducting special operations. Planning, executing and assessing the effects of

special operations.

n. Countering WMD. Planning, delivering and assessing measures counter the

effects of WMD.

A-08. Managing Finance. Monitoring and managing resource consumption within agreed
budgets against defence outputs.

a. Managing Financial Transactions. Monitoring and managing resource

consumption by activity period in-year against budgets to ensure that the
Department secures value for money and meets the expected standards of probity
and propriety.
b. Accounting. Preparing departmental resource accounts for audit by the NAO.

c. Managing Budgets. Managing the delivery of outputs against the consumption of

resources within agreed limits.

d. Developing Financial Policy. Developing departmental financial policy in line with

HMT and NAO guidance.

e. Conducting Financial Audit. Evaluating the economic, efficient and effective use
of defence resources, the prudent administration of the department and the
adequacy and effectiveness of the department's risk management by means of
internal audit.
ANNEX B WS-I BASIC PROFILE 2.0 CONTENTS

WS-I Basic Profile 2.0 Contents

Content
1Introduction
1.1Relationships to Other Profiles
1.2.Guiding Principles
1.3. Compatibility with Basic Profile 1.1 and 1.2
1.4. Notational Conventions
1.5. Profile Identification and Versioning
2. Profile Conformance
2.1. Conformance Requirements
2.2. Conformance Targets
2.3. Conformance Scope
2.4. Claiming Conformance
3. Messaging
3.1. Message Serialization
3.1.1. XML Envelope Serialization
3.1.2. Unicode BOMs
3.1.3. XML Declarations
3.1.4. Character Encodings
3.1.5. XOP Encoded Messages
3.2. SOAP Envelopes
3.2.1. SOAP Envelope Structure
3.2.2. SOAP Body Namespace Qualification
3.2.3. Disallowed Constructs
3.2.4. xsi:type Attributes
3.2.5. SOAP 1.2 attributes on SOAP 1.2 elements
3.3. SOAP Processing Model
3.3.1. SOAP Fault Processing
3.4. SOAP Faults
3.4.1. Identifying SOAP Faults
3.4.2. SOAP Defined Faults Action URI
3.4.3. SOAP Must Understand or VersionMismatch fault Transmission
3.5. Treatment of URIs in SOAP
3.5.1. Comparison of URI values of SOAP Information Items
3.6. Support for WS-Addressing
3.6.1. Requiring WS-Addressing SOAP headers
3.6.2. NotUnderstood block in MustUnderstand Fault on WS-Addressing SOAP headers
3.7. Use of WS-Addressing MAPs
3.7.1. Use of wsa:Action and WS-Addressing 1.0 - Metadata
3.7.2. Understanding WS-Addressing SOAP Header Blocks
3.7.3. Valid Values for action Parameter on the Content-Type MIME header When WS-
Addressing is Used
3.8. Use of SOAP in HTTP
3.8.1. HTTP Protocol Binding
3.8.2. Parameters on the Content-Type MIME Header
3.8.3. HTTP Success Status Codes
WS-I Basic Profile 2.0 Contents
Content
3.8.4. HTTP Redirect Status Codes
3.8.5. HTTP Cookies
3.8.6. Use of Non-Anonymous Reponse EPR in a Request-Response Operation
3.9. Use of URIs in SOAP
3.9.1. Use of SOAP-defined URIs
4. Service Description
4.1. Required Description
4.2. Document Structure
4.2.1. WSDL Schema Definitions
4.2.2. WSDL and Schema Import
4.2.3. WSDL Import location Attribute Structure
4.2.4. WSDL Import location Attribute Semantics
4.2.5. Placement of WSDL import Elements
4.2.6. XML Version Requirements
4.2.7. XML Namespace Declarations
4.2.8. WSDL and the Unicode BOM
4.2.9. Acceptable WSDL Character Encodings
4.2.10. Namespace Coercion
4.2.11. WSDL documentation Element
4.2.12. WSDL Extensions
4.3. Types
4.3.1. QName References
4.3.2. Schema targetNamespace Structure
4.3.3. soapenc:Array
4.3.4. WSDL and Schema Definition Target Namespaces
4.3.5. Multiple GED Definitions with the same QName
4.3.6. Multiple Type Definitions with the same QName
4.4. Messages
4.4.1. Bindings and Parts
4.4.2. Bindings and Faults
4.4.3. Unbound portType Element Contents
4.4.4. Declaration of part Elements
4.5. Port Types
4.5.1. Ordering of part Elements
4.5.2. Allowed Operations
4.5.3. Distinctive Operations
4.5.4. parameterOrder Attribute Construction
4.5.5. Exclusivity of type and element Attributes
4.6. Bindings
4.6.1. Use of SOAP Binding
4.7. SOAP Binding
4.7.1. Specifying the transport Attribute
4.7.2. HTTP Transport
4.7.3. Consistency of style Attribute
4.7.4. Encodings and the use Attribute
4.7.5. Multiple Bindings for portType Elements
4.7.6. Operation Signatures
4.7.7. Multiple Ports on an Endpoint
WS-I Basic Profile 2.0 Contents
Content
4.7.8. Child Element for Document-Literal Bindings
4.7.9. One-Way Operations
4.7.10. Namespaces for wsoap12 Elements
4.7.11. Consistency of portType and binding Elements
4.7.12. Enumeration of Faults
4.7.13. Type and Name of SOAP Binding Elements
4.7.14. name Attribute on Faults
4.7.15. Omission of the use Attribute
4.7.16. Default for use Attribute
4.7.17. Consistency of Envelopes with Descriptions
4.7.18. Response Wrappers
4.7.19. Part Accessors
4.7.20. Namespaces for Children of Part Accessors
4.7.21. Required Headers
4.7.22. Allowing Undescribed Headers
4.7.23. Ordering Headers
4.7.24. Describing action Parameter on the Content-Type MIME Header
4.7.25. SOAPAction HTTP Header
4.7.26. SOAP Binding Extensions
4.8. Use of @soapActionRequired in WSDL 1.1 SOAP 1.2 Binding
4.9. Use of XML Schema
4.10. WS-Addresing 1.0 - Metadata
5. Service Publication and Discovery
5.1. bindingTemplates
5.2. tModels
6. Security
6.1. Use of HTTPS
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Normative References
Appendix D: Defined Terms