WIDESCREEN PRESENTATIONTips and tools for creating and presenting wide format slides

2

Service-Oriented Architecture Reference

Model (SOA RM) 14 May, 2009

Table of Contents Part 1: Overview Part 2: Extract of PM White Paper Conclusion and Recommendation Next Steps

3

Part 1:

Overview

4

Purpose 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

5

Purpose 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

6

SOA Defined

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)

7

Service-Oriented Architecture (SOA) is an approach to defining and organizing information resources, such as

applications, information stores, and information transport based upon the concept of services.

Service-Oriented Architecture (SOA) is an approach to defining and organizing information resources, such as

applications, information stores, and information transport based upon the concept of services.

Uses of SOA RM 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

8

Enterprise RM

9

SOA TRM

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

10

From a functional perspective, the

Infrastructure Components Model

includes.

11

Real Time and Non-Real Time

Services

Presentation Services

Security Services

Discovery Services

Management Services

Mediation Services

Messaging Services

Runtime Infrastructure Components Model of the CANES SOA Reference Architecture

Service Reference Model (SRM)

Enterprise Governance Construct

Programmatic – management structure employed to deliver solutions to user requirements.

The structure is defined at the strategic level and executed at the Service and lower levels.

Operations – user requirements (mission areas, tactics techniques and procedures, logistical considerations (networks, classification, and time of response)

Technical – available architecture/hardware/software solutions that can be employed to meet user requirements. Judged by reliability, availability and maintainability

Programmatic

Operational

Technical

DON CIO

OPNAVONR

ASN RDA NNWC

PEO, PMW CoCOMS, JFCOM, JCS, Other Services

Ech III, Industry

ESBComponent Services

Framework

TRM

Part 2:

SOA Reference Model

13

Section 1 INTRODUCTION 1.1 Purpose 1.1.1Navy SOA RM Document Goals & Objectives 1.2 Scope 1.3 Benefits 1.4 Key Guidance & References 1.4.1Compliance 1.4.2OASIS SOA Reference Model and CANES SOA

Reference Architecture 1.5 Document Organization 1.6 Use of Commercial Best Practices

14

Goals & 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

15

Goals & Objectives, cont’d 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

16

Goals & Objectives, cont’d 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

17

ComplianceThis 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.

18

1. OASIS Reference Model2. JCIDS as defined by CJCSI 6212.01E3. DoDAF 1.5, the FORCEnet Framework, 4. The OSI Model 5. DoD GiG initiatives 6. PEO C4I Masterplan for Systems Engineering

v2.07. Net Centric Enterprise Solutions for

Interoperability (NESI)8. Navy Technical Reference Model

Commercial Best Practices

Key considerations for building a SOA The following guiding principles define the ground

rules for development, maintenance, and usage of any

SOA:

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..

• 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

Section 2 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

20

21

The RM

Mission Areas

Interoperability

Enterprise Services

A BRM Approach for the Navy 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. “

22 Three slides

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. 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

23

SRM, contd

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).

24

