Hi Ashraf, thanks for your answer and pointing out the different research projects and standards in that area. I fully agree with everything what you said.
After doing some more reading, I found quite some good input at the SEI pages, such as this: http://www.sei.cmu.edu/library/abstracts/reports/04tr020.cfm Basically, according to the authors (inline with your statements), reaching technical, syntactic and semantic interoperability already gets you quite a big step towards the required interoperability. Now, looking at technology, technical interoperability should be pretty much there, by using IP on internal and external LAN's. Syntactic and semantic interoperability should be dealt with by the ESB. You mentioned that the service should only deal with business logic, e.g. the function the service performs. But one also would want to encapsulate the service specific mapping logic at the syntactic and semantic level into some kind of adapter, so changes to the service requester and provider (changed database structure, changed communication protocol) and the required changes to the "mapping" layer don't effect the ESB itself. I guess, I always need some kind of down-to-earth example in more technical terms, e.g. how would one structure the required layers and map them to technology (e.g. IBM Websphere Message Broker) ? Are there standards out there which try to tackle exactly those kind of problems so that one doesn't have to re-invent the wheel (maybe SCA) ? thanks, nick --- In [email protected], Ashraf Galal <ashra...@...> wrote: > > 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 > > > > >
