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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: RE: [soa-rm] Diagram


The graph cannot be interpreted without the context of the accompanying
text in the RM for SOA rev 10.  Accordingly, all concepts are abstract
in nature.

Your comments have illustrated another potential pitfall which is the
lack of a formal reference for interpreting concept maps.  Individuals
may accordingly make inconsistent interpretations of the concept map or
mind maps.

Perhaps we might revisit the use of UML?

Duane

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: McGregor.Wesley@tbs-sct.gc.ca
[mailto:McGregor.Wesley@tbs-sct.gc.ca] 
Sent: Wednesday, December 07, 2005 10:18 AM
To: Duane Nickull; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Diagram

Thanks for the reply Duane.

Here are my comments.

1. It is unclear from the diagram what is a realizable concept and what
is completely abstract. If a service is virtual, it cannot have real
associations hence my comment. Was it ever decided what a service is? As
I recall it was not.
2. It is not the level of granularity that bothers me but the
consolidation of static and dynamic states of existence. Mixing the two
in the same diagram merely creates confusion. 

Wes

 -----Original Message-----
From: 	Duane Nickull [mailto:dnickull@adobe.com] 
Sent:	December 7, 2005 1:02 PM
To:	McGregor, Wesley; soa-rm@lists.oasis-open.org
Subject:	RE: [soa-rm] Diagram


Wes wrote:

I would add a reference to the policy from the Service Description to
indicate association. I agree services have policy, but it is the
Service Description that points to the policy at design time and the
services use them at run-time.

DN: This is not needed since if a service has a policy, and a service
description described a service, then the service description can
described the service policy.  It is not necessary to make lines between
every concept.

I would also add a transient run-time agreement (with a lifetime
attribute) entity as part of the interaction within the execution
context.

DN:  That can be described in the text.  With graphics like these, we
have to stick to a consistent level of granularity for all elements of
the graph.  The text accompanying them can describe each one on more
detail.

Duane





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