© 2009 The MITRE Corporation. All rights reserved. Multi-Partner SOA Interoperability Presented to the US-NATO Information Sharing (UNIS) Technical Exchange Meeting December 3, 2009 Brad Mercer, Department Head Naval C3 Systems Department The MITRE Corporation

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Service-Oriented Architecture (SOA) promised that multiple information exchange partners could easily achieve enterprise integration and interoperability ■… but our experience has shown that it is quite possible to build collections of non-interoperable SOA silos when the scale of the enterprise is not properly considered The Promise of SOA

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Operational Activity 1 Composable Business Processes Operational Activity 2 Operational Activity 3 Operational Activity 4 Service 1Service 2Service 3Service 4 Operational View ●Operator wants to achieve efficiency and effectiveness within his operational environment ●Primary expectation upon SOA is that it allows him to employ composable operational processes and information to achieve increased operational agility ●Inherent capability to arrange and rearrange system functions in new ways in support of operational agility greatly lags the need for such capability … so much so as to produce a significant capability gap Services View ●Operations are dependent upon the use of IS to obtain, distribute, process, access, and combine information ●Traditional IS architectures are not sufficiently robust and generally inflexible when compared with the need for requisite system agility to enable desired operational agility ●SOA is the one architectural form that inherently offers sufficient system agility to satisfy the need identified by the capability gap Operational Process Service Process

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Composition-Based Software Development and Execution Services-Based Application ●Functionality implemented as a composition of services described using a business process description language such as BPEL (i.e. service-process or business process) ●Traditionally implemented as a compiled software program ●Legacy programs can be refactored into services or retrofitted with a standards-based services interface Services Infrastructure ●Form of middleware that provides a platform for execution of service compositions ●Provides process mediation (e.g. orchestration or choreography), S2S messaging and data mediation, policy enforcement (e.g. security, “runtime” management) ●Commonly provides “composition” and test environment; service development and management environment (inc. registration and discovery); policy development environment; content management and delivery Services Infrastructure Services-Based Application Underlying Infrastructure (processing system, storage system, network system)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Service-Oriented Enterprise Services Infrastructure Services-Based Application Enterprise A Underlying Infrastructure An enterprise employs: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique “Stack” Architecture/Standard (i.e. standard patterns) An enterprise employs: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique “Stack” Architecture/Standard (i.e. standard patterns)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Building SOA Silos Services Infrastructure Services-Based Application Silo A Services Infrastructure Services-Based Application Silo B Services Infrastructure Services-Based Application Silo C Each “silo” employs: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique“Stack” Architectures/Standards (i.e. standard patterns) Each “silo” employs: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique“Stack” Architectures/Standards (i.e. standard patterns) Enterprise A Enterprise CEnterprise B

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Building SOA Silos Services Infrastructure Services-Based Application Silo A Services Infrastructure Services-Based Application Silo B Services Infrastructure Services-Based Application Silo C A key to achieving enterprise integration and interoperability is proper consideration of what constitutes the enterprise Enterprise A Enterprise CEnterprise B

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Service-Oriented Environment (SOE) Services Infrastructure Services-Based Application Services Infrastructure Services-Based Application K2 “Federation” “Node” “Trusted Boundary” “Trusted Domain” “Integration” K1 “Interoperation” “Trusted Boundary” “Trusted Domain” K3

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Key Architectural Interfa ces Pa ge 9

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SOA Reference Architecture Services Infrastructure Services-Based Application SOA Reference Architecture provides: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique “Stack” Architecture/Standard (i.e. standard patterns) SOA Reference Architecture provides: ► Unique Interface Syntax and Semantics (i.e. specific patterns) ► Unique “Stack” Architecture/Standard (i.e. standard patterns) K2

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Notional SOA Model

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Notional SOA Model Interface Architecture Implementation

