• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Migrating OOPerl to Java (or .NET)

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic