My advice: do not put ESB between business service consumer and business service, it is SOA anti-patter; do not follow the data model transformation pattern by Thomas Erl
- Michael ________________________________ From: monohusche <[email protected]> To: [email protected] Sent: Tue, May 25, 2010 5:58:06 AM Subject: [service-orientated-architecture] Semantic decoupling on the bus 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
