To provide the essential transparency in accessing the Grid compute resources, the computation toolkit linking Matlab to Condor resources has been implemented in a distinctive structure, which separates the user interface from the underlying message processor that are responsible for interactions with different remote resources based on various protocols. The user interface is an API that represents the basic semantics of compute operations and is designed to be simple but stable. In contrast, the message processor is in a much more dynamic form. It is implemented as two chains of filters for input and output message processing. Each filter is responsible for processing a specific message part, or even the entire message based on the protocol it is responsible for. At the end of the chains, there is a communication handler, which is responsible for direct interactions with the compute resource or compute service middleware. By using Java reflection, the filter chains are dynamically constructed during the runtime based on the information loaded from a configuration file, which is detached from the client applications and can be easily modified. It is therefore possible to access different resource systems by loading different set of filters, or adapt to changes by adding new filters and remove existing ones.

Condor .NET Web Service