When considering a full application with the presentation layer (with servlets/JSP in Tomcat for instance) and an ESB to interact with legacy systems, where should 'higher-level' application-specific persistence located?
Is it done by the servlets, is it done by another platform such as EJB on J2EE, or is an SE 'allowed' to do persistence too even though the definition states that it does not communicate with the outside world? In all tutorials I saw so far, the Service Engines are always stateless and volatile, just performing orchestration, routing and transformation etc. without persistence. Lets take the example of a simple 'Fund Transfer' application (for example along the lines of this tutorial: http://www.packtpub.com/article/aggregate-services-in-servicemix-jbi-esb) which makes use of finer grain Debit and Credit operations on external systems. In reality, just calling the BC operations on the isolated legacy systems is not enough. For example, the BPEL Business Process handling the balance transfer needs to persist the 'higher-level' coarse-grain transaction information somewhere, which is independent from the fine-grain services underneath. For instance, for the Fund Transfer business process, we need reply to the user with a 'fund transfer' transaction code (not the fine-grain transaction codes for each credit and debit operation). The user can then perform other business processes such as Query Transaction History, or the outcome of that particular fund-transfer transaction (imagine if he is transferring funds to another bank, and clearance takes a few days). I know one can do this wherever he wants, but what is the best architectural approach to this to ensure proper SOA practices? -- View this message in context: http://www.nabble.com/Where-should-application-specific-persistence-be-located--tp16583061p16583061.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
