Yes, it pushes the transformations within the boundaries of the
consumer and provider, which I do believe is a good thing. Of course,
agreeing to an interface up front does that. The canonical model
pattern has more to do with consistently across multiple services,
IMO. I agree with Michael that it should strive for consistency in
models, not the one end-all/be-all schema of the universe that
everyone will use, which in reality, cannot be created.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On May 29, 2009, at 2:15 PM, Herbjörn Wilhelmsen <[email protected]
m> wrote:
Hi Todd,
A quote from the article: 'each project team agrees to use the same
pre-defined data models for common business documents'
To me that fragment of a sentence means that services (as well as
service consumers) should attempt to avoid transformations of
messages or message parts by using the same models so that the need
to transform messages and message parts ideally is eliminated. If
anything that pushes the transformation in behind the service
boundaries, doesn't it? Was that not what you wanted?
As for the prevention of transformation, I believe it is more about
reducing transformations than eliminating them. Sooner or later you
are going to need transformations. And when you do the Canonical
Schema, in a similar way as Canonical Data Model, will make those
transformations easier to create.
Sincerely
Herbjörn
2009/5/29 Todd Biske <[email protected]>
The one nitpick I have against this article is the notion that using
a canonical model prevents the application of the data model
transformation pattern. In reality, it's just pushing the
transformation somewhere else. Think about it this way: both
consumer and provider have some internal processing model. What the
canonical model pattern does is force the transform from processing
model to service/message model to the endpoints, rather than
allowing the endpoints to push their models outward, leading to a
bottleneck of transformations in the middle. I prefer having the
transformation from processing model to messaging model be as close
to the endpoint as possible.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On May 28, 2009, at 6:07 PM, Gervas Douglas
<[email protected]> wrote:
<<Of all the patterns in the SOA design patterns catalog, there is
perhaps no other as simple to understand yet as difficult to apply
in practice as Canonical Schema. There are also few patterns that
spark as much debate. In fact, that application potential of
Canonical Schema can become one of the fundamental influential
factors that determine the scope and complexion of a service
inventory architecture. It all comes down to establishing baseline
interoperability. The Canonical Schema pattern ensures that
services are built with contracts capable of sharing business
documents based on standardized data models (schemas). Unlike the
well-known pattern Canonical Data Model (Hohpe, Woolf) which
advocates that disparate applications be integrated to share data
based on common data models, Canonical Schema requires that we
build these common data models into our service contracts in
advance. Hence, the successful application of this pattern almost
always requires that we establish and consistently enforce design
standards. But before we discuss the standardization of data models
and all of the enjoyable things that come with trying to make this
happen, let's first take a step back and describe what we mean by
"baseline interoperability." When services and service consumer
programs interact, data is transmitted (usually in the form of
messages) organized according to some structure and a set of rules.
This structure and the associated rules constitute a formal
representation (or model) of the data. When different services are
designed with different data models representing the same type of
data, then they will have a problem sharing this data because the
data models are simply incompatible. To address this problem, a
technique called data model transformation is applied whereby data
model mapping logic is developed so that data exchanged by such
services is dynamically converted at runtime from compliance with
one data model to another. So successful has this technique been
that a corresponding Data Model Transformation pattern was
developed. However, with data model transformation comes
consequences. And with the overuse of data model transformation
comes real problems pertaining to architectural complexity,
increased development effort, and runtime performance demands that
can impact larger service compositions to such an extent that if
you press your ear close enough to your middleware you can actually
hear the churning and grinding of this extra runtime latency. These
and other details and issues will be discussed separately during an
upcoming series article dedicated to the Data Model Transformation
pattern. What's important for us to understand for now is that the
primary goal of applying Canonical Schema is for us to avoid having
to apply Data Model Transformation. This brings us back to design
standards and the scope of their application. Establishing
canonical schemas as part of services delivered by different
project teams at different times requires that each project team
agrees to use the same pre-defined data models for common business
documents. This may sound like a simple requirement but something
simple is not always easy. Many organizations have historically
struggled with the enforcement and governance of standardized data
models – so much so that it has led to organizational power strugg
les, resentment of individuals at being "enforced", and technical
difficulties with large-scale compliance and change management (of
the data models). These are all reasons as to why the Canonical S
chema pattern is very commonly applied together with Domain Invent
ory. Limiting the application, enforcement, and governance of stan
dardized data models to the confines of a manageably sized service
inventory dramatically increases the potential to successfully re
alize the full potential of this pattern. Canonical Schema epitomi
zes the transition from silo-based, integrated enterprises to serv
ice-orientation. It is a pattern that solves a big problem but ask
s in return that we make an equally big commitment to its on-going
application.>>
You can read this at:
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1356943_mem1,00.html
Gervas
#ygrp-mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana;
font-size: 10px; font-weight: normal; } #ygrp-msg p a { font-
family: Verdana; font-size: 10px; } #ygrp-mlmsg a { color:
#1E66AE; } div.attach-table div div a { text-decoration: none; }
div.attach-table { width: 400px; } --> l>
--
Med vänliga hälsningar
Herbjörn Wilhelmsen
th; padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-
count span { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg
#ygrp-msg p a span.yshortcuts { font-family: Verdana; font-size:
10px; font-weight: normal; } #ygrp-msg p a { font-family: Verdana;
font-size: 10px; } #ygrp-mlmsg a { color: #1E66AE; } div.attach-
table div div a { text-decoration: none; } div.attach-table { width:
400px; } -->
