Imagine a C++ framework as a business layer, but with controlling logic as well. E.g. user rights, state of the webflow etc. With some plain C code to access DB2. The whole framework is host based. We are looking for a way to replace the existing framework gradually with a java framework. The main challenges are: the application is already huge, there are several application clients connected to the c++ framework at the same time (it's one web application with many instances), my knowledge of what is possible today with java on host is very limited (since all people I work with stick with C++)

Do some good ideas exist for gradually moving the old framework without breaking existing code?
I guess as entry one would expect a web service or RMI server for transactions. But how to replace the business/controlling logic gradually is still a black box to me.

What is the reason for replacing? Technical or political?
–
user1249Jul 5 '11 at 7:25

i think both... honestly: writing code, compiling, transferring, recompiling and getting new errors isn't exactly fun. On the other hand a reason why my boss thinks it is lethal to switch is because 'everyone else is doing a company standardized java project'
–
ToskanJul 5 '11 at 14:59

1

consider learning the native tools. You might find them easier. Also, tedious work is not necessarily fixed by reimplementing things in another language - you might find that the amount of work is much much larger than you expect.
–
user1249Jul 5 '11 at 15:01

1

Migrations from a legacy code its a very difficult task, many companies, actually avoid it, but, sometimes fixing existing errors become more programming-time expensive that making a new one...
–
umlcatJul 5 '11 at 21:57

2 Answers
2

Honestly this sounds like technology for the sake of it. Its one of the main reasons why businesses mistrust their IT departments.

Look at at from the business point of view -- you want to do a ton of work, which will almost certainly introduce a new set of bugs, and, end up with a system that does the same as the current system but more slowly.

I wouldn't suggest you write a new system in C++ anywhere on any platform, and Java has superlative support on the mainframe (assuming you mean IBMs Zos) so it would be a good choice for a new system.

But if it ain't broke don't fix it.

If you really want to go ahead with this then you need to do:

Use Websphere application server (runs in USS so its mostly the same JAR files as any other websphere application server.) which will provide you with a ready made framework.

Avoid using the fancy EJB beans to access the DB2 data, stick with POJOs and plain SQL to access the existing DB2 tables. IBATIS is a good bet to ease the ORM coding.

Use the existing DB2 database as the main communication medium between the 'old' C++ and the new Java components.

Where you need more direct communication between the old and new applications use MQ if possible it's easy reliable and works anywhere, avoid JNI, RPC and CORBA as they will dump you in a world of pain.

Do not redevelop components piecemeal, choose a business function and refactor everything related to that function.

We just completed a similar project. Our solution used DB2 and stored procedures as the common access point for application level services. The legacy code, COBOL in this case, maintained access to the functionality provided in the stored procs and newer Webshpere apps access the same functionality (a business requirement).

We will probably never be able to get rid of the legacy code in its entirety (batch runs at night) but we are slowly moving toward a full Java stack.

can you maybe go into detail on what websphere products you used?
–
ToskanJul 19 '11 at 9:10

It is WAS7 running on z/Linux platform. RAD7 used to develop the EJBs that managed the transactions and data access to DB2 (standard VO/DAO data layer). The front end is all HTML/Javascript driven by Struts.
–
Ken BrittainJul 20 '11 at 18:02