Where should application-specific persistence be located?

[jbx <jo...@gmail.com>]

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.