Soa Ref Model White Paper Industry

The Navy Service Oriented Architecture
Reference Model, a new beginning

SOA-RM
White Paper

Jose Davila
May 19, 2009

i

Table of Contents

1.0 INTRODUCTION ................................................................................................................. 1
1.1 PURPOSE .......................................................................................................................... 1
1.1.1 Navy SOA RM Document Goals & Objectives ............................................................ 2
1.2 SCOPE .............................................................................................................................. 2
1.3 BENEFITS .......................................................................................................................... 3
1.4 KEY GUIDANCE & REFERENCES .......................................................................................... 3
1.4.1 Compliance .................................................................................................................. 3
1.4.2 OASIS SOA Reference Model and CANES SOA Reference Architecture ................. 3
1.5 DOCUMENT ORGANIZATION ................................................................................................ 3
1.6 USE OF COMMERCIAL BEST PRACTICES .............................................................................. 4
2.0 THE NAVY TECHNICAL REFERENCE MODEL ............................................................... 6
2.1 BUSINESS REFERENCE MODEL (BRM) ................................................................................ 7
2.1.1 A BRM Approach for the Navy .................................................................................... 8
2.1.2 SOA and Business Process Management – A Commercial Best Practices Example 8
2.1.3 Service Component Architecture (SCA) Standard and Business Integration ............. 9
2.2 SERVICES REFERENCE MODEL (SRM) .............................................................................. 11
2.3 TECHNICAL REFERENCE MODEL (TRM) ............................................................................ 12
2.3.2 COI application-specific SOA .................................................................................... 15
2.3.3 NESI elements ........................................................................................................... 16
2.3.4 SOA and Network Management Architecture............................................................ 17
3.0 SOA IMPLEMENTATIONS WITHIN THE NAVY .............................................................. 18
3.1 CANES USE CASE .......................................................................................................... 19
3.1.1 Architectural Patterns ................................................................................................ 19
3.1.2 Middleware Model of the CANES SOA Infrastructure Architecture ........................... 22
3.2 W EB SERVICES FRAMEWORK ........................................................................................... 23
3.2.1 Infrastructure Components of the CANES SOA Architecture .................................... 25
3.2.2 Management Services ............................................................................................... 27
3.2.3 CANES SOA Governance Infrastructure Architecture .............................................. 28
4.0 CONCLUSION AND RECOMMENDATION ..................................................................... 30
4.1 SOA GOVERNANCE ......................................................................................................... 30
4.1.1 A Governance Model for Navy Consideration ........................................................... 30
4.1.2 SOA - Beyond the Reference Model ......................................................................... 32
APPENDIX A - REFERENCES ..................................................................................................... 35

ii

List of Figures

Figure 1: Navy Technical Reference Model ............................................................................................ 6
Figure 2: SOA RM Instantiations ............................................................................................................. 6
Figure 3: Navy SOA RM .......................................................................................................................... 7
Figure 4: Complete SOA Integration Solution Architecture ................................................................... 10
Figure 5: SOA Production TRM ............................................................................................................. 13
Figure 6: NESI Compliant COI Framework ........................................................................................... 17
Figure 7: Platform Model of the CANES SOA Runtime Infrastructure Architecture .............................. 20
Figure 8: Middleware Model of the CANES SOA Runtime Infrastructure ............................................. 23
Figure 9: Runtime Infrastructure Components Model of the CANES SOA Reference Architecture ...... 26
Figure 10: SOA Integration + SOA Governance, Management & Security ........................................... 30
Figure 11: Governance Model ............................................................................................................... 31
Figure 12: Standard IDEF0 Model ......................................................................................................... 34

iii

Foreword
Originally drafted for the Navy this paper takes the opportunity to document the many conceptual
and adaptive pieces discussed within the walls of Navy Headquarters and Acquisition
Commands, as a concept to corral the beginnings of mandated standards, loosely coupled
directives and ongoing efforts by Programs of Record in the Navy to implement a SOA capability
both afloat and ashore. It goes as far as providing definitions of what SOA is, what it represents
and how the Navy should use it as well as manage it. So, be a little forgiving when the obvious is
stated, although for some the obvious will be new information.

1.0 Introduction
This Navy SOA Reference Model (RM) is intended to identify the standards, specifications, and
technologies that support and enable the delivery of service components and capabilities to
Navy‘s Service Oriented Architecture (SOA) implementations.

The basic idea of a SOA is familiar to most all in the IT community, whether on the commercial
side or the DoD/Navy side. The concept is of very large blocks of ―services‖ that facilitate
interoperability, reuse, and orchestration largely through the ―loosely coupled‖ architecture that
keeps individual service design details completely hidden, exposing only the input and output
parameters needed for interface of a service with users, providers, other services, or system
servers/management platforms.

The SOA architectural approach accounts for the fact that the individual services that comprise a
future SOA already exist. These services may have been designed with older technologies and
associated standards that would not be used today. They may also be relatively large systems
comprised of highly interlinked components that cannot easily be disassembled to form individual
smaller services.

Conceivably, there could be some large segments (e.g. an afloat platform) of an enterprise that
cannot be exposed to the SOA during a disconnected state except through a small pipeline
carrying limited information in each direction. However, through that pipeline, with the proper SOA
interface standards/ technologies, that afloat platform can still be made to function as an
individual ―service‖ in the SOA, and it may thereby still take advantages of the SOA infrastructure
and the other services in the SOA.

While the very concept of a SOA is founded on the objective of interoperability between services,
businesses, and technical platforms, it also implies standardization of concepts, service
components, development processes, etc. The RM serves to outline the technology elements that
collectively support the successful adoption and implementation of a SOA for service
interoperability, service reuse, enterprise system management, and governance, but it is clear
that the SOA model also provides the foundation to advance the re-use of technology, component
platforms, and middleware across the Navy through standardization. Therefore, via the
implementation of SOA, the Navy will benefit fiscally from economies of scale by identifying and
re-using the best solutions and technologies to support their business functions, and missions.

1.1 Purpose

The purpose of this document is to present a relatively concise technical description of a large
scale SOA (as typified e.g. by CANES) along with a summary description of the SOA technical
components, middleware solutions, governance solutions, etc. as well as key standards that will
form the foundation of the SOA. The document will briefly describe the overall goals of a SOA in
the context of both the well-understood generic commercial SOA goals as well as the unique and
more demanding goals of a DoD instantiation of a SOA. The SOA will be described from the top

1

level down in terms of how the SOA design can achieve, via specific technical approaches and
component solutions, the SOA technical objectives for a enterprise that has a full and diverse
range of domains, platforms, and systems.

1.1.1 Navy SOA RM Document Goals & Objectives

This document addresses the following goals and objectives:

Make clear the fundamental rationale and advantages for the adoption of a SOA style of
architecture
Define key SOA concepts, architectural features, core SOA functions, and the alternative
patterns/systems/platforms/technologies/standards that enable those concepts, features
and functions
Identify the key elements of a SOA infrastructure, the supporting technologies, and
recommendations for each
Establish / summarize the strong need for SOA Governance, enterprise management,
and configuration management
Describe the issues with and needs for IA/Security in a SOA environment
Make available a SOA Reference Document that concisely summarizes issues
associated with secure development and / or use of services, middleware components,
infrastructure components, and management platforms
Emphasize the associated technology standards and specifications in all descriptions of
the SOA component services, functions, and the corresponding COTS platforms and
systems
Provide Commercial Best Practices that are applicable to SOA implementations
Identify and briefly describe key SOA implementations within the Navy (e.g. CANES) that
are representative of best practices for Navy SOA

1.2 Scope

The scope of this document is principally limited to brief summaries and discussions of SOA
concepts, components, and technologies described from a services view of a SOA architectural
framework. Non real-time Web Services technologies and platforms form the principal means of
implementing SOA in both the commercial and navy applications, so these receive much
attention. However, other technologies (including ―real-time‖ technologies) are also fundamental
for the War-fighting and legacy system needs, and these are within the scope of this document.

