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] Good Recent SOA Piece: "Managing an XML Data Model In Your SOA - Best Practices"


Title: Re: [soa-rm] Good Recent SOA Piece: "Managing an XML Data Model In Your SOA - Best Practices"
<Quote>
1. The mechanicals -- where the service is, what types of bytes to squirt at it and so on. This *is* part of the semantics of a service; and there are a significant number of services which can be completely characterized at this level (e.g., message forwarding service)
</Quote>
 
Is this *really* semantics in the traditional sense of the term? Or are these technical requirements that can be defined - for example - using WSDL?
 
<Quote>
2. The syntax -- what kinds of data, what structures does the service  chew on. This is the *data model* level of the semantics. I personally would include things like choreography at this level also.

</Quote>
 
It seems to me that we might be mixing concepts here that are not as closely related as they may be portrayed to be. A choreography is a peer-to-peer, public representation of the interactions between participants in an overarching business collaboration. I would put this in the "process" bucket more so than the "syntax" bucket, although a participant in a choreography must certainly understand the syntax (and semantics) of a choreography definition, such as one conforming to W3C WS-Choreography (caveat: WS-Choreography is still in process within W3C).
 
So I would say that if we wanted to include the notion of choreography here, we should include a "process" category.
 
<Quote>
3. The effect -- what is the result and what are the preconditions of  interacting with a service.
</Quote>
 
Since preconditions and effects are 2 different, but related, things, we may want to call this "semantic requirements", or "preconditions and effects". For that matter, we should also include the other 2 from OWL-S: Input and Output (i.e. for the full "IOPE").
 
<Quote>
4. The context -- when should the service be invoked, who owns it etc. etc.
</Quote>
 
Does this description *really* embody context? I would say it's part of #1, "The Mechanicals". I believe context would involve conditions under which a service is invoked, which may yield different results than if invoked under other conditions.
 
Joe
 

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com

 

From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
Sent: Tue 5/10/2005 11:54 AM
To: SOA-RM
Subject: Re: [soa-rm] Good Recent SOA Piece: "Managing an XML Data Model In Your SOA - Best Practices"

et al....
  When trying to nail down the introduction to semantics, the data 
model seems to be part of the overall story. There appear to be 
several distinct levels of understanding of a service:
1. The mechanicals -- where the service is, what types of bytes to 
squirt at it and so on. This *is* part of the semantics of a service; 
and there are a significant number of services which can be 
completely characterized at this level (e.g., message forwarding 
service)
2. The syntax -- what kinds of data, what structures does the service 
chew on. This is the *data model* level of the semantics. I 
personally would include things like choreography at this level also.
3. The effect -- what is the result and what are the preconditions of 
interacting with a service.
4. The context -- when should the service be invoked, who owns it 
etc. etc.

(I have not done complete justice to what is in the pipeline btw.)

The datamodel aspect, it seems to me, fits both in level 2 and in 
level 3. Things like XML schema are definitely level 2. If you 
include ontology in data model, then it is a level 3 phenomenon.

Incidentally, the nice thing about this analysis is that it parallels 
linguistics: language can similarly be analysed in terms of 
morphology, syntax, semantics and pragmatics.

Frank


On May 9, 2005, at 6:16 PM, Matthew MacKenzie wrote:

