SOA Service in DM2 David E. Ellis

Joint Action (JA) SOA RAF Joint Action is the coordinated set of actions involving the efforts of two or more actors to achieve an effect  In DM2 it is a Subtype of DM2 Activity with definition: Joint Action is Cumulative Work, which can only results from the coordinated Activity of two or more performers. These performers are not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources). Joint Action Resource transformations may include change in place, time, state, & form of input Resources. They are allowed only upon receipt of the Execution Message and after all controls (e.g. Performer Intent and Execution Context) are established(need better verb for established).

SOA RAF Execution Context Execution Context: The agreements which encapsulate the necessary alignment form the basis upon which interactions may proceed – in the Reference Model, this collection of agreements and the necessary environmental support establish the execution context. While the execution context captures the conditions under which interaction can occur, it does not capture the specific service invocations that do occur in a specific interaction This definition is in progress and I do not have the most currently agreed upon definition.

IDEF0 Execution Context In DM2 terminology, Execution Context is the output of the Joint Action Rule Enforcement Activity when all rules (e.g. Ecosystem, Participant Role, etc.) required for the individual performers to accomplish their individual (public and/or private) activities required for a specific Joint Action attempt are satisfied or mutually agreed to be ignored. DM2 Execution Context is the Control for allowing the Joint Action to happen upon receipt of the Execution Message.

Alex briefing - formal concepts of behavior1 somewhat informally presented… It ain’t interesting unless something happens A behavior (or any of its sectarian variants: activity, process, function, task, …) is a transformation of something into something else. No transformation: nuthin’ happened. Boring… We’ve got 4 sorts of possible transformation: place, time, state, & form Consequently, we can say some decisive things about architecturally interesting behaviors: They start. They stop. They stop after they start. There is some interval between starting and stopping. A behavior finishes in finite time. Ergo, we have some more concrete things we can say: An output must be observable An input must be observable Which leads to: Input gets transformed into output. Furthermore: All input gets transformed into output Only input gets transformed into output

Alex Briefing - formal concepts of behavior2 somewhat informally presented… Conversely: Output gets transformed from input All output gets transformed from input Only output gets transformed from input. Note: there are certain caveats to these stipulations: Ontologically: Creative acts Representation of input & output in modeling artifacts These observations constrain what architectural concepts of behavior may be interesting for organizational or management purposes: If you can see what goes in… And you can see what comes out… Which, by the way, means you can also see how long it took… Then (and only then) can you manage the behavior! If you can’t see both gazintas and gazoutas, then you can’t measure it… Then you can’t figure out the production function: output = f( input, …) Which means you can’t manage it because you don’t grasp essential relationships between gazintas and gazoutas… You can’t manage it because you are seeing a random (perhaps chaotic) process The behavior probably isn’t really random, but since you can’t see what you might do to control the behavior, it might as well be…

Joint Action - Initiation/End When a performer with a need begins interaction with a performer with the capability to potentially meet the need, the “start” of the Joint Action attempt begins. When all performers of the Joint Action have either (1) evidence of their respective Joint Action output Resource, or (2) evidence of Lack of Intent and/or Willingness of other performers is determined (e.g. irresolvable conflict of other Performer rule, failure to reply to clarification message request, or timeout of interaction infrastructure), the “stop” of the Joint Action attempt ends. There is no expectation of actually meeting the need until Execution Context interactions are complete and an Execution Message is communicated.

JA Execution Context Activities There are numerous methods for meeting the aggregate rules for a particular class of Joint Action Pre-Arranged Service Contract (all performers have prior agreement [execution context] and only need execution order needed to perform JA. Fast food model. Execution Context activities accomplished at first window and Joint Action activity completed at second window. SOA Model. Service Discovery and Description give details for starting JA interactions and subsequent Execution Context activities (choreography) are negotiated via messages. (establishment of infrastructure transmission path [SSL] is often an initial part of execution context activities – ecosystem rule) Execution Context Mediator (ESB’s) perform some Per-Arranged and abstraction of choreography activities to minimize number of messages. Secure Policy-oriented Object Routers (SPORs) provide each performer with a method of creating a single XML document (control-bundled input) which not only includes the Execution Message but all information about roles and rules need to adjudicate the Execution Context of both Sender and Receiver. Execution Context Activities vary based on the particular interaction infrastructure used to accomplish the Joint Action.

DM2 - More Definitions Resource used during Joint Action tuple: Association of a Resource used by Performer during attempt to accomplish the Joint Action. Performers contribution of Resources for Joint Action tuple: Association of a Performer to a resource provided by the Performer for use during the attempt to accomplish the Joint Action. The Pairing of performer Resources provides for the establishment of the transmission path for interaction messages for Execution Context and Joint Action.

Rescue Service Description What Resources provided by Service to Victim Rescue equipment and personnel Radio, Telephone and Network notification Paths What Joint Action(s) promised After Notification, Service will attempt Rescue What Willingness Criteria required Promise of Availability from 9-5 Monday thru Friday Promise of Rescue Dispatcher listening to transmission Resource during Working hours