Your SlideShare is downloading. ×
  • Like
Soa Ref Model (Navy)
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Soa Ref Model (Navy)


This brief was presented to the Enterprise Archtiecture Review Board on May 14, 2009.

This brief was presented to the Enterprise Archtiecture Review Board on May 14, 2009.

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • 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


  • 1. WIDESCREEN PRESENTATION Tips and tools for creating and presenting wide format slides
  • 2. 2 Service-Oriented Architecture Reference Model (SOA RM) 14 May, 2009
  • 3. Table of Contents  Part 1: Overview  Part 2: Extract of PM White Paper  Conclusion and Recommendation  Next Steps 3
  • 4. Part 1: Overview 4
  • 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
  • 9. Enterprise RM 9
  • 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
  • 13. Part 2: SOA Reference Model 13
  • 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
  • 21. The RM Mission Areas 21 Enterprise Services
  • 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
  • 46. 46 Backup
  • 47. DoDAF Relationship to SOA RM BRM SRM (SV1-5) TRM DRM (SV6) 47
  • 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.