Example WSDL descriptions
ADC BibCode Query (Accomazzi)
<?xml version="1.0" encoding="utf-8"?>
<definitions name="BibcodeQuery"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="urn:ADSBibcodeQuery"
xmlns:tns="urn:ADSBibcodeQuery">
<documentation>
A bibcode query service provided by the ADS
</documentation>
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ADSBibcodeQuery">
<element name="bibcode" type="string" minOccurs="1" maxOccurs="100" />
<element name="db_key" type="string" minOccurs="0" />
<element name="data_type" type="string" minOccurs="0" />
</schema>
</types>
<message name="getBibcode">
<part name="bibcode" element="tns:bibcode" />
<part name="db_key" element="tns:db_key" />
<part name="data_type" element="tns:data_type" />
</message>
<!-- not sure this is correct -->
<message name="returnBibcode">
<part name="body" type="xsd:string" />
</message>
<portType name="BibcodeQueryPort">
<operation name="getBibcode">
<input message="tns:getBibcode" />
<output message="tns:returnBibcode" />
</operation>
</portType>
<service name="BibcodeQuery">
<port name="BibcodeQueryPort" binding="tns:BibcodeQueryBinding">
<http:address location="http://adsabs.harvard.edu/" />
</port>
</service>
<binding name="BibcodeQueryBinding" type="tns:BibcodeQueryPort">
<http:binding verb="GET" />
<operation name="getBibcode">
<http:operation location="cgi-bin/nph-bib_query" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:content type="text/html" />
</output>
</operation>
</binding>
</definitions>
IRSA Catalog Search Services (Good)
<?xml version="1.0" encoding="utf-8"?>
<definitions name="CatalogSearch"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="urn:IRSACatalogSearch"
xmlns:tns="urn:IRSACatalogSearch">
<documentation>
A General Service for Interacting with IRSA Catalog Data
</documentation>
<types>
<documentation>
DATA STRUCTURES (TYPES) - This service deals in the
subsetting of astronomical catalogs. Basically, this is a
three-step process if you are starting cold: Get the list of
catalogs; get the description of a particular catalog (fields
names, etc.); and submit a query (SQL where clause and
specialized positional constraints). The structures defined
here represent the back-and-forth associated with these
exchanges. Since these are all instantiated using HTTP
GET/POST, there doesn't seem to be a particularly elegant way to
handle notification operations. Since we are actually
implementing that, we will most likely instantiate all this
functionality using SOAP. However, this description is close
enough (though not close enough to actually use) to our current
web services to make the relationships clear.
There are a few areas where I've used 'xsd:string' base
datatypes, etc. when some explicit community-defined schema
would be more appropriate. For instance, the search element
'location' should probably be type 'nvo:location' or, more
generally, their should be a standard 'nvo:spatialConstraint'
with a 'nvo:location'/'nvo:radius' pair as one option (polygonal
constraints being another).
</documentation>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:IRSACatalogSearch">
<complexType name="CatalogInfoElement">
<sequence>
<element name="catalogName" type="string"/>
<element name="catalogDescription" type="string"/>
<element name="serverName" type="string"/>
<element name="databaseName" type="string"/>
<element name="schemaName" type="string"/>
<element name="columnCount" type="integer"/>
<element name="rowCount" type="integer"/>
<element name="coneradius" type="double" minOccurs="0"/>
<element name="uploadradius" type="double" minOccurs="0"/>
<element name="version" type="string" minOccurs="0"/>
<element name="versionDate" type="date" minOccurs="0"/>
<element name="projectName" type="string" minOccurs="0"/>
<element name="infoURL" type="anyURI" minOccurs="0"/>
<element name="whereExample" type="string" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="CatalogInfoArray">
<complexContent>
<element name="schema" type="tns:CatalogInfoElement"
maxOccurs="unbounded"/>
</complexContent>
</complexType>
<complexType name="CatalogSchemaRequest">
<sequence>
<element name="database" type="string"/>
<element name="catalogName" type="string"/>
</sequence>
</complexType>
<complexType name="CatalogSchemaElement">
<sequence>
<element name="fieldName" type="string" />
<element name="originalFieldName" type="string" minOccurs="0"/>
<element name="fieldDescription" type="string" />
<element name="units" type="string" minOccurs="0"/>
<element name="inputType" type="string" minOccurs="0"/>
<element name="outputFormat" type="string" />
<element name="databaseFieldType" type="string" minOccurs="0"/>
<element name="canBeNull" type="boolean" minOccurs="0"/>
<element name="isIndexed" type="boolean" />
<element name="isOnShortList" type="boolean" minOccurs="0"/>
<element name="isOnStdList" type="boolean" minOccurs="0"/>
<element name="isOnMiniList" type="boolean" minOccurs="0"/>
<element name="numberOfNulls" type="integer" minOccurs="0"/>
<element name="minimumValue" type="double" minOccurs="0"/>
<element name="maximumValue" type="double" minOccurs="0"/>
<element name="meanValue" type="double" minOccurs="0"/>
<element name="stdDev" type="double" minOccurs="0"/>
<element name="notes" type="string" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="CatalogSchemaArray">
<complexContent>
<element name="schema" type="tns:CatalogSchemaElement"
maxOccurs="unbounded"/>
</complexContent>
</complexType>
<complexType name="CatalogSearchRequest">
<sequence>
<element name="serverName" type="string"/>
<element name="databaseName" type="string"/>
<element name="catalogName" type="string"/>
<element name="SQL" type="string"/>
<element name="searchRadius" type="double"/>
<element name="searchLocation" type="string"/>
</sequence>
</complexType>
<complexType name="CatalogSearchResponse">
<sequence>
<element name="recordCount" type="integer"/>
<element name="URL" type="string" />
</sequence>
</complexType>
<complexType name="CatalogQueryID">
<sequence>
<element name="ID" type="string"/>
</sequence>
</complexType>
</schema>
</types>
<!--
MESSAGES - How the above data structures are bundled up
as a set of messages. Since our service is pretty simple,
this is pretty much a one-to-one correspondence (as is true
for most services we've seen to date)
-->
<message name="getCatalogList">
<documentation>
No arguments; we just want the list
</documentation>
</message>
<message name="returnCatalogList">
<part name="list" type="tns:CatalogInfoArray" />
</message>
<message name="getCatalogSchema">
<part name="catalog" type="tns:CatalogSchemaRequest" />
</message>
<message name="returnCatalogSchema">
<part name="schema" type="tns:CatalogSchemaArray" />
</message>
<message name="doCatalogSearch">
<part name="request" type="tns:CatalogSearchRequest" />
</message>
<message name="returnCatalogData">
<part name="sourcelist" type="tns:CatalogSearchResponse"/>
</message>
<message name="queryIdInfo">
<part name="id" type="tns:CatalogQueryID"/>
</message>
<portType name="CatalogSearchPort">
<documentation>
SERVICE "METHODS" - The actual set of operations the
service is capable of supporting. For each we can have a
message that goes in and a message that comes out (though
not always both; see for instance the background search
submission / notification operations).
</documentation>
<operation name="getCatalogList">
<input message="tns:getCatalogList"/>
<output message="tns:returnCatalogList"/>
</operation>
<operation name="getCatalogSchema">
<input message="tns:getCatalogSchema"/>
<output message="tns:returnCatalogSchema"/>
</operation>
<operation name="submitForegroundCatalogSearch">
<input message="tns:doCatalogSearch"/>
<output message="tns:returnCatalogData"/>
</operation>
<operation name="submitBackgroundCatalogSearch">
<input message="tns:doCatalogSearch"/>
<output message="tns:queryID"/>
</operation>
<operation name="getBackgroundCatalogSearchStatus">
<input message="tns:queryID"/>
<output message="tns:returnCatalogData"/>
<fault message="xsd:string"/>
</operation>
</portType>
<binding name="CatalogSearchBinding" type="tns:CatalogSearchPort">
<documentation>
TRANSLATION TO WIRE FORMAT (BINDING) - There are a number of
ways the messages could be formatted when talking to the service.
This is where we get explicit about what the service can handle.
SOAP is the simplest match to the data structures we've defined
(XML going into XML) but most of our existing services are
HTTP GET/POST, so I've opted for using that as the illustration
here.
</documentation>
<http:binding verb="GET"/>
<operation name="getCatalogList">
<http:operation location="cgi-bin/Oasis/CatList/nph-catlist"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="text/xml"/>
</output>
</operation>
<operation name="getCatalogSchema">
<http:operation location="cgi-bin/Oasis/DD/nph-dd"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="text/xml"/>
</output>
</operation>
<operation name="submitForegroundCatalogSearch">
<http:operation location="cgi-bin/Oasis/CatSearch/nph-catsearch"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="text/plain"/>
</output>
</operation>
<operation name="submitBackgroundCatalogSearch">
<http:operation location="cgi-bin/Oasis/CatSearch/nph-bgcatsearch"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="text/plain"/>
</output>
</operation>
<operation name="getBackgroundCatalogSearchStatus">
<http:operation location="cgi-bin/Oasis/CatList/nph-catsearchstatus"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="text/plain"/>
</output>
<fault>
<mime:content type="text/plain"/>
</fault>
</operation>
</binding>
<service name="CatalogSearchService">
<port name="CatalogSearchPort" binding="tns:CatalogSearchBinding">
<http:address location="http://irsa.ipac.caltech.edu/"/>
</port>
</service>
</definitions>
Proposed HST Query (Kimball)
<?xml versiion="1.0" encoding="utf-8"?>
<definitions name="HSTQuery"
targetNamespace="urn:HSTQuery"
xmlns="http:/schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http:/schemas.xmlsoap.org/wsdl/wsdl/"
xmlns:http="http:/schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http:/schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/XMLSchema"
xmlns:thisns="urn:HSTQuery">
<!-- We haven't included a "types" section, because for now
the messages (see below) are pretty simple. We probably
will include a "types" section later, though. -->
<!-- "Messages" are bits of information that are passed
back and forth between machines. We don't care how
they cross the wire at this point; we just want to
declare what's in them. -->
<message name="PositionQuery">
<part name="ra" type="xsd:float" />
<part name="dec" type="xsd:float" />
<part name="radius" type="xsd:float" />
</message>
<message name="PiNameQuery">
<part name="piName" type="xsd:string" />
</message>
<message name="ProposalQuery">
<part name="proposalId" type="xsd:int" />
</message>
<message name="QueryResponse">
<part name="resultBody" type="xsd:string" />
</message>
<!-- The "portType" section combines messages into operations.
This will be like the "methods". Our operations are all
query-response, so each operation has an input message
and an output message. -->
<portType name="portType">
<operation name="queryByPosition">
<input name="thisns:PositionQuery" />
<output name="thisns:QueryResponse" />
</operation>
<operation name="queryByPiName">
<input name="thisns:PiNameQuery" />
<output name="thisns:QueryResponse" />
</operation>
<operation name="queryByProposal">
<input name="thisns:ProposalQuery" />
<output name="thisns:QueryResponse" />
</operation>
</portType>
<!-- The "binding" section finally specifies how the
how the messages that make up an operation cross
the wire. Right now, we just have a GET binding,
which means communication through a good old HTTP
GET. We can add other bindings (e.g. SOAP) later. -->
<binding name="thisns:GETbinding" type="thisns:portType">
<http:binding verb="GET" />
<operation name="queryByPosition">
<http:operation location="queryByPosition" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:content type="text/csv" />
</output>
</operation>
<operation name="queryByPiName">
<http:operation location="queryByPiName" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:content type="text/csv" />
</output>
</operation>
<operation name="queryByProposal">
<http:operation location="queryByProposal" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:content type="text/csv" />
</output>
</operation>
</binding>
<!-- This is where we define the location of the service.
Each binding can have a different location. -->
<service name="service">
<documentation>HST query service at MAST</documentation>
<port name="this:GETport" binding="thisns:GETbinding">
<http:address location="http://faxafloi.stsci.edu:4547/cgi-bin/HSTQuery"/>
</port>
</service>
</definitions>
HST availability service (Kimball)
<?xml version="1.0"?>
<!-- WSDL description of the MAST ADEC TWIG api. -->
<definitions name="urn:ADEC_MAST"
targetNamespace="urn:ADEC_MAST"
xmlns:typens="urn:ADEC_MAST"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- Types for search - result elements, directory categories -->
<types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ADEC_MAST">
<xsd:complexType name="SummaryResult">
<xsd:all>
<xsd:element name="missionName" type="xsd:string"/>
<xsd:element name="dataIdCount" type="xsd:int"/>
</xsd:all>
</xsd:complexType>
<xsd:complexType name="SummaryResultArray">
<xsd:complexContent>
<xsd:restriction base="soapenc:Array">
<xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="typens:SummaryResult[]"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
</types>
<!-- Messages for ADEC MAST Web APIs - get summary by position. -->
<message name="doGetSummary">
<part name="ra" type="xsd:double"/>
<part name="dec" type="xsd:double"/>
<part name="radius" type="xsd:double"/>
</message>
<message name="doGetSummaryResponse">
<part name="return" type="typens:SummaryResult"/>
</message>
<!-- Port for ADEC MAST Web APIs, "ADEC_MAST" -->
<portType name="ADEC_MAST_Port">
<operation name="doGetSummary">
<input message="typens:doGetSummary"/>
<output message="typens:doGetSummaryResponse"/>
</operation>
</portType>
<!-- Binding for ADEC MAST Web APIs - RPC, SOAP over HTTP -->
<binding name="ADEC_MAST_Binding" type="typens:ADEC_MAST_Port">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="doGetSummary">
<soap:operation soapAction="urn:ADEC_MAST#doGetSummary"/>
<input>
<soap:body use="encoded"
namespace="urn:ADEC_MAST"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:ADEC_MAST"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<!-- Endpoint for ADEC MAST Web APIs -->
<service name="ADEC_MAST_Service">
<port name="ADEC_MAST_Port" binding="typens:ADEC_MAST_Binding">
<soap:address location="http://faxafloi.stsci.edu:4547/soap/"/>
</port>
</service>
</definitions>
Simple access to SkyView (McGlynn)
<?xml version="1.0" encoding="utf-8"?>
<definitions
xmlns:s="http://www.w3.org/2991/XMLSchema"
xmlns:tns="uri:diy" targetNamespace="uri:diy"
... other name spaces ...
>
<message name="SkyViewQuery">
<part name="SURVEY" type="xsd:string">
<part name="VCOORD" type="xsd:string">
</message>
<message name=SkyViewImage">
<part name="SkyViewHTMLResponse" type="xsd:string">
</message>
<portType name="SkyViewPort">
<operation name="SkyViewRequest">
<input message="tns:SkyViewQuery">
<output message="tns:SkyViewResponse">
</operation>
</portType>
<service name="SkyViewService">
<port name="SkyViewGet" binding="tns:SkyViewHttpGet">
<http:address location="http://skyview.gsfc.nasa.gov">
</port>
</service>
<binding name="SkyViewHttpGet" type="SkyViewPort">
<http:binding verb="GET"/>
<operation name="SkyViewRequest">
<http:operation location="cgi-bin/nnskcall?(SURVEY)&(VCOORD)" />
<input>
<http:urlReplacement />
</input>
<output>
<mime:content type="text/html" />
</output>
</operation>
</binding>
</definitions>
</definitions>
Interaction diagram (Thomas)
- User requests information from your datacenter (ex. "what holdings at your
datacenter match this sky position"). A 'local service' (could be webserver cgi-bin
script, Java servlet, etc) handles the request. In the brave new world, we want to
return both information about holdings we have locally that match AND as well
information (in phase I, links) about off-site holdings that the rest of us have (that
match the original request).
- The local service gathers local and off-site information. The offsite information
may be cached in a local database (2a) or may be obtained via off-site services (2b).
Interaction with off-site services may be complex and require more than one
response/query interaction. Caching may be done in whatever format, I have just
put RDF/DAML on the cache jar as an example. Caching *may* be desirable in some
instances given the frequency of user requests, response times of off-site services,
etc.
- The response containing both local and off-site information is returned to the
happy user ("we have these holdings which match your request, in addition, there
are the following holdings at these datacenters you may be interested in looking at").
The user may then interact with the present web-page/servlet/etc to initiate a new