How to provide and consume services towards Legacy applications?

Hello,

I need to advice upon an architecture roadmap for our legacy applications.

The core legacy application is a set of servers waiting for requests (each on their own dataqueue), and a set of (RPG)-programs that need to be called in order to perform a specific action.

Remember that we intend to use this on an iSeries (AS/400), and that the history told us that Java on iSeries has to be dealt with very carefully.

As far as I can see now, I would propose following strategy :

- A service layer is deployed (a 'container-based' application) besides the current legacye applications
- Spring is used as lightweight framework.
- Initially this service layer will only have limited functionality (transformation of messages, & message broking)
- gradually more and more functional services are deployed.
- Finally we intend to have full applications in this service layer, which would lead us in the direction of a SOA


Consuming Services
A service in this service layer needs to communicate with the legacy applications (by means of dataqueues, Corba, program calls,...). Although I am new to Spring, it seems I can quite easily configure such access to legacy applications.

So at the 'bottom' side of the picture there is no real problem.

Exposing Services
But I cannot figure out how the layer can expose services easily.

- I used xFire to expose a webservice (JSR-181), and that works fine. However we intend to limit the use of webservices, to avoid possible performance issues.

- Furthermore I want to expose a service by listening on a dataqueue.
There seems to be quite a variety of ways to achieve this, and I cannot find the most simple way :
I tried to get http://www-128.ibm.com/developerwork...ry/wa-spring4/ sample up and running, but there one talks immediately about JNDI lookups etc.

- Do we need JNDI lookup, or can I simply configure everything in the config file? (Because this is currently a proof of concept, I don't mind to have some configurations twice, as long as we have a 'streamlined' architecture).

- Should we try to encapsulate all accesses by means of JMS, or should we use the 'naked' dataqueue API's as provided by IBM's JTOPen library? One reason to use the naked version might be performance.

- Should I restrict myself to Spring, or when should I start experimenting with an ESB like Mule?

- Can we expose some Corba-based beans to the outside world? or is this just a very bad idea of a newbie?

Database access
The service layer will have its own database, but it needs to retrieve data from the legacy databases also.

- All retrieval in legacy db is performed by means of Hibernate.
However the mapping of some legacy database tables (towards the new class model in the service layer) is not feasible, and in that case JDBC might be considered as a workaround.
- All database updates (in legacy db) needs to be performed by calling the appropriate services (dq-access, or program call)

In this way, the service layer is linked towards the database layout of the legacy applications.

Does anybody have good tips concerning this version-management between 2 applications:
The mapping files cannot be deployed in the legacy app jar file, nor in the service layers jar.
I intend to isolate the mapping files in separate jar's : this leads me to one jar file per <allowed> combination ( legacy app / service layer)

User Interface
We do not intend to provide any java-web clients. Company policy enforces the use of .NET (Winforms clients as well as ASP.NET browser based).

These client applications currently communicate with the legacy applications by means of :
- dataqueue requests (synchronous / async)
- Corba
- webservices (in future - probably very limited use)


I welcome your suggestions...

Regards
Luc