OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm-ra] revised section 4.3


Service opacity should not lead to conclusion that RAF address only comminication related actions and activities - here is no opacity if it does focus on comminication only.

- Michael

 

----- Original Message -----

From: Lublinsky, Boris

Sent: 01/23/12 02:13 PM

To: Mike Poulin, Peter F Brown, Rex Brooks

Subject: RE: [soa-rm-ra] revised section 4.3


Oh, what about the notion of service opacity?

 

 

includes actions not only in _between_ consumer and service but also the actions inside each of them with regard to the inter-action.

 

 

 

 

 

 

 

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Monday, January 23, 2012 6:52 AM
To: Peter F Brown; Rex Brooks
Cc: Ken Laskey; jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] revised section 4.3

 

 

 

 

 

Peter,

I like the idea of Activity (via included Joint Actions) can cross the ownership boundary. Actually, the Figure 2 in your sketch finally confirms what I tried to expain  for a quite long time already - service inter-action(activity?) includes actions not only in _between_ consumer and service but also the actions inside each of them with regard to the inter-action.

 

 


Cheers,
- Michael

 

 

 

----- Original Message -----

 

 

From: Peter F Brown

 

 

Sent: 01/23/12 05:47 AM

 

 

To: Mike Poulin, Rex Brooks

 

 

Subject: RE: [soa-rm-ra] revised section 4.3

 

 

 

 

 

Michael,

 

 

 

 

 

 

 

 

I understand the concern – would the following proposed intro to 3.2.3 make the issue crystal clear? That it is an Activity that spans an ownership boundary – a “joint action” that is of interest to us…..

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cheers,

 

 

 

 

 

 

 

 

Peter

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter F Brown

 

 

 

 

 

 

 

 

Independent Consultant

 

 

 

 

 

 

 

 

www.peterfbrown.com

 

 

 

 

 

 

 

 

P.O. Box 49719, Los Angeles, CA 90049, USA

 

 

 

 

 

 

 

 

Tel: +1.310.694.2278

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Wednesday, 18 January, 2012 15:23
To: Peter F Brown; Rex Brooks
Cc: Ken Laskey; jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] revised section 4.3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter,
 unfortunately, I still do not see a need in (or a gap without) introduction of Activity (over the Action). Probably, I missed something but (I hope) it would be easier for all to have a clear reason of why we need it in RAF.

- Michael

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

----- Original Message -----

 

 

 

 

 

 

 

 

From: Peter F Brown

 

 

 

 

 

 

 

 

Sent: 01/18/12 07:45 PM

 

 

 

 

 

 

 

 

To: Rex Brooks, Michael Poulin (mpoulin@usa.com)

 

 

 

 

 

 

 

 

Subject: RE: [soa-rm-ra] revised section 4.3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Rex, Michael

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I fully understand both your concerns – let me see if I can address them:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

We state in Section 1.3.2 that “Normative UML is used unless otherwise stated but it should be noted that it can only partially describe the concepts in each model - it is important to read the text in order to gain a more complete understanding of the concepts being described in each section.”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Yes, I have used the ‘normative’ UML construct for ‘Actor’ while trying to fit its use, by us, in the ‘realm’ of the system and not extend it to the ‘only-human’ world of the social structure and ecosystem, where I stick to using ‘Participant’ and ‘Person’ as appropriate.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I admit there is one potential problem and cause of confusion, if we stick to the following train of logic:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-          IF the UML construct ‘Actor’ is used, in canonical UML, to represent any role that a user can play with regard to a system;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-          And IF our concepts of ‘ecosystem’ and ‘social structure’ could be understood and modelled as UML systems (Zoran Milosevic’s comment and interpretation of RM-ODP);

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-          THEN, the UML construct ‘Actor’ would also apply to other roles played by people wrt the ecosystem and social structures (notably ‘Participant’ and ‘Stakeholder’)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Technically that is correct but I don’t think that this interpretation, if applied, would ‘break’ our model. In the new diagrams I have been very careful and explicitly sought to avoid modelling ‘Participant is-a Stakeholder AND is-a Actor’ (former figure 4).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I’m not sure I understand the reference to “blue man diagram”, so I’m assuming it refers to the UML Use Case diagram (figure 6) on line 726 of the 20120117 edition. I’d be happy for someone to make this canonical, if it isn’t – I had intended that it was. It contains Actors (understood very widely), Use Cases and a main flow of events consistent with the text that follows. In the caption I also state that “each role is represented using the UML stick figure for an actor”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Michael is right that in my fig 5, “Actor does not contribute (via feedback) into the social structure” – but, it never did. The relationship previously was modelled as “a Participant contributes to a Social Structure”. I have that modelled now as “Person contributes to social structure” (Participation is the role that the Person plays in that relationship). ‘Actor’ is still modelled as a class, albeit an ‘association class’ (although not clear in the sketch) defining the role played by a Person in any Action – which I think is correct.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The problem arises because I have used the UML stick-figure in Fig. 6 to model different ‘things’ (Analyst, Service Owner, Service Provider, Service Consumer and Stakeholder), all of which in UML are Actors. The easiest way to solve this would be to remove <<person>>Stakeholder from the left-hand side of the diagram – I had only modelled Stakeholder and Consumer separately to distinguish between the system-level actor (Service Consumer) and the real-world flesh-and-blood stakeholder (expressing needs and seeing them fulfilled) but it wouldn’t kill the model to remove Stakeholder and use only Consumer on the left. But we are then left with a ‘Consumer’ expressing needs, which is what we did not want. Can we represent Stakeholder in any other way and this still remain a Use-Case diagram? I don’t like the idea of modelling this as a workflow (if anything, it is probably closer to a Value Chain or Value Network) but happy to see what you can come up with, Rex.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I also wonder if we should just dump the lines containing the definition of ‘Role”, particularly as we use it far more extensively than just to model relationships with Person or Delegate within a social structure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

