Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

[Francis McCabe <fgm@fla.fujitsu.com>]

Greg:
  This is better :)
  However, a couple of nits:
1. the relationship between semantics and metadata is not one of  
realization but one of description.
2. there is a relationship between contracts and policies: a policy  
is a constraint that represents a party's requirements. A contract is  
a constraint that has been *agreed to* by all the parties bound by  
the constraint. Here constraint is meant very broadly as anything  
that can be measured to be true or false.
3. the relationship between service and semantics is not one of  
description, but, again, of constraint: the semantics is *true* of  
the service (or something is broken:) The fuzzy English word is  
characterized: the service is characterized by its semantics, that  
semantics is described in metadata. Aspects of the semantics include  
the data model, the action model, the policies that are relevant and  
the agreements that have been (or might be) entered into.

Of course, one of the agreements is that the service's semantics is  
sufficiently described in the available metadata that outside user  
agents can successfully interact with the service.

Frank


On May 19, 2005, at 12:24 AM, Gregory A. Kohring wrote:

> Frank,
>
> If I understand you correctly, then in your view there is little to
> be gained by distinguishing between syntaxt and semantics at this
> level.  Hence, the "Service Description" is purely semantics.
>
> Attached is another diagram which depicts this idea. Is this
> consistent with your ideas?
>
> -- Greg
>
> Francis McCabe wrote:
>
>> While I like the direction in which this is going, I have a couple of
>> issues:
>>
>> 1. I do not see semantics as being inside service description.
>> Semantics is an abstract concept that may be referred to but is not
>> contained in any description.
>> 2. I am not sure why data model is broken out in the way  
>> suggested.  To
>> me, tehe data model is an asepct of the semantics of the service.
>> 3. I do not see a hard and fast distinction between syntax and
>> semantics. Again, any syntactic constraints are simply part of the
>> overall semantics.
>>
>> The *reason* for this is that while it is tempting to equate   
>> semantics
>> with application semantics, that is not, in fact, a good  slope to  
>> slip
>> down.
>>
>> Once you liberate yourself from that misconception, one beings to see
>> all kinds of possibilities. For example, for an encryption/decryption
>> service, its entire semantic model consists of messages with   
>> encryption
>> markers etc. etc. Is that syntax? Depends on your point of  view;  
>> to my
>> mind it is semantics of a simple service.
>>
>>
>> Frank
>>
>>
>> On May 13, 2005, at 12:01 AM, Gregory A. Kohring wrote:
>>
>>
>>> Yes, this looks much better. Attached is a slight variation which
>>> moves the semantics into the description. At one time, "syntax" was
>>> also explicitly mentioned as being part of the description. Has that
>>> been dropped?
>>>
>>> -- Greg
>>>
>>> Duane Nickull wrote:
>>>
>>>
>>>> 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
>>>>>
>>>>>
>
>
>
> -- 
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
>
> <figure1.png>
>