As you know, PDM has a website – www.oilit.com. This was originally developed using Microsoft Front Page, which is supposed to remove the need for server side programming. Because HTML is “dumb”, server-side programs are required when for instance, a website visitor fills out a form, or performs a full text search across the site. Of course there is a snag in using Front Page (FP). Your internet provider has to play ball and run an FP compatible server. This can be done in two different ways.
Either the internet service provider (ISP) goes the whole Microsoft hog and runs everything on Windows NT with the Microsoft Internet Information Server extensions, or they elect to run FP extensions on their regular Unix boxes. You have to remember that most websites run the Unix/Linux Apache server. My provider, Verio, runs the FP extensions on a Unix box, and they work OK, up to a point.
Unfortunately, if you want to tailor the FP search engine even a little bit, you enter an inexorable logical path which Microsoft expects you and your ISP to take. It goes like this. One – you want to use FP to do your server side stuff? Just get your ISP to run the FP extensions on his Unix box. Two – you want a bell or whistle or two more out of FP? Just get your ISP to throw away the Unix boxes and move to Windows NT.
In other words, through a series of ‘gotchas’ Microsoft, expects the end user to force the ISPs to jettison Unix! Or perhaps I am seeing a conspiracy where there is none. Maybe Microsoft just forgot to include the bells and whistles in FP by accident. But it hard to understand why Microsoft, whose success is based on supplying massive functionality to the end-user, should now turn around and start playing to the centralized IT manager’s gallery. But I digress...
Faced with the dilemma of either upgrading my account with Verio (they do run a few NT boxes..) or installing my own server-side search engine on my Unix account (a hassle), I stumbled on another solution – ASP. PDM has been investigating application service provision for the past few months, now we had the chance of putting it to the test ourselves. Text searching is a prima facie candidate for ASP. Apart from avoiding the hassles mentioned above (you no longer either know nor care about what system is running whose software), you can expect to have a configurable search engine, professional looking output, and hopefully, more bells and whistles than your vanilla search components à la Microsoft.
Go to it
How does it work? First you fill out a few forms on the ASP website – telling it what directories to search and chosing a presentation format. Next you tell the ASP’s indexing motor to go to it. This took around an hour for the 1000 or so pages on the oil IT.com website. Next you cut and paste a few lines of html supplied by the ASP into your web page. That’s it! Now when a users launches a query on the PDM website, the query is actually carried out on the ASP’s machine, which returns a professional-looking list of hits worthy of Alta Vista. We can even use the search from a ‘dumb’ page of html on a local machine – no need for extensions of any sort.
So far we are pretty happy with the service (from AtomZ.com by the way). It does cost money, but has removed a thorn from our flesh. Seductive as the ASP logic is, before you outsource all your enterprise portal’s search functionality to an ASP there are a few mindsets which will need changing. It is exciting and quite easy to see how IT resources have become virtual, and how you no longer need to worry about what is being done how or where.
But are you going to let a third party index (and potentially read!) all your contracts, tenders, joint venture agreements, and other sensitive information? The ASP would no doubt claim that their contractual engagement and security ensures confidentiality. They probably never read any of the material they index! But I think it will be a while before all this activity is outsourceable. Which leaves the portal manager with the following problem. If you have to manage a part of your corporate information internally, then you might as well do it all!
So to conclude, how about a business opportunity. ASP-ed ASP! What is required in such circumstances is for the ASP to provide and maintain the binary, but to let the end-user run the program on his/her own machine. With the separation that the web imposes, and good design, it should be possible to upgrade and maintain the binary remotely and offer the security conscious end-user the assurance that mission critical information was not being perused off-site.
© Oil IT Journal - all rights reserved.