5. Purpose
5
OPNAV N61 requested SPAWAR 5.1, under its Enterprise
IT Systems/Technical Architecture authority, the task of
developing a Navy Enterprise SOA Reference Model
Develop a document that describes the goals of the Navy
in the context of both the well understood generic
commercial SOA goals as well as a Navy instantiation of a
SOA
6. Purpose
6
Develop a document that describes the goals of Navy
in the context of both the well-understood generic
commercial SOA goals and a Navy description of a
SOA
Present a general technical example of a large scale
Navy SOA
Description of the SOA technical components
Key standards that will form the foundation of the
SOA
SOA technical objectives for a Navy enterprise
Governance issues
7. SOA Defined
Service-Oriented Architecture (SOA) is an approach to
7
defining and organizing information resources, such as
applications, information stores, and information transport
based upon the concept of services.
SOA is not a technology — it is not something that can be
bought off the shelf.
From a technical perspective what are the attributes of a
SOA?
From a standards perspective, a SOA needs three
standardized items:
Common registry mechanism such as Uniform Dynamic Directory Interface
(UDDI)
Common format for defining interfaces such as Web Service Development
Language (WSDL)
Common format for messages between software components such as
Services Oriented Architecture Protocol (SOAP)
8. Uses of SOA RM
8
Assists in guiding the governance of SOA
implementations
Use in Systems Engineering Technical
Review (SETR)
Other technical assessments
Analysis/studies
Provide content for net centric guidance
10. SOA TRM
10
Touches on these layers:
Application Services
Common Computing Environment
To define a SOA include:
Mediation
Collaboration
Messaging
Security
Visualization
Orchestration
Discovery
To articulate the standards to define a SOA:
Create a list of the types of standards that characterize a SOA
Then populate with a list of IT standards
11. Service Reference Model (SRM)
11
Runtime Infrastructure Components Model Messaging
Services
of the CANES SOA Reference Architecture
Mediation Services
Management
From a functional perspective, the Services
Infrastructure Components Model
Discovery
includes. Services
Security Services
Presentation
Services
Real Time and
Non-Real Time
Services
12. Enterprise Governance Construct
Programmatic – Operations – user
management requirements (mission
structure employed areas, tactics
to deliver solutions techniques and
to user Programmatic Operational procedures, logistical
requirements. PEO, PMW CoCOMS, considerations
DON JFCOM, JCS, (networks,
The structure is CIO Other Services
defined at the classification, and time
strategic level and of response)
executed at the OPNAV
Service and lower ONR
levels. ASN RDA NNWC
Technical – available
architecture/hardware/software
solutions that can be employed to
meet user requirements. Judged by TRM
reliability, availability and
maintainability Ech III, Industry
Technical
ESB Component Services Framework
14. Section 1
14
INTRODUCTION
1.1 Purpose
1.1.1 Navy SOA RM Document Goals & Objectives
1.2 Scope
1.3 Benefits
1.4 Key Guidance & References
1.4.1 Compliance
1.4.2 OASIS SOA Reference Model and CANES
SOA Reference Architecture
1.5 Document Organization
1.6 Use of Commercial Best Practices
15. Goals & Objectives
15
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
16. Goals & Objectives, cont’d
16
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
17. Goals & Objectives, cont’d
17
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
18. Compliance
18
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.
1. OASIS Reference Model
2. JCIDS as defined by CJCSI 6212.01E
3. DoDAF 1.5, the FORCEnet Framework,
4. The OSI Model
5. DoD GiG initiatives
6. PEO C4I Masterplan for Systems Engineering v2.0
7. Net Centric Enterprise Solutions for Interoperability
(NESI)
8. Navy Technical Reference Model
19. Commercial Best Practices
19
Commercial Best Practices offer the richest
source of information on SOA successes,
failures and the best form of implementing,
integrating, and developing middleware for the
enterprise..
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
20. Section 2
20
2.0 THE NAVY REFERENCE MODEL
2.1 Business Reference Model (BRM)
2.1.1 A BRM Approach for the Navy
2.1.2 SOA and Business Process Management – A Commercial
Best Practices Example
2.1.3 SCA (the Service Component Architecture Standard) and
Business Integration
2.2 Services Reference Model (SRM)
2.3 Technical Reference Model (TRM)
2.3.1 Standards and Technologies
2.3.2 COI application-specific SOA
2.3.3 NESI elements
2.3.4 SOA and Network Management Architecture
22. A BRM Approach for the Navy
22 Three slides
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. 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.
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. ―
23. Services Reference Model (SRM)
23
The SRM is a business-driven, functional framework
that classifies Service Components with respect to
how they support business and/or performance
objectives. It 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
24. SRM, contd
24
The Navy SRM is the functional framework that
classifies Service Components with respect to how
they support business and/or performance objectives.
The 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).
25. Technical Reference Model (TRM)
25
SPAWAR Services Oriented Architecture (SOA) Technical Reference Model (TRM)
3/26/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
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.
26. Web Services Approach to SOA
26
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
27. Web Services Approach to SOA, cont’d
27
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.
28. SOA Concepts Related to
Standards/ Technologies
28
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.
29. Section 3
29
3.0 SOA IMPLEMENTATIONS WITHIN THE NAVY
3.1 CANES use case
3.1.1 Architectural Patterns
3.1.2 Middleware Model of the CANES SOA Infrastructure
Architecture
3.2 Web Services Framework
3.2.1 Infrastructure Components of the CANES SOA
Architecture
3.2.2 Enterprise Service Bus
3.2.3 Management Services
3.2.4 Navy CANES SOA Governance Infrastructure Architecture
30. SOA Implementations within the Navy
30
PEO C4I Core Services Stack Promulgation
Core Services v1.0 for ISNS
CANES Afloat Core Services; the use case
31. NESI Compliant COI Framework
31
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.
32. NESI Elements
Net-centric Enterprise Solutions for Interoperability
32
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.
Prescribes an N-tier architecture model with client, presentation,
middle, and data tiers.
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.
33. PEO C4I Approved Core Services Stack
33
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 Metadata not included MDR - NCES
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 ashore OpenFire XMPP (server only)
Security not included TBD
34. CANES SOA Governance
34
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
35. Aspects of Navy SOA
35
Lexicon [Terms, Definitions]
Patterns and Practices
Address
Architecture & Use-Cases this level
Profiles [Specifications, Standards]
C4ISR RI Bridge between IWS/CS RI Bridge between
SOA
[Web Services] Implementations (CORBA)
SOA
Implementations
TEN RI
Impl Impl Impl
[JBoss] [Sun] […]
36. Coordination Activities
36
Worked with SOA TA at SSC-LANT
PMW 160
Multi Service SOA Consortium
Architecture IPT
Marine Corps SOA Working Group
37. Section 4
37
CONCLUSION AND RECOMMENDATION
4.1 Governance
4.2 Beyond the Reference Model
38. SOA Governance
38
Start governance early
Effective governance provides visibility into and
control of your implementations
is crucial to successful SOA Integration
39. A Governance Model for Navy
Consideration
Programmatic – management
Operations – user
structure employed to deliver
requirements (mission areas,
solutions to user requirements.
Programmatic Operational tactics techniques and
The structure is defined at the CoCOMS, procedures, logistical
PEO, PMW
strategic level and executed at DON JFCOM, JCS, considerations (networks,
the Service and lower levels. Other Services classification, and time of
CIO
response)
OPNAV
ONR
ASN RDA NNWC
Technical – available
architecture/hardware/software
solutions that can be employed TRM
to meet user requirements.
Judged by reliability, availability Ech III, Industry
and maintainability
Technical
ESB Component Services Framework
40. A Governance Model for Navy Consideration,
cont’d
40
Strategy to implement the diagram
Focuses on creating an Enterprise..
Process & artifacts provide:
Roles & responsibilities
Compliance; policy, audit, metrics
Implementation guidance
―ilities‖ identification
41. A Governance Model for Navy Consideration,
cont’d
41
PEO, PMW support the programmatic aspects of
implementing SOA in accordance with approved
standards
JCS, CoCOMS, JFCOM, establish requirements for
operational use of SOA in regards, to mission areas,
tactical requirements, logistics…
Echelon III use and implementation of available
architecture/hardware/software solutions for meeting
user requirements.
42. Roles for Governing SOA
42
PEO, PMW – support the programmatic
aspects of compliance to governance
processes
CoComs, JFCOM, JCS and Military Services
define the operational construct and
requirements for the SOA
Ech III, Industry, develop and implement the
governance process on the architecture
43. Beyond the Reference Model
43
Capture the major issues, questions, and/or
challenges that need to be addressed in:
(a) building process into Navy SOA enterprise
planning, and
(b) in establishing governance policies and systems
that can sustain SOA in and after they are
implemented.
44. Recommendations
44
Approve the Reference Model
SRM and TRM
Develop BRM and DRM
45. Next Steps
45
Develop a Navy SOA Governance Construct
Establish end-to-end governance process
Establish waiver process
Alignment with other existing processes
Different
instantiations of SOA
DoD guidance and directives
48. PEO C4I Navy Technical Reference
Model Level 0
48 Mediation
COI COI COI COI COI Collaboration
Application Services
Application Services
Messaging
Common Services
SO Security
A
Common Computing Environment Visualization
Orchestration
Communications & Networks
Discovery
49. SOA Implementations
Architecture and Standards Determines Interoperability
1 2
Application Application Service-Based
A B
Applications
Web
Corba
Services
Profile
Profile
Infrastructure Infrastructure
DDS Profile Service
X Y
Infrastructures
• Example: 1 is a C4I system and 2 is a weapon system
• Different “Vertical Stacks 1 and 2” use different standards in
pursuit
49 of similar goal
50. SOA Implementations
Architecture and Standards Determines Interoperability
• The web services standards used in
1
this instantiation of a SOA reflect
Application
current industry practices
A
Web • Do NOT want many different
Services
implementations of a SOA using
Profile
web services standards
Infrastructure
X • The web services standards should
be common across Navy and DoD
• The implementation of those
standards should be common
across Navy and DoD
50
• Group the standards together in a
51. SOA Implementations
Implementation 1 Implementation 2
Web Services CORBA
Common definition Common registry
language such as XML mechanism such as ORB
Common registry Common format for
mechanism such as UDDI defining interfaces such
Common format for as IDL,
defining interfaces such Common format for
as WSDL, messages between
Common format for software components
messages between such as IIOP.
software components 51
such as SOAP.
Notas del editor
Discuss OPNAV request for this information and how it has evolved into the need for a Technical Authority and governance of SOA efforts across the Navy
Discuss OPNAV request for this information and how it has evolved into the need for a Technical Authority and governance of SOA efforts across the Navy
The TRM currently exists and was defined by ongoing SOA implementations in the Navy and PEO C4I Core Services Stack promulgationThe SRM incorporates how, when, and to what extent legacy and emerging enterprise services are utilized in a SOAThe BRM which is yet to be defined is the key to the GiG integration of SOA and use of services between DoD as a whole. It is the key to the interoperability of the Navy
TRM * is a combination of :Component Driven, technical framework that categorizes standards Associated guidance for the implementation and use of these standardsMapping and reuse of standards to technology and business processesSOA TRMDeveloped a SOA TRM Based on web services standardsCovers these categories for applications and infrastructureMediationCollaborationMessagingSecurityVisualizationOrchestrationDiscovery
Mansfield notes:Programmatic:Throughout the course of systems (or system of systems) development and delivery, the programmatic sphere is subjected to a series of requirement checks and functional assessments based on a milestone schedule that is implemented to justify continued funding. This makes the programmatic sphere (i.e., Program Manager) reluctant to accept any changes to requirements for fear of disrupting the process and loss of funding. There is actually a counter-incentive to introducing new (i.e., Net-centric) review cycles for fear of program revocation based on time and funding constraints. That is to say, new requirements equals more time meaning breaking of milestone schedule which puts the project at risk of having its funding cut. Therefore there is no incentive to follow interoperability path, especially without moneys specifically provided to pay for the requirements derived from the need for Net-Centricity. Without the flexibility (and inThe operations sphere has roles and responsibilities that are applied at different points in the lifecycle of a program. Operations:The operations sphere is heavily tasked in the beginning of the process to establish the plan and requirements. In subsequent phases of the process, Operations is less involved as the solution is developed and produced and does not get fully re-engaged until deployment. As the missions change throughout the lifecycle, it is difficult for these changes to be inserted into the process. Additionally, since the Operations sphere doesn’t get full re-engaged until deployment, the end-user employs the new capabilities using the old tactics, not being given time to fully develop a better mental model based on access to now information and capability. The end result is that money is wasted constantly adopting and fielding new technologies without adapting the TTPs/CONOPs. This ultimately is why \"Force Transformation\" Technical:The technology sphere is generally handed functional requirements and asked to develop solutions. Once the architecture and technical baseline is approved and funded, any changes in the design or technologies (large or small) can cause undue burden at many levels of the process and therefore are avoided except at major delivery milestones. These cycles are typically not less than a couple years per milestone. Additionally, the acquisition sphere often attempts to force solutions on the technology sphere to immediately cut costs and “simplify” the architecture by applying a “just buy” or “just reuse” of product set or other baseline philosophy. It is not as simple as architectural “copy/paste”. The result is increased cost to integrate improper solutions into the baseline and support the solutions, and potential failure to meet technical performance and schedule.
For ISNS but adopted by CANES as a starting point in the absecce of governance.
Tech Authority for SOA
Multi-Service SOA Consortium workDISR and GESPWeb ServicesIndustry
