by Manohar Kamath
July 25, 2000

Although Active Server Pages is one of the most popular web framework and is very much mainstream, there still lies the limitation of operating system dependence. A few vendors created third-party tools that would let you run ASPs on systems running operating systems other than Windows. ChiliSoft was the first to introduce the first such server way back in 1997 (as I remember). Instant ASP, another such product from Halcyon Software, gives us the same promise of running ASPs on any platform of your liking.

I had a chance to talk to Naufal Khan, the Vice President-Engineering at Halcyon Software, about the Instant ASP product and their strategies on making this a successful product.

About Naufal Khan
Naufal A. Khan serves as Vice President of Engineering and has 7 years of successful industry experience. Naufal oversees Halcyon's entire R&D efforts including research on future product concepts, product development, QA, and on-going development of enhancements and features to existing products. Prior to joining Halcyon, Naufal served as a technical advisor at Business Objects, where he was responsible for various customer research projects and supporting large accounts requiring time-critical problem solving. He holds a BS in Electrical Engineering & Computer Science from UC Berkeley.

Manohar: Hello Naufal, welcome to Active Server Corner. How did the instantASP product come about? Was there any"inspiration" from chilisoft's ChiliASP by any chance?

Naufal: Instant ASP was the next 'natural' step for us. We already had products by the name Instant Basic for Java (IB4J) and Instant Converter.  These products provided VB to Java migration.  In fact, IB4J was a complete 4GL development environment written in 100% Pure Java, could execute
on any Java platform, and generated Java bytecode from VB source code.

With application development taking a server-side, thin client focus, and even Microsoft introducing ASP, a cross-platform ASP product made very good sense - especially given the fact that a majority of servers out there are not Windows machines (and in those days especially, PERL/CGI route was quite painful - it still is, compared to ASP).

Furthermore, we had already been looking at server-side scripting frameworks and considering ways to leverage our existing compiler & Java
technology/expertise on the server.  We already had VB based products and I personally view ASP doing for the server side what VB did for client-server.  Therefore, it just was a very natural market for us to evolve into - and it made (and proved to have) darn good business sense.

As for Chilisoft, we became aware of them during our initial market research process.  They had a good lead but looking at their platform limitations and compatibility problems, and our own expertise in this segment (VB/compiler/interpreter development) and experience doing similar products (IB4J, Instant Converter, Instant Basic Script), we were confident that we can take lead. They were also missing the Linux platform which, at that time especially, was critical.  It turned out that we were right and we have our customers and developer community to thank for it.

Why did you consider to port ASP to many platforms? Why not ColdFusion which is a great competitor to ASP?

Once again, doing Instant ASP was right down our alley - given our past product line and experience.  This was a big reason.

Furthermore, there were other factors:

1. ASP is easier to use than Coldfusion
2. ASP is free and comes with the OS
3. Plenty of development tools out there
4. MS is behind it
5. Cold Fusion was not quite as popular as ASP.

All these factors indicated that ASP will ultimately win the server-side framework war over Coldfusion.  Secondly, we just didn't see MS going cross-platform with ASP :), and this meant that ASP developers will always be limited to IIS and NT.  Our whole idea was to take them to ANY platform they want - be it AS/400, NetWare or Linux - and let them run in a scalable and reliable manner - something that NT/IIS couldn't provide (especially on high-traffic sites).

What would however be interesting is to see Coldfusion support ASP - they already have JSP support and with ASP support (perhaps from a 3rd party vendor), they can certainly increase their market size.

Technologies evolve very quickly. So, building a product which tailgates another tool, isn't it quite challenging to follow-up any updates to ASP? Example. If Microsoft decided to add a feature to ASP tomorrow, how would you reflect this in instantASP?

That's an excellent question. And yes, you are absolutely right - it *is* challenging.  However, I believe our developers have done a remarkable job at keeping at it and providing timely updates.  There were certain ASP 3.0 functions that we provided in our products when they were being tested in by its beta users.

All our products are heavily customer-driver and this is one area where user feedback becomes very important.  We strive to be highly responsive to them and maintain a close relationship with them (its not unusual for us to provide fixes and enhancements within a few days).  If customers request an ASP upcoming feature, we give it special priority and make every effort to make it available.  This is in addition to our own 'watchdogs' who look out for and evaluate new features.

Coming soon, in the enterprise version of Instant ASP, we are going to provide support for load balancing and clustering (allowing different instances of iASP to share session/state information).  These are features that MS has planned for ASP+ which won't be out for quite some time.

Your product information says "build once, deploy anywhere". How would a developer take into account that things like ADO that are available on NT platform, may not be available on other platforms?

