Updated VOSupportInterfaces spec
thakar at skysrv.pha.jhu.edu
Mon Nov 7 08:10:17 PST 2005
I agree about combining the WSDL and about the naming convention
consistency. I'm partial to camel-cased, but IIRC I inherited the names
in the document and didn't bother to change them. I'll take care of
combining the WSDL and changing the names.
As for the rpc/literal, I don't know enough about WSDL/WS to really have
an informed opinion about it, so I'll defer to others' judgement on
this. I guess .NET defaults to document/literal.
On Fri, 4 Nov 2005, Guy Rixon wrote:
> thanks for working on this. It's good to get some progress.
> getRegistration isn't mandatory; only getAvailability is considered mandatory
> at present.
> All these interfaces have to be mixed in with another WSDL contract to produce
> a useful service with a single port. Therefore, I suggest that we combine the
> WSDL documents, putting the mandatory and optional interfaces into one
> contract. We need to add language to the specification explaining that the
> implementor picks apart the "normative" WSDL contract.
> Would you like to have a go at combinging the WSDL?
> I see that you have different messages for the SOAP and HTTP-get/post binding,
> but with equivalent semantics: the SOAP binding uses messages with complex
> types and the HTTP bindings use lists of type parameters. I understand that
> this is because HTTP-get _has_ to use lists of simple types, but I think that
> calls into question the details of the SOAP binding.
> Presume that we want to bind the _same_ port type to SOAP and to HTTP-get,
> which we do. Presume that we want to bind _all_ the operation in each case
> because that makes the contract much neater and easier to understand. Presume
> that all the messages _can_ be expressed as simple types based on W3C XML
> schema types, which is true here. In that case, should the SOAP binding not be
> rpc/literal rather than document/literal? It's what the RPC style is for. It
> would reduce the number of messages and would eliminate the HarvestWebLog and
> HarvestServiceLog types from the contract.
> It might be helpful to make consistent the capitalization of operation names
> and names of message parts. We have a mix at present. I suggest that the names
> of parts should be camel-cased since they are like field in objects. The names
> of operations could either be camel-cased because they are like methods of an
> object that represents the service, or they could have initial capitals
> because they are like objects that contain the message parts as fields. I
> don't mind which, but I think we should be consistent.
> On Thu, 3 Nov 2005, Ani Thakar wrote:
> > Hi all,
> > I've posted an updated VO Support Interfaces draft spec, version 0.23
> > at:
> > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupportInterfaces-0.23.pdf
> > This includes changes to the logging interfaces to fix some missing
> > information as well as to update the interfaces to send output to a
> > logging VOStore. This part will still need tweaking before it is
> > finalized, of course. I've also added a note about access/security for
> > the logging VOStore.
> > I posted the WSDL for the updated services in VOSupportInterfaces.wsdl,
> > but I noticed that there were 2 WSDL documents for the support
> > interfaces: VObsServices.wsdl which contains the getAvailability and
> > registry metadata interfaces, and the other one containing the logging
> > interfaces. Since the latter are non-mandatory, I've updated the
> > support interfaces section to include both WSDL files, one for mandatory
> > support interfaces and the other for non-mandatory (logging) interfaces.
> > I updated the comment in the VObsServices.wsdl file to reflect the fact
> > that the logging WSDL was in a separate document.
> > However, I note that the current draft spec contains identical
> > language, "All VO services *should* implement ..." for all the current
> > support interfaces, mandatory and non-mandatory. I guess this should be
> > changed to "must implement" for the mandatory interfaces, right?
> > Please send me comments, questions if you have any. Cheers.
> > Ani
> > --
> > Aniruddha R Thakar, Research Scientist, The Sloan Digital Sky Survey
> > Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695
> > 410-516-4850 fax:410-516-5096 thakar at jhu.edu www.sdss.jhu.edu/~thakar
> > -----------------------------------------------------------------------
> > Love is like war; easy to begin but very hard to stop. [H.L. Mencken]
> Guy Rixon gtr at ast.cam.ac.uk
> Institute of Astronomy Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
Aniruddha R Thakar, Research Scientist, The Sloan Digital Sky Survey
Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695
410-516-4850 fax:410-516-5096 thakar at jhu.edu www.sdss.jhu.edu/~thakar
Artificial Intelligence is no match for natural stupidity.
More information about the grid