An ESB enables service virtualization, which provides many dimensions of decoupling between service requesters and service providers.
An ESB provides a level of indirection and decoupling between service requesters and service providers that enables better separation of concerns. In other words, /integration logic/ (such as protocol transformation, message format transformation, and so on) is separated from /business logic/ (that is, the actual function that a service performs). An ESB can provide virtualized services that can effectively wrap existing application logic with a standards-based service interface. Hence, the ESB helps to bridge the gap between the business problem (that is, providing a flexible set of services that can implement required business processes) and the existing IT environment with all its protocols and formats and existing legacy applications. The data transformation pattern by Thomas Erl, if applied in the ESB layer it would not be point-to-point integration. It will explore the benefits of the ESB such as virtualization of: *Location and identity*, *Interaction protocol, **Interface, **Qualities of (Interaction) Service (QoS) Each pattern has a useful using in some conditions and have some draw back of course and he stated that in his pattern. * * * *The Impacts* of Maintaining the standardization of contract schemas can introduce significant governance effort and cultural challenges. *These would lead to failure in traditional EAI and SOA too. To answer your question of "*how to keep business logic away from the bus, while isolating service consumers and providers on a syntactic and semantic level ?", which is not an easy question to answered, I would suggest the following: Layered architecture for information exchange that blends together existing concepts of Levels of Information Systems Interoperability and Levels of Conceptual Interoperability. Let's distinguish some terminology first: Syntax focuses on a structure and adherence to the rules that govern that structure. Semantics: Low level semantics focuses on definitions and attributes of terms; high level semantics focuses on the combined meaning of multiple terms. Pragmatics: considers data use in relation to its structure and the context of application. Then we have to consider Levels of Information Systems Interoperability: Enterprise, domain, functions, connected, & isolated. Although the LISI models are used successfully to determine the degree of interoperability between information technology systems, they do not provide a systematic formulation of the underlying properties of information exchange. To remady, Tolk, A., and Muguira, J.A. introduced the Levels of Conceptual Interoperability Model (LCIM) in which there are various levels of interoperability between participating systems: Conceptual, Dynamic, Pragmatic, Semantic, Syntactic, Technical, and Stand alone. Syntactic (Introduces a common structure to exchange information,) requires a common information exchange reference model. Semantic (The meaning of the data is shared) requires that a common data format is used. Pragmatic interoperability require that the use of data be mutually understood, where the term “use” is interpreted as the context of its application. You have to choose the best combinations that fit your current and future requirements and plan for them. All the best Ashraf Galal monohusche 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 > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
