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"


Thanks for the clarification Ken. 
 
I was actually referring to something closer to the 2nd type of vocabulary (but perhaps not exactly - described further below). I see the first type as being representable using an ontology (i.e. the entities of a SOA, their properties, the relations between them), as well as a taxonomy.
 
The second type is close to, but not quite what, I was thinking. The difference between what is represented in your excellent presentation, and what I was thinking, is how (what I will refer to as ) the canonical data model is developed. I believe that in your presentation and in your description below, there is an assumption that multiple data models already exist (those of the service consumers), and that there is some sort of effort involved to create a "one-size-fits-all" from these. I agree that this approach does not always work properly - and the more n's there are, the tougher it is. This is the fundamental difference between what you were describing, and what I have been thinking.
 
I was actually thinking of a case in which multiple data models already exist, but a SOA is created without an effort to harmonize those data models - i.e. the potential service consumers are not known, and no attempt is made to identify them, contact them, gather them, meet with them, etc. I believe this is a very realistic scenario. So in such an effort, a canonical data model would be constructed with the notion of "if you want to interact with this service, this is the information you need to provide", etc. Mediation may certainly be required, but that would be done on the part of the service consumer, most likely (as you point out) through an XSLT transformation. So in this case, there would be no "compromise vocabulary" (or data model), because there is nothing to compromise on except within the effort to create the service(s).
 
Last evening, Matt suggested the term "conceptual data model", which I also support. Either one is fine with me at this point - as long as we don't simply call it "data model" with no qualification.
 
Hope that helps--
 
Joe

 

Joseph Chiusano

Booz Allen Hamilton

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



From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Tue 5/10/2005 9:52 AM
To: SOA-RM
Subject: Re: [soa-rm] Good Recent SOA Piece: "Managing an XML Data Model In Your SOA - Best Practices"

Joe,

I see there being two sets of vocabularies (data models?) in our SOA discussion. The first is the vocabulary relevant to describing a SOA. We are developing/collecting that as part of the RM and that will hopefully facilitate the discussion of SOA by others. The second set is the domain vocabularies of the various SOA users. These vocabularies are specific to specific domains of discourse. These overlap (otherwise, there would be no need for interaction) and is the focus of most integration efforts. It is for the second set that the idea of an interchange/compromise/hub-and-spoke/... vocabulary is introduced to mediate the exchange of information within a consistent semantic framework. I am interpreting the term "canonical" to refer to that interchange vocabulary. While this is a standard approach, I contend it is limited and does not scale. Thus, I'm saying the RM may include the concept of a mediation service to facilitate information interchange across vocabularies. If the situation is simple enough that the interchange vocabulary is sufficient, then this is the implementation of the mediation service used. (It could be a single hardwired translation or a more general service that, for example, processes any XSLT input.) However, the idea of a mediation service does not codify the use of a canonical vocabulary as the means to accomplish this functionality.

I could not figure out how to reference the presentation I gave at the recent OASIS Symposium (is there a way to find past presentations on the OASIS Web site?) so I uploaded it to the Member Submission area of the TC. Please see slide 4.

If I am misinterpreting what you mean by a canonical data model, please clarify.

Ken



On May 9, 2005, at 9:06 PM, Chiusano Joseph wrote:

Please help me understand the difference between the concept of canonical data model in the link provided earlier in the thread below, and what we need to define. I'm very sorry that I am not understanding here. What is the gap? (yes, I know it's a clothing store;)
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com


From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Monday, May 09, 2005 1:22 PM
To: Chiusano Joseph; 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"

If we are basing our concept of SOA on the diagram in the link you provide, then I object.  It works in certain limited situations but does not scale as a global solution.  Even for the limited cases, there is no extension that adequately covers how to connect the successes of the limited cases.  This does not mean you should never use a canonical vocabulary, just know its limitations and be prepared to keep moving on to the next level solution.

Ken

At 01:07 PM 5/9/2005, Chiusano Joseph wrote:

<Quote>
If you want to come up with a "canonical" vocabulary to capture SOA semantics as will be described in the reference model, that is fine because it will be the SOA-RM vocabulary.  Do not expect it to provide general translation capabilities for all services.
</Quote>

Ken,
I don't know that we would actually come up with such a SOA-RM vocabulary - instead, I foresee the possibility of our including the notion of a canonical data model as a component within our specification.
Joe

Joseph Chiusano<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Booz Allen Hamilton

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


From: Ken Laskey [ mailto:klaskey@mitre.org]
Sent: Mon 5/9/2005 12:57 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"


I'll go back to my comments on 5/6 re Good Recent SOA Piece:

<recap>
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:-)
</recap>

If you want to come up with a "canonical" vocabulary to capture SOA
semantics as will be described in the reference model, that is fine because
it will be the SOA-RM vocabulary.  Do not expect it to provide general
translation capabilities for all services.

Being trained as a fluid mechanics engineer, I see this as the classic
nozzle where things funnel down from one large plenum to a minimum flow
passage and then expands into a second large plenum.  The problem is the
minimum flow can be a choke point.  It works the same way with vocabulary
translation.

Ken


At 12:38 PM 5/9/2005, 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 ***
>>>>>
>>>>>
>>>>
>>
>>
>
>--
>***********
>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
>Chair - OASIS Service Oriented Architecture Reference Model Technical
>Committee - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>Adobe Enterprise Developer Resources  -
> http://www.adobe.com/enterprise/developer/main.html
>***********
>

--
      ---------------------------------------------------------------------------------
   /   Ken
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***




--
     ---------------------------------------------------------------------------------
  /   Ken Laskey                                                                \
 |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
 |    7515 Colshire Drive                    fax:      703-983-1379   |
  \   McLean VA 22102-7508                                              /
    ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***

------------------------------------------------------------------------------------------
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]