Wolfgang,
Jade asked me to report the status of our project, tentatively called tWSDL.
The first thing to keep in mind is that this project is completely independent of OACS, maybe more important: there are no additional dependencies beyond using AOLserver and tDOM. Parts of it run with tclsh, most runs with libnsd loaded, the client side will likely be completely independent of AOLserver (maybe not independent of libnsd).
WSDL is a step beyond XML-RPC and SOAP. WSDL is more like a data model for a service. An important new feature is that WSDL defines message types. By defining types, WSDL enables type checking prior to invoking a procedure. The same information can be used to figure out how to construct messages, where to send them, and how to validate the result.
Unfortunately Tcl doesn't specify types, so there is a little more work required if you want very good type checking. On the other hand, Tcl's very simple (and few) data structures makes it easy to model a procedure call and result in XML Schema.
Speaking in OACS language: WSDL is like a page contract, where you can equate a page to an WSDL operation.
WSDL could potentially cover a huge number of implimentations. However, tWSDL is first restricted by the WS-I Basic Profile. This means that the basic protocol is SOAP/HTTP using document/literal, plus a few hundred other restrictions. (Literal is required, tWSDL may end up supporting rpc/literal). These choices greatly reduce the complexity of XML processing. Third parties can add their own protocols, by adding a routine which processes a small slice of the request. Note that collections of operations, called 'portTypes', are completely independent of the protocol, so everything below portTypes: operations, messages and types never change if you add a protocol.
So what do we want to be able to do with tWSDL?
Server side:
- It should be possible for the developer who knows zero about WSDL/XML/SOAP to easily create a service based upon a Tcl procedure.
- It should also be relatively easy to create a service which enforces type checking on the input and output documents.
- More advanced developers should be able to construct services which can process and produce XML documents at the complexity of, for instance, an invoice or sales transaction.
Client side:
- A tWSDL client should be able to read a WSDL file and create a client Tcl API.
- Client code can then use the new client API to invoke the service.
- In the simple case, a single call to a client API will return a Tcl result.
- In more complex cases, client API's will construct an XML document, then invoke.
- Client will have full ability to validate outgoing and incoming documents and report faults.
So where is tWSDL right now?
The server side is progressing very well. We can create a service based upon any Tcl procedure which produces a simple result (list).
Extending this to more complex results will be relatively easy. Although there are automatic procedures for handling the usual case, these can be replaced with custom code. Eventually there will be helper procedures to make it easier to write custom code.
It is important to point out that custom code doesn't need to deal with any of the other parts of tWSDL. Essentially the custom code which invokes the procedure is handed a Tcl representation of the XML document (by reference). This document could be of any complexity. The custom code completely handles this processing until it returns a reference to the result XML. In the current API, this 'custom' code is auto-generated.
The separation of the invoking code from the service ensures that the developer is not limited by 'my' preconceived ideas: any XML document can be processed and/or returned.
Although simple things are simple, the simplist thing: no brainer WSDL, is still a few weeks away. This is nothing more than a wrapper with a few conventions on how things should be done. At the moment we have two services, one imaginary (no real backend), one real. These two services offer enough diversity to build the no brainer service.
Since tWSDL will be used with ACS code, I will develop a switch for ad_proc, which Jade mentioned above. The switch will employ the conventions (hmmm, maybe we can configure those), to build a service at runtime. In any case the switch will do nothing more than cause a single proc to run which will use introspection to create a no brainer service. It should be just as easy to call the proc outside of ad_proc (at the correct time).
Another important part of tWSDL is fault/error handling. Currently client errors are handled: incorrect target namespace and invalid document (type errors). Server errors are not handled yet, but will most likely return a stacktrace. You still get a 500 response, which is all most clients need to know that it is a server error. Error checking/handling is done according to the WS-I Basic Profile.
Code Release:
I'm open to suggestions here. I don't mind releasing this package now, but anyone using this needs to remember that major changes could result. However, I have already done a handfull of major changes and the code changes to the application code have been easy and fast to apply. Application code relies mostly on metadata, so there is very little risk that a big change in implimentation would change the amount and type of metadata required. Most changes so far have been to the form in which the metadata is presented to the API.
OACS has a unique and valuable API, there is also a huge investment in page flows which cannot be replicated by a web service. A web service can potentially be useful in OACS for existing and potential packages, but not every package. The only thing that is really universal across all OACS installations is the Tcl API. tWSDL offers the potential to expose any Tcl API as a web service. In addition, it should be noted that OACS also uses conventions related to types and data structures. It would not be difficult to exploit this metadata to build high quality web services with very little additional effort by the developer.
There are still many questions to be resolved for any web service package including security and how a web service should fit into the request processor. The fact that web services use a different processing model than a pure HTTP service makes this a difficult question.
