delegation of intent via conversation david e. ellis

24
Delegation of Intent via Conversation David E. Ellis

Upload: ashlynn-pitts

Post on 13-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Delegation of Intent via Conversation David E. Ellis

Delegation of Intent via Conversation

David E. Ellis

Page 2: Delegation of Intent via Conversation David E. Ellis

The two types of Actors

Delegate

Page 3: Delegation of Intent via Conversation David E. Ellis

Actor Exchange Actions

Collection of Communication

Action is a Conversation

Page 4: Delegation of Intent via Conversation David E. Ellis

SOA Definitions• Computational delegates accomplish Communications Actions by exchanging a sequence

of bits across some type of communications media.• A Computational delegate which creates a sequence of bits is or represents the Owner.• The SOA-RA defines a resource as “any entity of some perceived value that has identity.”• Identity/Meaning for a sequence of bits is established by computational standards and

the SOA-RA defines Identity as “the collection of individual characteristics by which an entity, human or nonhuman, is recognized or known.”

• The SOA-RA defines a Goal as “a measurable state of the world that an actor is seeking to establish.”

• A dictionary defines Objective as “something that one's efforts or actions are intended to attain or accomplish; purpose; goal; target.” They are often used to define steps to achieve or realize a Goal.

• The SOA-RA defines Responsibility as “an obligation on a role player to perform some action or to adopt a stance in relation to other role players.”

• A dictionary defines Constraints as “a limitation or restriction” and the SOA-RA defines Policy Constraint as “a measurable Proposition that characterizes the constraint that the policy is about.”

Page 5: Delegation of Intent via Conversation David E. Ellis

More SOA definitions• The Service Provider computational delegate (Listener) is “Committed” to perform

some Service Action based on receiving resources from the Consumer computational delegate (Speaker) as described, for example, in a WSDL.

• The Consumer Intent/Objective is understood by examining the resources (sequence of bits) received by the Listener and matching them with the corresponding operation defined in the WSDL.

• The SOA-RA defines the Intentional Force of a communicative act as “the proximate purpose of the communication. For example, a communicative action may be a request, or it may inform the listener of some fact.”

• The Service Provider WSDL may specify some “Responsibility” to honor a Constraint like using encrypted (e.g.HTTPS) communications.

• The Service Consumer (Resource Owner) has Policy Constraints: For Example:– READ access Constraints are enforced by encrypting the Resource with a key.– WRITE access Constraints which can not be enforced but can be verified by the Listener– Other Policy Constraints are communicated by encapsulation of Resources with a standards based

envelop (e.g. SOAP {WS-*} conversation or EDXL-DE with XACML distribution policy encapsulation)

Page 6: Delegation of Intent via Conversation David E. Ellis

Characteristics• Participants are capable of independent actions to achieve goals.

They have volition and can parse various types of interactions with other participants either directly or via the delegates representing the participant.

• Computational Delegates are limited to specific actions to achieve goals entrusted from participants. They have no volition and can parse only specific types of interactions with either participants and/or other delegates.

• Interaction between computational delegates is a special type of communication action because the range of actions is limited to the mutually understood orchestration or choreography of exchanged messages.

• A Conversation is the sequence of communication actions which leads to the joint achievement of a Real World Effect which may or may not satisfy the goals of all participants.

Page 7: Delegation of Intent via Conversation David E. Ellis

Delegate Characterisitics• An interactive delegate is a computational entity (e.g.

application) which is orchestrated by adopting behavior of it’s represented participant (usually the service consumer)

• An adaptive delegate is a computational entity which adopts specific behavior with respect to using a resource from some other delegates perspective only during the period of a specific service engagement (usually the service mediator or initial computational entity offering a composite service capability)

• A semi-autonomous delegate is a computational entity which considers the SOA eco-system and adopts behavior requested from other delegates based on it’s internal processes (usually the service provider capability offering or a sensing system in event notification MEP)

Page 8: Delegation of Intent via Conversation David E. Ellis

InteractiveDelegate

AdaptiveDelegate

Semi-AutonomousDelegate (Service)

ServiceConsumer

ServiceMediator

ServiceProvider

MediatorAssertion

ServiceAssertion

UserInteraction

