I'm not familiar with the failures of going with CDM, but we have many customers who have successfully used our Progress DataExtend SI product. It and tools like it are much less complex to maintain than going with the data model transformation patern.
David Cleary Progress Software --- In [email protected], "monohusche" <monohus...@...> wrote: > > Hi there, > > I tried to find existing topics around the aspect of transformation within > the context of an ESB, but wasn't really successful, so here it is (pls point > me to past threads if relevant). > > We are in the process of setting up our SOA framework (context, reference > models, architectures etc.) as well as our SOA strategy (maturity assessment, > target state, roadmap, governance model). > > So one question that keeps popping up for me is the aspect of loose coupling > at data/message/semantic level. If we are aiming to loosely integrate service > consumers with service providers in the future, we know this requires > isolation at various levels, we also know that the service consumers and > providers won't be necessarily greenfield developments but could be legacy > apps as well as COTS packages. > > So, it is very likely that all of those will have a different understanding > (syntactically and semantically) of the information objects involved in > service calls which requires transformation which normally is considered as a > platform service within an ESB (providing the access to a transformation > capability). > > Let's say, I have 5 service consumers and 5 service provider all partly > dealing with customer information. The assumption is that all service > consumers use all of the service providers. The other assumption is that all > of the parties involved (consumers and providers) have proprietary internal > representations of customer data. > > If I follow the data model transformation pattern by Thomas Erl > (http://www.soapatterns.org/data_model_transformation.php), for me, it would > essentially result in having 5*5 transformation maps (e.g. XSLT stylesheets) > which is just another kind of point-to-point integration. > > Now, one pattern mentioned regularly is the Canonical Data Model (CDM) which > is used as an intermediary abstraction layer where each node translates > into/from it, in this case resulting 10 stylesheets and a proper "bus > structure". On the other hand, it is regularly stated (Josuttis) that > maintaining a centralized CDM is hard to maintain, and already failed during > the classic EAI projects. > > So, what's the consensus around this topic from real-world projects, how to > keep business logic away from the bus, while isolating service consumers and > providers on a syntactic and semantic level ? > > I hope, I didn't miss anything important. > > thx nick >