With a focus on the Services View, that means that there is not any extensive discussion of the
likely approaches for a SOA Management View (e.g. for configuration control), or for an IA View
(e.g. for computer network defense), or for a Physical View (e.g. that addresses basic network
resources that are not SOA specific). Neither is it necessary to address the various Software
View considerations that go into building the various services. The latter does not need to be
addressed largely because it is a fundamental concept of SOA for each service component to
have its software completely hidden from that service interface exposed to users or other
services.

While the focus here is not on the IA/Security or detailed System Management considerations, it
is recognized that these are critically important areas that warrant thorough attention in a SOA
implementation. However, the central role of these areas is clear and indicated within the scope
of this document.

2

1.3 Benefits

This document should prove to be useful as a guide for program managers and others to
understand system architects‘ and system designers‘ selections, recommendations and decisions
regarding technical solutions and related standards regarding individual SOA service
components, middleware components, as well as SOA enterprise platform components.

For those responsible for planning at the enterprise level, a good understanding of SOA
architectural essentials and alternatives for SOA systems, platforms, core service components,
and technologies should be a significant benefit for their IT decision making and budgeting
processes. As will be further discussed in this SOA RM, the SOA Management and Governance
systems, that are essential parts of the SOA infrastructure, are critically important for both SOA
planning and efficient operations. To the extent that this document adds clarity to those
considerations, this is another significant benefit.

1.4 Key Guidance & References

1.4.1 Compliance
This document is intended to comply with high-level guidance, which is mandated by the
competent authority. The following documents are used in reference to the compilation of this
information.

a. JCIDS as defined by CJCSI 6212.01D a
b. DoDAF 1.5, the FORCEnet Framework,
c. The OSI Model
d. DoD GiG initiatives
e. Net Centric Enterprise Solutions for Interoperability (NESI)
f. PEO C4I Masterplan for Systems Engineering v2.0
g. Navy Technical Reference Model

1.4.2 OASIS SOA Reference Model and CANES SOA Reference Architecture
The intention of this SOA Reference Model (RM) is to provide a foundation to describe the
standards, specifications, and technologies supporting the secure delivery, exchange, and
construction of business (or Service) components and IT solutions consistent with Navy needs for
Service Oriented Architecture solutions.

To put this document in context with other related documents, we note first that

SOA concepts utilized in this document are consistent with the relatively abstract concepts
presented in the OASIS Reference Model for Service Oriented Architecture v1.0.

The much less abstract (but not ―concrete‖) CANES Systems Design Specification document is
an example of the ―reference architectures and patterns‖ that defines more categories of SOA
design. In this case for a typical large scale SOA, the ―concrete architectures‖ in the CANES case
will come from the contractors who will be chartered to design and create the CANES SOA.

1.5 Document Organization

The organization of this document is as follows:

3

Chapter 1: The Reference Model Background - provides the definition, purpose,
development, and validation process for the Navy Reference Model.
Chapter 2: The Hybrid Reference Model - provides a complete overview of version of the
Technical Reference Model, Service Reference Model, and the Business Reference
Model, including definitions of each Service Area, Service Representation, Service
Category and Service Specification.
Chapter 3: Describes SOA implementations currently planned or in use in the Navy. It is
high level, how CANES and IWS are using the RM.
Figures: Lists figures applicable to the Reference model or architectures referenced in
this document.
Appendix: Provides detailed references used in this document.
References: A Bibliography of source materials used to compile the information
contained in the document.

1.6 Use of Commercial Best Practices

One can broadly define a SOA as a group of services that communicate with each other.
However, by now, SOA is understood by most in the IT community. Whether on the commercial
side or the DoD/ Navy side, as a concept of very large blocks of ―services‖ that facilitate
interoperability, reuse, and orchestration, Largely through the ―loosely coupled‖ architecture that
keeps individual service design details completely hidden….exposing only the input and output
parameters needed for interface of a service with users, providers, or other services.

SOAs build applications out of software services. Services comprise intrinsically unassociated
units of functionality that have no calls to each other embedded in them. Instead of services
embedding calls to each other in their source code, they use defined protocols, which describe
how one or more services can talk to each other. This architecture then relies upon linking and
sequencing of services, in a process known as orchestration, to meet more complex business
systems requirements.

SOA has the goal of allowing large chunks 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, very
large chunks of functionality may not prove granular for easy reuse. Each interface brings with it
some amount of processing overhead, so there is a performance consideration in choosing the
granularity of services.

For this SOA concept to operate successfully, no interactions between the specified building
block services must exist internal to each of those services, hence the ―loose coupling‖
requirement that is always a term used to describe SOA. Programmers develop the services
themselves using traditional languages like Java, C#, C++, C or COBOL.

SOA relies on services exposing their functionality via interfaces, which humans and other
applications and services can read to understand how to utilize those services.

―When all is said and done‖ a SOA provides a design framework for realizing efficient system
development and improved total system quality. SOA primarily uses the Web services standards
and technologies and is rapidly becoming a standard approach for enterprise information
systems.

4

1.6.1.1 Key considerations for building a SOA

The following guiding principles define the ground rules for development, maintenance, and
usage of any SOA.

Reuse, granularity, modularity, composability, componentization, portability, and
interoperability
Standards compliance (both common and industry-specific)
Services identification and categorization, provisioning and delivery, and monitoring and
tracking
The following specific architectural principles for SOA service design and definition focus on
specific themes that together comprise the essential features that define a SOA:

Service encapsulation - Many web-services are encapsulated in order to be used under
the SOA. Often such services were not originally planned to be under SOA.
Service loose coupling - Services maintain a relationship that minimizes dependencies
and only requires that they maintain an awareness of each other
Service contract - Services adhere to a communications agreement, as defined
collectively by one or more service description documents
Service abstraction - Beyond what is described in the service contract, services hide
logic from the outside world
Service reusability - Logic is divided into services with the intention of promoting reuse
Service orchestration - Collections of services can be coordinated and assembled to
form composite services
Service autonomy – Services have control over the logic they encapsulate
Service optimization/Quality of Service – Closely tied to the objective of avoiding
service or SOA disruption during Service version and policy changes.
Providing for control mechanisms to address issues such as outages, peak load
congestion
Optimization mechanisms include load-balancing, content-based routing, Service Level
Agreement (SLA) policies.
Service discoverability – Services are designed to be outwardly descriptive so that they
can be found and accessed via available discovery mechanisms

5

2.0 The Navy Technical Reference Model
The Navy Technical Reference Model is a high level framework for visualizing the various layers
throughout the Navy, see Figure 1. It allows for better management of business at a strategic
level while providing a means for gauging progress towards the target EA. For SOA, we are
concerned with the services layer but there are linkages to the application and computing layer as
well as IA and QOS.

Figure 1: Navy Technical Reference Model

In order to achieve a Standards Profile for SOA adherence to the Navy Technical Reference
Model should provide the domain-centric levels of functionality to be addressed in this document.
To describe a SOA, decompose it into terms and definitions, use cases, and specifications and
standards. Figure 2 describes a C4I and a weapon system instantiation of a SOA, along with the
general types of IT standards. The bridge between those instantiations is a coordinated
methodology of sharing information.

Figure 2: SOA RM Instantiations

6

To fully describe a C4I, weapon system or other instantiation of a SOA, a Navy SOA RM
establishes a common set of general performance outputs and measures that users can use to
achieve program and business goals and objectives. The model (Figure 3) describes the linkage
between internal business components and the achievement of business and customer-centric
outcomes using the available technology and resources (money, infrastructure).

Figure 3: Navy SOA RM

2.1 Business Reference Model (BRM)
The alignment and relationship of the Reference Model to Enterprise Architectures is one of the
next steps towards implementing the model across the Navy. Aligning the layers of the Business,
Service and Technology, enables the categorization of an IT investments, assets and
infrastructure by the common definition and purpose of the Service Specifications and Service
Components in the Model.

