Challenge: Simplest VFP web application EVER! 2

[dantre]

Hello,

Can anyone show me the absolute simplest way to call a VFP function which is housed on a web server from a client computer via a web browser?

Restrictions:
No ASP allowed. FOXISAPI confuses me (if you can make it simple, be my guest). No pay tools (i.e. WebConnection/WestWind).

Objective:
I'd like to be able to submit a name string, using an HTML form, to some VFP code (DLL/EXE/Whatever) that is sitting on a server. The code would then return a custom greeting, like...

RETURN "Hello "+cName+"!"

...to the web browser.

Is this possible?

The closest I've come was to create a COM DLL and then use VBScript CreateObject() to access it. The flaw with this is that, I believe, the client machine must have the DLL registered. Also, it requires that the user enable ActiveX (therefore it only works in IE, and may be perceived as a security threat). The ActiveX part I can deal with, however. But I can't ask every user to register a custom DLL.

I'd be very interested to see what we can come up with. This could make a great FAQ if we succeed.

Thanks in advance! -Dan

 

[Mike Gagnon]

Otherwise I can test it on mine.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Mike Gagnon]

No, you can't access a .DLL file using the CREATEOBJECT(...) calling method unless that .DLL is registered on the computer running the CREATEOBJECT(...) command.

But if I understand correctly, the webpage will be on the server that the DLL is registered on. I can only assume that the webpage is not at the client's station trying to call a dll on the server. Or am I interpreting this wrong.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Mike Gagnon]

BTW I just got confirmation from Francis Faure of

http://www.atoutfox.com

in France. If the COM (or in his case a COM+) is registered on the web server and the HTML page is also on that server it can be done. That is the way his site runs.
This link is in French, but it is a step by step
demonstration on how to do it.

http://www.atoutfox.org/20041111-iframe.asp?htm=C31.htm

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

dantre, do you have a website you can test this on?

I have a remote host to test on, but I'm having a lot of trouble figuring out if I can register my COM server.

If you have a better means to test this, please do. Thanks!

Also, feel free to use my super simple DLL/VBScript example to test. I'm sure you're already aware of this, but you will have to unregister the DLL on your client machine (if that is the machin you build it on) to be sure that it is calling it from the server.

Let me know how it goes... -dan

 

[wgcs]

Hi Dan, let me answer each of your statements here:

So, these are the key rules for using CREATEOBJECTEX()?

- the web host and client must both have VFP installed.
No, the client wouldn't need VFP... the client would need whatever runtime is executing the script... if vbscript can CreateObjectEx, and your web page has vbscript on it, then the client would need the vbscript runtime.

- the web host must have the COM server registered (and maybe the client as well, or just the type library?)
Right. Since the web host will be instantiating the COM server, the COM server MUST be registered there. This also means that the Web Host MUST be a Windows-based computer: Linux computers cannot instantiate a Win32-COM Server.

As for the client, it seems that having the type library registered can make the connection faster (by reducing the communication between client and host), but isn't necessary. (registering the whole COM object on the client can be equivalent to registering just the type library).


Is there any method that doesn't require the client to install or register anything? Does FOXISAPI require the client to have VFP runtime files?
The whole purpose of "thin-client" (brower) web pages is to avoid having the client install or register anything. FOXISAPI is an example of this: the server calls the VFP COM object, and returns simple HTML to the client... the client doesn't need any VFP runtime (or any other runtime).. the client simply needs a browser that is capable of displaying the returned HTML.

It's starting to sound more and more like I need to start learning a new language...
Well, HTML already is a new language. VFP never was free: all the enterprise-class free active web page solutions are languages other than VFP... Non-free VFP solutions that seem to be enterprise-class are WestWind and Active Foxpro Pages (though I'm not very familiar with either of these).

I have a remote host to test on, but I'm having a lot of trouble figuring out if I can register my COM server.
What OS is the remote host running? It must be a variety of Windows if it will host a VFP COM object. Even if it is windows, you'll need significant administrative priviledges to configure ISAPI.

Also, feel free to use my super simple DLL/VBScript example to test. I'm sure you're already aware of this, but you will have to unregister the DLL on your client machine (if that is the machin you build it on) to be sure that it is calling it from the server.
The whole problem of your vbscript example is that it is not a web application: it is instead a vbscript client-based application that uses DCOM to access a web service.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[wgcs]

Dan,

I'd recommend you start your own, local, host.

1) Install sambar server from here:

http://www.Sambar.com

(it's free for personal use, and supports ISAPI..I've run it for years)

2) Place FOXISAPI.DLL into the cgi-bin directory under the Sambar directory (find it here: c:\Program Files\Microsoft Visual Foxpro 8\Tools\FoxIsApi\FoxIsApi.DLL

3) Build and register the FOXWEB.DLL example found at C:\Program Files\Microsoft Visual Foxpro 8\Samples\Servers\FoxIsApi\FoxWeb

4) Test your new ISAPI/VFP server by browsing to this page:

http://localhost/cgi-bin/foxisapi.dll/foxweb.server.hello?fred

That's it. I know you said ISAPI confuses you, but I think that if you get clearly in mind how the stuff goes together, it'll make sense.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[dantre]

Thanks Bill!

Would Sambar be easier than just installing the IIS component?

I've never run a server before. Is it neccessary that I have a computer that is dedicated as a server? I only plan on using it for casual testing, is it OK if it is my main home PC? Or behind a router?

I'm decent with VFP and a lot of web laguages, but I am clueless when it comes to servers. But I have a feeling that it's one of those things that isn't that difficult once the mystery is taken away.

BTW, my host is using a UNIX box so ISAPI is not possible there.

 

[wgcs]

I find Sambar much easier to configure and adjust than IIS. It's lack of popularity also makes it a smaller target for hackers/worms.

I run Sambar on 2 regular desktops behind a router (two different routers), and I run IIS on my notebook (just to compare ease of management).

As far as I can tell, once you get ISAPI configured (which is completely different for Sambar and IIS), the VFP COM DLL couldn't care less which one you use.

I agree with you: servers become very simple once the mistery is removed. The first step is recognizing that the old paradigm of "client" v/s "server" isn't enforced over the internet... as far as TCP/IP is concerned, Every computer that has an IP address is a "Host".. a server (this wasn't always the case, for example on LANs running Netware or on AS/400 systems, there definitely were dedicated servers).

The client/server paradigm is therefore now just a pattern, and one that very often not followed.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[Mike Gagnon]

