[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
Hello Greg: I would like to quickly first try to answer Frank's question. Assuming we can, I concur with your suggestion. Frank: "Why is the data model separated out as though it were an appendage? Constraints apply to data as well as everything else. " I copied this from Greg's diagram. My interpretation is that as it reads now, one could infer that "data model" is a sub part of service description. It has an implied relationship to constraints, including it's components "Policy and Contract" in the sense they are all part of the larger "service Description". Constraints are a part of service description, which in itself is related to service. All aspects and components of the service description (data model, constraints, policy and contract) may be advertised. Did that answer the question? Duane Frank - Are you referring to CoreRM5.png? Just want to check. Duane Greg Kohring wrote: > OK, Suppose we freeze figure 2-1 as Duane suggest with CoreRM5.png > > I would then suggest that section 2 of the document be re-organized > using the major headings: "Service", "Service Description" and > "Discovery, Presence and Availability". Under "Service Description", > we would then have the headings "Constraints" and "Data Model" and > under "Constraints" we would have "Policy" and "Contract". > > This will help the reader make the correspondence between the document > and the figure. > > -- Greg > > Duane Nickull wrote: > >> Here is a rendering based on Greg's diagram that accounts for all the >> comments below. >> >> - I placed Metadata as a bracket inside the "service description" box. >> - Semantics will have to be explained using text accompanying this >> diagram to state that they are omnipresent. >> - turned the stack upside down so service is at the bottom. To me, >> it seemed more intuitive that the thing that is core is at the bottom >> and the other items are built out (up??) from it. Comments? >> - used the UML dependency arrow as the convention between service and >> service description to denote that a SD should not exist without a >> service. >> - redrew the line between metadata and policy / contract to connect >> with the outer container of "constraints" >> - removed the words "enables discoverability" from the association. >> >> If we use this, we should probably build an appendix containing clear >> and concise rules about how to interpret this mind map since it >> borrows association conventions from UML and mixes them together with >> other conventions. >> >> Comments? >> >> Duane >> >>>>> >> >> ------------------------------------------------------------------------ >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]