fP SOAP Server - Is there demand?

[Fairlight]

Many of you know of my flagship web integration product, OneGate.  That
product is a field=value CGI-based framework application.

A common misconception since a few years ago is that "web services" is
strictly done using SOAP.  Another common misconception is that everything
which can do field-based CGI can do SOAP.  I recently had a fellow
consultant who has used my OneGate product for years tell someone else that
it can do SOAP.  Not true.  I ended up writing a smaller, less
feature-rich, custom solution for the referred party's SOAP needs with
filePro.

What I'm contemplating is writing OneSOAP.  Essentially, this would be a
filePro-centric universal SOAP service running under Apache (or any other
web server which is set up to be able to run Perl code).  I'd take the
OneGate 5.x base code as a starting point.  I'd rip out everything to do
with fields, and orient it towards straight, un-mangled handling of HTTP
POST of raw XML (or even other data).  I'd include my XML2CSV program
to assist in getting data into filePro easily, via IMPORT.  All the new
features for output, like file inclusions, mail-merge fields, etc., would
all remain.

While OneGate's field-based orientation lets me easily get the data
directly into filePro in an actual filePro file so that it's as easy as a
lookup to get your field values, the very nature of XML means that the data
relationships are buried within the structure of the data itself.  This
precludes doing any sort of sensible import that makes it "just do a
lookup" easy.  That said, if I bundled XML2CSV into the product, it would
give you a very easy-to-traverse CSV file to walk through and grab what you
need.  That's as close as it's getting, given the nature of XML.  That's
not a "me" limitation, that's a limitation of the abstract and malleable
one-to-many relationships possible within XML.  Even header-detail wouldn't
work, because you'd need to know exactly what relationships you should be
parsing in any given task.  Honestly, that's something that needs to be a
business-rules-derived set of code, best handled inside filePro itself at
import time.  It can't readily be genericised.

As far as the "relay" capabilities of SOAP, anyone could really take
something like cURL and perform the relays as per business rules, as they
see fit.  So I wouldn't even directly address the relay issue, as it's
easily addressable.

What you'd get would be all the rest of OneGate's in/out pipeline, with
high organisational structuring, easy configuration, protection of filePro
license seats, automagic file cleanup, and of course the XML2CSV
functionality bundled in.  Checking against WSDLs and Schemas (which are
really meant to be developer guides, more than anything else) would NOT be
included.  It would expect sane XML, and really be schema/DTD-agnostic, to
maintain the generic gateway attitude OneGate has always presented.

Before I even consider using a bunch of my free time (in which I'd much
rather be writing/playing music, gaming, or learning how to use Blender
to make stunning 3D graphics and animation), I'm trying to see if there's
demand for such a beast.  The results decide whether I further contemplate
coding such a beast, or not.

If there is sufficient demand, I very well may develop the product.  If
not, it's not worth eating up my Copious Free Time and Copious Free Energy,
and I'll stick a fork in the idea, and simply move on without pursuing it.

mark->
-- 
Fairlight Consulting
http://www.fairlite.com
fairlite at fairlite.com
(502) 509-3840