[thelist] Looking to move from ISAPI to something else

[Ken Schaefer]

OTOH I would suggest sticking with Visual Studio.NET and ASP.NET

You could invoke your COM+ objects (assuming that's where you move your
existing ISAPI code) via COM Interop. I believe the debugger in VS.NET will
let you move between managed and unmanaged code.

Cheers
Ken

--
www.adOpenStatic.com/cs/blogs/ken/ 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: thelist-bounces at lists.evolt.org [mailto:thelist-
: bounces at lists.evolt.org] On Behalf Of Roger Ly
: Subject: [thelist] Looking to move from ISAPI to something else
: 
: Hey all,
: 
: I'm doing some research into possible alternatives for
: technology used to build our company web site.
: Currently, we are working on IIS with Oracle.  We have
: built our site with ISAPI extensions written in C++
: running on top of IIS.  We have developed a proprietary
: scripting language on top of that to help us partially
: separate some of our business logic from the
: presentation layer displayed to the end user.  While
: this has been a decent solution thus far, we are
: investigating the possible move to another solution
: that has a more powerful scripting front-end, while
: still being able to use and support any legacy business
: logic we have already developed.
: 
: Some of the things that are required by us:
: * We will still remain on the IIS platform
: * We still need to interface easily with Oracle
: * We want to retain some legacy code we have written in
: C++ and exported into DLLs (access via COM or something
: similar would be ideal).  There is no need for us to
: re-write our billing libraries, for example.
: * We would love to keep a good deal of
: presentation/business logic separation.  Being able to
: hire HTML developers who don't necessarily understand
: how our legacy code works, but can still design and
: build functional pages would be a plus.
: * Being able to easily debug and profile things as we
: run into a problems is a must-have.
: 
: I have currently been doing some in-depth investigation
: into the different areas I have some experience in:
: JSP/J2EE, ASP.NET, PHP and ColdFusion.  For most of the
: points above, I think using these technologies as a
: front-end scripting-type language would suffice.  For
: all of these, the presentation/business logic
: separation is a matter of education on the development
: teams part, they all can be used to separate the two,
: but of course, they all can be used incorrectly in the
: opposite way.
: 
: The two biggest desires are access to legacy C++ code
: via COM (or something similar), and tied with that, the
: ability to easily debug and step through problems with
: the code, both on the scripting side, and as it makes
: its way into the legacy libraries.  Since our current
: scripting library is written in the ISAPI extension
: layer, debugging just requires us to attach to the
: current ISAPI process, and walk through the code.  As
: we separate things out into two different technologies,
: it will become more difficult to attach to the JSP
: engine, for example, and then when it attempts to make
: a call to an outside library, attach to that library as
: well so we can see how everything is working.
: 
: Does anyone here have any practical experience on the
: matters that I have brought up?  Can you point me to a
: good set of resources to help continue my research?