We could also add an explanatory statement after the definitions of Stakeholder, Actor, Participant, Non-Participant and Delegate.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In UML, Stakeholder and Participant could both be modelled as Actors if the whole ecosystem, as defined, were also to be considered as a ‘system’. However, the distinctions between the SOA-based system, the broader Ecosystem and the roles played in and by Social Structures, are all important distinctions for this work. ‘Actor’ is therefore only used in the context of the System and specific roles played in the wider Ecosystem are represented by Stakeholder and Participant as appropriate.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In 3.2.3, the figure is explicitly not an activity diagram: in the caption, I state that Activity is “expressed informally as a graph of Actions, with a single Start point and alternative End points”. I am trying to make the link between the valid RM-ODP definition of Activity, without having to define it ourselves. Yes, Michael is right that our concept of Joint Action is a type of Activity, formally speaking. But I deliberately chose not to open that can or worms and use the RM-ODP definition for illustrative purposes – the idea of an activity being an acyclic graph of actions is particularly useful I think in getting to grips with issues around orchestration, choreography and composition, as a graph of actions does not assume nor preclude specific ordering, branching, forking, etc…

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Hope this helps,

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter F Brown

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Independent Consultant

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

www.peterfbrown.com

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

P.O. Box 49719, Los Angeles, CA 90049, USA

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tel: +1.310.694.2278

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: Rex Brooks [mailto:rex.brooks@ncoic.org]
Sent: Wednesday, 18 January, 2012 07:55
To: Peter F Brown
Cc: Ken Laskey; jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] revised section 4.3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Haven't had time and health to review thoroughly, but I thought we had agreed that we would make it clear in our discussion of UML as a communication v. modeling tool that our definition of actor is significantly different from that used for UMLUse-Case diagrams. Hence we should either reiterate that in the text around the blue man diagram or else make it a canonical UML use case, which it resembles just enough to cause confusion, or else use some other diagram, such as as BPMN workflow to show workflow. However, without a previous use of and explanation of that kind of diagram, that would actually be worse. So I would use Visio and make it a purely informational diagram without any reference to UML, nor any possiblity of confusion over the use of "Actor." If I can find the time, I will actually do that so that it is clear what I mean. Of course, that's not possible in the 35 minutes left before the meeting.

Cheers,
Rex

On 1/16/12 6:59 PM, Peter F Brown wrote:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Hi,

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OK, here is the Gold Copy returned, with filename incremented.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The main changes compared with Ken’s send out of a few hours earlier are:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 3.1.1 – clarification of term “Actor” to make it compatible with the UML construct of the same name (useful for our purposes and for the modelling that follows);

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Update of fig 5, to include Activity;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 3.1.2.1 – moved fig 6 below role definitions: fits better with text that follows regarding needs, requirements, capability, etc that also appear in the use case of fig 6;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 3.2.3 – introduce ‘Activity’ (using RM-ODP definition) and new (informal) diagram and clarification of our use of ‘Action’ and ‘Activity’ (normative reference to RM-ODP has also been added to section 1.6.1)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cheers,

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Peter F Brown

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Independent Consultant

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

www.peterfbrown.com

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

P.O. Box 49719, Los Angeles, CA 90049, USA

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tel: +1.310.694.2278

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Ken Laskey
Sent: Monday, 16 January, 2012 16:18
To: soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com
Subject: [soa-rm-ra] revised section 4.3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I’ve incorporated all adjudicated changes to section 4.3 and attempted to capture consensus in some original material appearing in section 4.3.4 to the end.  I am hoping for a continuation of the agreeability over the past few days and everyone will be happy with the changes; at the least, I am hoping for an acceptable balance among everyone’s remaining unhappiness.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Take a look and start the discussion.  I’d like nothing better than to have this resolved before Wednesday’s call.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ken

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---------------------------------------------------------------------------

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dr. Kenneth Laskey

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MITRE Corporation, M/S H305              phone: 703-983-7934

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7515 Colshire Drive                                    fax:        703-983-1379

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

McLean VA 22102-7508

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 
 

 

 
---------------------------------------------------------------------

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 
 

 

 
To unsubscribe, e-mail: soa-rm-ra-unsubscribe@lists.oasis-open.org

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 
 

 

 

 

 

 
 

 

 
For additional commands, e-mail: soa-rm-ra-help@lists.oasis-open.org

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]