Multi-Partner SOA Interoperability
description
Transcript of Multi-Partner SOA Interoperability
© 2009 The MITRE Corporation. All rights reserved.
Multi-Partner SOA InteroperabilityPresented to the US-NATO Information Sharing (UNIS) Technical Exchange Meeting
December 3, 2009
Brad Mercer, Department HeadNaval C3 Systems DepartmentThe MITRE Corporation
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 2
■ 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/2009 - 3
OperationalActivity 1
Composable Business Processes
OperationalActivity 2
OperationalActivity 3
OperationalActivity 4
Service 1 Service 2 Service 3 Service 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
OperationalProcess
ServiceProcess
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 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 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
UnderlyingInfrastructure
(processing system,storage system,network system)
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 5
Service-Oriented Enterprise
Services Infrastructure
Services-Based Application
Enterprise A
UnderlyingInfrastructure
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/2009 - 6
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)
Enterprise A Enterprise CEnterprise B
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 7
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 interoperabilityis proper consideration of what constitutes the enterprise
Enterprise A Enterprise CEnterprise B
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 8
Service-Oriented Environment (SOE)
Services Infrastructure
Services-Based Application
Services Infrastructure
Services-Based Application
K2 K2
“Federation”
“Node” “Node”
“Trusted Boundary”“Trusted Domain”
“Integration”
K1“Interoperation”
“Trusted Boundary”“Trusted Domain”
K3
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 9
Key Architectural Interfaces
Pag
e 9
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.
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 10
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)
K2
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 11
Notional SOA Model
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 12
Notional SOA Model
Interface Architecture
Implementation
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 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)]
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 14
Pag
e
14
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!!!
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 15
■ “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/2009 - 16
SOA Reference Architecture
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 17
■ 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/2009 - 18
■ 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/2009 - 19
Some ContextAssociated System
SRTI: Services RuntimeInfrastructure
SRTI PolicySubsystem
ManageServices
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 20
Services Runtime Infrastructure (SRTI)Associated System
SRTI: Services RuntimeInfrastructure
SRTI PolicySubsystem
ManageServices
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 21
■ 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/2009 - 22
SRTI: Use Case Diagramuc SRTI [SRTI]
Services Runtime Infrastructure (SRTI)
Inv oke Serv ice End-Point
Execute Serv ice Process
Mediate Process
Mediate Data
Messaging Data
Search Serv ice End-Point
Application
(from Actors)
Enforce Policy
SRTI Policy Subsystem
(from SRTI Policy Subsystem)
Mediate Policy
«extend»
«extend»
«include»
«extend»
«include»
«include»
«include»
«include»
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 23
SRTI: Sequence Diagramsd SOA RA Sequence Diagrams [Execute Serv ice Process – Orchestration / Choreography with optional Messaging and Mediate Data]
Execute ServiceProcess
(from SRTI)
Mediate Process
(from SRTI)
Search ServiceEnd-Point
(from SRTI)
Invoke ServiceEnd-Point
(from SRTI)
Application
(from Actors)
Messaging Data
(from SRTI)
Mediate Data
(from SRTI)
Enforce Policy
(from SRTI)
loop Execute Process
[Unti l Services are Exausted]
opt Message Data
opt Mediate Data
opt Enforce Policy
[If Enforce Policy Required, Determine Acceptabili ty or Denial of Execute (specific) Service]
Invoke ServiceProcess()
Execute ProcessScript()
Find ServiceEnd-Point()
Return ServiceEnd-Point()
Request Policy Enforcement()
Enforced Pol icy Results()
Invoke Service(via End-Point)
Return CompletionStatus Flag()
Move Data BetweenServices()
MediateDataContracts() Request Policy
Enforcement()
Enforced PolicyResults()
Mediation Results()
MessagingResults()
Return ProcessScript Results()
Return Service Process Results()
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 24
SRTI Use Case Capability Protocol Product*Execute Service Process Orchestration WSBPEL JBoss jBPM v4.2
Mediate Process Orchestration WSBPEL JBoss jBPM v4.2
Search Service End-Point
Service Discovery(Runtime Only)
UDDI v3.0 UDDI v3.0
Invoke Service End-Point
Orchestration WSBPEL JBoss ESB v4.2
Messaging Data Messaging WS-ReliableMessagingWS-Notification
JBoss ESB v4.2METRO 1.3Globus Toolkit+GOTS
Mediate Data Mediation JBoss ESB v4.2
Enforce Policy Security(Partial)
WS-SecuritySAML 2.0
IC DOD Security RA v1.0
Mediate Policy Security(Partial)
WS-SecuritySAML 2.0
IC DOD Security RA v1.0
Initial Technical Reference Model (TRM)
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 25
SRTI Policy SubsystemAssociated System
SRTI: Services RuntimeInfrastructure
ManageServices
SRTI PolicySubsystem
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 26
■ 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/2009 - 27
SRTI Policy Subsystem: Use Case Diagram
uc SRTI Policy Subsystem [SRTI Policy Subsystem]
IC DOD SOA SecurityReference Architecture v1.0
SRTI Policy Subsystem
(from SRTI)
Enforce Policy
(from SRTI)
Mediate Data
(from SRTI)
Mediate Process Monitor Data Monitor Process
Authenticate Actor
Validate Credentials
Control Access
Secure Message
Mediate Policy
Create Audit Trail
«include»«extend»
«include»
«extend»
«include»
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 28
■ 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/2009 - 29
SRTI Policy Subsystem:Control Access
act Control Access
SRTI Policy SubsystemSRTI
Control Access PEP
Finish
Initiate Control Access PDP
Retrieve Actor Credentials
Retriev e Serv ice EndPoint
Return Action Code
PEP Enforces Policy Decision
PDP Policy Decision
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 30
SRTI Policy Subsystem:Secure Message
act Secure Message
SRTI P
olicy SubsystemSR
TI
Secure MessagePEP
Finish
Return Action Code
PEP Enforces Policy Decision
Secure Message Type
Apply Integrity (Digital Signature)
Apply Confidentiality (Encrypt Message)
Transport
Message
Digital Signature
Encryption
Not Selected
Initiate Secure Message PDP
PDP Policy Decision
[Transport]
[Message]
[DigitalSign]
[Not]
[Encrypt][Not]
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 31
SRTI Policy Subsystem:Authenticate Actor
act Authenticate Actor
SRTI Policy Subsystem
SRTIM
ediate Presentation
Prov ide Actor Credentials
RequestAuthenticateActor
Enforce Validate Credentials (Actor)
Retreiv e Actor Credentials Locate Credentials
Finish
Allow Entry
Return Action Code
Return Action Code {Unknown}
Enable Entry
Deny Entry
Load Actor Credentials
PEP Enforces Policy Decision
Create Security Token
GenerateSecurity Token
Enforce Authenticate Actor
Initiate Authenticate Actor PDP
PDP Policy Decision
[Found]
[Not Found]
[Permit]
[Deny, Unknown]
[No]
[Yes]
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 32
Associated System - Use ApplicationAssociated System
SRTI: Services RuntimeInfrastructure
SRTI PolicySubsystem
ManageServices
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 33
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()
Exit Appl ication Results()
Exit Results()
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 34
Services ManagementAssociated System
SRTI: Services RuntimeInfrastructure
SRTI PolicySubsystem
ManageServices
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 35
ONR SOA RA:Data Reference Model - DRM (Partial)
Associated System
SRTI: Services RuntimeInfrastructure
SRTI PolicySubsystem
ManageServices
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 36
SRTI DRM Detail (Initial)
class Data Reference Model
SRTI
- Controls: text- DataIn: text
«output element»- DataOut: text
«id»- ServiceProcessLabel: text- SRTIlabel: text
+ ExecuteServiceProcess(text, text, text*, text) : void- SearchServiceEndPoint(text, text*, text) : void {query}- InvokeServiceEndPoint(text, text, text*, text) : void- MessageData(text, text, text, text) : void- MediateData(text, text, text, text) : void- EnforcePolicy(text, text, text) : int
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>])
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 37
■ 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/2009 - 38
Services Management:Use Case Diagram
uc Govern Serv ice Descriptions
Associated System
Services Management
Register Serv ice Description
Remov e Serv ice Description
Update Serv ice Description
Search Serv ice Description
(from SRTI)
Mediate Presentation
Manage Serv ice Descriptions
Search Policy Description
Manage Policy Descriptions
Create Policy Description
Update Policy Descriptions
Remov e Policy Descriptions
Human Manager
(from Actors)
(from SRTI)
Manage System
Human User
(from Actors)
(from SRTI)
Use Application
Non-Human User
(from Actors)
«Invariant»{Actor needs to be a Manager to access Manage System}
Non-Human Manager
(from Actors)
Execute Audit
(from SRTI)
Manage Security«extend»
«invokes»«extend»
«invokes»«extend»
«extend»
«extend»
«include»
«include»
«extend»
«extend»
«extend»
«invokes» «extend»
«invokes» «extend»
«include»
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 39
Services Management:Manage Service Descriptions
uc Manage Serv ice Descriptions
Services Management
(from Govern Services)
Register Serv ice Description
(from Govern Services)
Remove Serv ice Description
(from Govern Services)
Update Serv ice Description
(from Govern Services)
Search Serv ice Description
(from Govern Services)
Manage Serv ice Descriptions
(from SRTI)
Manage System
«invokes»
«invokes»
«extend»
«extend»
«extend»
«extend»
«include»
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 40
Services Management:Manage Policy Descriptions
uc Manage Policy Descriptions
Services Management
(from Govern Services)
Search Policy Description
(from Govern Services)
Manage Policy Descriptions
(from Govern Services)
Create Policy Description
(from Govern Services)
Update Policy Descriptions
(from Govern Services)
Remov e Policy Descriptions
(from SRTI)
Manage System
(from Govern Services)
Execute Audit
(from SRTI)
Manage Security
«extend»
«extend»
«extend»«invokes»
«extend»«invokes»
«include»
«extend» «include»
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 41
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.
Enter ManageServiceDescriptions()
Invoke RegisterService Description()
Check ServiceExistance()
Return SearchDescription Results()
[Service Description doesnot Exist]:Add NewService Description()Return Register
Service DescriptionResults()
Invoke UpdateService Description() Retrive Service
Description()
Return ServiceDescription()
[Service Description Exists]:Perform Update ServiceDescription()Return Update Service
Description Results()
Invoke RemoveService Description()
Retrive ServiceDescription()
Return ServiceDescription()
[ServiceDescription Exists]:Perform RemoveServiceDescription()
Return Remove ServiceDescription Results()
Retrive Service Description()
Return Service Description()
Return ManageService DescriptionResults()
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 42
SRTI Policy Subsystem Interfaces
class Data Reference Model
SRTI Policy Subsystem
- Controls: text
«id»- SRTIPolicySubsystemLabel: int
- AuthenticateActor(boolean) : int- ControlAccess() : int- MonitorData(text*) : void- MonitorProcess(text*) : void- SecureMessage(int, boolean, boolean) : void- SecureMessageEncryption() : viod- SecureMessageSignature() : void- ValidateCredentials() : int
© 2009 The MITRE Corporation. All rights reserved.
12/03/2009 - 43
Key Architectural Interfaces
Pag
e
43
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.