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


I made an error in my assessment, please disregard this one and look at
the email with the new image attached.  It is coming to the list soon.


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
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. 


 -----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

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


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