Soa Ref Model White Paper Industry
51
The Navy Service Oriented Architecture Reference Model, a new beginning SOA-RM White Paper Jose Davila May 19, 2009 i
description
Drafted by a team of engineers working with me for SPAWAR we compliled standards and instantiations of SOA in the Navy.
Transcript of Soa Ref Model White Paper Industry
The Navy Service Oriented Architecture
Reference Model, a new beginning
SOA-RMWhite Paper
Jose Davila
May 19, 2009
i
Table of Contents
1.0 INTRODUCTION................................................................................................................1
1.1 PURPOSE......................................................................................................................... 11.1.1 Navy SOA RM Document Goals & Objectives............................................................1
1.2 SCOPE............................................................................................................................. 21.3 BENEFITS......................................................................................................................... 21.4 KEY GUIDANCE & REFERENCES.........................................................................................3
1.4.1 Compliance.................................................................................................................31.4.2 OASIS SOA Reference Model and CANES SOA Reference Architecture..................3
1.5 DOCUMENT ORGANIZATION................................................................................................31.6 USE OF COMMERCIAL BEST PRACTICES.............................................................................4
2.0 THE NAVY TECHNICAL REFERENCE MODEL...............................................................6
2.1 BUSINESS REFERENCE MODEL (BRM)...............................................................................72.1.1 A BRM Approach for the Navy....................................................................................82.1.2 SOA and Business Process Management – A Commercial Best Practices Example. 92.1.3 Service Component Architecture (SCA) Standard and Business Integration..............9
2.2 SERVICES REFERENCE MODEL (SRM).............................................................................122.3 TECHNICAL REFERENCE MODEL (TRM)...........................................................................12
2.3.2 COI application-specific SOA....................................................................................152.3.3 NESI elements..........................................................................................................162.3.4 SOA and Network Management Architecture............................................................17
3.0 SOA IMPLEMENTATIONS WITHIN THE NAVY..............................................................18
3.1 CANES USE CASE.........................................................................................................193.1.1 Architectural Patterns................................................................................................193.1.2 Middleware Model of the CANES SOA Infrastructure Architecture...........................22
3.2 WEB SERVICES FRAMEWORK...........................................................................................233.2.1 Infrastructure Components of the CANES SOA Architecture....................................253.2.2 Management Services..............................................................................................273.2.3 CANES SOA Governance Infrastructure Architecture...............................................28
4.0 CONCLUSION AND RECOMMENDATION.....................................................................30
4.1 SOA GOVERNANCE.........................................................................................................304.1.1 A Governance Model for Navy Consideration...........................................................304.1.2 SOA - Beyond the Reference Model.........................................................................32
APPENDIX A - REFERENCES....................................................................................................35
ii
List of Figures
Figure 1: Navy Technical Reference Model............................................................................................6Figure 2: SOA RM Instantiations.............................................................................................................6Figure 3: Navy SOA RM..........................................................................................................................7Figure 4: Complete SOA Integration Solution Architecture...................................................................10Figure 5: SOA Production TRM.............................................................................................................13Figure 6: NESI Compliant COI Framework...........................................................................................17Figure 7: Platform Model of the CANES SOA Runtime Infrastructure Architecture...............................20Figure 8: Middleware Model of the CANES SOA Runtime Infrastructure..............................................23Figure 9: Runtime Infrastructure Components Model of the CANES SOA Reference Architecture......26Figure 10: SOA Integration + SOA Governance, Management & Security...........................................30Figure 11: Governance Model...............................................................................................................31Figure 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 ab. 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.0g. 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
Lexicon [Terms, Definitions]Patterns and Practices
Architecture & Use-CasesProfiles [Specifications, Standards]
C4ISR RI[Web Services]
IWS/CS RI[CORBA]
Impl[JBoss]
Impl[Sun]
Impl[…]
Bridge between SOAImplementations
Impl[JBoss]
Impl[CORBA]
Impl[…]
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
SOA Reference
ModelBusiness
Reference Model(BRM)
Service Reference
Model(SRM)
Technical Reference
Model(TRM)
Support Delivery of
Services
Standards &Technologies
Rule Publication
Governance Policy and Guidance Development ManagementUse CasesArchitectural PatternsPlatforms
Commercial Best PracticesRe-useContent ManagementCollaboration
Use, Extend, CreateSearchPortal Personalization
Navy C4I RMC4I Core Services StackWeb Services 2.0CORBASOAPRESTNESIRPC DCOM
Business Lines and Functions
Enabling Capabilities, components, and services
Supporting Technologies
and StandardsData and Information Reference Model(DRM)Classification,
Categorization, XML, Sharing
Component-Based Architecture
Service Domains
Service Types
Service Components
7
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.
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.
8
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.
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
9
implementations can be managed successfully where hand-offs between multiple roles can be better governed if these dependencies are centrally managed.
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:
10
Does my ESB avail itself of reusable components for connectivity, security, and orchestration?
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
11
leverageable foundation for reuse of applications, application capabilities, components, and business services.
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
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 compliantPeople 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
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 ModelMiddleware ModelRuntime Infrastructure Components Model
CANES SOA Governance Infrastructure ArchitectureRegistries, Repositories, and Asset ManagementPolicy Management and Compliance TestingContract ManagementTesting and DiagnosticsService Creation GovernanceService Runtime GovernanceService Utilization GovernanceService Maintenance GovernanceServices 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 that services use to interact. The CANES SOA Governance Infrastructure Architecture defines tools and services for governing the development and utilization of services.
19
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.
Platform Interface
ISRService-based
Application
ISRService-based
Application
ISRService-based
Application
ISRService-based
Application
OtherService-based
Application
OtherService-based
Application
OtherService-based
Application
OtherService-based
Application
C2Service-based
Application
C2Service-based
Application
C2Service-based
Application
C2Service-based
Application
Infr
ast
ructu
reServ
ices
Mess
agin
gServ
ices
Mess
agin
gServ
ices
Mess
agin
gServ
ices
Media
tion
Serv
ices
Media
tion
Serv
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Managem
ent
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Dis
cove
ryServ
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Securi
tyServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Pre
senta
tion
Serv
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Realtim
eand
Near-
Realtim
eServ
ices
Realtim
eand
Near-
Realtim
eServ
ices
Service Bus
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
Mid
dle
ware
Mess
agin
gServ
ices
Mess
agin
gServ
ices
Mess
agin
gServ
ices
Media
tion
Serv
ices
Media
tion
Serv
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Managem
ent
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Dis
cove
ryServ
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Securi
tyServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Pre
senta
tion
Serv
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Realtim
eand
Near-
Realtim
eServ
ices
Realtim
eand
Near-
Realtim
eServ
ices
ISRService-based
Application
ISRService-based
Application
ISRService-based
Application
ISRService-based
Application
OtherService-based
Application
OtherService-based
Application
OtherService-based
Application
OtherService-based
Application
C2Service-based
Application
C2Service-based
Application
C2Service-based
Application
C2Service-based
Application
XM
L-R
PC
XM
L-R
PC
ebXM
LebXM
L
XM
L
Syn
dic
ation
XM
L
Syn
dic
ation
WSF
WSF
PO
XPO
X
XM
L-R
PC
XM
L-R
PC
ebXM
LebXM
L
XM
L
Syn
dic
ation
XM
L
Syn
dic
ation
WSF
WSF
PO
XPO
X
XML MessagingMiddleware
XM
PP
XM
PP
AM
QP
AM
QP
STO
MP
STO
MP
Oth
er M
OM
Serv
ices
Oth
er M
OM
Serv
ices
Message-OrientedMiddleware
Java
RM
IJa
va R
MI
DC
E R
PC
DC
E R
PC
DC
OM
DC
OM
ON
C R
PC
ON
C R
PC
Oth
er R
PC
or
DO
Serv
ices
Oth
er R
PC
or
DO
Serv
ices
Java
RM
IJa
va R
MI
DC
E R
PC
DC
E R
PC
DC
OM
DC
OM
ON
C R
PC
ON
C R
PC
Oth
er R
PC
or
DO
Serv
ices
Oth
er R
PC
or
DO
Serv
ices
RPC / Distributed Object Middleware
Java
Mess
agin
gServ
ice (JM
S)
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 WSF provides the easiest and most convenient way to implement interoperability across heterogeneous systems and to support SOA design practices.
23
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.
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.
24
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
Runtime Infrastructure Components
Mess
agin
gServ
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Runtime Infrastructure Components
Mess
agin
gServ
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Runtime Infrastructure Components
Mess
agin
gServ
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Mess
agin
gServ
ices
Mess
agin
gServ
ices
Media
tion
Serv
ices
Media
tion
Serv
ices
Managem
ent
Serv
ices
Managem
ent
Serv
ices
Dis
cove
ryServ
ices
Dis
cove
ryServ
ices
Securi
tyServ
ices
Securi
tyServ
ices
Pre
senta
tion
Serv
ices
Pre
senta
tion
Serv
ices
Realtim
eand
Near-
Realtim
eServ
ices
Realtim
eand
Near-
Realtim
eServ
ices
25
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.
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.
26
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.
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
27
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.
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.
28
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
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
decision making among required capabilities and priorities (Operational Domain), funding and management (Program Domain) and implementation (Technical Domain).
Operational and Technical focus and efforts include the injection of R&D capabilities, CONOP development, prototyping, the assessment of technical implementation plan against operational requirements, operational utility, training development, technical test and operational test. The key collaboration between the strategic and tactical activities is involving the operational SMEs in the end-to-end process to ensure appropriate capabilities are being developed/evolved.
Operational and Program focus and efforts include the requirements validation; investment planning, modeling and simulation, and war gaming. The key collaboration between the strategic and tactical activities is the roadmap and PR11 plan accomplishments.
Technical and Program focus and efforts include planning of capabilities, tracking dependencies, overall status, funds management, long term planning, technical life cycle support, R&D project execution
Figure 11: Governance Model
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: The operations
31
sphere has roles and responsibilities that are applied at different points in the lifecycle of a program. 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 insertion of these changes into the process. Additionally, since the Operations sphere isn’t fully 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"
The technology sphere is where functional requirements are developed into 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.
4.1.2 SOA - Beyond the Reference Model
This Navy SOA Reference Model (RM) is a technical reference intended to identify the architectural solution patterns, components, technologies, and standards that are fundamental to the Navy needs for Service Oriented Architecture (SOA) implementations. While much of this document focuses on the needed SOA technical features and the corresponding technical solution patterns, this document also makes clear that Navy SOA governance solutions and solutions for the related Navy SOA enterprise planning and management are essential for the Navy to benefit from its SOA initiatives more fully.
This closing section of the RM is intended to 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.
This document has addressed most of the technology related governance and management focus areas. These include a variety of service operations management functions, lifecycle management functions, and service, metadata management functions. In the governance category, some of the most critical areas relate to configuration control, versioning, service monitoring, change management, and of course security.
Therefore, the RM does outline the technologies needed to build, manage and govern a SOA from a technical point of view, but we have not addressed questions such as:
How are we going to manage it and use it to its full potential? How do we determine what services are required by Navy?
In addition to the fundamental infrastructure, services such as repositories and registries, what other specific services (or service categories) are most needed or most beneficial to support IT enterprise needs as well as Navy war-fighter needs. Some suggestions are:
32
Voice services: archiving, encryption, auto translation, enhancement, recognition, other processing,
Video or other data services: archiving, compression, encryption, other processing, Human resources databases, Training and education services
How will the planning, identification, management, updating, accommodation, or development and acquisition enforcement use key standards?
Will there be a need for firmly established and managed test procedures to develop and qualify service components? Is there already sufficient knowledge and experience within the Navy to establish best practices for this testing and qualification?
What will be the process for the proposal, approval, implementation, and follow-up management of new services in an existing Navy SOA?
Is there already a qualified "service registry" that lists and describes all services (Navy, DoD, commercial) that may be available to users, and to developers of other composite services who may want to leverage the existing services? For answers to this question, active participation in the Multi-Service SOA Consortium is required to leverage DISA and Army services such as NCEE, NCES, SOSCOE just to name a few.
How do we intelligently design our IT enterprise from both the business and technology point of views? Are available commercial tools appropriate for these tasks, or is this exclusively a task for teams of managers and technology specialists?
Similarly, (as discussed throughout this RM), there are many commercial standards, technologies, and infrastructure components, that can clearly be leveraged for SOA interests. What will be the best management/governance practices for optimizing that leveraging of commercial technology? Ask the question in terms of DOTMLPF: Doctrine, Organization, Training, Material, Personnel, and Facilities
33
Figure 12: Standard IDEF0 Model
Clearly, there are SOA management/ governance questions associated with every one of these elements. We have addressed many of them, however in order to begin the process of governance the Navy should develop a SOA Governance Infrastructure (SGI) that would fit into its current construct of standards, management, and overarching support to Programs of Records, Family of Systems, and System of Systems. The development of an SGI will point out a clear path for the Navy’s future into the Enterprise Services realm that can be interoperable and loosely coupled with Multi-Service and DoD components as a whole.
Consider IWS, CANES, NMCI, NGEN and ONEnet. How do we take advantage of the common technology across those areas? Is there a need for formalize inter program-working groups, such as currently attempted by the INO Integration group and its various strike teams, and CANES/NEGN Alignment IPT which are trying to harmonize the services and components ashore and afloat? The IDEF Model in Figure 12 will serve as a guide to the requirements for finding and governing these common services and components.
A well-defined SOA Governance will include guidance on the use of services across the Naval services and DoD. As shown in the CANES use case, the concept of applications using common services over a common infrastructure is possible. However, a SOA Governance structure as shown in Figure 11 is needed not only for one instantiation but across all instantiations of a SOA.
34
Appendix A - References
a. Joint Capability Integration and Development System (JCIDS) - CJCSI 6212.01Eb. Federal Enterprise Architecture Technical Reference Model V 1.1c. The Net-Centric Operations and Warfare Reference Model (NCOW RM) Version 1.1 d. Net-Centric Enterprise Services (NCES) (GIG EIE MA reference)e. Navy Web Services 2.0 Profile v1.3f. Many Common Object Request Broker Access (CORBA) Profileg. Department of the Navy’s (DON) Common System Functions List (CSFL)h. PEO C4I Masterplan for Systems Engineering (MPSE)i. PEO C4I Navy Technical Reference Model (NTRM)j. PEO C4I SOA Stack Promulgation (Core Services v1.0)k. Net Centric Enterprise Solutions for Interoperability (NESI)
http://www.dod.gov/nii/org/cio/doc/Net-Centric-Data-Strategy-2003-05-092.pdfl. CANES Systems Design Specification (SDS)m. Service Component Referencesn. The Burton Group SOA Runtime Infrastructureo. CANES SD-SOA Requirements Allocation v 1.1p. SOA Governance and commercial best practices
http://www.oracle.com/technology/pub/articles/dev2arch/2008/03/blueprint-soa-integration.html
q. Service - Oriented Architecture Concepts, Technology, and Design, Thomas Erl
35
