Re: [soa-rm-ra] Thin vs Thick

[Ken Laskey <klaskey@mitre.org>]

Frank,

I got lost in the details of your stack but I pretty much agree with  
everything up to that.

I think the thick vs. thin confusion comes from the fact that things  
are indeed fractal and many discussions conflate levels that should  
remain separate.  So from the perspective of a consumer wanting to use  
a service, the consumer sends an appropriate message to the service  
and expects the advertised RWE to occur.  Our debate has been whether  
the action is the message or what the service does in response to the  
message, but from the consumer perspective that is irrelevant as long  
as the RWE is what was expected.

Now Dave Ellis usually pops in here to say it's important to follow  
the message because he needs intermediaries to authenticate the  
consumer and check the validity or other aspects of the message.  Dave  
is sometimes a developer and sometimes a consumer of service  
composition that is opaque to the original consumer.  From Dave's  
perspective, he sees necessary actions among the services in the  
composition but these actions should follow all the explanations we  
put together with that higher-level consumer in mind -- at least that  
is the going in assumption.  This is the fractal nature.  So when I  
try to strangle Dave, it is not because his concerns are invalid but  
because they aren't relevant at the higher level.  I'm sure we could  
also find a level that is more nitty gritty than Dave and he would be  
uninterested in the particulars there.

So the important point is to keep a constant level of granularity when  
looking to explain something.  What level of detail is important to a  
given set of participants?  What details may be important but are  
merely minutiae?  Then we can test whether those explanations also  
work for other levels of granularity for other participants, but we  
don't do all the levels at the same time.

We have demonstrated that madness lies in that direction.

Ken

On Jul 23, 2008, at 4:05 PM, Francis McCabe wrote:

> The RM defines service as:
>
> A service is a mechanism to enable access to one or more  
> capabilities, where the access is
> provided using a prescribed interface and is exercised consistent  
> with constraints and policies as
> specified by the service description.
>
> The RM does not define the concept of participant, and is explicitly  
> vague about service consumers and service providers.
>
> (In fact, one could argue that the correct title for the RM should  
> have been "Reference Model for Service"; rather than Service  
> Oriented Architecture.)
>
> We have a different job, in particular, we have to gain clarity on  
> the relationship between participants and services. This is one of  
> the key responsibilities of the Service as Ecosystem view.
>
> In the service (sic) of that clarity, we introduce the concepts  
> involved in capturing the fact that participants are acting in the  
> context of a SOA.
>
> Looked at from the perspective of a participant, it seems clear to  
> me at any rate, the key idea is that a SOA presents the participant  
> with a bunch of levers that can be manipulated in order to 'get  
> things done'. More specifically, most of the levers involve  
> (business) relationships that I may have with other participants and  
> transactions that I wish to execute with those participants.
>
> There is some uniformity to those levers: they have descriptions and  
> mode of operation of those levers is based on communication. This is  
> like saying that all the active elements of a UI are presented as  
> buttons, and each button has a label and a tooltip. The uniformity  
> is key to *realizing* and *using* a SOA-based system but does not  
> materially affect *what* participants are trying to do.
>
> So, again from the perspective of a participant, the participant can  
> be seen as *using* the SOA-based system to get things done. Using a  
> SOA-based system means *acting* against services or *providing*  
> services (or some other combination such as *mediating* services).
>
> I believe that if you start from this perspective, then you have to  
> explain a couple of things: what does it mean to *act* against a  
> service, and how do you use communication to do so. This is quite  
> difficult to disentangle, especially when you consider the fractal  
> nature of everything; and even sending a message can be viewed as a  
> kind of action.
>
> We must also remember to capture the relationship aspect as well as  
> the transactional aspect. This is where the *social structure*,  
> *role*, *right* and *responsibility* show up.
>
> One way of doing all of this is to take a foundational approach: we  
> build up layers that each address different aspects.
>
> One such stack within the Ecosystem viewpoint could look like this:
>
> Layer 0.a: Action, Actor, RWE
>
> Layer 0.b: Participant, Agent, Stakeholder
>
> Layer 1.a: Joint Action, Communicative Action
>
> Layer 1.b: Social Structure, Social Action, Social Fact,  
> Ownership(Resource)
>
> Layer 2: Service Action, Transaction
>
> Layer 3: Role, Rights, Responsibilities, Governance
>
> (This stack is offered as a guide: I have no special investment in  
> it.)
>
> So, to address the thick vs thin question. I am arguing that the  
> question of whether service is thick or thin depends on your  
> viewpoint. From the perspective of a participant, it seems pretty  
> thin - it is a means by which the participant's actions are  
> mediated. From the perspective of realizing, offering and discovery  
> it seems pretty thick.
>
> This is one reason why we have multiple viewpoints :)
>
> Frank
>
>
>

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508

smime.p7s