By web services here we mean SOAP (Simple Object Access Protocol) Services.
"[Definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.]
Our definition of the term "Web services" does not presuppose the use of SOAP as a packaging format or a processing model. Nor does it presuppose the use of WSDL as a service description language. There are, and will be in the future, plenty of Web services that use raw HTTP as a data transfer protocol and some mutually agreed-upon XML format as the message content. The Web Services *reference architecture* does, however, assume that the higher levels of the Web services protocol stack are built on the foundation of SOAP and WSDL.
Hence the W3C definition does not require SOAP, but it is a de facto standard at present for web services.
If we choose SOAP and WSDL, a range of tools exist.
- We have tried - Java, C#, Python and Perl
- Generate Proxy classes in your language
- Marshals calls to the service
- Serializes/Deserializes XML from service into/out of native objects.
- Generates WSDL for your service.
- Language/Platform independence
- Donít care much about the format of the XML - got a local object (tools)
- Making service is easy
- Allows complex operations/info in easy manner
In general, we host our web services on IIS using Microsoft .NET server. We write our services in C#.
- Small learning curve (new technology - must learn the ABCs)
- Can be difficult to get exactly the XML/WSDL you want (if you care)
- Need a web server and application server running (if hosting service)
- Performance - not a problem so far
There are many web services available at JHU - most are listed on the
Virtual Observatory Page.
Services of particular interest to users of SDSS data are mentioned here.
The Image Cutout service (ImgCutout) is briefly covered in the API page. This web service allows you to get jpg images of parts of the sky covered by SDSS.
The service URL is:
As with all web services, you may get the WSDL by adding ?WSDL to this URL - i.e.
The DIME page describes writing a Java client to this service. The Image Cutout service underpins many of the pages on the SkyServer website.
This web service allows submission of SQL queries, with results returned in a number of formats.
The service URL may be found at:
The CAS Client page describes writing Java and Python clients to this service.
This service is briefly mentioned on the API page.
The Service URL may be found at:
The Density Map tool is built on this service.
There is a group of web services for accessing spectral data from the SDSS:
Further information about Java and C# clients for these services may be found on the
Spectra Client page.
The Spectra Website is built on top of these services.
As already mentioned, the Spectra Website is built on top of the spectra and filter services.
Many of the tools on the SkyServer site rely on the ImgCutout service. The Navigate tool is probably the best example.
Global color-coded maps such as the seeing map shown on the right may be produced from the Density Map tool, which relies on the DensityMap service.||
Mirage (pictured on the right) is a powerful data analysis tool from Bell Labs. We have made a wrapper for Mirage using the CAS Access service and
the NVO Registry. The wrapper allows loading of VO data and data from SQL queries to CAS.
For more information, and to download, see the