On Fri, 5 Mar 2004, Giaretta, DL (David) wrote:
> A couple of points:
> 1) the parameter system certainly needs to do what ORAC-DR needs
> 2) we probably don't really want to redesign the whole parameter system from
> scratch.
>
> It sounds as if what Alan did is OK for now - but Al has the authority to
> change things as necessary to fit in with ORAC-DR Web Services.
>
Since this was mentioned here are my views on a parameter system
("requirements" is too strong a word):
- What gets sent over the "wire" between a client and the new java
application should be language agnostic. The easy way to do this
is simply to specify a DTD for the content and pass around the XML
as a big string with a parser at the receiving end that converts
it to the actual Parameter object.
- It makes sense for me for the XML that gets sent from a client to a
task to be exactly the same dialect of XML as gets returned to the
client from the task (extra elements with textual output clearly
only comes from the task).
- The XML content can be sent as simple strings over SOAP.
- All new Starlink applications should adopt the SAME scheme for
their web services. ie a new Java application should be able to be
controlled by the same XML as the classic applications (note that
this is only discussing the arguments, clearly the method names
can be anything you want). One caveat here is that I'm perfectly
happy for web services that take simple (non-object) mandatory
arguments to continue to do so - I'm only suggesting here that
passing variable numbers of arguments or objects should use the
standardised XML
- The parameter system should be able to take "keyword=value" strings
as a constructor but I don't think those should go over the wire.
- If a parameter is to be associated with an object that object should
serialise to a public XML DTD and should be embedded in the parameter
XML:
<StarParam>
<parameters>
<parameter name="clip>5</parameter>
<parameter name="NDF1">/home/timj/blah.sdf</parameter>
<parameter name="NDF2">
<ndx> . ... </ndx>
</parameter>
...
</parameters>
</StarParam>
ie we can ship NDXs around by putting them inside the parameter
elements. Again the return XML will be similar with the addition
of some message information (note that I haven't seen the parameter
XML so it will look different to this)
<StarParam>
<parameters>
<parameter name="mean">52.567</parameter>
<parameter name="median">34</parameter>
<parameter name="NDF1">/home/timj/blah.sdf</parameter>
</parameters>
<messages>
<message>KAPPA blah completed</message>
<message>More content</message>
</messages>
</StarParam>
- If a task requires more information from a client it should throw a
NeedMoreInfo (or whatever) exception and include the parameter name
and prompt that needs more info. The task itself will not assume
that the info is coming since it is stateless. The client will
have to get the information that is required and resend the entire
parameter set or simply give up.
ORAC-DR can handle all of this. I'm just saying that I would rather all
Starlink apps used the same approach rather than writing special code for
each app.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|