Rules Rules

Each Delegate has aspects of the three characteristics above: however,there is a dominant characteristic (purpose) which labels the Delegate type.

Page 9: Delegation of Intent via Conversation David E. Ellis

Trust among delegates• Stewardship is a concept of acceptance of the responsibility for

honoring the original resource owner intent when using a shared resource (service message, consumer identity, non-repudiation, credit card)

• Ownership boundary transition involves exchange of stewardship for a resource between two or more Social Structures

• Computational Trust is the degree of assurance that the resource owner has in the accepting delegate’s commitment to honor the resource stewardship across ownership boundaries of a social structure.

• The Computational Chain of Trust is the transitive aggregation of Computational Trust of a resource as it is communicated across ownership boundaries of social structures in accomplishing a specific service engagement.

Page 10: Delegation of Intent via Conversation David E. Ellis

Delegates have two types of interfaces

• There are two types of interfaces used by delegates. They are Asynchronous and Synchronous.

• Synchronous interfaces are established by delegates to wait for a specific response for a limited timeout period.– They exhibit blocking behavior during timeout period on the requesting

delegate. – They are usually associated with:

• Interactive delegates, or• highly orchestrated semi-autonomous delegates (ESBs).

• Asynchronous interfaces are established by delegates to wait for a less specific communications with no timeout period.– They do not exhibit blocking behavior on the listening delegate.– They are usually associated with:

• Choreographed adaptive or semi-autonomous delegates• They are often used by communications stacks to accept messages (.e.g. Service

interface) • Both types of interfaces are used in SOA ecosystems.

Page 11: Delegation of Intent via Conversation David E. Ellis

General Message Exchange • Consumer delegate expresses intent via conversation to delegate interface via

message(s)– Adaptive delegate could be Event notification (Pub/Sub) mediator or Composite Service with

one or more semi-Autonomous delegates which it mediates.– Semi-Autonomous delegate (simple request/response)

• Delegate performs and/or observes some type of service action. Service Actions could include:

– Observing immediate state of delegate (Eco-System)– Performing one or more action itself– Request other delegates to perform service actions– Waiting for another delegate to report event of interest to consumer.

• Delegate reports RWE and/or other information to Consumer delegate via conversation.

– Report message could be single response message (request response MEP) to synchronous interface (S) of consumer (tightly coupled).

– Report conversation could be series of messages during performance of service actions.This could be synchronous (S) and asynchronous (A) interface on the Consumer delegate.

– Report message could be single event notification message to synchronous (s) interface of the Consumer delegate.

Page 12: Delegation of Intent via Conversation David E. Ellis

Message Exchange Pattern

1

5

4

6

2

3

A

AA

S

The Request Response andEvent Notification MEPsare a subset of a generalConsumer to CompositeService message pattern .Where:The registerinterest message isa loosely coupled requestMsgwith the Event Broker and theConsumer delegate has apersistent asynchronouslistener interface.

In the MEP Figure:Messages 1 and 2 relay theintent of the Consumerdelegate. Operations 3 and Message 4performs or observes the actualRWE which has happened.Message 5 and 6 inform theconsumer of the actual RWEwhich might not be the intent.

A

Page 13: Delegation of Intent via Conversation David E. Ellis

GoalsObjectivesResponsibilitiesConstraints

1

GoalsObjectivesResponsibilitiesConstraints

2

Requires-understanding-identity 1 <-- > 2

Ownership Domain 2

1 2

Accountability

Ownership Domain 1

Intent

2 3

Accountability

Ownership Domain 2

Intent

Ownership Domain 3

GoalsObjectivesResponsibilitiesConstraints

1

Scalable SOA System of Systems

Each SOA Conversation exchanges Resources which have a Purpose (Goals/needs)and Policy (Objectives, Responsibilities and Constraints). This exchange sends Intentand returns acceptance of Accountability to enforce purpose and policy of exchange.Each Resource (e.g. identity, non-repudiation, Credit Card number) exchanged ineach conversation must be Atomic and Stateless.The subsequent Conversations are a composite of these original resources delegationof Goals, Objectives, Responsibility, and Constraints with the intervening DelegatesGoals, Objectives, Responsibility and Constraints from their Domains.

