Website that interfaces with Delphi. Which technology?
Arthur Hoornweg
in the near future we want to build a website that interfaces with
some Delphi applications that are running on the same server
that will be web server. The purpose is to present some
data from a data acquisition system (oil industry) to the customers
over the internet.
The delphi applications are currently user-mode programs that generate
all kinds of graphic images and tables.
We want the web server to somehow interface with these applications
so that we can re-use the Delphi code rather than rewrite it.
What would be the best way to get this done?
I have considered the following possibilities:
- Turn each Delphi application into a COM server of some kind (other
technologies such as Remobjects or Midware could be used too)
and let the web server (IIS, for example) directly communicate
with them through either isapi dll's, ASP or ASP.NET
- Extract the relevant units from my Delphi applications and make
ISAPI applications out of them
- Put an Intraweb 9.0 web server inside each Delphi application and
somehow tell IIS that certain pages must be retrieved from certain
IP ports on the same machine and passed on (can this be done?)
- Any other ideas?
-
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
danny heijl
> What would be the best way to get this done?
My preferred technique: I write a Windows service in Delphi that uses an
Indy 9 TIdTcpServer listener to handle requests from the web
application. Easy, fast, inherently multithreaded, stable, scales well.
Each message is preceded by an integer with the length of the message,
so that I can use ReadCardinal followed by a single ReadBuffer for
maximum efficiency.
Danny
---
Del Murray
and provides complete control.
Arthur Hoornweg
> My preferred technique: I write a Windows service in Delphi that uses an
> Indy 9 TIdTcpServer listener to handle requests from the web
> application. Easy, fast, inherently multithreaded, stable, scales well.
I fail to see how that would help me.
How would this enable a web server such as Microsoft IIS to "talk" to
a bunch of Delphi executables on the same PC and pass their results
on to the user's browser?
Arthur Hoornweg
> I have been using webbroker for years with no problems at all. Scales well
> and provides complete control.
Please elaborate.
Can I make the IIS webserver communicate with existing Delphi
applications on the same PC with webbroker?
What I need to do is the following: The user calls a html page
on the IIS web server.
When he clicks a certain link, the web server contacts a running
Delphi application on the same pc and requests some data
(mostly a dynamically generated JPG). The webserver then
passes this image on to the user.
danny heijl
> I fail to see how that would help me.
>
> How would this enable a web server such as Microsoft IIS to "talk" to
> a bunch of Delphi executables on the same PC and pass their results
> on to the user's browser?
The web server application is a tcp client of the tcp service. It
fetches the data from the service as needed and presents it to the user.
I thought this was obvious.
Danny
---
Arthur Hoornweg
> The web server application is a tcp client of the tcp service. It
> fetches the data from the service as needed and presents it to the user.
> I thought this was obvious.
Sorry, it is not. Forgive my ignorance, I have very little experience
writing web stuff.
I've done static webpages in the past and also a few Intraweb projects
in which the web server was actually inside the application, a "remote
control" so to speak, but this is a different beast.
In this case, we want to deploy a standard webserver (IIS) and give it
the ability to query data from running Delphi applications (executables,
not dll's).
Can you explain how I can interface IIS with other processes running on
the same machine?
Del Murray
The problem you have is that most likely your existing Delphi program was
not meant to be "talked to". A Browser only sends a string of text to an IIS
Server. The IIS Server will then examine the text to see what the browser
wants it to do. The browser may be saying "post" , followed by a bunch of
data .. or it may be saying "get", followed by some data. In both cases,
part of the text ususally consists of "what program to use" and "here is the
data to go with it". The IIS Server then either responds itself if it can,
such as a request for a new "html page" or it load a program (specified in
the string coming from the browser) and passes the data to the program and
then the IIS Server and the Browser part compay. The "called" program may
infact send data back to the browser. It builds up HTML, passes it to the
IIS Server and says, "send this to the session that made the request of me".
Then IIs sends it to the browser and the browser interprets the html and
paints it on the screen ... then they part company again. On each request
from the browser to the server, you have to treat the data and the program
as though they dont know each other. THis means that you MUST have a
technique to "save state" on the server so that you can logically follow an
individual user in what he is doing. ie .. which customer , which invoice
etc. We can give you techniques for that if you decide to go the Webbroker
route.
So, webbroker programs are Delphi programs (DLLs) that the IIS Server can
pass data to, or receive data from as it comes and goes from the browser. To
do this, the usual technique is to have in the html page that the browser is
displaying, a "form".As part of the form syntax you will see something like
<form method="POST" action="/scripts/rmwebmain.dll/debtoredit" name="fn">
.... a bunch of html with input fields
</form>
The "Action" portion tells the IIS Server that "rmwebmain.dll" is to be
called and particularly the procedure "debtoredit". This is an entry point
in the DLL. It can have many entry points that handle specific requests. In
the example above, the program "posts" data about the debtor which is
supplied in the datastring coming from the Browser.
So the problem you have right now is that you have no program (dll or CGI
exe module) for the IIS Server to pass the request from the browser to.
Go to www.matlus.com and you will find some good tutorials on how to build
web programs. There are many ways and variations of the ways and this is
just one. I like it because I am not depending on any 3rd party tools to do
any "magic" that is out of my control. It is also very very fast and
efficient and highly scaleable. The dll can read data from a sql server
located anywhere in the network.
There is another way to solve your problem. If your data comes from sql
server then you can enable SSL encoding for the server and make your
application availiable "through" a browser link and have it load and run on
the client computer and reach across the internet just for it's data. There
are two drawbacks here. Once SSL is enabled on a SQL Server then any progams
which access the server, even the local programs, must use SSL to access
it. Of course that is not difficult. The second drawback is that you dont
want to execute queries that return large data sets. The beauty of the DLL /
Webbroker approach is that all the processing is done on the servers and
only text chunks are returned to the browser which theoretically cuts down
on internet traffic.
HTH
Del
Del Murray
of a CGI program. Its less efficient on paper but some friends I have out
here in the webesphere use CGI with very good results. Your application may
be one of them.
danny heijl
> Sorry, it is not.
Yes it is, if you make it so.
> Can you explain how I can interface IIS with other processes running on
> the same machine?
You just write a IIS-based web application (using Webbroker, Websnap,
Asp.Net, PHP, JSP, you name it) where you use a tcp client component
(TIdTcpClient if using Delphi win32, TcpClient or plain Socket if using
.Net, etc..) to consult your Delphi Windows service that contains your
existing Delphi code and that also happens to be a tcp server that runs
on the same machine (or another machine, doesn't matter).
It is conceptually very simple, but if you're not used to network
programming and writing windows services and multithreading you may have
to study a bit first, but this is what keeps the job interesting after all.
There are other possibilities, like using Delphi Active Server Objects
hosted in IIS. This may work just as well for you, and would perhaps be
easier to begin with.
Danny
---
Nils Boedeker
>
> - Turn each Delphi application into a COM server of some kind (other
> technologies such as Remobjects or Midware could be used too)
> and let the web server (IIS, for example) directly communicate
> with them through either isapi dll's, ASP or ASP.NET
>
> - Extract the relevant units from my Delphi applications and make
> ISAPI applications out of them
we use both... COM and ISAPI...
Nils
Arthur Hoornweg
> You just write a IIS-based web application (using Webbroker, Websnap,
> Asp.Net, PHP, JSP, you name it) where you use a tcp client component
> (TIdTcpClient if using Delphi win32, TcpClient or plain Socket if using
> .Net, etc..) to consult your Delphi Windows service that contains your
> existing Delphi code and that also happens to be a tcp server that runs
> on the same machine (or another machine, doesn't matter).
Ah, I see. So one lets the active web page itself implement a connective
element between the web server and the running Delphi application.
Would it be possible to let an isapi DLL make a COM call to a running
COM server? If yes, what user account would the isapi be running
under?
Arthur Hoornweg
thanks for your exhaustive explanation of the topic.
It would be easiest for me to equip my Delphi applications with a
communication layer (maybe turn them into out-of-process
COM servers) and then let the web server communicate with
them through either an ISAPI, CGI or even ASP.
I'll have to think it over.
A CGI that communicates with a running Delphi application would
definitely be the easiest (it would just be a simple executable with
a builtin COM client) but I understand that this scales poorly.
Also, if IIS runs under a different user account than the Delphi
application, COM becomes much more difficult to get working.
Packing all functionality inside the CGI itself is not feasible because
of the lengthy SQL server initialization procedure (login plus loading
of many lookup tables).
I have thought about putting the complete functionality inside an ISAPI DLL
(which is loaded only once as far as I understand) but I am worried about
threading issues (The backend code is not threadsafe, I'd have to serialize
it somehow).
danny heijl
> Would it be possible to let an isapi DLL make a COM call to a running
> COM server? If yes, what user account would the isapi be running
> under?
No problem, but I think it would severely limit your performance. The
user ID depends on how you configure the ISAPI in IIS. Default would
normally be the anonymous internet user (IUSR_machinename).
Danny
---
Arthur Hoornweg
> Arthur Hoornweg schreef:
>
>> Would it be possible to let an isapi DLL make a COM call to a running
>> COM server? If yes, what user account would the isapi be running
>> under?
>
> No problem, but I think it would severely limit your performance.
Would other mechanisms (TCP, Remobjects, Midware...) be more
performant than inter-process COM?
danny heijl
>
> Would other mechanisms (TCP, Remobjects, Midware...) be more
> performant than inter-process COM?
>
No, unless your server is so heavily loaded that it becomes necessary to
move parts of the application to another server.
The potential performance problem with COM is the threading model. IIS
is multithreaded, and if your COM server is single-threaded or even
apartment-threaded this can quickly become a bottleneck. It's usually
not the overhead of COM marshaling that's the problem.
Danny
---
Arthur Hoornweg
> The potential performance problem with COM is the threading model. IIS
> is multithreaded, and if your COM server is single-threaded or even
> apartment-threaded this can quickly become a bottleneck. It's usually
> not the overhead of COM marshaling that's the problem.
I am not too worried about that. The internet uplink (DSL 1 megabit)
will be the bottleneck in my case. The images transferred are something
like 50-100 kilobytes.
"Leonardo M. Ramé"
similar). When it receives a request from the CGI, the app must load the
image, base64 enconde and send it as a response to the CGI who adds
correct headers with mime type (in this case image/jpeg), then responses
to the caller with that string. The browser should interpret correctly
as a JPG.
Leonardo M. Ramé
http://leonardorame.blogspot.com
Nils Boedeker escribió: