Problem:
Customer has a page ASP that accesses a COM Object generated by Net Express. In the Windows environment this works correctly. Now the customer would like to know this solution can be migrated to the UNIX environment.
Resolution:
There is a company, Mainsoft, that has produced the COM/DCOM support for UNIX. They can be found @ www.mainsoft.com. You can see an article on Microsoft's website on this subject:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/msdn_unixcom.asp
However, they would need to solve the following issues:
- migrate or find an ASP web server on UNIX (it may be possible to use: Sun's ONE Active Server Pages 4.0.1 -formerly Sun Chili!Soft ASP-)
- migrate the COBOL bits (calls to Microsoft API's, use of non-portable COBOL routines, names of files... )
- Server Express also has no support for COM/DCOM, so the COBOL COM interface programs that he uses and that are provided with the Net Express class libraries (all the classes that extends "olebase") would need to be re-written by them (to get us to write them, they would have to pay for it) at the very least.
Because the migration would require quite a lot of work and COM is an old technology (Microsoft is pushing now for .NET), it wouldn't be worth the effort in my opinion. I thought about migrating their application to .NET because that would mean that at least the effort of the migration would be to go forward, but even though the .NET environment is available on UNIX/Linux (provided by Novell and Microsoft, see http://www.mono-project.com/about/index.html and http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7462-47D0-8E56-8DD34C6292F0&displaylang=en) the migration would be even more difficult because they would first have to move his ASP to ASP.NET and for this reason alone I don't think it is a viable solution.... even if we did support the clr execution environment on UNIX/Linux (the code would have to be generated with Net Express) but we don't support it.
The only other alternative that I can think of would be to migrate to Enterprise Server, but that would mean even more changes: Enterprise Server does not host COM or Object COBOL classes. So they would need to remove the COM interface class and make them procedural COBOL programs before they could be used Enterprise Server. Then the procedural COBOL program could be exposed as one of the many services from ES (Web Service/J2EE etc..). However, the advantage that this alternative would have is that once the migration is done, they would have portability and they would only have to maintain one source for both platforms, Windows and UNIX, even though this may not be a requirement.
