[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1
Ron: Thank you for the vote of confidence. I am not happy with the new graphic and I would like ot see what Gregory comes up with as a replacement. For the record, I personally am able to live with the graphic we have there now but want to make sure if there is a better way to do things we can use it. Duane Schuldt, Ron L wrote: >Duane - if you add "Enable interpretation" to the line connected to the Semantics box, I believe you would have a suitable replacement for the multi-layered stack diagram. > >Ron > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: Thursday, May 12, 2005 1:46 PM >Cc: soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, >Figure 2-1 > > >Does something like this make more sense than a stack diagram. This is >uses a multi-layered approach to group things and reduce the number of >lines. > >Duane > >Duane Nickull wrote: > > > >>The issue we had with the concept map is we ended up with a >>proliferation of arrows for items like "semantics" and security since >>they are omni-present. We tried various other depictions and finally >>came to the stack. I agree that the stack alone is not sufficient and >>also lends itself to ambiguity so we agreed to place some text by it. >> >>There are standard conventions for interpreting stack diagrams. For >>example - layers in the stack are only able to talk to adjacent >>layers. Layer n can interact with n-1 and n+1, but not n+2. >> >>The position of the vertical layers indicate they are relevant to each >>horizontal layer they are adjacent to. >> >>In stack diagrams, there is no named associations present so it is >>ambiguous. >> >>Accordingly, one can infer the following from the diagram in 2.1 >> >>Service descriptions (are associated with) services >>Policies (are associated with) service descriptions >>Contracts (are associated with) policies >>data models (are associated with) contracts >>semantics (are associated with) service descriptions, policies, >>contracts and data models. >>Services, Service descriptions, policies, contracts and data models >>may all be discoverable and their presence and availability known. >> >>What I do not like is that it also separates the data model from the >>service description and separates the contract from the service >>description. >> >>It may be better to go with a layered concept map. >>Duane >> >> >> >> >> >>Gregory A. Kohring wrote: >> >> >> >>><current> >>>Figure 2-1 SOA Architectural Model >>></current> >>> >>><suggested> >>>Remove the figure. >>></suggested> >>> >>> >>><notes> >>>Sorry, but this figure is rather vacuous. All we see are a bunch of >>>rectangles stacked together with no obvious relationship between them. >>>Some of the rectangles have an "is-a" relationship to their neighbor, >>>while others have a "describes" relationship and some I cannot even >>>decipher what the relationship should be. >>> >>>I understand that people feel UML is too technical for this document, >>>however, diagrams like this detract from the document's readibility. >>>Try using a concept map if you really want to place a diagram at this >>>point. >>></notes> >>> >>> >>> >>> >>> > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Chair - OASIS Service Oriented Architecture Reference Model Technical Committee - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]