The Business Reference Model is the business foundation for the Navy‘s Enterprise Architecture
initiative. It provides a common business area, Line of Business (LOB), and Sub-function
language between C4I and Weapons Systems as well as interoperability to other service
components. It identifies opportunities to share services and technical solutions among
organizations that perform similar functions, connecting the more technical Enterprise
Architecture Reference Models to the business and helping guide and prioritize the development
of those models, and help identify the high-level scope of enterprise projects. The model
describes the navy‘s Lines of Business, including its internal operations and its services for
Sailors, bureaus and offices that perform them. By describing the Navy around common business
areas instead of the stove-piped technical view, the BRM promotes Service-Wide collaboration.

7

2.1.1 A BRM Approach for the Navy
While a well-planned SOA can be executed by the Navy can help realize cost savings, service re-
use and a greater responsiveness to a changing environment, how the Navy proceeds and what
approach takes the key to a successful implementation. Traditional approaches to SOA
implementation entail a top down enterprise-wide approach, which requires an enormous time
investment that by the time the project is complete no longer aligns to the Navy‘s business needs.
A recommended approach is a ‗via media‘ approach or ‗middle out‘ approach that combines both
a top-down and a bottom up approach methodology. In this approach, efforts are driven by
strategic vision and business needs, and are met through incremental, iterative SOA projects that
use this technique to assist Programs of Record with their SOA initiatives. Although many
perspectives exist and this document does not attempt to solve this technical dilemma for the
Navy, it does what to stimulate thoughts about how to proceed by providing three abstract
capability layers that are exposed within a SOA that would facilitate identification, reuse, and
orchestration of services. They are based on Loose Couple thinking and are: Expose, Compose,
and Consume.

Expose - Expose focuses on how existing IT investments are exposed as a set of broad,
standards-based services, enabling these investments to be available to a broader set of
consumers. Existing investments are likely to be based upon a set of heterogeneous
platforms and vendors. If these applications are unable to natively support Web services
a set of application or protocol-specific set of adapters may be required. Service creation
can be fine grained (a single service that maps on to a single business process), or
coarse grained (multiple services come together to perform a related set of business
functions). Expose is also concerned with how the services are implemented. The
functionality of underlying IT resources can be made available natively if they already
speak Web services, or can be made available as Web services though use of an
adapter.
Compose - Once services are created, they can be combined into more complex
services, applications or cross-functional business processes. Because services are exist
independently of one another they can be combined (or ―composed‖) and reused with
maximum flexibility. As business processes evolve, business rules and practices can be
adjusted without constraint from the limitations of the underlying applications. Services
compositions enable new cross-functional processes to emerge, allowing the enterprise
to adopt new business processes, tune processes for greater efficiency, or improve
service levels for customers and partners.
Consume - When a new application or business process has been created, that
functionality must be made available for access (consumption) by IT systems, other
services or by end-users. Consumption focuses on delivering new applications that
enable increased productivity and enhanced insight into business performance. Users
may consume ―composed‖ services through a broad number of outlets including web
portals, rich clients, Office business applications (OBA), and mobile devices. ―Composed‖
services can be used to rapidly roll out applications that result in new business
capabilities or improved productivity. These application rollouts can be used to measure
the return on investment (ROI) in an SOA.

2.1.2 SOA and Business Process Management – A Commercial Best Practices
Example

The convergence of SOA and Business Process Management (BPM) has become one of the
most talked about subjects in industry - and one of the most confusing. Let us try to eliminate
some of that confusion by first focusing on the influence of BPM on SOA architectures.

8

We cannot talk about IT integrating ERP systems without also considering how that integration
will play with the business analysts or LOB who actually need that data or services for their
business processes. These two often-contradictory elements need to work together as part of a
fully integrated solution. When SOA and BPM play well together, we have seen enormous
benefits. Not only is there alignment between the various roles in IT and the LOB, but the
processes are implemented in an optimized way that both camps can successfully manage. Let
us look at one example of how SOA & BPM can work together and provide complimentary
benefits.

Once a business process model is implemented and automated across the SOA Integration,
optimization occurs when runtime feedback is returned to the business analyst via integrated
business-activity monitoring. This lets business users see where process improvement needs to
occur in real time. Once improvements are identified, the business analyst can update both the
models and the business and the development cycle begin anew. True business transformation
and optimization are realized through this iterative business-integration cycle.

To see these types of benefits SOA and BPM needs to be integrated in such a way as to give
multiple users in the organization common unified tools to share metadata, share governance and
management information, and ultimately optimize the interoperability between a business
processes and how those processes are translated to the back-end integration.

Figure 10 describes one example of how that type of process can be described from a business
analyst viewpoint. That process can be shared into a repository; the respective metadata (not
necessarily the process view) can be shared among architects, developers, and operations. For
example, an architect can implement the ERP entry point for the back-end process, a developer
can build a transformation map, and the operations people can specify an SLA policy.

When BPM is combined with the power of SOA Integration, enterprises reap enormous benefits.

2.1.3 Service Component Architecture (SCA) Standard and Business Integration
The concept of building multiple complex services without boundaries (i.e. large distributed
services) is nothing new. However, trends are emerging that are shaping the creation,
management, and deployment of composite services.

Enter SCA, the Service Component Architecture standard. This important standard specifies an
abstract model that architects can leverage for developing, managing, and modeling composites.
These composites are enterprise-wide, free of any limitations imposed by project boundaries or
the scope of an integration scenario. These integration services between ESBs, BPMs, and Data
Service Platforms constitute one component within a composite flow. Other entry-points can
originate from Web 2.0 portals or even simple SOAP-based JMS events.

The importance of managing these composites and providing tools for them is extremely critical
for the success of complex SOA Integration projects. In this example in Figure 4, an architect
models a composite service flow within the Eclipse environment. The entry points and
dependencies are identified which helps to ensure that the actual implementation matches the
intended implementation. This also helps ensure that the lifecycle of complex SOA integration
implementations can be managed successfully where hand-offs between multiple roles can be
better governed if these dependencies are centrally managed.

9

2.1.3.1 SOA Integration Solution Architecture

Figure 4: Complete SOA Integration Solution Architecture

The combination of SOA governance, BPM, and composite services in figure 4dds up to state-of-
the art capabilities for integrating any type of service, data, message, or event. Adopting a holistic
approach to SOA governance, management, and security will provide essential visibility and
control, and allow business processes to be tied into integration services. Those services can
then be shared with teams across the enterprise.

2.1.3.2 SOA Business Planning Thoughts and Integration Checklist

If it is one thing that SOA has taught us, it is the need for re-use. We have just looked at how
leveraging common components within the SOA Integration solution gives us the most well-
rounded capabilities for the overall solution. Beyond that lesson, we will look at three other
important lessons learned in SOA:

Start Governance early: SOA Integration and SOA Governance need to work together
to give you the benefits of agility, cost-reduction, and reduced risk.
Do not do SOA in an IT vacuum: With SOA and BPM ensure that business processes
are optimized to realize the benefit of SOA for the entire organization.

Start small, but think holistically. Small projects are a great starting point, but services quickly
develop into composite services. These composite services need to be managed, designed, and
deployed centrally, as well as, work together with the SOA Integration solution.

SOA integration fulfills a great many purposes for your enterprise. However, choose your
architecture pattern carefully and ensure that your solution architecture meets the forward-looking
requirements of your business. Below are some key questions you should ask when considering
a SOA integration solution:

Does my ESB avail itself of reusable components for connectivity, security, and
orchestration?

10

How are composite services managed, are they standards-based, do they work only with
integration or can they go beyond?
Is there a SOA governance solution optimized for the integration solution?
Is it SOA integration or simply integration?
How does BPM fit together with the SOA integration solution?
What types of connectivity options are offered—an adapter approach or a SOA
approach?
Are there common or shared components in the architecture? Can tooling modules be
plugged in?
Will you need to start completely over when you think about data or events?
Does the SOA integration solution have capabilities for enterprise wide deployments?
Does the SOA integration solution scale beyond the enterprise?