You can do it through your local host (providing you install IIS which is free if you don't have it on your computer installed.) And to test on your own computer, you use this:

http://localhost

And this would be tested from someone else computer on the same network.

http://192.168.100.1/

&& Whatever your IP adress is.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

So, Mike, it works?

Just HTML,VBScript, and a COM DLL?

No Client-side installation/registration required?

 

[dantre]

I installed Sambar and tried to test this...

when i open the html file from the sambar docs folder in IE it works, but if I try to access the exact same html file as as

http://localhost/test.html

i get an error, ActiveX can't create the object.

Any ideas?

 

[Mike Gagnon]

So, Mike, it works?

Just HTML,VBScript, and a COM DLL?

It does for me, but not as regular registered DLL, but as a
COM+ (webservice) as described in the link above (sorry its in French) and so is this one

http://www.atoutfox.com/articles.asp?ACTION=FCONSULTER&ID=0000000079

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

My French is a bit rurty...

How do you install/register a DLL as a COM+?

Not with REGSVR32?

 

[dantre]

um, I meant "rusty" not "rurty."

So I finally figured out how to install the dll/tlb as a COM+ application using the component services manager.

It's still not working for me (via localhost)

Did you modify the code of the class definition at all? I just built the dll as a multi-threaded DLL COM, then I added it as a COM+ application, then I loaded the html page with the VBScript CreateObject method on it.

I get "Error: ActiveX Component can't create object:'test.myclass'"

I can't see what I'm missing... Is the only thing that makes our dll a COM+ application instead of a COM object, the fact that we installed in the component services manager?

 

[dantre]

Ah, I didn't publish the DLL using the web service wizard in VFP, as in your tutorial.

I get the error "SOAP toolkit must be installed" when I try to use the web service wizard. So I installed the SOAP toolkit 3.0 from microsoft.com and I still get the error. Ack! I'm destined to fail...

 

[Mike Gagnon]

dantre

And now you might understand why I said this isn't material for an FAQ. There are many components and many techniques that you need to understand before this "simple VFP web application" works under most conditions. It is way beyond a good understanding of VFP, as you mention it is like learning a new language. The VFP part is the easy one.
The only thing I can say is I have created a COM+ webservice in VFP to retrieve a zip code based on a street address, and once registered, this COM can be accessed from a Wedsite. Also the site the I mentioned above does use this technique as well. So yes it is possible to access VFP type DLL (COM+) from a web page, but all parts have to be in place and configured properly.



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[dantre]

Yeah, I guess so. I just feel like it's unneccessarily complicated. So I'd like to demystify the process for people who'd like to run some VFP code in a website. Maybe I'm trying to take the easy way out, but I don't feel like everyone needs to have an in-depth understanding of web services and COM+.

Mike, just to be sure, did you use the web services wizrd to get it to work?

Thanks for your tutorial, eventhough it is en français, it was very helpful.

 

[wgcs]

I hear ya, Dan,

The trouble is that the "magic" of the web (meaning the astounding inter-operability of millions of websites) is that all communication between the browser (running on any OS) and the webserver (running on any other OS) happens over a simple serial connection pipe on port 80.

On the other hand, all kinds of "magic" happens (meaning: very complicated stuff that never gets revealed to high-level programming languages like VFP, VB, C#, ASP) to make ActiveX (or DCOM) work so "seamlessly" between Win32 application components.

The two systems are fundamentally different from each other... even if you got VFP working using DCOM, there's no guarantee that all your users would have all the appropriate ports open that DCOM uses to communicate from client to server... I don't even know what ports are used (though I'm sure it's documented somewhere). But it's clear to me that the Win32-based solution of remotely instantiating an ActiveX control on a server will eventually (pretty quickly) encounter problems, considering the wide variety of clients, servers and firewalls that would have to be traversed.

(BTW: When Mike calls the VFP component a "web service", I'm pretty sure he simply means a service accessible over the web... not a SOAP/WSDL "Web Service" such as the Web Service Wizard would produce.

The commandeering of the term "Web Service" by the SOAP/WSDL backers has made this general term somewhat confusing.

The purpose of SOAP is to take what would be a COM/DCOM object method call and "serialize" (encodes) it into an XML stream that describes what the object method call should be made, than pass that text-based XML stream over port 80 to the server, where the SOAP server "de-serializes" and actually performs the object method call.

DCOM ignores this step: the object method call is made directly (using who-knows-what-protocol over who-knows-what-port) from the client to the server.


It can all be very confusing.. but that's what Microsoft's .NET initiative is all about... I believe their original concept was: Users aren't caring about their OS anymore, so lets try to make Microsoft Windows.NET the new Internet Operating System. We'll make it so easy for programmers to call web services that it's just like writing a local program... BUT the Users and Servers will all have to run on Windows!

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[Mike Gagnon]

(BTW: When Mike calls the VFP component a "web service", I'm pretty sure he simply means a service accessible over the web... not a SOAP/WSDL "Web Service" such as the Web Service Wizard would produce.

Just to clarify, I meant SOAP/WSDL "Web service". A VFP COM DLL installed on the web server that can be called both from the web page and a VFP application. You will note in the article I posted, the code is distinctively SOAP type.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[wgcs]

Sorry, Mike. I should have read your tutorial...

- Bill

Get the best answers to your questions -- See FAQ481-4875.