Initial Design

Cishell Components to be Modeled by Web Service Interactions

Algorithms

The central components of Cishell, algorithms should be exposable at full functionality with no effort by algorithm authors beyond obeying minimal natural restrictions. Visualization algorithms are a notable exception; even if they are eventually exposed in some form, the functionality of visualizations exposed remotely will be reduced in many cases.

Job Scheduler

Being able to observe and manage the state of algorithms will be important as Cishell becomes a serious distributed research tool.

Logging

This is as necessary as algorithms. While some people might find the logging dispensable, for scientific research it is indispensable, and thus must be conveyed between instances of Cishell when algorithms are invoked remotely, without loss.

Data Manager

Most of what the data manager does may not be directly exposed as web services, but it will handle the conveyance of data to and from remote invokees and invokers. Update: there was considerable discussion on this in the latest meeting, and information about this will now go at Data Manager

Web Services Standards for Modeling the Needed Components

WS-I Basic Profile

The Basic Profile contains a simple set of rules for maintaining web service interoperability. All non-interactive services should, at worst, degrade under plain WS-I Basic Profile compliance to basic functionality -- call the service, get a response with what you want. This might include the use of Attachments, which has some associated issues, but they are included in the Attachments Profile of the Basic Profile, so those issues are likely acceptable.

WS-Addressing

WS-Addressing gives us endpoint flexibility, which can be used to do delegated invocation and the like. It is also part of several other standards we intend to use, including WSRF and WS-I Basic Profile.

WSRF

WSRF gives us properties, which will be useful in many context, and lifetime management, which will be useful for the scheduler service. Properties could include progress, logs, et cetera.

WS-Notification

Besides being used by WSRF to handle property monitoring, WS-Notification can provide our logging solution. In WSRF, a ReferenceProperty of an endpoint serves to identify a given resource, which will be for the instance of an algorithm. Using that resource identification to make a notification subscription will result in sending logging generated by the algorithm to the subscriber, including anything that was generated before the subscription request was received (which will be sent immediately, possibly as one or a few chunks).

Soap with Attachments/MTOM

Often it will make sense to pass data as an attachment -- whenever that data is small 'enough' and already on the local machine, for instance. In such a case, attachment-passing makes a lot of sense, because then all the security for passing the message works with passing the attachment, and there's no problem with the file being too large. Soap with Attachments and MTOM both have the same wire format (and thus interoperability, at least a lot of), but using MTOM on the server/client might be more beneficial due to increased compatibility with other WS-* standards.

Existing Implementations Potentially Useful for Implementation

Muse

Muse implements the whole stack, and focuses on code generation. For these reasons it probably isn't the best solution for what it provides (primarily WSRF), but its an option, especially as its under active development.

Apache WSRF

These are WSRF-related libraries, but they're not under active development like Muse is, and so might not be as useful.

Axis 2

Axis 2 is the core of a modern web services stack.

Particularly Important Remaining Problems

Security

See Data Management

URI vs WS-Attachment