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


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


12/03/2009 - 3

OperationalActivity 1

Composable Business Processes




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


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)


12/03/2009 - 5

Service-Oriented Enterprise



Enterprise A

UnderlyingInfrastructure

An enterprise employs:► Unique Interface Syntax and Semantics

(i.e. specific patterns)► Unique “Stack” Architecture/Standard

(i.e. standard patterns)


12/03/2009 - 6

Building SOA Silos



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)

Enterprise A Enterprise CEnterprise B


12/03/2009 - 7

Building SOA Silos



Silo A



Silo B



Silo C

A key to achieving enterprise integration and interoperabilityis proper consideration of what constitutes the enterprise

Enterprise A Enterprise CEnterprise B


12/03/2009 - 8

Service-Oriented Environment (SOE)





K2 K2

“Federation”

“Node” “Node”

“Trusted Boundary”“Trusted Domain”

“Integration”

K1“Interoperation”

“Trusted Boundary”“Trusted Domain”

K3


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.


12/03/2009 - 10

SOA Reference Architecture



SOA Reference Architecture provides:► Unique Interface Syntax and Semantics

(i.e. specific patterns)► Unique “Stack” Architecture/Standard

(i.e. standard patterns)

K2


12/03/2009 - 11

Notional SOA Model


12/03/2009 - 12

Notional SOA Model

Interface Architecture

Implementation


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


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!!!


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)


12/03/2009 - 16

SOA Reference Architecture


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


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


12/03/2009 - 19

Some ContextAssociated System

SRTI: Services RuntimeInfrastructure

SRTI PolicySubsystem

ManageServices


12/03/2009 - 20

Services Runtime Infrastructure (SRTI)Associated System



ManageServices


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


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»


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()


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)


12/03/2009 - 25

SRTI Policy SubsystemAssociated System


ManageServices



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


12/03/2009 - 27

SRTI Policy Subsystem: Use Case Diagram

uc SRTI Policy Subsystem [SRTI Policy Subsystem]

IC DOD SOA SecurityReference Architecture v1.0


(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»


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


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


12/03/2009 - 30

SRTI Policy Subsystem:Secure Message

act Secure Message

SRTI P

olicy SubsystemSR

TI

Secure MessagePEP

Finish

Return Action Code


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]


12/03/2009 - 31

SRTI Policy Subsystem:Authenticate Actor

act Authenticate Actor


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


Create Security Token

GenerateSecurity Token

Enforce Authenticate Actor

Initiate Authenticate Actor PDP

PDP Policy Decision

[Found]

[Not Found]

[Permit]

[Deny, Unknown]

[No]

[Yes]


12/03/2009 - 32

Associated System - Use ApplicationAssociated System



ManageServices


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()


12/03/2009 - 34

Services ManagementAssociated System



ManageServices


12/03/2009 - 35

ONR SOA RA:Data Reference Model - DRM (Partial)

Associated System



ManageServices


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


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


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»


12/03/2009 - 39

Services Management:Manage Service Descriptions

uc Manage Serv ice Descriptions

Services Management

(from Govern Services)

Register Serv ice Description


Remove Serv ice Description


Update Serv ice Description


Search Serv ice Description


Manage Serv ice Descriptions

(from SRTI)

Manage System

«invokes»

«invokes»

«extend»

«extend»

«extend»

«extend»

«include»


12/03/2009 - 40

Services Management:Manage Policy Descriptions

uc Manage Policy Descriptions

Services Management


Search Policy Description


Manage Policy Descriptions


Create Policy Description


Update Policy Descriptions


Remov e Policy Descriptions

(from SRTI)

Manage System


Execute Audit

(from SRTI)

Manage Security

«extend»

«extend»

«extend»«invokes»

«extend»«invokes»

«include»

«extend» «include»


12/03/2009 - 41

Manage Services: Sequence Diagramsd SOA RA Sequence Diagrams [Manage System - Manage Serv ice Descriptions]

Manage ServiceDescriptions


Register ServiceDescription


Search ServiceDescription


Update ServiceDescription


Remove ServiceDescription


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()


12/03/2009 - 42

SRTI Policy Subsystem Interfaces

class Data Reference Model


- 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


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.

Documents

Multi-Partner SOA Interoperability