CIShell Manual : Initial Design Thoughts (old)
This page last changed on Feb 22, 2011 by mwlinnem.
Initial DesignCishell Components to be Modeled by Web Service InteractionsAlgorithmsThe 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 SchedulerBeing able to observe and manage the state of algorithms will be important as Cishell becomes a serious distributed research tool. LoggingThis 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 ManagerMost 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 ComponentsWS-I Basic ProfileThe 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-AddressingWS-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. WSRFWSRF 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-NotificationBesides 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/MTOMOften 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 ImplementationMuseMuse 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 WSRFThese are WSRF-related libraries, but they're not under active development like Muse is, and so might not be as useful. Axis 2Axis 2 is the core of a modern web services stack. Particularly Important Remaining ProblemsSecuritySee Data Management URI vs WS-AttachmentSee Data Management |
![]() |
Document generated by Confluence on May 31, 2011 16:37 |