aspose file tools*
The moose likes Servlets and the fly likes Migrating OOPerl to Java (or .NET) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Migrating OOPerl to Java (or .NET)" Watch "Migrating OOPerl to Java (or .NET)" New topic
Author

Migrating OOPerl to Java (or .NET)

Jason Hollman
Greenhorn

Joined: Mar 24, 2005
Posts: 3
Hello Ranchers!

I have a large (75k SLOC) application written in OOPerl. My company wants to move away from OOPerl (backed by a MySQL database) to another language and we're considering both Java and .NET. The software is hosted and used by customers in an ASP model. We cannot toss away the old application. Is there a way to migrate to Java (or .NET if people know that technology as well) without disrupting the current version. For example, can we build new modules/services with Servlets/JSP/other Java technologies, run both parts in parallel (as close to one single application as possible from the customer's point of view) and then later rewrite the Perl parts in Java? Has anyone done this? Is it possible? What are the problems we would encounter? What are the limitations? Any benefits?

Thanks in advance for any help!

--Jason
[ March 24, 2005: Message edited by: Jason Hollman ]
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

That's an awfully tough question to answer accurately without really doing an in depth analysis of your app and your requirements.

On the surface, there is no reason why two apps couldn't share the same database.

The devil is in the details though.
Concurrency issues, sessions....

While it might be fun to start a .NET vs J2ee flame war, I doubt you'll really get any information that you can use from a forum (from either camp) in this case.

If you're app is strictly a hosted model, then you probably won't care much about platform independence so the vendor lock-in from going to .NET probably won't matter. On the other hand, if it's written in Perl, it's most likely already sitting on an *nix system.

Bottom line is, you've got a lot to consider and nobody on a forum is going to be able to help you much with it.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
danny liu
Ranch Hand

Joined: Jan 22, 2004
Posts: 185
My company wants to move away from OOPerl (backed by a MySQL database) to another language and we're considering both Java and .NET. The software is hosted and used by customers in an ASP model.

If this is a big project, java seems to be a better option. There are fewer
.Net open source projects provided.

Is there a way to migrate to Java (or .NET if people know that technology as well) without disrupting the current version.

IMO, it is very tough without rewriting the current version. State maintenance is big trouble.

Dan
Jason Hollman
Greenhorn

Joined: Mar 24, 2005
Posts: 3
It's a ticketing / workflow project. Think of it as maybe a bug tracking system or maybe billing system. One person creates a ticket, it gets passed downt he line (often send back for lack of information) and when people get tickets they may take certain actions outside the system.

People will stay logged into the system all day, but there's not much session state to be maintained, e.g. long term complex state. They might open a list of current tickets assigned to them and start working on one or two. Obviously during the day that list will change, but tickets take a few to many minutes to deal with. It's not like a lot of state is changing every second. I'm wondering if we can keep all state in the database and just have people refresh often. (There's already a refresh button for this type of reason.)

--Jason
[ March 24, 2005: Message edited by: Jason Hollman ]
danny liu
Ranch Hand

Joined: Jan 22, 2004
Posts: 185
It's a ticketing / workflow project. Think of it as maybe a bug tracking system or maybe billing system. One person creates a ticket, it gets passed downt he line (often send back for lack of information) and when people get tickets they may take certain actions outside the system.


I am not sure how your old system is implemented. If there are not many session or application states included, you may use the following strategies to track the state.

a. embed the states into the query string

or

b. for each flow, write a record in your database which memorizes all
related state informaton. As such, your perl or jsp page may easily access
this information via a serial NO. (e.g. an order ID)

Dan
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1821

Again, the answer all depends on the architecture. Certainly if each app used the other as a webservice, it wouldn't care about the technology driving the backend. If the old app was modular, then the new app could just gradually overtake each of the modulaes of the old app. If they used the same locking mechanisms, then they wouldn't case that they share the same database. If they had some eggs, they could have ham and eggs, if they had some ham.

That's a lot of ifs. Theoretically, it is possible.

BTW, Welcome to JavaRanch, Jason. Hope you enjoy your stay.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Migrating OOPerl to Java (or .NET)