[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
Could you guys please slow down!!! I get busy for a couple days and I'm six dozen emails behind! OK, good job in sorting this stuff out. A couple accumulated comments, hopefully not too OBE: - The only place to expose semantics of a service is through its service description/metadata. - Given the context in which SOA is discussed, metadata is an integral element on whose reliance too much depends and for which there is so little concrete discussion and understanding. (Forgive me, I saw Star Wars and I'm starting to talk like Yoda.) - Semantics doesn't directly enable discoverability but it enable interoperability of intended meaning and that enables, among other things, discoverability. What is often missed in the descriptions of registries is that we need to know both the semantics of the description categories (i.e. the tags) and the semantics of the description values (i.e. what goes between the tags). - Policy, agreement, process model, data model together do not characterize the semantics but rather characterize the context. Each of these elements may have its own semantics and the critical thing is that the semantics must be shared, either by using the same vocabulary or having a robust mediation between vocabularies. - Having an (at least approximate) equivalence between service description and metadata aligns nicely with section 1.1.3.1 of the draft. However, section 1.1.3 talks about data model (included in latest diagram), a description of functions and then assumptions, constraints, and policies. We also seem to have misplaced the service interface. I'd still like to see more about what is a processing model that should be exposed as part of the service description for a particular service. Ken On May 20, 2005, at 7:07 PM, Duane Nickull wrote: > Michael: > > I see why you are asking the question. If everything is a constraint > within the service description box and nothing is not a constraint, we > do not need to explicitly use the "constraint" box. It's sole purpose > is to group those members of the service description that are > distinguished as "of type 'constraint'" from those that are not. > > That brings us to..... > > CoreRM8.png > > which looks suspiciously like the first drawing Gregory did ;-) > > Are we there yet? > > Duane > > Michael Stiefel wrote: > >> But in that sense everything is a constraint. >> >> Frank does view the world that way (see his reply to my comment). >> >> Now if I may be pedantic - making everything a constraint is similar >> to saying that the words in a dictionary definition are a constraint >> because they constrain the way a word is used. While that may be >> ture, nobody thinks of a dictionary definition that way, so I am >> dubious about us looking at our definition of a service description >> that way. >> >> >> Michael >> >> At 06:26 PM 5/20/2005, Duane Nickull wrote: >> >>> My view on this is that the data model is a constraint of the >>> information flowing in and out of a service. It may be realized as >>> a schema referenced from a WSDL in WS architecture. >>> These things constraint the way a service is used. >>> >>> Duane >>> >>> Michael Stiefel wrote: >>> >>>> How is the data model a constraint? >>>> >>>> If everything is constraint, what is being constrained? >>>> >>>> Michael >>>> >>>> At 05:56 PM 5/20/2005, Francis McCabe wrote: >>>> >>>>> I would prefer to see >>>>> 1. policy, contract linked together -- reflecting the >>>>> contract=agreed >>>>> policy idea. >>>>> 2. data model is one of the constraint types, like policy and >>>>> contract >>>>> 3. we should also mention process model if we are going to call out >>>>> the data model. >>>>> >>>>> Being a total pedantic, policy, agreement, process model, data >>>>> model >>>>> together characterize the semantics; however, the metadata/service >>>>> description is a projection of that semantics (there may be several >>>>> service descriptions for one service). >>>>> >>>>> Frank >>>>> >>>>> >>>>> On May 20, 2005, at 2:44 PM, Duane Nickull wrote: >>>>> >>>>>> Michael: >>>>>> >>>>>> Thanks - I tried it horizontally and for some weird reason, it >>>>>> seems to resonate better. >>>>>> >>>>>> If we can get Frank's sign off and no one else has any opposition, >>>>>> maybe we can use this one? >>>>>> >>>>>> One other thought - should Data Model be larger? In the book >>>>>> Documenting Software Architectures, I seem to recall some >>>>>> conversation about size mattering (yeah yeah). Accordingly, I >>>>>> enlarged the data model to give it more presence. How does this >>>>>> look? See attached Core RM6.png >>>>>> >>>>>> Duane >>>>>> >>>>>> Michael Stiefel wrote: >>>>>> >>>>>> >>>>>>> Would going from right to left or left to right remove any >>>>>>> associations of top and bottom as more natural or more >>>>>>> fundamental? >>>>>>> >>>>>>> Have you ever looked at a globe with the Southern Hemisphere at >>>>>>> the top? To most of us that live in the Northern Hemisphere it >>>>>>> looks wrong, but of course, from the point of view of outer space >>>>>>> either pole of the globe could be on top. >>>>>>> >>>>>>> I like the fact that semantics will be explained on the side. >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> At 02:37 PM 5/20/2005, 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <CoreRM6.png> >>>>>> >>>> >> >> > <CoreRM8.png> ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]