[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Disambiguating Action (Part I)
-------- Original Message --------
Subject: Re: [soa-rm-ra] Disambiguating Action (Part I)
From: Francis McCabe <frankmccabe@mac.com>
Date: Sun, May 25, 2008 7:30 pm
To: Ken Laskey <klaskey@mitre.org>
Cc: michael.poulin@uk.fid-intl.com, soa-rm-ra@lists.oasis-open.org
I guess that I risk sounding a little like a broken record. Comments
etc inline.
On May 25, 2008, at 5:27 PM, Ken Laskey wrote:
> some responses below. Hope these provide more clarity than confusion.
>
> Ken
>
> On May 25, 2008, at 1:50 PM, michael.poulin@uk.fid-intl.com wrote:
>
>> Jeff and Ken,
>>
>> playing a role of an outsider, I can say that my confusion comes
>> from the multiple adjectives of Action in RA.
>>
>> If I follow Kens interpretation, stating that the Action is
>> somewhat the same as the WSDL operation, then Action against
>> service is somewhat the same as calling WSDL operation, right?
>>
>> For Web Services, the aforementioned statement is enough to say
>> about interaction between Participant-consumer and the service.
>> However, for a SOA service it is far from enough. Here is the
>> reason: Action against service and service Action relate to each
>> other as 1:N, where N=0..M (many). That is, an Action against
>> service may result in no service actions, or in one, or in more
>> than one Actions.
>
> The consumer sends a message to invoke an Action for the purpose of
> realizing RWE. If the message is malformed, the Action SHOULD
> respond with a fault. If the message is appropriately processed,
> the consumer can expect the identified RWE or faults describing why
> the RWE were not realized.
No problem with this. Except, that in some circumstances (e.g. in
responding to a DoS attack), I could see that no response is also
legitimate in cases of badly formed messages.
>
>>
>> If you agree with this, then Capability is associated rather with
>> the service Action than with the Action against service.
>
> The consumer sends an appropriate message to invoke the service
> Action. The service, and this Action in particular, SHOULD result
> in to RWE being realized as the result of the Capability which the
> service accesses.
This is where I have heartburn. It sounds like an RMI call, and I
thought that we were over that.
David E's scenario of event propagation does not naturally fit with
'invoking' a service action. A propagated alert should be dealt with
primarily by further propagation.
From a service consumer's perspective, the act of successfully
sending a message counts as an attempt to perform the action against
the service. From the service provider's perspective, the system has
to validate the message, and then figure out what the consequences of
that action are. This is the kind of language needed to stay in the
realm of public semantics.
>
>> Service Capability exists w/o Action against service and w/o Intent.
>
> The underlying capability exists independent of the service. The
> functionality of the service depends on what functionality of the
> capability (or some combination of capabilities) that the service
> accesses. I do not use the term service capability.
>
Definitely agree. This was stressed over and over in the RM
>
>> The Capability is described in the Service Description and cascaded
>> into Service Contract (mostly for the business services).
>
> No, the service is described in the service description, but a
> cascading from the capability description may be an effective way of
> assembling the service description. I do not use service contract
> to in any way mean service description because I find such
> references unclear and misleading.
>
Also agree completely.
>>
>> BTW, can a Capability exist w/o a service?
>
> Per the RM, most definitely.
>
>> What hosts Capability in SOA eco-system if it is not a service?
>
> Service is the access to the capability. We do not restrict the
> implementation, such as the details of hosting, of the capability.
>>
>> Service has Functions (not necessary WSDL operations) which
>> collectively constitute Capability, i.e. Functions realize
>> Capability.
>
> No. The functionality of a service relates to the business services
> it supports.
I agree with this. But, I find it hard -- using the language of WSDL
and RMI -- to capture the notion of business services or business
functionality. Examples such as temperature conversion services are
especially off the point here I think. A business entity that decides
to expose a service will only do so if there are clear business
reasons for doing so. (In a world of rational business people anyway:-)
On the other hand, the language of social facts etc. *can* (in my
opinion) capture business functionality. I.e., we are talking about
effecting social facts, entering into commitments, changing the world
and so on. I think that so long as one's nose is in WSDL one cannot
adequately see business functionality.
> The capability (or some combination of capabilities) enables the
> realization of the desired RWE, and the service provides the access
> to this capability. As stated above, the capability exists
> independent of SOA, but we believe SOA enables a more powerful means
> of access.
I think that there are at least two notions of capability. The
'public' capability is directly expressed via the service. I.e., I use
a service to get things done, to do things to people. As a user of a
service, the capability I am interested in is the one documented in
the description. The other notion of capability is that that enables a
service provider to fulfill the promises made in the description.
I have a real issue with tying RWE to the internal machinery of a
service.
Consider an airline flight booking service. I can ask the service to
book me a flight -- that is a capability that is offered by the
service. When I use the book action, then I am booking a flight. The
book action is part of the expressed capability of the service.
The fact that in order for that to work the airline has to have banks
of servers, databases, ESBs etc. etc. so that it can honor the
guarantee of a seat on a plane does not substitute for the RWE of the
book seat action.
>
>> Each Function may or may not associate with service Actions and
>> Events (or be implemented by).
>
> It may be a combinations of Actions, where the combination is
> specified by the Process Model, that results in the service
> functionality and the set of RWE.
>
>> Collective execution of service Actions and Events produce real
>> world effect (RWE).
>
> You might say execution of Actions produce RWE, but Events are
> merely the reporting of RWE to interested parties.
>
>> The RWE cannot exist w/o Capability
>
> true
>
>> and A set of Actions-Events
>
> No, it may be possible to invoke the capability through means other
> than SOA services.
Although true, this is also outside our area of concern (a.k.a. remit)
>
>> ; Action against service and Intent are needed to generate RWE.
>
> If SOA service is used to access the capability, then Action is
> required. Intent is not required but assumed.
This is right. But, trust sticks its nose in here: if we cannot trust
the intent of a service participant, then we may not honor the actions
of the participant.
>
>>
>> Plus, we may have different RWE produced by the same service in
>> different execution context (EC).
>
> This is possible if, for example, the applicable policies are
> different. For example, if one EC requires privacy of my personal
> information and another EC does not have this restriction, then the
> second EC may result in my personal information being sold to a
> third party.
This is true for any software system of any significance.
>
>> This is based on suggestion that while service Capability and
>> Functions stay the same in different EC, the service Actions and
>> Events may differ.
>
> With the exception of the term service capability, this is basically
> accurate.
>>
>> Here is an example with a Cleaning shop. The cloth cleaning is the
>> Capability.
>
> Well, cleaning certain items is the capability and use of the
> cleaning cloth is an implementation detail.
>
>> Cleaning may be done as wet or dry, it may be for white only or for
>> colorful cloth these are the Functions (Functionality).
>
> The functionality is more likely that I can effectively clean
> certain items. Again, the details of how I do it are likely private.
>
>> Cleaning process, ironing and wrapping are Actions.
>
> They may or may not be separate actions. If they are separate
> things I can request, they may be implemented as separate actions.
> If they are separate steps in a total process, they may be separate
> actions and the process model may specify how these are combined,
> but the separate actions may not be typically invokes separately by
> a consumer.
>
>> In one country, when you order a cleaning, you assume that the
>> cloth would be ironed also. In another country, ironing has to be
>> explicitly requested. Thus, the same Action against service results
>> in different service Actions depending on the EC (country).
>
> Likely variations in the process model and which variation may
> depend on country.
>>
>> - Michael
>>
>>
>>
>>
>> Subject: Re: [soa-rm-ra] Disambiguating Action (Part I)
>> From: Ken Laskey <klaskey@mitre.org>
>> To: "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
>> Date: Sun, 25 May 2008 07:53:58 -0400
>>
>> Jeff,
>>
>> A nice layout of the problem.
>>
>> I'll need to work on all the questions later but let me add what I
>> meant by Capability when I contributed to and have since explained
>> the RM, and where I thought things fit together when contributing
>> to the RA.
>>
>> There are 59 occurrences of capability (singular or plural) in the
>> RM. Over half occur in section 2.1: the first is the definition of
>> SOA:
>>
>> Service Oriented Architecture (SOA) is a paradigm for organizing
>> and utilizing distributed capabilities that may be under the
>> control of different ownership domains.
>>
>> This is immediately followed by
>>
>> In general, entities (people and organizations) create capabilities
>> to solve or support a solution for the problems they face in the
>> course of their business.
>>
>> The RM was careful to avoid using the term service to define SOA
>> when service itself hadn't been defined, so this discussion occurs
>> before any mention of service. After that, service is informally
>> defined (the formal definition is in section 3) through
>>
>> These concepts emphasize a distinction between a capability and the
>> ability to bring that capability to bear. While both needs and
>> capabilities exist independently of SOA, in SOA, services are the
>> mechanism by which needs and capabilities are brought together.
>>
>> This is where I sometimes use the term "underlying capability".
>> The capability exists outside of SOA and is part of the black box
>> through which certain RWE can be made to happen; the service tells
>> the capability to do (some subset of) its stuff.
>>
>> Functionality is the general description of what "business service"
>> is accomplished by using the capability or the service that
>> accesses it. In an earlier email, I said (for our current
>> endeavor) I didn't care what functionality was possible from a
>> capability; the important thing was the functionality that a
>> service accessing the capability could deliver. If I combined a
>> number of underlying capabilities to form a service, it is the
>> combined functionality with which I am concerned.
>>
>> The real world effects are the specific things that happen when I
>> use a capability or a service. Again, I am not interested in the
>> RWE of the capability, only those RWE accessible through the
>> service. For the RM, Frank introduced the concept of RWE as the
>> accumulation of changes to shared state, and we expanded this to
>> include an information response to something like an HTTP GET where
>> there was no obvious state change.
>>
>> As you noted, Action is not defined in the RM, but we talk about
>> "invoking a service" or "actions being invoked against a service".
>> There was no intent to use the term invoke to make explicit
>> connections with distributed computing models; again, we chose a
>> term from an already overloaded English language.
>>
>> So that's where we stand going into the RA.
>>
>> Now when I come along for the RA and try to start writing about
>> service description, I need to figure out how some of these pieces
>> work; otherwise, I don't know what information I need to convey to
>> actually use those pieces. I also want to make the point that
>> service description is not a random collection of documentation but
>> is actually an indispensable compendium of critical information
>> needed to use a service. To do that, I need to connect the pieces,
>> and that's why I draw together the leaf nodes in the artifact in
>> Figure 20 and connect these in Figure 26 to what I saw as the
>> unifying concept: the Action.
>>
>> Now my interpretation when writing this was that Action was
>> somewhat the same (allow me to be fuzzy here) as the WSDL
>> operation. An Action is initiated by receiving a message at the
>> identified endpoint, using the identified protocol, carrying the
>> necessary information corresponding to the the identified structure
>> and semantics, and conforming to identified policies and contracts
>> when realizing the identified RWE.
>>
>> Is this inconsistent with the "application of intent"? Not
>> necessarily because Action as I used it is the bringing together of
>> pieces that enables you to actually apply the intent. Or at least
>> I can look at it that way.
>>
>> As for the visual model in Figure 10, it is missing a connection
>> between Intent and Action. I would say the Participant has a Goal
>> (not currently in model) that is committed to through Intent, and
>> Intent is applied through Action. Additionally, the Participant
>> employs an Agent to perform Action as currently shown, but I
>> wouldn't has a connection between Intent and RWE.
>>
>> I'll put off working through the various roles of Participant until
>> later.
>>
>> Ken
>>
>>
>> P.S. As a quick aside: when actually solving a problem, I am more
>> interested in the available capabilities than I am in the service.
>> I want to be able to get things done, and the fact that some SOA
>> service can provide access to the capability may have a decisive
>> effect on how I construct my solution, but I can't do anything
>> unless I can make use of the appropriate capabilities. One of my
>> problems with service registries is I think they are emphasizing
>> the wrong part of the solution.
>>
>> On May 23, 2008, at 2:03 PM, Jeffrey A. Estefan wrote:
>>
>>
>> OK Folks,
>>
>> The hot topic of the day is "Action." Here is my initial (Part I)
>> attempt based on interpretation of the content described in the RM
>> v1.0 Std and the RA v1.0 PRD1 and mapped to one of the simplest
>> examples of a service offering, the classic temperature conversion
>> service. I do not propose to have all the answers here. Where
>> there are open questions, I will note them with the hope that these
>> questions will spur conversation from the RA editors and SC members
>> who have been actively engaged in discussion surrounding this
>> topic. I encourage you to read through the entire note before
>> responding to the individual open questions summarized below.
>>
>> So let's get started...
>>
>> Believe it or not, in the RM, we use the word "action" ten times
>> and the plural "actions" twenty-seven times, yet we never actually
>> defined what action is. We introduced the notion of an Action
>> Model and defined it to be "the characterization of permissible
>> actions that may be invoked against the service," but never
>> action. We were very careful about distinguishing between "private
>> action" from "public action," but again, we did not define action.
>> This is why it was important for us to do so in the RA. Indeed,
>> Frank did so on lines 754-755 of the RA PRD1. Here, Action is
>> defined as "the application of intent by a participant (or agent)
>> to achieve a real world effect." We'll come back to this
>> definition and its associated models in a bit, but first, let's
>> elaborate more on the Action Model.
>>
>> For a simple temperature conversion service that has the capability
>> of converting degree expressed in Fahrenheit units to degree
>> expressed in Celsius (centigrade) and vice versa. The service's
>> functions are two: 1) given a numeric value that represents degree
>> Fahrenheit, return a numeric value that represents degree Celsius,
>> 2) given a number value that represents degree Celsius, return a
>> numeric value that represents degree Fahrenheit. Simple enough,
>> right? So what is the Action Model for this service? From a
>> implementation technology point of view, this service could be
>> implemented using a distributed object computing model, which
>> exposes two operations that represent the two functions described
>> above. For the sake of this discussion, it does not matter whether
>> that technology is Java RMI, CORBA, Jini, .NET, COM+, DCOM,
>> Openwings, XML Web services, or some other distributed object
>> computing technology. It's just that in order to realize this
>> service, at least in today's world, it's likely to a variant of a
>> distributed object computing model that exposes remote operations
>> (functions) that the consumer can invoke.
>>
>> So again I ask, what is the Action Model for this service? Well,
>> it has to be a description of those two functions, right? The
>> reason I am making this point is because of the operative word
>> "invoke" in our definition of Action Model. This leads to the
>> question of functions versus "characterization of the permissible
>> actions that may be invoked against the service," which, of course,
>> defines the Action Model. We don't spend a lot of time talking
>> about functions in the RM with the exception of Service
>> Functionality, which is part of the Service Description artifact.
>> On lines 602-603 of the RM, the sentence reads "A service
>> description SHOULD unambiguously express the function(s) of the
>> service and the real world effects (see Section 3.2.3) that result
>> from it being invoked." But that also sounds like Capability. So
>> as you can see, we've already introduced some ambiguity in our
>> model that we need to resolve. How do we distinguish between
>> functions (or functionality) and capabilities (or capability) and
>> permissible actions (or Action Model)? Do the permissible actions
>> correspond to operations? Or is that an implementation detail? I
>> suspect the latter, and why the RM was wise in using "action"
>> instead of "operation."
>>
>> Now let's return to the RA in which Action is finally defined. For
>> this discussion, I am referencing the material described in Section
>> 3.5.1 Actions, Real World Effects and Events. As noted earlier,
>> this is the Section in which I feel Frank has done a fairly nice
>> job in defining what Action really is, which is "the application of
>> intent by a participant (or agent) to achieve a real world
>> effect." That seems reasonable enough. Now, let's explore the
>> visual model shown in Fig. 10 (line 766). This model depicts the
>> relationships between key concepts such as Action, Intent, Event,
>> and Real World Effect. Well, we know from the RM that the Real
>> World Effect (RWE) is the actual result of using a service (as
>> opposed to the capability being offered). On lines 767-769 of the
>> RA PRD1, Frank introduces yet another definition of RWE and to be
>> honest, I don't think we should do that. In fact, in the RA, we
>> should not create new definitions of core RM concepts at all. We
>> should only define terms like Action that were not specified in the
>> RM. But I digress. We should capture this point in our issues
>> spreadsheet. What is more important here is to disambiguate the
>> model depicted in Fig. 10.
>>
>> Here, Participant is used. But we know from the Stakeholders and
>> Participants Model of the RA (Section 3.1) that a Participant can
>> be a Service Consumer, Mediator (third party), or Service
>> Consumer. If we were to replace Participant with say Service
>> Provider in Fig. 10, does the model still work? And where does the
>> Service itself fit into the model? If indeed Participant were
>> Service Provider, one could envision the Agent to be the Service.
>> Is this a fair assumption Frank? Open question. And what would
>> this mean in terms of Event? Would a Service Provider care about
>> events? The only scenario I see that happening is in a V&V
>> scenario. In other words, the Service Provider or some entity
>> (person or organization) working on behalf of the Service Provider
>> is engaged in testing the Service prior to exposing its
>> capabilities to the world. Here, the Service Provider or
>> supporting entity would actually be acting in the role of Service
>> Consumer (for testing purposes) and Events could be relevant.
>> Again, open question to Frank.
>>
>> Now, if we were to assume the Participant is a Service Consumer (or
>> Mediator), does the model still work? Kind of. Where I think it
>> breaks down is, again, on Action. What action does the Service
>> Consumer perform? Is it sending a message? Well, we don't get
>> into that here. And does just sending a message (which can
>> certainly be consider an action initiated by the Consumer) cause
>> the RWE to occur? Certainly just sending a message cannot. It is
>> the actions performed by the Service Provider Agent (i.e., the
>> Service) that are invoked as a result of the Service Consumer Agent
>> sending the appropriate message that leads to a RWE. So now the
>> argument for Joint Action starts to become clearer (we think!).
>> But I will defer the discussion surrounding Joint Action until next
>> time. For now, let's see if we can resolve some of the potential
>> ambiguities w.r.t. the Fig. 10 visual model I just described.
>>
>> Summary of open questions and gut responses (looking for yours!):
>>
>> 1) How do we distinguish between Capability (or Capabilities),
>> Functionality (or Functions), and Action Model (permissible Actions)?
>>
>> For me, at least, it seems that Capability is at a higher level of
>> abstraction than Functionality. Capability could be described in
>> natural language text that is part of summary description of the
>> service, contained, of course, in its Service Description artifact,
>> which could be included as a service registry-repository entry. In
>> terms of the simple temperature conversion service described above,
>> Capability could be a simple brief description of what the service
>> does without getting into the specifics of the underlying
>> functions. As with Capability, Functionality could be described in
>> natural language text that is part of the Service Description
>> artifact. In terms of the simple temperature conversion service
>> described above, Functionality would be a bit more granular and
>> would describe the two functions that the service offers; one from
>> degree Fahrenheit to degree Celsius and the other from degree
>> Celsius to degree Fahrenheit.
>>
>> The Action Model (permissible actions) is very similar to
>> Functionality (functions) except that the description of the
>> permissible actions is intended for consumption by humans and non-
>> human agents as part of the Service Interface, which is a critical
>> component required at design time. An example of a design time
>> scenario is the following: A human(s) uses the Action Model
>> described in the Service Interface to construct code that would
>> invoke the actions exposed by the Service. From an implementation
>> perspective, these actions would likely correspond to invocations
>> on remote operations. We do not make the connection between Action
>> Model and Service Interface very clear in the RM with the exception
>> of drawing a simple directed line from Behavior Model to Service
>> Interface in Fig. 9 (line 565). I did not see evidence of any
>> text in the RM that supports this linkage, which is OK except that
>> it leaves open some ambiguity.
>>
>> What is not yet clear, is what role the Action Model has at run
>> time (Interaction). Perhaps none! Maybe this is the point Frank
>> is trying to make in distinguishing Action (which is not the same
>> thing as Action Model) from Joint Action and Communicative Action,
>> described in Sects 3.5.3 and 3.5.4 of the RA PRD1. That said, I'd
>> prefer we defer that discussion until Part II if we can.
>>
>> 2) Does the visual model depicted in Fig. 10 of the RA PRD1 (line
>> 766) hold up for different types of Participants, i.e., Service
>> Consumer, Mediator, and Service Provider? How does Event play out
>> in a Service Provider Participant role?
>>
>> I do not have a gut response to this open question. Please see my
>> earlier discussion notes around this topic.
>>
>> 3) What is the role of the Service, currently not depicted in the
>> model of Fig. 10. nor described in the supporting text? From the
>> Service Provider perspective, is it the Service Provider Agent that
>> represents the Service?
>>
>> I do not have a gut response to this open question. Please see my
>> earlier discussion notes around this topic.
>>
>> Next time, I'd like to focus on Joint Action and how it relates to
>> Interaction. And the role of messages and message exchange to
>> Action. Maybe the latter will be a Part III discussion, we'll see.
>>
>> Hoping for a spirited discussion that will hopefully converge on
>> disambiguating Action for not only us but for our readers at-large!
>>
>> Regards...
>>
>> - Jeff E., JPL
>>
>>
>> -----------------------------------------------------------------------------
>> Ken Laskey
>> MITRE Corporation, M/S H305 phone: 703-983-7934
>> 7515 Colshire Drive fax: 703-983-1379
>> McLean VA 22102-7508
>>
>>
>>
>>
>>
>
> -----------------------------------------------------------------------------
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-983-7934
> 7515 Colshire Drive fax: 703-983-1379
> McLean VA 22102-7508
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]