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. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
■ 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
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
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
K 1 – Service to Service Virtual* InterfaceK 2 – Service to Infrastructure InterfaceK 3 – Infrastructure to Infrastructure Interface
Assumes a centralized service infrastructure where service-to-service messaging is accomplished via service-oriented middleware (e.g. ESB); “K1” can be implemented directly via peer-to-peer (i.e. P2P) architectures where service-to-service messaging middleware is not used.
*
ServiceInfrastructures
Service-BasedApplications
Infrastructure X
Application A
Infrastructure Y
Application B
Infrastructure Z
Application C
K 1
K 3
K 2 K 2K 2
T here are three key architectural interfaces (K 1, K 2, and K 3) thatdetermine interoperability in any Service-Oriented Environment.
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)]
Reference Architecture and Possible Implementations
Reference Architecture
Reference Implementation
Implementation1
Implementation2
Implementationn●●●
definitive interpretation
measures
Reference Architecture provides template for development of and standard for validation of
implementations
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!!!
■ “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.
■ 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
■ 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
Associated System: Use Applicationsd SOA RA Sequence Diagrams [Use Application]
MediatePresentation
(from SRTI)
Use Application
(from SRTI)
All Human
(from Actors)
Execute ServiceProcess
(from SRTI)
loop Use Application Capabilities
[Unti l Actor Requests Application Exit]
Use Application Sequence Diagram for Non-Humans: Drop All-Human Actor and Replace Mediate Presentation with Al l Non-Human actor.
Authenication system variables are set at this time either by a service or application capabil i ty. If a service cal l is made, SRTI security attributes can be set by enforcing the policy AuthenticateActor.
opt Execute Application Serv ice Process
opt Execute Request Application Serv ice Process
loop Display Application Capability
[For Each Application Capabil i ty]
opt Exit Application Serv ice Process
Request Access()
[Has Authority to Access Application Presentation]:Access Application Presentation()
Request Appl icationAccess()
Execute Request Appl icationAccess Service Process()
Return Request ApplicationAccess Service Process Results()
Request Application AccessResult(True, False)
Request Create ApplicationPresentation()
Set ApplicationCapabil i ty Access()
Only display Authorized (Accessis True) Application Capabil i ties
Display ApplicationPresentation()
Return AccessResult(True, False)
[[Application] Capabil ity Access is True]:Select Capabi li ty()
Invoke Appl icationCapabil ity()
Execute ApplicationService Process()
Return Application ServiceProcess Results()
Return Appl icationCapabil ity Results()
Display Capabil i tyResults()
Request Exit (Logout)
Exit Application()
Execute Exit ApplicationService Process()
Return Execute Exit ApplicationService Process Results()
Manage Services: Sequence Diagramsd SOA RA Sequence Diagrams [Manage System - Manage Serv ice Descriptions]
Manage ServiceDescriptions
(from Govern Services)
Register ServiceDescription
(from Govern Services)
Search ServiceDescription
(from Govern Services)
Update ServiceDescription
(from Govern Services)
Remove ServiceDescription
(from Govern Services)
Manage System
(from SRTI)
alt Select Manage Serv ice Description Action
[Select Register Service Description]
[Select Update Service Description]
[Select Remove Service Description]
[Select Search Service Description]
Manage System and i tssubsystems can invoke Execute Service Processes, just like any other application. The flows to Execute Service Process are hidden for diagram clarity.
K 1 – Service to Service Virtual* InterfaceK 2 – Service to Infrastructure InterfaceK 3 – Infrastructure to Infrastructure Interface
Assumes a centralized service infrastructure where service-to-service messaging is accomplished via service-oriented middleware (e.g. ESB); “K1” can be implemented directly via peer-to-peer (i.e. P2P) architectures where service-to-service messaging middleware is not used.
*
ServiceInfrastructures
Service-BasedApplications
Infrastructure X
Application A
Infrastructure Y
Application B
Infrastructure Z
Application C
K 1
K 3
K 2 K 2K 2
T here are three key architectural interfaces (K 1, K 2, and K 3) thatdetermine interoperability in any Service-Oriented Environment.