[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"
Joe
Hmm - thought provoking. Not sure it is relevant to the RM
but feel it
is worth a discussion.
Statement: Mediation can overcome
differences in data models.
Thoughts: Is it the actual data model or the
serialization of the data
model that is transformed, validated etc? If
the data models are not
aligned by virtue of the fact an element that is
mandatory in the target
is not present in the source, regardless of the
serialization, this
cannot be overcome. If it is mandatory and not
included, the
invocation request should fail.
IMO - mediation is
an observable, perceived behavior, much like
computational
intelligence. If I tell someone that I am not coming to
work tomorrow,
then tell them five minutes later to book and appointment
at the office with
me tomorrow, an intelligent person should raise an
objection to the request
based on the grounds I have stated I am not
going to be present. Our
corporate time management software can do the
same thing, yet it is not
intelligent. The observable behavior could
create the illusion of
intelligence, much the same way negotiation may
be perceived. The
reality if that they can both be done with hard coded
declarations and
decision points.
Any further thoughts???
Duane
Chiusano
Joseph wrote:
> Regarding "what is mediation?": I realize that
these[1][2] are not
> authoritative sources, but at least they provide 2
perspectives of
> what "mediation" means. Both seem to support the notion
that
> transformation (such as XSLT transformation) is part of
mediation.
> Would like to hear additional views within our TC as
well.
>
> From [2]:
>
>
>
>
"Mediation is the missing piece of the jigsaw. Simply put, it involves
>
the transformation, routing, validation and processing of messages,
>
which in turn enables differences in information models between web
>
service providers and users to be accounted for and overcome when
>
creating applications. This is essential when integrating newly
> defined
web services with existing
infrastructure."
>
>
>
> [1] http://www.oreillynet.com/pub/wlg/6977
>
>
[2]
> http://www.looselycoupled.com/sub/print.php?dir=opinion&name=bradl-save-infr1206&year=2004
>
<http://www.looselycoupled.com/sub/print.php?dir=opinion&name=bradl-save-infr1206&year=2004>
>
>
>
>
Joe
>
>
>
> Joseph Chiusano
>
> Booz
Allen Hamilton
>
> Visit us online@ http://www.boozallen.com
>
>
>
>
>
>
>
------------------------------------------------------------------------
>
From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent:
Tue 5/10/2005 1:09 PM
> Cc: SOA-RM
> Subject: Re: [soa-rm] Good
Recent SOA Piece: "Managing an XML Data
> Model In Your SOA - Best
Practices"
>
> Ken:
>
> I would like to explore the
notion of "mediation" service. Is it
> actually mediating?
XSLT is declarative and very deterministic. You
> have a tree model
of your entire document, then XSLT processors read an
> instruction and
test the case against the input tree. If the condition
> matches,
then it does the second part of the declaration (usually to
> write out to
a new tree model). It seems to be reduced to a simply set
> of
decision points.
>
> Duane
>
> Ken Laskey
wrote:
>
> > 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
> > ***
>
>
>
> --
> ***********
> 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
>
***********
>
--
***********
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
***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]