I am wondering how many ways there are to write a Pick/DataBASIC
service that takes in a parameter from a URL and returns (via http) a
result.

Let's say that there is JavaScript in a browser that is doing an
XMLHttpRequest (or ActiveX), aka AJAX, request to a URL such as
www.mydomain.com/myservice.whatever?this=that

What all is behind this URL? It might be enlightening (to me at least)
to inventory the ways to accomplish this feat.

1. PHP + OpenQM client/server library + OpenQM
In a non-transaction processing environment (in fact doing only
read-only right now), I have done this with a PHP wrapper that Tom D
wrote for OpenQM, which uses the OpenQM client/server interface written
in C (IIRC).

2. Tomcat + Java + UOJ library + UniData
I have also done this using a tomcat app server (either in addition to
or instead of another web server), Java, and UniObjects for Java (UOJ)
with UniData. I had to add in home-grown connection pooling at the
time, but UOJ now comes with it (for a price).

Please add to this list. Thanks. --dawn

dawn wrote:
3. Tomcat + Java (or PHP or ASP) + JD3 + D3.
4. Tomcat + Java + Java OBjEX + jBASE.
5. CGI + jBASE binary executable.

Note that Tomcat is not the only servlet container out there. Far from
it - so you can substitute Resin, Weblogic, WebSphere, JRun, Sun One
Server or what-have-you for Tomcat. Likewise, in your point 2, you could
have UV instead of UDT.

Luke

Luke Webber wrote:
Everything so far (you and Glen) requires either a servlet container or
CGI. Neither of those is readily available for those doing web site
development using a typical ISP (which is often similar to what a
corporate web setup might look like for developers who don't have a lot
of say on that setup). That's why LAMP (linux, apache, MySQL, PHP) is
so popular -- it works both for shops with their own servers and those
using ISPs, most of whom provide both PHP and MySQL (typically for
extra dollars on the latter).

Does anyone have a solution that uses neither CGI nor a servlet
container? --dawn

dawn wrote:
Look again, Dawn. JD3 can be used with PHP on the server side. OTOH, it
needs a connection to your database server. You could just open a hole
in your firewall to allow connections on the JD3 ports from the specific
web server - that should be secure enough.

Frankly, I don't know why you're so stuck on the public server approach.
It's dead cheap to run your own server at home. All you need is a cheap
server PC and Linux, plus a static IP address. OK, the speed may not be
all that an ISP can offer directly, but with ADSL2+ it ain't half bad.
Even a standard ADSL link can run 512Kbps in both directions, which is
OK for most lowish-volume sites.

Luke

Luke Webber wrote:
I knew I should ask a question and not just let that one slide -- I
have no clue what JD3 is. Is it specific to D3?

Not for most people, it isn't.

I'm guessing I'm in the majority of people in the world when I say that
I don't want to install and maintain a production server environment.
Bandwith, disk space, OS upgrades, app installs, unplanned downtime,
security, backups, user administration, fail-over, performance tuing,
....

I can run a test server environment that way. Cheers! --dawn

dawn wrote:
Yes it is. But it's a possibility. For that matter, you could probably
port it to UV or UDT.

[snip]
It's not that bad. Just make sure your ADSL router has a decent firewall
and only open the ports you need. Upgrades? We don't need no steenking
upgrades! How many exploits have you heard of for Tomcat anyway?

User admin? Better to have control of that yourself than to have to call
your ISP every time you want to do it, and there are GUI tools to make
it easier. Not that it's ever been hard. App installs? There's the rub.
Your ISP won't /let/ you do app installs will he? That's why you're
stuck in your present loop.

OK, failover and performance tuning can occupy a fair bit of time, but
are you sure your ISP has got it right anyway? I'd almost be willing to
bet that at least half the ISPs out there don't bother to do failover,
and they sure as hell aren't going to tune your web app or your database
schema for you.

You can run a production environment that way. You can build a
full-blown cluster if you want. Do it with secondhand hardware bought
cheap from swap meets. Why not?

For that matter, not all ISPs are unfriendly to Java. There's a decent
sampling right here...

http://mindprod.com/jgloss/ispvendors.html

Cheers,
Luke

For a standard ISP that provides LAMP or hosted ASP/ASP.NET, you could
use a forwarding technique which accepts the request then redirects it
wherever you want using sockets or Web Services. When you go to
someone's home page where they show you the weather, you don't really
think they have a weather station there do you? Of course not. A
request is made to another server and the results are incorporated
into the end-user's page. This is how the net works and this is the
core of SOA.

For security reasons some ISP's don't allow outbound socket calls
except outbound HTTP on port 80 or 443. This is an invitation to use
Web Services - which is one of the reasons why I wrote my articles ont
this topic over two years ago.
http:// removethisNebula-RnD.com/articles/

Your home or office firewall/router should not accept HTTP requests
from any IP address(es) other than your static HTML host (the LAMP
people). This gives you almost rock solid security. From there your
real back-end environment probably doesn't need any more security than
what you require for your own LAN. Being paranoid I'd put more effort
into this but YMMV.

So what do you need?
1) PHP or Perl on your LAMP host that accepts a web query and parses
out the request data. Millions of examples of this on the Net.
2) A PHP/Perl-based Web Service client that accepts a block of text
(from #1), passes it on for external processing, and returns the
results to #1 for final end-user rendering - probably HTML. Again,
tons of examples available everywhere.
3) A firewall that you can tune to only accept port 80 traffic from a
selected IP block.
4) Any HTTP server you want on any OS you like on your own LAN.
5) Any freeware/buyware Web Service Server software that will extract
data from an XML packet and return the data back to the client -
again, all free, lots of examples.
6) Any freeware/buyware discussed in these forums to pass a block of
text from #5 to your MV server and return the results. (With mv.NET
and Visual Studio you can do #4-6 in a couple minutes.)

Any help?
T


"dawn" wrote:

I've used dotnet web services, which access the database (jBASE) using
jRCS...

Like others, the web service can exist publically on the internet, but the
database can be stored elesewhere behind a firewall that only allows the web
server's IP through on the jRCS port.

Regards
Simon

--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Hi Dawn - I have a number of live websites out there, they all run on
iis, using ASP or ASP.NET and connect to u2 using uniobjects (or
uniobjects.net). Works fine even without connection pooling. Down the
line connection pooling is what we shall be putting into place, either
using the new offering from IBM (+ maybe the U2 Soap Server), or
MV.NET.

I have also done sites in the java realm, on tomcat/jboss etc with
connections to U2 using our bespoke socket interface.

I think really the options are quite large, but more so on the choice
of web/application server, to actually get into MV data you either need
a bespoke interface (sockets etc) or use one of the tools like
uniobjects.

I would like to see a better way of getting from php on linux into U2.
I know some people have done some work on this using UCI and extensions
to php in C, but a nice packaged, documented offering would be pretty
cool.

rgds
Symeon.






Simon Verona wrote:

Out of interest, I have used message queueing to perform connection pooling
to the database by running a service (windows) on the server which spawns a
number of processes that access the message queue and then call the
subroutines on the server (using jrcs) returning any result back through the
message queue.

This means you limit the no of simulataneuos connections to the server, and
control licence usage without getting http failures (it just slows down!).

I think that MSMQ can be transported between machines automatically over
http.

This also gives you security of delivery of message as well..

and it works!

Regards
Simon
--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

"Symeon" <symeonb (AT) gmail (DOT) com> wrote