2.1.3.3 Challenges in Adopting SOA - One common challenge faced involves
managing services metadata.

SOA-based environments can include many services, which exchange messages to perform
tasks. Depending on the design, a single application may generate millions of messages.
Managing and providing information on how services interact is a complicated task. This
becomes even more complicated when these services are delivered by different organizations
within the company or even different companies (partners, suppliers, etc). This creates trust issue
across teams, and hence SOA Governance becomes very important.

Another challenge involves the lack of testing in SOA space. No sophisticated tools exist that
provide testability of all headless services (including message and database services along with
web services) in a typical architecture.

Another challenge relates to providing appropriate levels of security. Security models built into an
application may no longer be appropriate when the capabilities of the application are exposed as
services that can be used by other applications. That is, application-managed security is not the
right model for securing services.

Interoperability is perhaps the most important aspect of Navy SOA implementations. The WS-I
organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce
compatibility. Thus the emphasis on the WS-I profile of Web Services standards in this
discussion.

Finally, it should be obvious that modifications to the external parameters exposed by a service
can be a problem in cases where other services rely on the subject service as part of its
functionality. Again, this situation necessitates comprehensive SOA management and
governance.

2.2 Services Reference Model (SRM)

The SRM is a business-driven, functional framework that classifies Service Components with
respect to how they support business and/or performance objectives. The SRM is structured
across horizontal service areas that, independent of the business functions, can provide a
leverageable foundation for reuse of applications, application capabilities, components, and
business services.

11

The Navy Service Reference Model is the functional framework that classifies Service
Components with respect to how they support business and/or performance objectives. The SRM
is based on the structure of the Federal Enterprise Architecture (FEA) SRM, described reference
b.

The Navy SRM directly links to the Lines of Business in the Navy Business Reference Model
(BRM) that provide the taxonomy of Navy operations. The SRM is structured across the Navy
mission areas of the Warfighter, Business, Intelligence, and the Enterprise Information
Environment (EIE). The Service Components for these mission areas provide a ―leverageable‖
foundation to support the reuse of Navy applications, application capabilities, components, and
business services.

In this version of the SRM, Business Enterprise Architecture represents the Navy‘s Business
Operations Mission Area Service Components. The Net-Centric Operations and Warfare
Reference Model (NCOW RM) Version 1.1 and Net-Centric Enterprise Services (NCES)
represent the EIE Mission Area Service Components.

The Department of the Navy‘s (DON) Common System Functions List (CSFL) represents the
Warfighter Mission Area Service Components; the Intelligence Community Enterprise
Architecture (IC EA) system functions represent the Intelligence Mission Area‘s Service
Components. These areas will be further developed in future versions as common components
for each mission area evolve.

The SRM identifies Service Domains that provide a high-level view of the services and
capabilities that support enterprise and organizational processes and applications. The Service
Domains are supported by Service Types and further classified into Service Components. And
each Service Domain is classified into one or more Service Types that group similar capabilities
in support of the domain.

Each Service Type also includes one or more Service Components that provide the ―building
blocks‖ to deliver the component capability to the business.

2.3 Technical Reference Model (TRM)

The SOA TRM is shown in Figure 5. Each aspect of the reference model will be addressed is
addressed in the following paragraphs.

12

SPAWAR Services Oriented Architecture (SOA) Technical Reference Model (TRM)
1/14/2009
Governance
Policy Process

Service Registries
Visualization & Presentation

Service Management
Collaboration Tools

Security
Mediation, Messaging & Orchestration

Data Services

Data Model &
Metadata Data Infrastructure
Repository

Acquisition & Contracting Technical Management

Figure 5: SOA Production TRM

The TRM is a framework to describe how technology supports the secure delivery, exchange,
and construction of Service Components. The TRM outlines the technology elements that
collectively support the adoption and implementation of component-based architectures, as well
as the identification of proven products and toolsets that are embraced by Navy.

1. Data Infrastructure: Database, data engine and supporting hardware and software
activities that store and retrieve information in a reliable manner. SOA implementations
do not allow end-users to access the data infrastructure directly. All Data Infrastructure
activities are governed under Technical Management per applicable policy and business
rules established by the Governance Authority.
2. Data Model & Metadata Repository: The Data Model of the Data Infrastructure and
Metadata Repository software and hardware activities. All Data Model activities are
governed under Technical Management per applicable policy and business rules
established by the Governance Authority. All Metadata Repository activities are
governed jointly by both Process and Technical Management. The joint responsibility
promotes trust and understandability across the domain and the Metadata Repository is
one of the two component tools supporting governance.
3. Data Services: Data Services are the data exchange standards, software, and hardware
component activities that provide access to the Data Infrastructure to efficiently, reliably
and securely deliver data to the domain. All Data Services activities are governed under
Technical Management per applicable policy and business rules established by the
Governance Authority.
4. Mediation, Messaging and Orchestration: The exchange standards, software, and
hardware component activities that provide access to other component services. All
Mediation, Massaging, and Orchestration activities are governed under Technical
Management per applicable policy and business rules established by the Governance
Authority.
a. Mediation Services: Provides the connector and adaptor services to multiple
middle-ware platforms inside and outside of the domain for policy enforcement
and data conversions.

13

b. Messaging Services: Event, reply, publish and subscribe messaging services
providing notifications across distributed domains that are acted upon by different
user groups.
c. Orchestration Services: Provides the coordination and composition services to
execute other services in particular manner to achieve mission capability.
5. Service Registries: The registration, access, discovery and use of all SOA service
component activities. The Service Registry is governed under the Process and Policy
authority but the Technical Authority is responsible for implementation. The Service
Registry is one of the two component tools supporting governance.
6. Collaboration Tools: The set of web technology services managing content such as
Wiki, BLOG, Geospatial and Social Networking. Collaboration Tools are governed under
the Process and Policy authority but the Technical Authority is responsible for
implementation.
7. Visualization: The set of web technologies services providing user access such as
Portals. Visualization is governed under the Process and Policy authority but the
Technical Authority is responsible for implementation.
8. Security: Security method and service activities to protect information and information
systems from unauthorized access, use, disclosure, disruption, modification, or
destruction in order to provide integrity, confidentiality and availability. All Security
activities are governed under Technical Management per applicable policy and business
rules established by the Governance Authority.
9. Service Management: Auditing and logging, security, quality of service guarantees,
service-level agreements, service life cycle, and service virtualization activities. Quality
of service guarantees and service-level agreements activities are governed by the
Process Authority. Auditing and logging, security, and service virtualization activities are
governed by Technical Management. Service life cycle is governed jointly by both the
Process Authority and Technical Management.

Web Services Approach to SOA - Web Services is a common way for implementing a service-
oriented architecture. Web services make functional building blocks accessible over standard
Internet protocols independent of platforms and programming languages. These services can be
new applications or just wrapped around existing legacy systems to make them network-enabled.

Each SOA building block can play one or both of two roles:

Service provider creates web service, publishes interface and access information to a
service registry, decides category the service should be listed in for a given broker
service and what sort of agreements/ contracts are required to use the service. The
Universal Description Discovery and Integration (UDDI) specification defines a way to
publish and discover information about Web services. Other service broker technologies
include ebXML (Electronic Business using eXtensible Markup Language) and those
based on the ISO/IEC 11179 Metadata Registry (MDR) standard.
Web service client (or service requester) 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.

SOA and Web Service Protocols - Implementers commonly (or principally) build SOAs using
Web Services standards (for example, using SOAP) that have gained broad industry acceptance.
These standards also provide good interoperability and some protection from lock-in to
proprietary vendor software. However, one can, implement SOA using any service-based
technology, such as Jini, CORBA or REST.

14

Moreover, there is an ongoing debate (at least on the commercial side) as to whether the SOA‘s
are best founded on the SOAP based messaging approach versus the REST based IP approach.
However, it is expected that a large Navy or DoD SOA will typically need to leverage multiple
approaches.