Technical Reference Model (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.

25

3/26/2009

SPAWAR Services Oriented Architecture (SOA) Technical Reference Model (TRM)

Visualization & Presentation

Collaboration Tools

Mediation, Messaging & Orchestration

Data Services

Data InfrastructureData Model &

Metadata Repository

Service Registries

Security

Service Managem

ent

GovernancePolicy Process

Acquisition & Contracting 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

26

Web Services Approach to SOA, cont’d

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.

27

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.

28

Section 3 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

29

SOA Implementations within the Navy

PEO C4I Core Services Stack Promulgation Core Services v1.0 for ISNS

CANES Afloat Core Services; the use case

30

NESI Compliant COI Framework

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.

31

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.

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.

32

Net-centric Enterprise Solutions for Interoperability

PEO C4I Approved Core Services Stack

Navy SOA Core Services per the PEO SOA Stack Promulgation Memo

Core Service Objective CandidatesService 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 Catalogue

not included MDR - NCES

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

33

CANES SOA Governance

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

34

Aspects of Navy SOA35

Lexicon [Terms, Definitions]Patterns and Practices

Architecture & Use-CasesProfiles [Specifications, Standards]

C4ISR RI[Web Services]

IWS/CS RI(CORBA)

Impl[JBoss]

Impl[Sun]

Impl[…]

Address this level

Bridge between SOAImplementations TEN RI

Bridge between SOAImplementations

Coordination Activities

Worked with SOA TA at SSC-LANT PMW 160 Multi Service SOA Consortium

Architecture IPT Marine Corps SOA Working Group

36

Section 4 CONCLUSION AND RECOMMENDATION 4.1 Governance 4.2 Beyond the Reference Model

37

SOA Governance

Start governance early Effective governance provides visibility into

and control of your implementations is crucial to successful SOA Integration

38

A Governance Model for Navy Consideration

Programmatic – management structure employed to deliver solutions to user requirements.

The structure is defined at the strategic level and executed at the Service and lower levels.

Operations – user requirements (mission areas, tactics techniques and procedures, logistical considerations (networks, classification, and time of response)

Technical – available architecture/hardware/software solutions that can be employed to meet user requirements. Judged by reliability, availability and maintainability

Programmatic

Operational

Technical

DON CIO

OPNAVONR

ASN RDA NNWC

PEO, PMW CoCOMS, JFCOM, JCS, Other Services

Ech III, Industry

ESBComponent Services

Framework

TRM

A Governance Model for Navy Consideration, cont’d

Strategy to implement the diagram Focuses on creating an Enterprise..

Process & artifacts provide: Roles & responsibilities Compliance; policy, audit, metrics Implementation guidance “ilities” identification

40

A Governance Model for Navy Consideration, cont’d

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.

41

Roles for Governing SOA

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

42

Beyond the Reference Model

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.

43

Recommendations

Approve the Reference Model SRM and TRM

Develop BRM and DRM

44

Next Steps

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

45

Backup

46

DoDAF Relationship to SOA RM

47

TRMSRM(SV1-5)

BRM

DRM(SV6)

PEO C4I Navy Technical Reference Model Level 0

48

COICOICOICOI COI

Application Services

Common Computing Environment

Communications & Networks

Qu

al ity

of S

erv

ice

( QO

S)

Info

r ma

tion

As

su

ran

ce

(IA

)D

ata

Ar c

hi te

ctu

r e

Common Services

Application Services

Mediation

Security

Collaboration

Orchestration

Messaging

Visualization

Discovery

SOA

49

SOA Implementations

ServiceInfrastructures

Service-BasedApplications

• Example: 1 is a C4I system and 2 is a weapon system

• Different “Vertical Stacks 1 and 2” use different standards in

pursuit of similar goal

• “Horizontal Slice” ties the two vertical slices together so they can share data

Infrastructure X

Application A

Infrastructure Y

Application B

Architecture and Standards Determines Interoperability

Web Services

Profile

CorbaProfile

DDS Profile

1 2

50

SOA Implementations

• The web services standards used in this instantiation of a SOA reflect current industry practices

• Do NOT want many different implementations of a SOA using web services standards

• The web services standards should be common across Navy and DoD

• The implementation of those standards should be common across Navy and DoD

• Group the standards together in a profile that provides guidance on how to use and implement

Infrastructure X

Application A

Architecture and Standards Determines Interoperability

Web Services

Profile

1

SOA Implementations

Common definition language such as XML

Common registry mechanism such as UDDI

Common format for defining interfaces such as WSDL,

Common format for messages between software components such as SOAP.

Common registry mechanism such as ORB

Common format for defining interfaces such as IDL,

Common format for messages between software components such as IIOP.

51

Implementation 1Web Services

Implementation 2CORBA