United eWay tWSDL Plan: System Overview

tWSDL Server API

tWSDL Server

Client

HTTP Doc	SOAP Doc	TYPE Doc	TYPES	WRAP API
Protocol Checker		Type Checker		INVOKER
tWSDL Core API & tWSDL DB
Protocol Server		Typer		WRAPPER
AOLserver				Tcl API

tWSDL Core Components

The above figure illustrates the relationship between various components which will make up the tWSDL System. A graphic is hardly a model of a software application, but we can use it as a partial representation, which can be used as a reminder of how the system will work. Before going into an explaination of the parts, let me explain how the graphic represents the relationship between the parts.

Overall, the figure has three parts along a horizontal line. The parts are the client component, an undefined gap and the server component. The undefined gap merely represents a separation of the client and server. In our specific case this will usually be the internet or some other local network. Beyond the figure on the right and left are user requirements. Users setup servers and use clients. Users can be people or other applications. The horizontal line (direction) also represents the layers of programs and applications between users. Therefore, each vertical line (the vertical sides of the boxes) represent an interface between layers. This is usually refered to as an Application Programming Interface or API.

Each box represents either a program or data, or both. The central gap is a data box which can be thought of as TCP packets or as HTTP requests and responses. Each vertical line also represents a barrier or boundary between programs and/or data.

Just as each vertical line divides applications or programs which have different functionality, each horizontal line divides parts of a system which offer similar functionality. An horizontal line also represent a division between an application and the data it uses.

Each pair of horizontal line divides an overall system into channels. These channels work or exist to extend or expose the overall functionality of the system, end to end.

Applying these generalities to the figure, notice that the tWSDL Core API & tWSDL DB is represented as a box which extends horizontally from the network interface to the user interface. This implies that this component mediates the entire process and calls on other components to perform various functions. The fact that it touches the network interface reflects the fact that the Core component will provide an interface into the tWSDL DB database to serve WSDL files and other Web Service details.

If you mouse over this component, a dashed red line will replace the solid base of the box. This indicates that information and/or control passes between the components. However, the sides of the boxes remain solid, which indicates that information/control MUST pass through the Core and not horizontally between components. So a red dashed line between components represents the way in which information/control flows.

The tWSDL Server is an application which will run on top of an instance of AOLserver. AOLserver has a built in Tcl interpreter and an associated Tcl API. In addition, AOLserver allows installation of additional C and Tcl Modules. C Modules are accessed via an associated Tcl API. All exposed Tcl API are available to the tWSDL System.

The tWSDL System is composed of several components. There will be a Core tWSDL API which will be used to maintain and manage all aspects of the System. This Core API will be extensible in several areas for various reasons.

One extension area will be the Wrapper. A Core set of API will allow the developer to wrap any generic function. Extensions of this basic API will make it easier to create Wrappers for specific Tcl API for which some otherwise necessary information can be derived. For example, a simple Wrapper could assume that all inputs and outputs are strings. Simple introspection would allow for inputs to be named. Another example could be for database procedures where the types can be looked up in a data dictionary. The Wrapper creates a function which takes a representation of an XML document and returns another XML document. The Wrapper is run once to create a tWSDL application. The API generated by the Wrapper will not be a localized API. It should be possible to package and move to another system without the need to rerun the Wrapper. One additional note on Wrapper extensions: it is also possible that an entirely different Wrapper can be used. The only requirement on the Wrapper is that it create a procedure which takes an XML document of the correct type and returns another XML document of the correct type. In practice, these XML documents (their in memory representation) will be Tcl namespace references.

The Typer is another potential area for extension. The Core API will cover the allowable methods of creating types. A similar line of reasoning for Wrapper extensions can be applied to the Typer. In both cases, extensions will either make an assumption which limits the amount of data needed, or will be able to find the data needed from another source.

Following WS-I Basic Profile, tWSDL will only support SOAP over HTTP. However, it should be possible to add additional protocols as an extension.

Several components will be relatively fixed. These will be the Invoker, the Type Checker and the Protocol Checker. Each of these components will operate under the direction of the tWSDL Core.

A tWSDL Application

Before going into more details about the Server in operation, let's note a few points about how a tWSDL Application will come to life.

Using the Core tWSDL API, a developer will write a script which will define the Application. This script should handle the generation of the desired tWSDL Application. A generated tWSDL Application will consist of several parts:

A WSDL File: A Web Sevice Description defines the public interface of the Web Service. In the case of tWSDL, this file should contain ALL the information needed to use the service.
A WRAP API: This consists of a series of API which will be called by the Invoker to perform the Service.
New Types: Any types defined in the script will be added to the tWSDL DB. The tWSDL DB will be a collection of all data needed to run all tWSDL Applications in a particular AOLserver installation. On paper the tWSDL DB will just be a series of scripts which load data into memory. The in memory representation will be Tcl Namespaces (without procedures).
New Registered Procs (Bindings): A startup file for the Application will use registered procs to 'bind' a service to the required address/port during server startup. The registered procs will invoke the tWSDL Core to handle the request.
Once the Service is loaded, a browsable copy of the WSDL Service Description and SOAP Message examples will be published.