[nvo-techwg] Re: Updated VOSupportInterfaces spec
Ani Thakar
thakar at skysrv.pha.jhu.edu
Wed Nov 16 14:59:03 PST 2005
Guy,
Well, it looks like in .NET you can just add the SoapRpcMethod tag to
the webmethod and that does the trick (generates rpc/literal WSDL).
I've updated the WSDL on the test site:
http://skydev.pha.jhu.edu/SkyServerLog/SkyServerLog.asmx
but haven't updated the WSDL on the IVOA twiki yet because I still have
to combine the 2 WDSL docs. I've also updated the support interfaces
draft to include the camel-case names for the webmethods and attributes.
Ani
On Mon, 7 Nov 2005, Guy Rixon wrote:
> Thanks Ani.
>
> You're right, .NET does default to doc/literal. IIRC, the whole idea of
> "wrapped" mode, where rpc/literal gets morphed into doc/literal, is from .NET.
> If we only had SOAP bindings to consider, then it wouldn't matter as
> rpc/literal and wrapped doc/literal amount to the same messages on the wire
> and the toolkits don't care about the differences; this is the normal situaton
> for SOAP implementors. Since we're wierd enough to want non-SOAP bindings, the
> differences matter a lot to us and I think rpc/literal SOAP saves us some
> complications. Let me know if this a problematic in .NET.
>
> Cheers,
> Guy
>
> On Mon, 7 Nov 2005, Ani Thakar wrote:
>
> >
> > Hi Guy,
> >
> > 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.
> >
> > Ani
> >
> > On Fri, 4 Nov 2005, Guy Rixon wrote:
> >
> > > Ani,
> > >
> > > 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.
> > >
> > > Cheers,
> > > Guy
> > >
> > >
> > > 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.
> >
>
> 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
Center for Astrophysical Sciences, JHU
3701 San Martin Drive, Baltimore MD 21218-2695
410-516-4850, Fax: 410-516-5096
thakar at jhu.edu, http://www.sdss.jhu.edu/~thakar
-----------------------------------------------------------------------
The best lack all conviction, while the worst
Are full of passionate intensity. [W. B. Yeats]
More information about the grid
mailing list