1 / 43

Multi-Partner SOA Interoperability

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. The Promise of SOA.

yepa
Download Presentation

Multi-Partner SOA Interoperability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. The Promise of SOA • 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

  3. Composable Business Processes • 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 Operational Activity 1 Operational Activity 2 Operational Activity 3 Operational Activity 4 Operational Process Service1 Service 2 Service 3 Service 4 Service Process • 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

  4. 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-Based Application • 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 UnderlyingInfrastructure(processing system, storage system,network system)

  5. Service-Oriented Enterprise Enterprise A Services-Based Application • An enterprise employs: • Unique Interface Syntax and Semantics(i.e. specific patterns) • Unique “Stack” Architecture/Standard(i.e. standard patterns) Services Infrastructure UnderlyingInfrastructure

  6. Building SOA Silos Enterprise B Enterprise C Enterprise A Services-Based Application Services-Based Application Services-Based Application Services Infrastructure Services Infrastructure Services Infrastructure Silo A Silo B Silo C • Each “silo” employs: • Unique Interface Syntax and Semantics (i.e. specific patterns) • Unique“Stack” Architectures/Standards (i.e. standard patterns)

  7. Building SOA Silos Enterprise B Enterprise C Enterprise A Services-Based Application Services-Based Application Services-Based Application Services Infrastructure Services Infrastructure Services Infrastructure Silo A Silo B Silo C A key to achieving enterprise integration and interoperabilityis proper consideration of what constitutes the enterprise

  8. Service-Oriented Environment (SOE) “Node” “Node” “Interoperation” Services-Based Application Services-Based Application K1 K2 K2 “Integration” Services Infrastructure Services Infrastructure K3 “Federation” “Trusted Boundary” “Trusted Domain” “Trusted Boundary” “Trusted Domain”

  9. Key Architectural Interfaces

  10. SOA Reference Architecture Services-Based Application • SOA Reference Architecture provides: • Unique Interface Syntax and Semantics(i.e. specific patterns) • Unique “Stack” Architecture/Standard(i.e. standard patterns) K2 Services Infrastructure

  11. Notional SOA Model

  12. Notional SOA Model Interface Architecture Implementation

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

  14. Reference Architecture and Possible Implementations Reference Architecture provides template for development of and standard for validation of implementations Reference Architecture definitive interpretation Implementation 1 Implementation 2 Implementation n Reference Implementation ●●● measures measures 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!!!

  15. Joint SOA (JSOA) • “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.

  16. SOA Reference Architecture

  17. SOA RA Foundations • 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

  18. SOA RA Foundations • 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 • 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]

  19. Some Context Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  20. Services Runtime Infrastructure (SRTI) Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  21. SRTI Use Cases • Execute Service Process • Mediate Process • Search Service End-Point • Invoke Service End-Point • Messaging Data • Mediate Data • Enforce Policy • Mediate Policy (SRTI Policy Subsystem)

  22. SRTI: Use Case Diagram

  23. SRTI: Sequence Diagram

  24. Initial Technical Reference Model (TRM)

  25. SRTI Policy Subsystem Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  26. SRTI Policy Subsystem Use Cases • 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

  27. SRTI Policy Subsystem: Use Case Diagram

  28. Common Services vs. Common Policies • 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

  29. SRTI Policy Subsystem:Control Access

  30. SRTI Policy Subsystem:Secure Message

  31. SRTI Policy Subsystem:Authenticate Actor

  32. Associated System - Use Application Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  33. Associated System: Use Application

  34. Services Management Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  35. ONR SOA RA:Data Reference Model - DRM (Partial) Associated System SRTI: Services RuntimeInfrastructure SRTIPolicySubsystem ManageServices

  36. SRTI DRM Detail (Initial) ExecuteServiceProcess(<ServiceProcessLabel>, [<DataIn>], [<DataOut>], [<Controls>]) SearchServiceEndPoint(<ServiceEndPointLabel>, <ServiceEndPoint>, [<Controls>]) InvokeServiceEndPoint(<ServiceEndPointLabel>, [<DataIn>], [<DataOut>}, [<Controls>]) MessageData(<ServiceEndPointSend>, <ServiceEndPointReceive>, [<Contract>], [<Controls>]) MediateData(<ServiceEndPointSender>, <ServiceEndPointReceiver>, <Contract>, [<Controls>]) EnforcePolicy(<PolicyLabel>, [<PolicyPattern>], [<Controls>])

  37. Services Management Use Cases • 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

  38. Services Management:Use Case Diagram

  39. Services Management:Manage Service Descriptions

  40. Services Management:Manage Policy Descriptions

  41. Manage Services: Sequence Diagram

  42. SRTI Policy Subsystem Interfaces

  43. Key Architectural Interfaces

More Related