2.3.1.1 SOA Concepts Related to Standards/ Technologies

SOA architectures can operate independently of specific technologies. Designers can implement
SOA using one or more of wide range of technologies/ protocols, including SOAP, REST, RPC,
DCOM, CORBA, WCF, or Web Services SOA and Business Architecture

At the heart of SOA planning is the process of defining architectures for the use of information
supporting the business (whether commercial or Navy), and the plan for implementing those
architectures. Enterprise Business Architecture is always the highest level of architecture.

Within this area, IBM announced SOMA (service-oriented modeling and architecture) as the first
publicly announced SOA-related methodology in 2004. Since then, efforts have been made to
move towards greater standardization and the involvement of business objectives, particularly
within the OASIS standards group and specifically the SOA Adoption Blueprints group. All of
these approaches take a fundamentally structured approach to SOA, focusing more on the
Services and Architecture elements and leaving implementation to the more technically focused
standards. Another pertinent example is SAP Enterprise Services Architecture, which is focused
on a strict governance process and the use of semantics to improve the usefulness of services in
business process innovation.

2.3.1.2 RPC and Distributed Object Middleware for Other Service Based
Applications / Presentation and Real-time /Near-real-time Services

RPC and distributed object (DO) middleware systems support tightly coupled client/server
applications. RPC and distributed object middleware support managed communications, but they
do not use XML, and they do not have universal vendor or open source community support.
Examples of RPC systems include the Open Network Computing (ONC) RPC, the Distributed
Computing Environment (DCE) RPC, and Microsoft RPC. Examples of distributed object
systems include Common Object Request Broker Architecture (CORBA), Java Remote Method
Invocation (RMI), and Distributed Component Object Model (DCOM).

RPC and distributed object middleware systems are a natural fit for point-to-point interactions in
homogeneous, tightly coupled application architectures, such as used in integrated warfare
systems; but they can hinder a SOA initiative. They do offer high performance, and transaction
integrity support.

2.3.2 COI application-specific SOA
Net-centric Enterprise Solutions for Interoperability (NESI) is a joint effort between the U.S.
Navy‘s Program Executive Office for C4I & Space and the U.S. Air Force‘s Electronic Systems
Center. It provides reference architecture, implementation guidance, and a set of reusable
software components. These facilitate the design, development, maintenance, evolution, and use
of information systems for the Net-Centric Operations and Warfare (NCOW) environment. NESI
has also been provided to other Department of Defense (DoD) services and agencies for
potential adoption.

The NESI Implementation Framework guidance applies to all phases of the acquisition process
as defined in references NESI comprises six parts, each focusing on a specific area of guidance.

15

NESI provides guidance on software development best practices, software architecture, design
patterns, and standards. The overall goal is to provide common, cross-service guidance in basic
terms for the program managers and developers of net-centric solutions. The objective is to help
translate into concrete actions the plethora of mandated and sometimes contradictory guidance
on the topic of net-centric compliance and standards. It does not replace or repeat existing
direction.

NESI provides significant guidance for building systems that support Communities of Interest
(COIs). A COI is a collaborative group of users who exchange information for their shared goals,
interests, missions, or business processes. The success of this exchange depends on a shared
vocabulary. Within NESI, COIs have the following properties:

A COI is a group of people who share a common vocabulary. There is typically a
deliberate effort to produce this community vocabulary.
A COI may be institutional, expedient, functional, or cross-domain.
A COI may be a subset of another COI.
A COI always encompasses more than one system or node. A system is a source of data
and/or capability, and often participates in more than one COI.
A COI typically encompasses more than one organization.

2.3.3 NESI elements
NESI organizes the enterprise into three elements:

Enterprise Services provide enterprise-wide capabilities to link nodes, services,
applications, and components.
Nodes provide local hardware and software to support COIs and users.
Services, Applications, and Components provide the mission capabilities the
warfighters need.
NESI prescribes an N-tier architecture model with client, presentation, middle, and data tiers.
NESI relies upon the Net-Centric Enterprise Services (NCES) program. The combination of
NCES and NESI yields an open-standards architecture that allows the enterprise to encapsulate
the elements of existing or new systems. The elements plug together seamlessly and can be
upgraded and expanded more easily.

The NCES architecture does not currently provide detailed guidance for developing systems or
applications to support COIs. NESI complements NCES by expanding the guidance for COIs and
for the infrastructure required to build mission applications that integrate into COIs and the
enterprise.

The DoD Enterprise includes software components delivered by different organizations on
different schedules. All components, however, are organized around the architecture shown in
the Figure 6 below shows the types of components that coexist in the enterprise and support
each other.

16

Figure 6: NESI Compliant COI Framework

2.3.4 SOA and Network Management Architecture

The principles of SOA apply to the field of network management. Examples of service-oriented
network management architectures are TS 188 001 NGN Management OSS Architecture from
ETSI, and M.3060 Principles for the Management of Next Generation Networks recommendation
from the ITU-T.

17

3.0 SOA Implementations within the Navy
The PEO C4I SOA Stack Promulgation Memo of 24 June 08 is an excellent two page introduction
to the Navy interest in SOA. It references and quotes from two earlier documents ((a)
SECNAVJNST 5000.3, 19 Dec 05, Navy IT and Applications Data Management; (b)DoN CIO
Memo , 6 April 07, Navy Enterprise Architecture and Data Strategy) that call for a Navy SOA
approach to implement a DoN Applications Data Architecture, as well as for achieving a net-
centric operations/ warfare alignment with the GIG.

The PEO Promulgation memo reiterates the expected benefits of the SOA approach that include
―ensuring that services are visible, accessible, understandable, and trusted‖. Also mentioned is
the objective of avoiding the old approach of building multiple systems that have their own
dedicated hardware and applications .The memo refers to the strategy of having ―early adopter‖
Navy SOA efforts that include LSG and MHQ w/ MOC.

Also very significant for this Navy SOA RM is the fact that the PEO memo defines a list of nine
SOA Core Service Functions that have PEO consensus as comprising the SOA stack for early
adopters. As indicated in the following chart, there are already candidate COTS systems
identified for providing the answers to these Core Service needs.

Table 1: PEO C4I Approved Core Services Stack

Navy SOA Core Services per the PEO SOA Stack Promulgation Memo

Core Service Objective Candidates
Service Discovery Federated UDDI jUDDI v2.0 compliant
People Discovery not included MS Active Directory, COMPOSE
Mediation Services not included ESB: Jboss ESB, v4.2.1 GA (SOA
Platform)
Content Discovery and not included MDR - NCES
Metadata Catalogue
Messaging JMS/ESB ESB: Jboss ESB, v4.2.1 GA (SOA
Platform)
Visualization Services JSR168/WSRP, OGC Compliant Portal: Jboss Portal v2.6 (Portal
Platform) OGC: Degree and/or
GeoServer
Orchestration BPEL and Supporting Tool Bundle BPM: Jboss jBPM v3.2.2 (SOA
Platform)

Collaboration XMPP fully federated afloat and OpenFire XMPP (server only)
ashore
Security not included TBD

In addition to the early adopter efforts, two other Navy initiatives are currently implementing SOA
Solutions within their Navy Constructs. These are the Consolidate Afloat Networks Enterprise
Services (CANES), and Integrated Warfare Systems (IWS).

As may be found in the CANES SOA Reference Architecture document, a more complete list of
service functions, features, attributes, or ―qualities‖ (as termed by the CANES document), that
goes beyond the nine SOA Core Service Functions, can set the groundwork for a discussion of
alternative or candidate system solutions / patterns or technologies/ standards. These should be
considered as part of any Navy SOA instantiation. This Navy SOA RM therefore draws heavily
from the technical content of the CANES document, in order to facilitate a relatively concise
reference summary discussion of the systems, platforms, technologies, and standards
appropriate for addressing the needed Navy SOA functionality.

18

3.1 CANES Use Case