From our past products and being in the migration business for this long, we learned that that for a migration product to be successful, the migration & porting path must be simplified for the user - all hitches & obstacles need to be anticipated, and solutions/workarounds provided.

This motivated us to take the challenge and provide complete compatibility, as much as technically possible, on a non-Windows platform.  We developed complete equivalents of the built-in objects and installable components in Java.   In short, the objects that Microsoft ships ASP with, are also available in iASP.  These include ADO, CDO, Filesystem, etc.  The ADO is built as a JavaBean and provides access to any database which has JDBC/ODBC drivers available for it.  iASP also provides custom database connectors which take advantage of database and driver specific features to provide faster access and improved functionality.

In addition, Halcyon provides about a dozen add-on components based on popular 3rd party ASP components.  These components were built based upon users' votes on the 3rd party components that they use and need the most. These include components such as iASP_Mail, iASP_Grid, iASP_Chart, iASP_Sock (socket communication) and others.

Could you provide us with consumer interest in say instantASP version for AS/400 versus the version for NT? It's my belief most applications are written for either NT or UNIX systems, so why bother with AS/400 version?

Oh, you'd be surprised. AS/400 is one of our very popular platforms - in fact, we have sold more copies on the AS/400 platform than NT.  There are several reasons for it.  For one, AS/400 is making a very strong comeback in the server market - and when it comes to reliability and scalability, it has very few rivals.

Secondly, IBM has done a remarkable job with Java and with their app server solutions on the AS/400 platform.  iASP, with its ability to execute as a servlet, integrates very nicely with WebSphere on the AS/400 platform.

Instead of buying and maintaining a gigantic NT cluster, our users can put up a single AS/400 box which will not only serve ASP applications in a reliable & scalable manner, but do tons of other server side stuff using IBM's server side solutions - all of which are integrated into their iASP application.  Plus, if they want, they can still take advantage of their NT COM/DLLs using our RJAX (Java to com/DLL bridge) product.

What percentage of the functionality carries over from Microsoft's ASP into instantASP? Are there any "bonuses"? Is there any benefit in running instantASP on Windows NT?

Practically everything that can be supported on a non-Windows system is supported.  This means that Windows-specific features that don't make sense on non-Windows platform will not be available there.

There are certain bonuses.  For once, with iASP, users can connect not just to ActiveX/Com objects from their ASP applications - but they have a variety of options.  They can connect to Java classes, JavaBeans, EJBs, etc. - all as if they're using intrinsic ASP objects (using the good ol' CreateObject function).  Another bonus they get is with database connectivity.  Not to mention, certain areas where MS ASP was weak, we provided our own enhancements.  One such example was single apartment threading - in iASP, they can either do singe apartment threaded access like MS ASP or use a multi-threaded access like in Java.

There *are* some benefits to running iASP on WinNT - the first one is the ability to run the server of your choice.  For instance, if a user wishes to use Xitami or some other webserver and still provide ASP support, they have an option to do so.  They get all the other benefits that I just explained in the "bonuses" part.  Furthermore, with the Enterprise Edition, their ASP pages will be compiled to Java servlet bytecode - this results in blazing fast performance along with scalability and reliability.

Linux seems to be a hot operating system in the market, and most of the things are free. Doesn't it make sense to give the Linux version of instantASP for free and grab a large market share?

This is another excellent question - and quite frankly, one that we've pondered over on more than one occasion - and the verdict is not out yet.

Currently we do provide a free developer's edition which is a fully functional, non-time-bombed version - the only limitation it has is the number of concurrent connections.  This was largely done to allow developers to test and write their apps on the iASP platform.

While many server technologies ARE free on the Linux platform, the landscape has changed over the last few years.  More and more products have appeared and most of them are being sold in the conventional manner. So far I can't recall losing any sale simply over the nominal price tag. If there are any non-profits organizations or educational institutions then we do offer substantial discounts (or even free if necessary).

However, this remains an issue that we revisit occasionally and things may change in the future.

What's that developers must understand before they start using instantASP: code changes, special calls, etc.?

The one thing they need to be aware of are any OS specific dependencies in their applications.  For instance, if they're using any native DLLs which
obviously will not automatically port to a different platform.  In this case, they will need a product like RJAX or port the native binary themselves or hire our services organization to do it for them.  This, by far, is the only major issue they need to consider - and, in our experience, they usually do and hence, the porting  process turns out to quite smooth.

Other code changes are mainly system/environment specific - for instance, if they were originally using ODBC to Oracle, and now using JDBC, they will need to edit their database connection string appropriately.  Most of these minor changes are well understood by developers and we run into few obstacles or confusions on this front.

Related Links:
Halcyon Software, Inc.
Instant ASP product information