Requires-understanding-identity 1 <-- > 2

Page 14: Delegation of Intent via Conversation David E. Ellis

Unmet Consumer Needs Undesired Service RWE

Intersection ofService(s) RWEwith desired

Consumers RWE(Goals/Needs)

Each Intent conversation could lead to unattainable needs of requestor because of limited capability of delegate.This is even more pronounced in Composite Services.

Page 15: Delegation of Intent via Conversation David E. Ellis

Intent Delegation Methods

• The two common methods for delegating intent are Conversation and Encapsulation

• Unfortunately, Conversation is Point-to-Point, has specific graph-based legal policy outcomes, and often has state associated with delegated artifacts

• Encapsulation is not Point-to-Point, has ability to translate social structure specific policy assertions, and does not have state associated with delegated artifacts

• OASIS has developed both types of standards

Page 16: Delegation of Intent via Conversation David E. Ellis

OASIS Conversational Methods

• Here are examples of OASIS Conversational policy Standards– The Security Assertion Markup Language (SAML) defines the syntax and

processing semantics of assertions made about a subject by a system entity.– The eXtensible Access Control Markup Language (XACML) is a declarative

access control policy language implemented in XML and a processing model, describing how to interpret the policies.

– WS-Policy defines a framework for allowing web services to express their constraints and requirements as policy assertions.

– This Web Services Security a standard set of SOAP extensions that can be used when building secure Web services to implement message content integrity and confidentiality.

• Unfortunately, they do not cover all policy assertions needed and are just establishing ways of combining the expression of intent

Page 17: Delegation of Intent via Conversation David E. Ellis
Page 18: Delegation of Intent via Conversation David E. Ellis

OASIS Encapsulation Method

• The Emergency Data Exchange Language (EDXL) Distribution Element uses an Intent Encapsulation strategy which:– Uses role and keyword based ontological abstractions of policy– Provides an Open Container Model to enable dissemination of one or

more messages and/or policy assertions– Provides flexible mechanisms to inform message routing delegate

processes and/or processing of policy decisions by delegates.– Enable dissemination of messages based on geographic delivery area– Use and re-use of data content and models developed by other

standards and initiatives

• It allows for adapting or delivering all policy assertion needed and are now establishing ways to express intent

Page 19: Delegation of Intent via Conversation David E. Ellis
Page 20: Delegation of Intent via Conversation David E. Ellis

Policy Expression

• Policy Expression must have Subject, Action and Direct Object and Context.

• SOA RA Chapter Three establishes the criteria for:– Actor– Social Structure– Social Action– Role– Resource– Ownership– Commitment– Assertion

• These form the basis for defining Intent and Accountability delegation in a complex SOA Ecosystem

Page 21: Delegation of Intent via Conversation David E. Ellis

Actor Role in Message Exchange

Actor

Actor

Page 22: Delegation of Intent via Conversation David E. Ellis

Abstract EDXL-DE Policy Sentence Structure

Subject(SOA -> role; etc.EDLX –DE ->senderRole, recipientRole)

Direct Object(SOA -> anything EDXL –DE ->Keyword, etc.)

Intent Verbs (Send, Route, Process, Receive, etc.)

Page 23: Delegation of Intent via Conversation David E. Ellis

EDXL-DE Policy Stack Processes

June 2008 DRAFT

Sender Receiver

PolicyEncapsulation

PolicyEncapsulation

Page 24: Delegation of Intent via Conversation David E. Ellis

Actor (Role)

Producer(speaker)

Interactivedelegate

(application)

Actor (Role)

Consumer(Listener)

Semi-autonomous

delegate

Adaptivedelegate

(e.g. SPOR)

A C T D

Adaptivedelegate

(e.g. SPOR)

D T C A

Semi-autonomous

delegate

Social Structure A Social Structure B

Policy Enforcement PointCOI B Ownership Boundary

Intermediate Execution Context

Policy Enforcement PointCOI A Ownership Boundary

Intermediate Execution Context

MediatorNetwork

Delegation of AuthorityTo Mediation Network

Policy EnforcementAuthority Vector forOther Stakeholders

Execution Context for Mediated or Composite SOA Messaging