Delegation of Intent via Conversation David E. Ellis

The two types of Actors Delegate

Actor Exchange Actions Collection of Communication Action is a Conversation

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

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)

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.

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)

Interactive Delegate Adaptive Delegate Semi-Autonomous Delegate (Service) Service Consumer Service Mediator Service Provider Mediator Assertion Service Assertion User Interaction Rules Each Delegate has aspects of the three characteristics above: however, there is a dominant characteristic (purpose) which labels the Delegate type.

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.

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.

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.

Message Exchange Pattern A A A S The Request Response and Event Notification MEPs are a subset of a general Consumer to Composite Service message pattern. Where: The registerinterest message is a loosely coupled requestMsg with the Event Broker and the Consumer delegate has a persistent asynchronous listener interface. In the MEP Figure: Messages 1 and 2 relay the intent of the Consumer delegate. Operations 3 and Message 4 performs or observes the actual RWE which has happened. Message 5 and 6 inform the consumer of the actual RWE which might not be the intent. A

Goals Objectives Responsibilities Constraints 1 Goals Objectives Responsibilities Constraints 2 Requires -understanding -identity 1 2 Ownership Domain 2 12 Accountability Ownership Domain 1 Intent 23 Accountability Ownership Domain 2 Intent Ownership Domain 3 Goals Objectives Responsibilities Constraints 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 Intent and returns acceptance of Accountability to enforce purpose and policy of exchange. Each Resource (e.g. identity, non-repudiation, Credit Card number) exchanged in each conversation must be Atomic and Stateless. The subsequent Conversations are a composite of these original resources delegation of Goals, Objectives, Responsibility, and Constraints with the intervening Delegates Goals, Objectives, Responsibility and Constraints from their Domains. Requires -understanding -identity 1 2

Unmet Consumer NeedsUndesired Service RWE Intersection of Service(s) RWE with 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.

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

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

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

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

Actor Role in Message Exchange Actor

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

EDXL-DE Policy Stack Processes June 2008DRAFT SenderReceiver Policy Encapsulation

Actor (Role) Producer (speaker) Interactive delegate (application) Actor (Role) Consumer (Listener) Semi- autonomous delegate Adaptive delegate (e.g. SPOR) A C T D Adaptive delegate (e.g. SPOR) D T C A Semi- autonomous delegate Social Structure ASocial Structure B Policy Enforcement Point COI B Ownership Boundary Intermediate Execution Context Policy Enforcement Point COI A Ownership Boundary Intermediate Execution Context Mediator Network Delegation of Authority To Mediation Network Policy Enforcement Authority Vector for Other Stakeholders Execution Context for Mediated or Composite SOA Messaging