Thx Michael,

but that doesn't really help me, does it ? What's your recommendation for the 
problem I described ?

The other thing: what do you mean by "not putting the ESB between consumer and 
provider" ? where should the ESB sit if not between those facilitating 
interoperability on all levels ?

thanks a lot, nick

--- In [email protected], Michael Poulin 
<m3pou...@...> wrote:
>
> 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 <monohus...@...>
> 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
>


Reply via email to