Forum OpenACS Q&A: Contract Job: Web Services Infrastructure for AOLServer

<h3>Web Services for AOLServer</h3>

<h4>Project overview</h4>

Currently AOLserver has a number of implementations of SOAP web services, of varying degrees of maturity and completeness (https://openacs.org/xowiki/tsoap). None of them is as complete or as effective as support on other platforms. United eWay would like to fund the development of a Web Services infrastructure for AOLserver, as we have the need for reliable and effective SOAP-based web services on the AOLserver platform.

Recognizing the broad need for web services, this project will be open-sourced under the GPL license with the goal of making it available to the broader AOLserver community so others can benefit from the work and contribute improvements to the project.

<h4>Project specifications</h4>

The project needs to fulfill the following specifications:

  1. It should be written in Tcl, for a vanilla AOLserver instance. Use of some Tcl extensions, such as tcllib, and AOLserver extensions, such as ns_cache, are fine, but there should not be any other third-party dependencies (e.g. no dependencies on any RDMS, on OpenACS or other Tcl toolkits). One key goal of this development effort is broad accessibility to web services for anybody using AOLserver. We are thus focused on a minimal integration path to install the Web Services package in any environment. We do anticipate adapters being written to streamline further the integration of the Web Services infrastructure into other toolkits.
  2. It should use tDOM.
  3. On the client side, an API must exist which accepts a path to a WSDL and the name of a TCL namespace and generates a functional Tcl API in the given namespace.
  4. On the server side, it should take a Tcl namespace and relative server URL, and generate (a) a WSDL from all procs in that namespace, (b) a browsable interface to the WSDL (ala .NET), and (c) exposed web services that direct web service requests to invocations of that proc.
  5. Runtime performance should be considered, though the distributed nature of Web Services will balance the needs for any specific performance metrics (i.e. The majority of time issuing web service requests should be spent in the communication between servers, and not in the implementation of this platform).
  6. Errors from the web service should be automatically marshaled to and from Tcl Errors.
  7. If any of the currently implementations of web services are well-written, they can be expanded upon. For example, the tsoap implementation may be almost everything needed for client-side web services.
  8. Support for Web Service Security is a specific non-requirement at this stage, though proposals which provide for WS-Security would be preferable.

<h4>Contract</h4>

The work will be on a contract basis. Interested parties are encouraged to bid based on the successful completion of the project. The success of the project will be evaluated based on its ability to:

  1. Accept an arbitrary WSDL (we have a collection of a set of WSDL for which we need immediate support) and successfully invoke each web service via a Tcl call
  2. Generating a valid WSDL from a Tcl namespace, and correctly accepting web service requests to the procedures defined in the namespace.
  3. Correctly marshal and unmarshal errors

<h4>Timeline</h4>

We are prepared to start work on this immediately, but would like the work completed within the next 3-5 weeks.

Very exciting project.
Collapse
Posted by Dave Bauer on
Jade did this ever happen? Is there any status update?

Thanks!

It's in progress -- actually working on the contract right now!
Collapse
Posted by Dave Bauer on
Thanks Jade,

For some reason I thought the original request was much older than mid-September. I'll try to be patient!

Collapse
Posted by Dave Bauer on
Hi there. I waiting 4 months :) Any news on this web services infrastucture for AOLserver?
Me too, me too 😉

Just a short note. Work is underway! If you want a good overview of the parameters, please read the WS-I Basic Profile, and a shorter version of the direction we are headed in is concisely described in this MSDN Article.

The package will have a dependency on tDOM, but usage will be limited to parse level validation of incoming documents, although we might use the XSLT engine to parse a WSDL into the client API.

All of Jade's original requirements will be met, but everyone should note that WSDL and WS-I have some requirements and benefits which are significant. Due to this fact, here are some additional points/requirements/benefits for this project:

  • Interoperability is guiding principle.
  • Only Document-Literal style will be supported.
  • XML Schema validation (applied to all documents)
  • Tcl representation of an XML Document will serve to unite internal API.
Collapse
Posted by Dave Bauer on
Tom,

You referred to XML Schema validation. I am thinking about validating some XML documents against an XSD schema and I am wondering if tDOM can do that. What sort of validation were you planning on implementing?