Hi Rafal, That depends on the rules and patterns that are followed in your organisation. It's the architect's decision. Typically, the ESB is used as an integration engine connecting different systems together, where the systems are responsible for implementing and encapsulating business logic as services which are then exposed within the ESB.
That design allows for a cleaner separation of roles and governance overall. It is also aligned with SOA Principles. I'd say that is the industry "best practice", but should not be a rule of thumb because the scenario in your organisation may perfectly justify a different architectural blueprint. You can always encapsulate custom business logic within beans in the ESB, but I recommend you take your decision holistically, considering organisational structure, risks, technical factors, ownership, roadmap, maintenance, etc. Hope this helps. Regards, Raúl. 2011/10/5 Rafal Janik <[email protected]> > Hi > thanks for the reply. > I understand the differences between BC and SE. > My question was just about "best-practises" in SMX - about including logic > which is not an integration stuff: if it's a true we should try to avoid put > into SE such logic? > > rafal > > > > W dniu 04.10.2011 20:09, Łukasz Dywicki pisze: > > In JBI spec service engines are places where logic should be implemented. >> Binding components are responsible only for protocol adoption (eg from http >> to nmr, from nmr to ftp). All other operations, including transformations, >> complex routing and message formation should be implemented as service >> engines. >> >> Pozdrawiam, >> Łukasz >> >> >> >>> Hi >>> >>> >>> I have a question regarding Service Engines role in integration process. >>> Should they just transform the message and do a simple operation or they >>> may be responsible for the huge logical functionalities? >>> >>> >>> >>> regards >>> >>> >>> >>> >> >
