Elliott's SOAP questions (fwd)

[Elton Smith <elton@jlab.org>]

Latifa -- I included you because if I were still working on the N* database I would be pushing this technology very hard -- see the last part of my response to get a flavor -- it is absolutely perfect for your project.

Some answers to Elliott's questions.

    On Thu, 31 May 2001 10:10:03 -0400 you wrote:

>Hi Dave,>
>
>Some questions about SOAP.>
>
>Why do you say the firewalls will always be open for SOAP?  At JLab you can't>
>get to the clon00 web server from outside.  Any access through our firewall has>
>to be requested and ok'd in the CC.  Just because it's for http access on the>
>standard http port means nothing.>
>

True, if the webserver can't be reached then you can't do SOAP over HTTP. There is no reason for a WebServer to be blocked -- the only thing it is really susceptible to (unless you allow untrusted CGI scripts and servlets to run) is a firestorm attack. This is a bad policy on the part of the CC. After all, there is a public jlab webserver -- why is the clon webserver any more of a risk? (well maybe because too many amateurs controlling the server environment) If you decide to use SOAP then you will have to a) run it via JLABs public server  (b) setup another public server (c) run it on a collaborator's server or (d) Fight the CC to allow public access to the CLON server.


>Also, who says you'll always use the default http port?  If you have a web>
>server and some sort of other SOAP server you have to use different ports. >
>Unless you combine all web and SOAP access into a single web server with a SOAP>
>servlet for your application.  But I imagine all sorts of programs, not just>
>servers, wanting to send/receive SOAP stuff on the same machine, so all manner>
>of ports will be used.>
>

No, different servlets can be different SOAP servers simultaneously, all using port 80. The SOAP message and the SOAP enabled webserver will route them accordingly -- the SOAP server applications will have to make themselves known server side by a deployment descriptor. There is no need to use other ports -- if so SOAP would be, conversely, firewall UNfriendly since typically the only way through is HTTP on port 80.

The process is: the webserver get the HTTP message. Being SOAP enabled, it recognizes it as a SOAP message rather than a "normal" file request. It routes it to the proper SOAP application which processes the message and responds.


>Note:  Hall D is not concerned with Fortran except for legacy stuff that will>
>have to be encapsulated in a c wrapper...I hope there will be little of this,>
>probably none in the online, maybe a little in the offline.>


Well that makes things a bit easier for Hall D. However, if I were still at JLAB I would propose a JLAB-wide SOAP project to build

a) The base servlet to enforce a reasonable naming convention. Probably in JAVA. One would have to decide if the base server includes support for asynchronous requests -- this is a complication but utimately allows you to build a messaging system which will allow for decentralization of the services.

b) A base client that can make the connection. Probably in C++. I would avoid JAVA here because if developers want to work in languages other than JAVA they will want to avoid the complexity of using JNI to load a Java Virtual Machine (which they might have to download - not to mention a steep learning curve -- and it cannot be done directly from FORTRAN) and which will incur a major performance hit. By contrast, it is much easier for a JAVA client to use JNI to load a library, and JAVA developers are used to it. Or maybe you write both a C++ and a JAVA client. Note these clients will have to include an XML parser.

c) A Fortran wrapper for the C++ library -- unless you are convinced nobody will ever write a FORTRAN app that will want to use your services.

Now you have a very useful tool (to say the least). Your SOAP server application can expand as much as needed, continuously providing new services. The messages, with their XML format, are largely self described and readily verified with XML schema. As services are added, then one in effect publishes the required XML and the service is instanly available. Start with simple things, like getting data out of the map (does HALL B still use the map manager?) Move to advanced requests, like getting data from the N* database. You are now simply limited by your imagination as to what services you supply, and they will be available to anyone around the world.

Hope this helps,

dph

>
>
>				Sincerely,>
>					Elliott>
> >
>
>
>================================================================================
>

>   Help feed the hungry, one click at a time:  http://www.thehungersite.com>
>
>    "Science plays a major role in satisfying the minor needs of mankind">
>
>
>================================================================================
>