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] My stab at an SOA-RM concept map


Semantics is not the same as context. Or rather, it depends on what  
you mean by semantics <duck/>

Earlier, I tried to identify at least two *layers* of semantics that  
may be relevant to us: the semantics of services qua services, and  
the semantics of a service in context (i.e., the business semantics  
of a service).

The traditional computer engineer's view on this would be to avoid at  
all costs the business semantics of service. I can understand this,  
but am not sure that we should. (Certainly, in any *given* deployed  
system, no-one is going to ignore the business semantics.)

The fact that the semantics associated with service does seem to be  
layerable should serve as a hint.

Frank

On May 31, 2005, at 3:58 PM, Vikas Deolaliker wrote:

>
>
> Is semantics the same as context? If it governs almost every entity  
> in SOA,
> then perhaps, one could split it up into SemanticGroups. Also there  
> is no
> feedback loop with semantics i.e. it looks static. Semantics would  
> most
> likely change over time i.e. dynamic.
>
> Thanks
> Vikas
>
>
> -----Original Message-----
> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> Sent: Tuesday, May 31, 2005 11:56 AM
> To: Matthew MacKenzie
> Cc: SOA-RM
> Subject: Re: [soa-rm] My stab at an SOA-RM concept map
>
> I do, ...
>
> To start with ...
>
> semantics is much like architecture: it is about concepts and the
> relationships between them. In our case, however, the semantics of a
> service is really about the expectations for the service: what do we
> need to know in order to effectively use the service and what will be
> the expected result of using the service.
>
> This last aspect is pretty open ended of course: the service model
> for my son's piggy bank may be identical to the service model for my
> grown-up bank: but the expected result of a withdrawal is
> dramatically different.
>
> So, I think, that data model, policies, processing model, are all
> aspects of the semantics of a service.
>
> To be able to capture the expected results of using a service
> requires a deeper modeling of the context in which services are
> deployed. Speaking personally, I am in favor of such a modeling, but
> perhaps people may be a little surprised at what would be involved
> (hint: it brings in concepts such as institutional facts, norms,
> roles, authority, empowerment)
>
> Frank
>
>
>
>
> On May 31, 2005, at 11:18 AM, Matthew MacKenzie wrote:
>
>
>>
>> On 31-May-05, at 2:02 PM, Behera, Prasanta wrote:
>>
>>
>>
>>> #1: Can u expand a little bit on the semantics of "govern"?  
>>> Semantics
>>> "define" and "govern" policy.
>>>
>>>
>>
>> It's just the best verb that popped into my head as I was drawing.
>> It seemed appropriate, since semantics do form a "glue" of sorts
>> for the various elements...at least that is my understanding from
>> discussions I've been part of.  Do you have a suggestion to replace
>> it?
>>
>>
>>
>>>
>>> #2: The relationship between "Data Model" and "Services" -- should
>>> it be
>>> more of a association type (line instead of a arrow)
>>>
>>>
>>
>> It's a concept map, I don't think there are association types.  In
>> fact, I mean for there to be arrows on every line.  There is a
>> problem with the drawing tool which I am investigating. The line
>> you mention may not be necessary, strictly speaking.
>>
>> -matt
>>
>>
>>
>>
>>
>>>
>>> Thanks,
>>> /Prasanta
>>>
>>> -----Original Message-----
>>> From: Matthew MacKenzie [mailto:mattm@adobe.com]
>>> Sent: Tuesday, May 31, 2005 9:13 AM
>>> To: Francis McCabe
>>> Cc: SOA-RM
>>> Subject: Re: [soa-rm] My stab at an SOA-RM concept map
>>>
>>> Having some problems with arrows in this tool, but I added another
>>> relationship to contract (attached).
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



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