We begin this Section by reviewing the principal SOA features (or ―qualities‖ as the CANES
Reference Architecture document calls them). The following seven features are consistent with
the ―guiding and architectural principals‖ listed in Section 2.1 for generic SOA (commercial,
Government, etc.). This shorter list of essential SOA features can be related to the CANES
discussion (some of which is concisely summarized in this CANES Section of this RM) of
architectural solutions, patterns, systems, etc, that allow those features to be achieved in a Navy
SOA.

A Navy SOA needs to have certain high-level attributes that are necessary for success. These
include the following features that are discussed briefly below.

Interoperability
Quality of Service
Loose Coupling
Service Operations Management
Service Lifecycle Management
Service Metadata Management
SOA Governance

These seven features are defined in the CANES Architecture Specification in detail.

NOTE: Systems Engineers can associate very specific DISR or Fn TV-1 Standards with
most of these individual SOA ―essential features‖. Furthermore, these features or
functions also align with WS-I standards (and the extended WS* standards) referenced in
the NWSP (Navy Web-Service Profile) that is included as an Appendix of this Navy SOA
RM.

The CANES document thoroughly addresses architectural solutions for achieving these
necessary features through discussions of solution ―patterns‖ along with the associated SOA
components, technologies etc. An outline of that discussion is as follows:

3.1.1 Architectural Patterns
CANES SOA Runtime Infrastructure Architecture
Platform Model
Middleware Model
Runtime Infrastructure Components Model

CANES SOA Governance Infrastructure Architecture
Registries, Repositories, and Asset Management
Policy Management and Compliance Testing
Contract Management
Testing and Diagnostics
Service Creation Governance
Service Runtime Governance
Service Utilization Governance
Service Maintenance Governance
Services Design Practices

Notice that there are two subsets of the CANES SOA Reference Architecture patterns. The
CANES SOA Runtime Infrastructure Architecture defines the managed communications systems

19

that services use to interact. The CANES SOA Governance Infrastructure Architecture defines
tools and services for governing the development and utilization of services.

CANES SOA describes the Runtime Infrastructure Architecture using three models.
Applications Platform Model - Provides a foundation for the development and
deployment of service-based applications. This also consists of a set of infrastructure
services and a service bus to integrate their use. The applications platform model
presents a description of the CANES SOA Runtime Infrastructure as seen by the service-
based applications and component services employing it.

Middleware Model - Defines a distributed communications and interoperability
foundation for the platform view.

Infrastructure Components Model - Defines the fundamental participants in a managed
communications infrastructure to include service endpoints and service intermediaries.

For this Navy SOA RM, summary descriptions of the Service Bus and other infrastructure
components that comprise the Platform model are all included together with a summary
description of all components of the infrastructure components model.

C2
C2 ISR
ISR Other
Other
Service-based
Service-based Service-based
Service-based
Application
Application Application
Application

Platform Interface

Service Bus
Infrastructure

Management

Presentation

Near-Realtime
Messaging

Realtime and
Services

Discovery
Mediation
Services

Services

Services

Services

Services
Services
Security

Services

Figure 7: Platform Model of the CANES SOA Runtime Infrastructure Architecture

3.1.1.1 Platform Model - Service Bus

The service bus as seen in figure 7, can be implemented in a variety of ways; one of which is with
an Enterprise Service Bus. It must support any type of communications style, including one-way
messages, request/response, peer-to-peer, brokered delivery, hub-and-spoke, and orchestrated
workflow. It must enable service endpoints, both application and infrastructure, to communicate
in a managed way both within and across organizational boundaries. All such communications
are governed by policy, and the service bus automatically invokes the necessary infrastructure
functionality required to enforce the policy.

20

3.1.1.2 Platform Model - Infrastructure Services

Infrastructure Services must provide the various infrastructure functionalities that enable the
managed environment. Specific infrastructure functionality required by a service should be
defined using declarative policies and enforced automatically by the service bus. The
infrastructure services are also discussed in the ―Runtime Infrastructure Components Model‖
section.

3.1.1.3 Platform Model - Service Platforms

Provide tools, frameworks, and hosting containers for service endpoints in a services
infrastructure. Typically, service platforms are aligned with middleware systems. For example, if
a service uses CORBA middleware, it must be developed and hosted using a CORBA service
platform. Likewise, if a service uses the Web Services Framework (WSF), it will be developed
and hosted using a Web services platform (WSP). Dozens of vendors and open source
communities provide WSPs. Most portals and application platforms also include a WSP, as do
many middleware products.

The CANES SOA Runtime Infrastructure will likely provide at least one WSP for Java
applications, and a second WSP for C++ applications.

WSP alternatives include:
Application platforms
Enterprise Service Bus (ESB)
Stand-alone and embeddable platforms

3.1.1.4 Platform Model - WSP Alternative - Application Platforms

Provide tools, frameworks, and hosting containers for applications. Most include the same for the
creation and deployment of Web services. For example, the Java 2, Enterprise Edition (J2EE)
v1.4 specification requires that all J2EE-compatible application servers include a WSP.

Most portals also provide built-in WSPs. The OASIS Web Services for Remote Portlets (WSRP)
specification defines standards for exposing and consuming portlets as Web services.

3.1.1.5 Platform Model - WSP Alternative - Enterprise Service Bus (ESB)

ESBs represent the latest technology for enterprise application integration (EAI). Unfortunately,
industry has not produced a clear definition of the ESB and this has caused a fair amount of
confusion. The term has reached critical hype status and now almost every middleware vendor
claims to provide one. One can, in fact, take two vendors‘ ESB products, sit them side by side,
and find little in common other than that they somehow sit in the middle of two or more network
services.

Although the product category encompasses a number of products with very different
characteristics, ESB products typically provide a simpler, more intuitive, and more open
integration solution than earlier generations of EAI products, such as integration brokers. (Note
that many integration broker vendors now label their products ―ESB.‖) An ESB is a critical
component of the CANES SOA Runtime Infrastructure. As a result, the Navy should be cautious
in committing to any one vendor.

ESBs typically perform a variety of functions and therefore are considered as a potential
implementation for three types of SOA runtime infrastructure components:

21

ESB as Service platform – An ESB provides tools, frameworks, and legacy application
adapters that developers can use to encapsulate legacy applications and their data, and
expose them as Web services. Many ESBs also provide tools and hosting containers for
the development of new services.
ESB as Service mediation system – An ESB provides routing and transformation
services, and some ESBs provide orchestration engines. These capabilities are
discussed further in the ―Mediation Services‖ section.
ESB for Service management – An ESB provides built-in administrative tools. These
capabilities are discussed further in the ―Management Services‖ section.

ESBs typically provide a set of adapters specifically designed to work with a variety of legacy
application environments. The Navy should consider employing a minimum set of ESBs based
on the adapters available.

3.1.1.6 WSP Alternative - Stand-Alone and Embeddable Platforms

Some Java WSPs may be deployed as stand-alone platforms, or they may be embedded within
other application platforms. J2EE 1.4-compliant application servers provide integrated, inherent
support for the WSF. The J2EE 1.4 specification requires support for the standard Java APIs for
the WSF and the WS-I Basic Profile. The latest versions of nearly all J2EE application servers
also support WS-Security.

3.1.2 Middleware Model of the CANES SOA Infrastructure Architecture
In a Navy SOA like CANES, various middleware falls into groups that support three different kinds
of applications: (see figure 8)

C2 service based applications / Messaging and Mediation Services – These use
XML based messaging middleware systems that include WSF, ebXML, XML-RPC, XML
Syndication, and POX
ISR service based applications / Management, Discovery, and Security Services –
These use MOM based middleware messaging systems that include JMS, AMQP,
XMPP, STOMP, and ―other MOM services‖
Other Service Based Applications / Presentation and Real-time (or near-real-time)
Services – These use RPC or Distributed Object Middleware systems that include ONC
RPC, DCE RPC, Java RMI, DCOM, plus ―other RPC or DO Services

The overall required Middleware Core Capabilities that are desired for all three of the middleware
groups include:

Protocol – standard data formats and communication mechanisms
Metadata – interfaces and data structures
Discovery – mechanisms to locate services and service metadata
Managed and mediated communications
Multiple message formats and transport protocols

To satisfy all these requirements, the SOA needs a range of middleware functionality as listed
above with the three kinds of applications (C2, ISR, Other). These ―functionalities‖ include:

eXtensible Markup Language (XML) messaging middleware systems
Message-Oriented Middleware (MOM) based middleware messaging systems
Remote Procedure Call (RPC) and distributed object middleware systems

22

C2
C2 ISR
ISR Other
Other
Service-based
Service-based
Application
Application

XML Messaging Message-Oriented RPC / Distributed Object
Middleware

Middleware Middleware Middleware

Java Messaging
Service (JMS)

Other RPC or
DO Services
Other RPC or
Syndication

DO Services
Other MOM
Syndication

ONC RPC
Other MOM

DCE RPC
XML-RPC

Java RMI
ONC RPC

DCE RPC
XML-RPC

Services

Java RMI
STOMP

Services
ebXML

DCOM
STOMP
AMQP

XMPP
ebXML

DCOM
AMQP

XMPP
WSF

POX
XML
WSF

POX
XML

Management

Presentation

Near-Realtime
Messaging

Realtime and
Discovery
Mediation
Services

Services

Services
Services

Services
Services
Security

Services
Figure 8: Middleware Model of the CANES SOA Runtime Infrastructure

XML Messaging Middleware (for C2 Service Based Applications)

XML is an open, standard, universally supported markup language for defining text and
representing structured data. Since its introduction in 1998, XML has become the most popular
data format and integration language. A family of standards has grown up around XML to
support additional features and functions. The core XML standards, all of which are managed by
the World Wide Web Consortium (W3C), include:

A number of messaging middleware systems uses XML for their data formats and XML Schema
for their message metadata language. These XML messaging systems include:

Web Services Framework (WSF)
electronic business using XML (ebXML)
XML-RPC
XML syndication protocols
―Plain old XML‖ (POX)

3.2 Web Services Framework

The WSF is an open, comprehensive, vendor-neutral, and language-independent middleware
framework that enables integration across disparate application environments. Nearly all
application platforms provide inherent support for the WSF, and most packaged application
systems now provide built-in WSF-compliant interfaces.

The WSF provides a comprehensive middleware system that was designed to support some of
the more esoteric requirements of a services infrastructure, such as flexible communication
styles, loose coupling, managed communications, and mediated messaging. As a result, the

23

WSF provides the easiest and most convenient way to implement interoperability across
heterogeneous systems and to support SOA design practices.

The WSF is based on a combination of ratified and de facto standards. The standards that make
up the core of the framework include:

Simple Object Access Protocol (SOAP) 1.1 – A de facto standard XML messaging
protocol,
Web Services Description Language (WSDL) 1.1 – A de facto standard interface and
protocol metadata language that uses XML Schema to define message formats,
Universal Description, Discovery and Integration (UDDI) 2.0 and 3.0 – A standard
discovery protocol and registry service specification (ratified by the Organization for the
Advancement of Structured Information Standards (OASIS)),
Web Services Interoperability Organization (WS-I) Basic Profile – A standard set of
interoperability guidelines when using SOAP, WSDL, and UDDI

Extensions to the WSF include those that add features such as security, reliability, and
transactions. The foundational WSF security standard, WS-Security, is ready for use and has
been ratified by OASIS and WS-I have published a draft of the WS-I Basic Security Profile.

The WSF extensions for reliability, transactions, orchestration, and other functions are still being
defined and the Navy should expect interoperability challenges when using these
implementations. For these specific applications, the Navy may want to use an alternative
middleware option, such as Message-Oriented Middleware.

The most interoperable SOA protocol is SOAP over HTTP, but HTTP is considered a less than
reliable protocol (per CANES Architecture Doc). The standards community is in the process of
developing a standard extension to the WSF for reliable messaging (WS-RX), but until this
standard is finalized, the WSF cannot support interoperable reliable messaging over HTTP. In
the meantime, two options are available:

A variety of middleware technologies have been used to create point-to-point connections
between Navy applications. By wrapping, these existing interfaces using adapters and exposing
them as Web services, legacy application functionality can be maintained while making the same
functionality available to the broader set of service-based applications with access controlled and
coordinated by the managed communications infrastructure.

Although a services infrastructure could be implemented using any middleware technology, the
WSF provides the best foundation to support most architectural requirements, such as
interoperability, security, flexible communication styles, and managed communications. The
reasons for selecting the WSF are threefold:

Most of the remaining middleware technologies described below support only some of these
features. Therefore, the Navy should implement services that comply with the WSF 1.1 and WS-I
1.2 Basic Profiles. In addition, the Navy should implement services that comply with SOAP 1.2
and UDDI 3.0 even though this exceeds the requirements of the WSF 1.1 and WS-I 1.2 Basic
Profiles. UDDI 3.0-compliant registries support both UDDI v2 and UDDI v3 protocols. Support
for UDDI v2 is desirable for broader interoperability, but UDDI v3 is desirable for numerous
enhanced features, such as policy-based security, enhanced query capabilities, subscriptions and
notifications, and internationalization.

EbXML is a middleware framework designed to support business-to-business (B2B) integration
and managed communications.

24

XML-RPC is an early offshoot from the original SOAP project. XML-RPC is a XML messaging
protocol that communicates over Hypertext Transfer Protocol (HTTP) and supports a tightly
coupled request/response.

XML syndication protocols, such as Atom and RSS define XML protocols for syndicating,
archiving, and editing ―episodic‖ websites, such as weblogs (blogs). They have universal vendor
and open source community support.

Plain Old XML For applications with simple communication requirements, ―plain old XML‖
messaging, also known as POX, may be preferred.

The Navy will incorporate POX within the CANES Services Infrastructure in support of
applications employing REST.

Message-Oriented Middleware (MOM) (for ISR service based applications) supports brokered,
asynchronous interactions among applications. MOM systems offer high performance,
transaction integrity support, and reliable message delivery.

RPC and distributed object (DO) middleware systems support tightly coupled client/server
applications. RPC and distributed object middleware support managed communications.

A variety of middleware technologies have been used to create point-to-point connections
between Navy applications. By wrapping these existing interfaces using adapters and exposing
them as Web services, legacy application functionality can be maintained while making the same
functionality available to the broader set of service-based applications with access controlled and
coordinated by the managed communications infrastructure.

3.2.1 Infrastructure Components of the CANES SOA Architecture
In a managed communications infrastructure, messages flow from one service endpoint to
another through a set of zero or more intermediaries. Service endpoints implement application
functionality, and they rely on metadata to determine how to communicate. Service
intermediaries provide infrastructure services and manage the communication process. They
monitor, optimize, control, secure, route, and mediate message traffic according to a set of
policies. Service endpoints, metadata, and policies are registered in a registry, which provides a
single point of reference for all information about services. Management systems configure,
monitor, and control service endpoints, service intermediaries, and service registries.

From a functional perspective, the Infrastructure Components Model includes the following.

Messaging Services
Mediation Services
Management Services
Discovery Services
Security services
Presentation Services
Real Time and Near Real Time Services

25

Runtime Infrastructure Components

Management

Presentation

Near-Realtime
Messaging

Realtime and
Discovery
Mediation
Services

Services

Services

Services
Services

Services
Security

Services
Figure 9: Runtime Infrastructure Components Model of the CANES SOA Reference
Architecture

For purposes of keeping this document to a manageable size on a few of the components shown
in Figure 9 are discussed for details on the complete list of RTI components in case see the
CANES Systems Design Specification.

Messaging Services - is accomplished by Middleware, which is discussed in the Middleware
Model Section 3.1.2.

Mediation Services - Standards-based mediation patterns/system solutions are accomplished
by:

Web Services Management (WSM) - WSM solutions typically support mediation of all
types of XML messaging traffic, including SOAP, ebXML, XML-RPC, RSS, and POX.
XML Gateways - XML gateway is a mediation system that focuses primarily on
addressing SOA security and performance issues. A comprehensive SOA security
strategy requires a combination of transport-level and application-level security
protections, and it requires layered defenses based on PEPs deployed at centralized,
intermediary, and endpoint locations.
Enterprise Service Bus (ESB) - ESBs represent the latest technology for enterprise
application integration (EAI). Unfortunately, industry has not produced a clear definition
of the ESB and this has caused a fair amount of confusion. The term has reached critical
hype status and now almost every middleware vendor claims to provide one. One can, in
fact, take two vendors‘ ESB products, sit them side by side, and find little in common
other than that they somehow sit in the middle of two or more network services. ESBs
typically perform a variety of functions and therefore are considered as a potential
implementation for three types of SOA runtime infrastructure components:
o ESB as Service Platform – An ESB provides tools, frameworks, and legacy
application adapters that developers can use to encapsulate legacy applications
and their data, and expose them as Web services. Many ESBs also provide
tools and hosting containers for the development of new services.
o ESB as Service Mediation System – An ESB provides routing and
transformation services, and some ESBs provide orchestration engines. These
capabilities are discussed further in the ―Mediation Services‖ section.
Orchestration Engines - Service composition and orchestration systems enable the
assembly and coordination of services into repeatable business processes. A business
process defines an atomic interaction composed of multiple services. The composite
business process can in turn be published as a higher-level service.

26

Infrastructure Services-based Mediation Patterns - Mediation services support the
transformation of data. This capability includes several different but related functions:

o Document Transformation – Provides simple transformations such as
transforming XML using eXtensible Style sheet Language (XSL); enables the
XML content provided by one application to be transformed to another XML
schema base to be utilized by another application.
o Service Invocation with Transformation – Provides adaptors that transform
data going to/from legacy applications or other non-standard interfaces;
translates information protocols from popular standards to XML, and translates
from XML to other popular information protocol adaptors.
o Service Orchestration – Orchestrates the flow of data between services; also
known as work-flow management; facilitates seamless interaction between
services by allowing service-based application composers to register a Business
Process Execution Language (BPEL) instruction set to define a unique
information workflow. This workflow is fully functional within a mediator, utilizing
remote service interactions, dynamic intelligent routing, and XML translation
services as necessary.

3.2.2 Management Services
Management Services should:

Ensure reliability and availability of critical components.
Set and monitor appropriate SLAs.
Locate components that meet performance and availability requirements.
Provide insight into the usage of offered services.
Provide distributed management of services.
Provide detection and handling of exception conditions.

Standards-based Service Management patterns include:

Built-in administration tools
Web Services Management (WSM)
Enterprise Systems Management (ESM)

Built-in Administration Tools (as a standards based service management pattern) Most SOA
infrastructure components provide built-in administration tools. For example:

A WSP provides a console for configuring services and managing service agents.
A service mediation system provides a console for configuring mediation policies and
managing intermediaries.
A service registry provides a console for configuring the registry service and its service
policies.

Discovery Services - Registries support discovery requirements thereby enabling service
consumers to find services, metadata, people, and content across the SOA environment that
match their requirements.

Within the CANES Services infrastructure, there are four types of discoverable objects needed to
support the execution of a variety of other services.

27

Service Discovery
Metadata Discovery
People Discovery
Content Discovery

The architectural patterns composing each type of discovery service are discussed in the
sections following.

People Discovery Services - People discovery provides capabilities for uniquely identifying,
finding, and publishing white pages information on identities within the CANES SOA environment.

Content Discovery and Delivery Services - Content discovery services provide a way to search
enterprise content. This capability not only indexes the enterprise content for search, but also
provides the ability to search other federated content repositories. Content discovery services
provide the ability to index public content automatically, as well as to establish and search
catalogs of tagged information.

Security Services - This capability provides security-related services, including authentication,
authorization, and attribute retrieval.

Presentation Services - Presentation Services provide the user-facing interface to service-
based applications. It provides a single launch point for the following services:

Identity Management (People Discovery)
Content Discovery
Collaboration
User Profiling and Customization

3.2.3 CANES SOA Governance Infrastructure Architecture
The CANES SOA governance infrastructure provides tools and services for governing the
development and utilization of services.

The discussion of alternatives for SOA governance infrastructure is organized into the following
areas:

Registries, repositories, and asset management
Policy management and compliance testing
Contract management
Testing and diagnostics
Service Creation Governance
Services Design Practices

Registries, Repositories, and Asset Management - Organizations use registries, repositories,
and Software Asset Management Systems (SAMS) to manage and maintain information about
services within a SOA environment. These systems support reuse by enabling service discovery.

A registry provides a single point of reference for all information about services.
A repository manages metadata about services.
A SAMS manages service artifacts, including metadata, documentation, code, tests, and
more.

Policy Management and Compliance Testing - Policy management systems manage the
lifecycle of SOA policies.

28

Contract Management - Contract management systems govern the process through which
service consumers and service providers negotiate a utilization contract.

Testing and Diagnostics - SOA testing tools should understand XML, WSDL, SOAP, and
various message exchange patterns in order to adequately test and monitor the connection
interfaces. Automated generation of test clients, test services, and test data from WSDL
definitions improves productivity.

Service Creation Governance - A registry provides a central point of reference about services
within a SOA environment, and it enables reusability.

A repository manages service metadata, and a SAMS manages service artifacts, such as
metadata, documentation, code, and test suites.

Services Design Practices - Services Design Practices (SDPs) comprise design principles and
best practices for creating loosely coupled, reusable services, …ensuring flexibility, platform
neutrality, and cross-platform interoperability. Guidance such as NESI and the FORCEnet
Services Description Framework (Fn SDF) provide an initial body of SDPs.

29

4.0 Conclusion and Recommendation
4.1 SOA Governance

One of the key lessons learned from early SOA efforts is: start SOA Governance early. This
precept can be applied to the SOA Integration Solution Architecture as well. Effective governance
provides visibility into and control of your implementations. The same is true for integration
implementations. SOA Governance is crucial to successful SOA Integration.

Governance is essential to ensuring that your SOA has been implemented as intended and that it
runs as intended and continues to meet business needs. Getting better visibility into and control
of your SOA system (a large part of which is Integration-centric) requires a purpose-built
architecture that combines Integration and Governance. In that context, Integration patterns
require more than simply monitoring services through an ESB. The emergence of SOA
Governance is driving a shift away from a narrow focus on the governance of integration solutions
alone to a more holistic focus on governance across the all elements of the SOA and throughout
the entire SOA lifecycle.

For example, to restrict data access, a policy for fine-grained entitlements might be implemented
for a data access service. This has its own unique enforcement and policy management
requirements for enforcing the entitlement on a particular service. Patterns like these are
emerging as the standard for successful SOA Governance. When SOA Integration and SOA
Governance work together, they give the right control and visibility needed for successful SOA
implementations. The model show in Figure 10 shows the relationship between various SOA
integration components.

Figure 10: SOA Integration + SOA Governance, Management & Security

4.1.1 A Governance Model for Navy Consideration
The future requires a primary focus on designing and easily implementing dynamically integrated
―lumps‖ of capability to meet a changing threat. Figure 11 shows the Navy‘s CPM alignment with
the strategic and tactical governance processes. In each domain (Program, Operational and
Technical), the non-overlapping area is intended to show tactical activities specific to the domain.
For example, tactical activities in the Technical Domain include comparison of technical
implementation environments and trade off analysis of integration approaches. In Figure 11, the
areas of overlap indicate strategic, collaborative, activities, which are essential to aligning

30

Soa Ref Model White Paper Industry

Soa Ref Model White Paper Industry

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Soa Ref Model White Paper Industry

Similar to Soa Ref Model White Paper Industry (20)

Recently uploaded

Recently uploaded (20)

Soa Ref Model White Paper Industry