© 2009 The MITRE Corporation. All rights reserved. 12/03/ K2 Interface Architectural Elements ■Data: data inputs and outputs (i.e. messages) across the services interface; data model for data exchanged across the services interface [also known as a Data Reference Model (DRM)] ■Operations: operations that can be invoked across the services interface upon the data inputs or outputs, or to accomplish other capabilities [also know as a Services Reference Model (SRM)] ■Protocols: standard methods and ways that data is exchanged and operations are invoked across the services interface [also known as a Technical Reference Model (TRM)] ■Service Levels: Performance and other QoS to be satisfied; any Quality of Service (QoS) requirements upon the operations [also known as a Performance Reference Model (PRM)]

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Pa ge 14 Reference Architecture and Possible Implementations Reference Architecture Reference Implementation Implementation 1 Implementation 2 Implementation n ●●● definitive interpretation measures Reference Architecture provides template for development of and standard for validation of implementations measures Implementations are considered equivalent in that they all reveal the same interface and therefore all support the same usage … Service-based applications that execute on one infrastructure will execute on another equivalent infrastructure … INTEROPERABILITY!!!

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■“JSOA” is an undefined term describing a collection of initiatives intended to lead to interoperable service-oriented information systems employed in joint warfighting. ■In many cases, “JSOA” is being used to describe the common underlying services infrastructure that might enable this interoperability. ■It is not necessary to mandate a common implementation to achieve this goal. A reference architecture adhered to by all implementations—both applications and infrastructure— brought to the joint warfighting space is sufficient. ■A reference implementation of a reference architecture is frequently defined to enable more rapid adoption of the reference architecture. A reference implementation is not a mandated common implementation. Joint SOA (JSOA)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SOA Reference Architecture

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Catalog User Goals and Key Scenarios –What are the user goals in utilizing a common service interfaces? –What are the key scenarios of usage? ■Derive Conceptual Foundation for the Architecture –Nouns – Objects Being Operated Upon –Verbs – Actions to transform the Nouns which enable Stakeholders to achieve their Goals SOA RA Foundations

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Nouns –Data ■ Data at Rest ● Stored “behind” the service interface ■ Data in Motion –Service / Process ■ Description ■ End-Point –Policy –Meta-data ■ Templates [Services, Policies] ■ Attributes [Data, Services, Policy] ■Verbs –Execute / Invoke –Enforce [Policy] –Messaging [Data] –Mediate ■ Mediate Data ■ Mediate Services / Service Process ■ Mediate Policy ■ Mediate Presentation –Manage ■ Create / Register ■ Update ■ Remove –Search / Discover SOA RA Foundations

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Some Context

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Services Runtime Infrastructure (SRTI)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Execute Service Process ■Mediate Process ■Search Service End-Point ■Invoke Service End-Point ■Messaging Data ■Mediate Data ■Enforce Policy ■Mediate Policy (SRTI Policy Subsystem) SRTI Use Cases

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI: Use Case Diagram

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI: Sequence Diagram

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Use CaseCapabilityProtocolProduct* Execute Service ProcessOrchestrationWSBPELJBoss jBPM v4.2 Mediate ProcessOrchestrationWSBPELJBoss jBPM v4.2 Search Service End-Point Service Discovery (Runtime Only) UDDI v3.0 Invoke Service End-Point OrchestrationWSBPELJBoss ESB v4.2 Messaging DataMessagingWS-ReliableMessaging WS-Notification JBoss ESB v4.2 METRO 1.3 Globus Toolkit+GOTS Mediate DataMediationJBoss ESB v4.2 Enforce PolicySecurity (Partial) WS-Security SAML 2.0 IC DOD Security RA v1.0 Mediate PolicySecurity (Partial) WS-Security SAML 2.0 IC DOD Security RA v1.0 Initial Technical Reference Model (TRM)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Core Use Cases –Enforce Policy (from SRTI) –Mediate Policy ■Passive Use Cases –Monitor Data –Monitor Process ■Use Cases from IC DOD SOA Security Reference Architecture v1.0 –Authenticate Actor –Validate Credentials –Control Access –Secure Message –Create Audit Trail SRTI Policy Subsystem Use Cases

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem: Use Case Diagram

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Common Service –Service: Exposed interface to a capability –Common: Requires pre-existing service registration store which is part of a common infrastructure –Trigger: Execute Service Process –Transforms, updates, creates and delivers data –Roughly equivalent to a business process ■Common Policy –Policy: Rule applied to the message flow between services –Common: Requires pre-existing policy table which is part of a common infrastructure –Trigger: Message flow across a Policy Enforcement Point (PEP) –PEP invokes a Policy Decision Point (PDP) in accordance with a SOA Security Pattern (e.g., IC DOD) –Requires existing condition to match policy from the policy table Common Services vs. Common Policies

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem: Control Access

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem: Secure Message

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem: Authenticate Actor

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Associated System - Use Application

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Associated System: Use Application

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Services Management

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ONR SOA RA: Data Reference Model - DRM (Partial)

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI DRM Detail (Initial) ExecuteServiceProcess(, [ ], [ ], [ ]) SearchServiceEndPoint(,, [ ]) InvokeServiceEndPoint(, [ ], [ }, [ ]) MessageData(,, [ ], [ ]) MediateData(,,, [ ]) EnforcePolicy(, [ ], [ ])

© 2009 The MITRE Corporation. All rights reserved. 12/03/ ■Manage Service Descriptions –Register Service Description –Update Service Description –Remove Service Description ■Manage Policy Descriptions –Create Policy Description –Update Policy Description –Remove Policy Description ■Search Service Description ■Search Policy Description Services Management Use Cases

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Services Management: Use Case Diagram

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Services Management: Manage Service Descriptions

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Services Management: Manage Policy Descriptions

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Manage Services: Sequence Diagram

© 2009 The MITRE Corporation. All rights reserved. 12/03/ SRTI Policy Subsystem Interfaces

© 2009 The MITRE Corporation. All rights reserved. 12/03/ Key Architectural Interfa ces Pa ge 43