• All key data must be in the database. If you are relying on anything else for processing or state that might be on the file system or in memory, you'll have to change that since the other side can't see it.
• I believe all database access in .Net is through the framework, so you won't have much control over the way it uses the database. Make sure you test and make sure it inserts and updates in the way you expect. The vendor DB we are interfacing with is poorly designed and in some cases we've had fields inserted with strange whitespace stuff at the end. This can be very confusing when trying to debug. Some tests to look at the db records before and after the new code modifies things might help.
• Be careful as you recreate shared components of your perl system. For example, if you have a share sub that does 'update_user_record' you'll probably need to re-write it on the other side. Make sure it does the same thing on both sides if they are to co-exist for a while. Again, some tests here would help you.
• Timing can be an issue for inserts on the .Net side. The implementation in our vendor product doesn't get back the results of a database commit before it passes control back to Perl. It happens when COM gets around to handling it. We had to build checks into the Perl part to check the DB and wait until the other side was done before it continued along. This could be just a problem with the vendor product.

It should be possible to live in both for a period of time, but the key people on the project will need to really understand all the moving parts of the system. It can be very difficult to support such a system as well, since there are many place to look when things stop working.

The up-side is your group will get a taste of .Net alongside Perl and be able to make some fair comparisons. You'll be able to pass up some good information on how successful the full transition is likely to be.

If your existing codebase is sufficiently modular then you should be able to package the pertinent parts up as windows script components and access these as COM objects from .NET (I can't speak for Java as I have never tried).

More on windows script components in Re: Creating a COM/OLE server

/J\

The directive is to move to Java or .NET. We cannot start from scratch.

I think you need to sit down with your boss and explain very carefully why this isn't possible. Switching programming languages almost always means starting from scratch in some sense. Sooner or later you'll have to rewrite everything you wrote before. There had better be a good reason!

...and of course, it's obvious that there isn't a good reason. If the people asking for this switch don't even care if you use Java or .NET, two completely different systems, then they really have no business telling you not to use Perl!

-sam

I think you need to sit down with your boss and explain very carefully why this isn't possible. Switching programming languages almost always means starting from scratch in some sense. Sooner or later you'll have to rewrite everything you wrote before.

Yes, we are aware of this and know that eventually everything will be rewritten. If it is technically impossible, e.g. trying to run Windows on Univac, that's one thing, if it's just pain and waste, I need to figure out how much pain and waste. It sounds like it is possible, even if not desirable--or do you disagree with the other replies?

...and of course, it's obvious that there isn't a good reason.

I really don't want to start a flame on this; suffice it to say, the decision is made. There are valid reasons for it (not everyone may agree, but it's not simply religious decision or an uninformed pointy haired boss). There are pro's and con's to choosing Java or .NET and I need to evaluate those, too.

--Jason

Since all of your data is in a mysql database, you could write stuff in java that will manipulate that data and perl will see the changes as well.

Of course, it is highly recommended that you not do this, because now instead of having your app split into 3 pieces (web, perl, and mysql) you have 4, or possibly 6 depending on how you look at it. (web, perl, mysql, and java) or (web, perl, mysql) and (web, java, mysql), meaning that you will be duplicating logic. This gets messy when a new requirement is added for a field, then you have to update it in both places.

If you must do this, consider converting the perl code to java or whatever as needed (screen at a time or functional units), and THROW THE PERL AWAY. There should never be 2 ways of doing the same thing, either one codebase or the other should be handling it.

I should clarify...

Yes, I certainly don't want to dubplicate code. There are many modules (here "module" means functional subsystem from the user's perspective). E.g. imagine 6 different people see the tickets and do different things with them. They each get a slightly different view and focus on different parts of the ticket data. 3 modules are done in Perl. We would want to do modules 4-6 in Java or .NET and then go back and one at a time convert modules 1, 2, and 3 to the same technology.

It sounds like this is doable as long as all state is maintained in the database, right? We do maintain session state while fields are being modified, but as long as no two people access the same ticket at the same time it should be ok; even then it's just the usual data concurrency/overwriting issues, and won't cause any type of server state inconsistency (as opposed to potential data inconsistency).

--Jason

Keeping all data (including state) in the DB allows you to develop manipulation programs in whatever language you like. Concurrency will be handled by the MySql server process, so it won't be an issue to you for what server state consistency is concerned.

As for data consistency, you really have to dig into your code looking and take countermeasures regarding possible critical races in UPDATEs. This could be achieved with a custom "locking" mechanism (via an added column, for example), but understand that a lock by a program which is about to die makes the locked data "read-only" virtually forever. Another quick solution would be replacing UPDATEs with REPLACEs.

Flavio

Don't fool yourself.

You're right, I was being a bit casual with terms. Technically we would migrate to Java to C#. I was using .NET because if we go C#, we could use the whole array of .NET tools and services.

--Jason

• Let Apache handle auth, even if it's with mod_perl handlers so that it can be consistent.
• As you write new functionality, do it in Java but running under the same apache using the same auth scheme as everything else
• If you come across functionality that you need in the new Java code that's already been written in the perl sections, rewrite it in Java and change the perl to actually use the new Java (using Inline::Java or something similar). This way you will never have the same functionality in more than one place (or in more than one language). This will also allow you to migrate the old stuff piece by piece.

I think I see this from a different perspective ( I know nothing about Java or .NET and very little about Perl. ) the powers_that_be are asking for a wholesale change in toolset. How well this works depends on the skillset and training of the workers using the tools.

The programmers who developed the existing Perl code have already spent time learning the application, the existing code base, and the available tools. Some company has paid for their salaries while they did this. The programmers have reached a certain productivity level with these tools.

Now you take all the old tools, set them aside, and put in new tools. Their productivity is going to go to zero. In addition mistakes are going to be made. Even if you were to replace the programmers with ones familiar with Java and .NET they would not be familiar with the application nor the existing code base. They would have to spend time getting familiar with the old code. In addition, mistakes would be made in translating from the old codebase.

I'm not arguing against doing it. Like you said there are very real reasons to do it. I'm just pointing out the potentially huge productivity hit and the need for the company to invest in training and tools. If the company does not invest sufficiently in training and new tools then it risks becoming uncompetitive in it's market.

Yes, it can be done, but it also can be done wrong!

You've got to ask yourself: "Which of many areas are the programmers going to be spending their time on? Learning a new language, learning a new methodology, reviewing old code, rewriting old code, rewriting old tools, building new tools, testing?" They can't do all of it. In situation like this I always recommend the company hire outside help to build tools for the programmers to use. Anything to speed up the adoptation of the new toolset. Also in your case there is going to be a big testing requirement so additional manpower will be needed there too.

P.S. Training; Not just training in the new tools but in training new workers in the old systems.

Yes, this can be an issue. But again, it has been considered. by knowledgable people and a determination has been made and those costs are considered acceptable given the benefits.

--Jason

And the benefits of migrating are what? The benefits would have to be pretty spectacular to offset the costs involved (which will be astronomical when you consider all aspects of this venture).

Update: It's sounds an awful lot like Smiling Man or Stef Murky have had a hand in this.