> Joe,
>
> I can see something like "conceptual data model", and I agree that 
> "data model" does seem kind of lonely.  I just don't think that 
> canonical works.
>
> Cheers,
> Matt
> On 9-May-05, at 8:58 PM, Chiusano Joseph wrote:
>
>
>> Matt,
>>
>> I think I can clarify here: I'm in agreement that we should not be
>> defining any sort of data model - just including it notionally as a
>> component in our RM. Also, I'm recommending that we call such a
>> component a "canonical data model" because the term "data model" 
>> seems
>> (to me at least) to be too generic. As you know, we often see an
>> adjective in front of it, such as conceptual data model, logical,
>> physical, etc. Simply stating "data model" may make the reader 
>> question
>> "why type of data model?".
>>
>> Or not - just wanted to bring it up for consideration.
>>
>> Joe
>>
>> Joseph Chiusano
>> Booz Allen Hamilton
>> Visit us online@ http://www.boozallen.com
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Matthew MacKenzie [mailto:mattm@adobe.com]
>>> Sent: Monday, May 09, 2005 1:07 PM
>>> To: Duane Nickull
>>> Cc: soa-rm@lists.oasis-open.org
>>> Subject: Re: [soa-rm] Good Recent SOA Piece: "Managing an XML
>>> Data Model In Your SOA - Best Practices"
>>>
>>> The rub is that we are not defining a data model.  If there
>>> was a definitive SOA-RM DM, then perhaps a canonical data
>>> model would be more appropriate.
>>>
>>> -matt
>>> Duane Nickull wrote:
>>>
>>>
>>>
>>>> Perhaps you are correct sir!!
>>>>
>>>> What do others think?
>>>>
>>>> Duane
>>>>
>>>>
>>>>
>>>>
>>>> Chiusano Joseph wrote:
>>>>
>>>>
>>>>
>>>>> Isn't the notion of a "data model" too general for our purposes?
>>>>> Shouldn't we be thinking in terms of a *canonical* data
>>>>>
>>>>>
>>> model[1]? If
>>>
>>>
>>>>> that is not what is needed, please give specifics as to
>>>>>
>>>>>
>>> why (i.e. I
>>>
>>>
>>>>> think that "we don't need a data model" is too general a
>>>>>
>>>>>
>>> statement).
>>>
>>>
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>> [1] http://www.eaipatterns.com/CanonicalDataModel.html
>>>>>
>>>>> Kind Regards,
>>>>> Joseph Chiusano
>>>>> Booz Allen Hamilton
>>>>> Visit us online@ http://www.boozallen.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: John Harby [mailto:jharby@gmail.com] Sent: Friday, May 06,
>>>>>> 2005 1:13 PM
>>>>>> To: soa-rm@lists.oasis-open.org
>>>>>> Subject: Re: [soa-rm] Good Recent SOA Piece: "Managing an
>>>>>>
>>>>>>
>>> XML Data
>>>
>>>
>>>>>> Model In Your SOA - Best Practices"
>>>>>>
>>>>>> IMHO, SOA should really be defined independent of data
>>>>>>
>>>>>>
>>> model and a
>>>
>>>
>>>>>> general definition of SOA should support any strategy
>>>>>>
>>>>>>
>>> employable by
>>>
>>>
>>>>>> data tiers. Defining the notion of data model really seems out of
>>>>>> scope to me.
>>>>>>
>>>>>> On 5/6/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> These are very interesting thoughts - I like the term "SOA data
>>>>>>> model". Can you please clarify further what the difference
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> between a "SOA data model"
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> and a "canonical data model" would be? (since I believe
>>>>>>>
>>>>>>>
>>> "SOA data
>>>
>>>
>>>>>>> model" may now be a newly coined term)
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Joseph Chiusano
>>>>>>>
>>>>>>> Booz Allen Hamilton
>>>>>>>
>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>
>>>>>>> ________________________________
>>>>>>> From: Vikas Deolaliker [mailto:vikas@sonoasystems.com]
>>>>>>> Sent: Fri 5/6/2005 12:37 PM
>>>>>>> To: Chiusano Joseph; 'Frank McCabe'; 'Ken Laskey'
>>>>>>> Cc: soa-rm@lists.oasis-open.org
>>>>>>> Subject: RE: [soa-rm] Good Recent SOA Piece: "Managing
>>>>>>>
>>>>>>>
>>> an XML Data
>>>
>>>
>>>>>>> Model In Your SOA - Best Practices"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The problem with "canonical data model" is that it does not
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> scale with time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Eventually it will not canonicalize but constrain the
>>>>>>>
>>>>>>>
>>> richness of
>>>
>>>
>>>>>>> communication that is expected among various SOA entities.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> IMHO SOA data mode should aim to define (a)  the
>>>>>>>
>>>>>>>
>>> interfaces used by
>>>
>>>
>>>>>>> SOA entities to exchange information, (b) mechanisms to
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> discover these
>>>>>>
>>>>>>
>>>>>>
>>>>>>> interfaces and (c) mechanisms to negotiate a
>>>>>>>
>>>>>>>
>>> vocabulary/format for
>>>
>>>
>>>>>>> data exchange over these discovered interfaces.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Vikas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>>
>>>>>>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>>>>>>> Sent: Friday, May 06, 2005 9:23 AM
>>>>>>> To: Frank McCabe; Ken Laskey
>>>>>>> Cc: soa-rm@lists.oasis-open.org
>>>>>>> Subject: RE: [soa-rm] Good Recent SOA Piece: "Managing
>>>>>>>
>>>>>>>
>>> an XML Data
>>>
>>>
>>>>>>> Model In Your SOA - Best Practices"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think some additional context may not have been
>>>>>>>
>>>>>>>
>>> provided below.
>>>
>>>
>>>>>>> While the article does state "This article does not
>>>>>>>
>>>>>>>
>>> discuss how to
>>>
>>>
>>>>>>> integrate data models", it is stated in the context of
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> "this article
>>>>>>
>>>>>>
>>>>>>
>>>>>>> will not get into this topic because it is either out of
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> scope or too complex to discuss".
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The author is actually a strong proponent of having an
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> integrated data
>>>>>>
>>>>>>
>>>>>>
>>>>>>> model, as they depict an integrated data model as one of
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> the layers of
>>>>>>
>>>>>>
>>>>>>
>>>>>>> their approach. I interpret this as a "canonical data
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> model", which is
>>>>>>
>>>>>>
>>>>>>
>>>>>>> a special type of data model used for data exchange.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Joseph Chiusano
>>>>>>>
>>>>>>> Booz Allen Hamilton
>>>>>>>
>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>>
>>>>>>> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
>>>>>>> Sent: Fri 5/6/2005 12:03 PM
>>>>>>> To: Ken Laskey
>>>>>>> Cc: Chiusano Joseph; soa-rm@lists.oasis-open.org
>>>>>>> Subject: Re: [soa-rm] Good Recent SOA Piece: "Managing
>>>>>>>
>>>>>>>
>>> an XML Data
>>>
>>>
>>>>>>> Model In Your SOA - Best Practices"
>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>> Frank
>>>>>>>
>>>>>>>
>>>>>>> On May 6, 2005, at 8:45 AM, Ken Laskey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The critical line in this article is
>>>>>>>>
>>>>>>>> This article does not discuss how to integrate data models.
>>>>>>>>
>>>>>>>> Its premise is the tried (and usually failed) that if
>>>>>>>>
>>>>>>>>
>>> we all get
>>>
>>>
>>>>>>>> into a room and be reasonable we can all find a common
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> vocabulary to
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> map to.  I could go on about when that works and when
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> that doesn't
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> (see my OASIS Symposium presentation for more) but if
>>>>>>>>
>>>>>>>>
>>> that is the
>>>
>>>
>>>>>>>> basis of SOA, then it will go no further than any other
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> integration
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> paradigm.  The driving question is how do you create a system
>>>>>>>> (service?) to do semantic negotiation between diverse
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> vocabularies
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> in a way that is (1) visible, (2) reusable, and (3)
>>>>>>>>
>>>>>>>>
>>> allows you to
>>>
>>>
>>>>>>>> use what you know (or can find) in ways that enables you
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> to do more
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> with little or no effort.
>>>>>>>>
>>>>>>>> The SOA RM will not specify how this is done but it
>>>>>>>>
>>>>>>>>
>>> must also not
>>>
>>>
>>>>>>>> codify an interchange vocabulary paradigm that will not scale.
>>>>>>>>
>>>>>>>> End of rant:-)
>>>>>>>>
>>>>>>>> Ken
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 6, 2005, at 10:32 AM, Chiusano Joseph wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Forwarding a good recent SOA piece[1] for those interested in
>>>>>>>>> reading it. Covers the notion of an integrated data model as a
>>>>>>>>> foundational concept; also presents a 6-layer approach to SOA
>>>>>>>>> (about mid-article).
>>>>>>>>>
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> [1] http://www.tdan.com/i032ht02.htm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Joseph Chiusano
>>>>>>>>>
>>>>>>>>> Booz Allen Hamilton
>>>>>>>>>
>>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> --------------------------------------------------------------------
>>>
>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> --------------------
>>>>>>>> Ken Laskey
>>>>>>>> MITRE Corporation, M/S H305     phone:  703-983-7934
>>>>>>>> 7515 Colshire Drive                        fax:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 703-983-1379
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> McLean VA 22102-7508
>>>>>>>>
>>>>>>>> *** note change of phone extension from 883 to 983 effective
>>>>>>>> 4/15/2005 ***
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> On May 6, 2005, at 8:45 AM, Ken Laskey wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The critical line in this article is
>>>>>>>>
>>>>>>>> This article does not discuss how to integrate data models.
>>>>>>>>
>>>>>>>> Its premise is the tried (and usually failed) that if
>>>>>>>>
>>>>>>>>
>>> we all get
>>>
>>>
>>>>>>>> into a room and be reasonable we can all find a common
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> vocabulary to
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> map to.  I could go on about when that works and when
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> that doesn't
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> (see my OASIS Symposium presentation for more) but if
>>>>>>>>
>>>>>>>>
>>> that is the
>>>
>>>
>>>>>>>> basis of SOA, then it will go no further than any other
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> integration
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> paradigm.  The driving question is how do you create a system
>>>>>>>> (service?) to do semantic negotiation between diverse
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> vocabularies
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> in a way that is (1) visible, (2) reusable, and (3)
>>>>>>>>
>>>>>>>>
>>> allows you to
>>>
>>>
>>>>>>>> use what you know (or can find) in ways that enables you
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> to do more
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> with little or no effort.
>>>>>>>>
>>>>>>>> The SOA RM will not specify how this is done but it
>>>>>>>>
>>>>>>>>
>>> must also not
>>>
>>>
>>>>>>>> codify an interchange vocabulary paradigm that will not scale.
>>>>>>>>
>>>>>>>> End of rant:-)
>>>>>>>>
>>>>>>>> Ken
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 6, 2005, at 10:32 AM, Chiusano Joseph wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Forwarding a good recent SOA piece[1] for those interested in
>>>>>>>>> reading it. Covers the notion of an integrated data model as a
>>>>>>>>> foundational concept; also presents a 6-layer approach to SOA
>>>>>>>>> (about mid-article).
>>>>>>>>>
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> [1] http://www.tdan.com/i032ht02.htm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Joseph Chiusano
>>>>>>>>>
>>>>>>>>> Booz Allen Hamilton
>>>>>>>>>
>>>>>>>>> Visit us online@ http://www.boozallen.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> --------------------------------------------------------------------
>>>
>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> --------------------
>>>>>>>> Ken Laskey
>>>>>>>> MITRE Corporation, M/S H305     phone:  703-983-7934
>>>>>>>> 7515 Colshire Drive                        fax:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 703-983-1379
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> McLean VA 22102-7508
>>>>>>>>
>>>>>>>> *** note change of phone extension from 883 to 983 effective
>>>>>>>> 4/15/2005 ***
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>



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