On Thu, 28 Aug 2003, David Forslund wrote: ... > >An example may help: > >Let's say if we call "http://calculator.tools.org/add?a=2&b=3"; and get > >5 as the returned value, then this is a "callable_from_URL" adding > >machine. > > We do this all the time, but it is simply passing arguments into an > existing "application" or piece of code. This can be done in most any > language. JSP does this, so do servlets. I don't see anything here that > has anything to do with Zope or Java.
Dave, You are righ, it does not matter how the application is implemented. The "callable_from_URL" interface gives convenient access to the application independent of implementation details. My point was that this _feature_ increases usability and facilitates interoperability.
callable_from_URL doesn't necessarily help in interoperability. There are almost
no constraints involved there that will help with interoperability other than not
caring what the language is.
... > >We do this all the time. I write a bunch of python routines and call them > >by their respective URL. (This is what Zope is, basically.) > > Just what is done in Java/JSP. You aren't executing arbitrary python > only the code you have set up to be called by the URL.
True, but since I can bundle any collection of arbitrary python (or non-Python) code, a "callable_by_URL" application can execute any arbitrary python and non-Python code.
You don't execute arbitrary python code given to you by a client. You let the client execute only the code you have specified. These two things are quite different and the distinction is what I'm talking about.
... > What I've seen on some applications is for a client to pass in arbitrary > SQL code to the server which is then executed. This is what is > undesirable. It is not what you are doing, thus my "dangerous" > statement doesn't apply.
I see what you mean by "calling arbitray code". At some level, any parameter being passed into any application can cause un-intended effects. Applications (inclusive of all code to the bare CPU) must deal with the uncertainties associated with "programmability".
Certainly, but this is what things like "Design by Contract" deal with and why
one has to understand the side effects of a call and constrain the random
user from doing something malicious. This is what all the "worm" stuff is about.
It is why things like "strong typing" and other constraining mechanisms help.
... > >Robustness requires many more considerations than interface. Staying with > >our discussion about application interface, an URL-callable interface has > >important usability advantages. > > But has poor security management.
Could you support this assertion with more information, references, or examples?
You need to know who is making the UR_call to decide whether you want to honor it.
This may be difficult unless you are adding something else to the mix. At least https
with full authentication.
How does calling an application via URL imply more difficulty performing security management?
> What I'm referring to is availability of a service when needed, not the > quality of the interface.
Why would it be harder to ensure availability of a "URL_callable" application? "URL_callable" is just an application interface (ok, it implies transport via http too).
You said you wanted to rely on someone else's service on the Internet. What
do you do when it isn't there and you need it for your application to function correctly?
There is huge market pressure to provide highly available "URL_callable" applications. Perhaps these R+D efforts can mitigate much of the availability issues.
Reliable networks are required. I don't think this has anything to do with R&D.
I had to give a talk at a hospital in ABQ and they wanted to show it on their system.
The network wouldn't even let them move the file to a machine across the hall. Something
was broken and they couldn't figure out what it was.
> If I want to have a system that works when I want it, I may need to have > all the services near by.
Even if we are using CORBA, having all services nearby increases likelihood of availability.
Certainly. Having them under your control helps. Having well defined and stable
interfaces also helps. When it is someone else's application, you may
not be able to count on it unless there is more than a casual relationship involved.
The bottom line is that http may provide sufficient availability (in conjunction with lots of redundant hardware and bandwidth). From the point of view of hardware/networking cost, "URL_callable" may be inferior to CORBA and Java messaging, for example. However, the superior usability of "URL_callable" (not to mention the installed base) has been winning developers and projects.
I don't see the superior usability. I think it is a familiarity thing.
...OK (from OpenEMed web application)
> >Has a nice tutorial too:
> > http://zopexmlmethods.sourceforge.net/
>
> Very good. But I don't see how this whole approach is any easier to use than
> in any other language.
How would you apply a XSLT to an XML document in JSP? Let's compare the same example application written in Zope vs. JSP.
StreamSource xml = new StreamSource(new File(application.getRealPath("")+"WEB-INF/classes/xcode/symptoms.xml"));
StreamSource xsl = new StreamSource(new File(application.getRealPath("xcode/demo-vitals.xsl")));
StreamResult result=new StreamResult(out);
TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer transformer = tFactory.newTransformer(xsl);
transformer.transform(xml,result);
(All of these objects are standard and work with any standard XML/XSL parser)
... > It would be nice if I could simple plug in some Java applications into > Zope.
I know that it is possible to plug Perl and PHP into Zope. I have not heard about plugging Java into Zope but anything is possible.
Certainly, but how?
... > is python, but having jython talk to python at the language level > doesn't seem to be happening. Am I mistaken?
Beats me, I don't know anything about how JPython talks to Python.
That's the point. You shouldn't have to. They are the same language.
> It appears that is quite trivial to execute python code from Java, but very
> difficult
> to go the other way unless I'm running something like jython. Can I run Zope
> with jython? Then I could lnk all of these capabilities together.
...
Here are some probable reasons why what you are proposing has not happened yet: http://mail.zope.org/pipermail/zope-dev/2000-March/004000.html http://mail.python.org/pipermail/python-list/2000-January/019936.html
In summary, URL_callable interface for applications is "language" independent and worthwhile considering since we all have our own favorite programming languages and computing platforms. Instead of waiting for "common language runtime (CLR)", I think the URL_callable interface already provides most of the benefits.
So to have jpython and python talk to one another, the only mechanism is URL_callable interface?
Very primitive, I would say. And gives up all the OO power of Python in the process.
Why should we wait around? That is what CORBA was designed for. Been around for 14 years. So is SOAP. So is XML-RPC.
What standards should we have for URL_callable interfaces to do healthcare?
What standards are required? Standards for use in healthcare have now been around for 3-5 years and could be implemented
in multiple languages and even in multiple transport approaches. I could put up OpenEMed as a Web Service today by simply advertising
the CORBA layers to Cape Connects CORBA to WSDL mapper.
Perhaps you subscribe to the REST philosophy?
Dave
Best regards,
Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
