I currently have a client/server application using a in-house built piece
of middleware to communication to a HPe3000.  Unfortunately the middleware
is about to not be available (for reasons we won't go into) so I'm trying
to look for a replacement implementation.

The clients reside on WinTel platforms from Win98 to XP (as well as
flavors of NT and 2000), HP-UX, and Linux.  There are a set of API calls
which allow the client to open a MPE session, run the server program, pass
a file to the server program to be processed, inquire on the status of the
processing, retrieve the results in the form of another file, as well as
do minor file management (think dir, get, and put in FTP).  The major
strength is being able to access this server program.  In this manner, the
creation of the MPE session, and in fact MPE itself is pretty much hidden
from the client itself.  The role of the server program is not totally
unlike an applet invoked from a web browser.

Clients operate in one of three modes:

1) "Online" - as part of desktop/interactive tool, submitting a single
file to be processed on the server, and then displaying the resulting to
the user

2) "Serial" - as part of a background tool which submits files to be
processed, waits, retrieves the results (timing out if it takes "too long"
for an answer), and displays results or just update status information on
a local database

3) "Batch/polling" - as part of a background tool which submits a number
of files to be processed and then goes away; it periodically comes back
later to retrieve the results of whatever files have been processed.

I've been thinking in terms several replacement strategies.  I'd like
feedback on the approaches and information if anyone has either done it,
or is aware of packages or tools to assist.

A) The poor man's approach is to simply use FTP itself to submit files to
be processed, and create a number of "signal" files to communicate
requests.  The server program on the HPe3000 would scan for requests,
handle them, with results in the form of other files which the client
programs could retrieve.  It's not robust and doesn't do a good response
on one-on-one status requests, but would allow for multiple client
platforms or a change in server platform.

B) Use a 3rd-party middleware tool to do the basic communication, with
custom "wrappers" on client and server side to translate the old API calls
that the middleware tool can interpret.  This minimizes the rewrite needed
by existing clients or the existing server (not unlike those migration
programs that put a shell around IMAGE calls under HP-UX).

C) Use a 3rd-party middleware tool, but this time with custom written or
add-ins from the tool itself to provide the entire client/server path.  In
this case the existing clients would likely need to rewrite their
interfaces to use the new API calls compatible with the middleware tool.

D) Use a web server to handle the communication and replace the existing
application server program with some set of applets or another program
which could run under, say Apache, and respond to requests in the
equivalent manner as now.  This still requires changes on the client side
to provide the additional information for a set of "stateless requests".
It would be best if this solution could work with both a web browser (in
which case we would write a new "dumb" web-based client), as well as
without the benefit of a browser (i.e. directly).  Again, using the web
server tends to isolate the application from changes in client or server
platform.

E) Use the web-server approach, but with the 3rd party tool, "wrap" it in
a custom front end so the clients don't really know what's changed.  The
wrapper would be responsible for keeping track of which session/status is
which.

F) Other ideas include looking into XML wrappers on the clients and a SOAP
transport (both new areas for me).

I'm sure there are other approaches that will occur to me the moment I hit
SEND, but this is a starting point to give you ideas where I'm trying to
go.

So, "hearing" all that, any thoughts or suggestions of how to do this, and
how much effort might be involved?

Thanx in advance,
Ric Goldman
Spellbinder Systems Group
Palo Alto, CA 94306-2436

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *