However to run a scientific computing job in ccaffeine, only ccaffeine usually is not enough. For example we may need to stage the data in from a Grid data manager for the job running and after the running stage the data out. Also a scientific computing job may need the cooperation between different remote services which may not be running in the ccaffeine framework. So it would be deseraible to merge the ccaffeine framework within the scientific workflow system (e.g. Kepler), thus a ccaffeine framework is able to communicate and share the data with the other servicesin the workflow context.
Our solution is wrapping the ccaffeine framework as a collections of web services With the web service interface, it is easy and nature for those WS-specifications and toolkits which are built over the ws stacks to interoperate with the ccaffeine framework, therefore to facilitate the sharing of the resource.
We can wrap the entire job as a specific service (e.g. the calculation of Pi value). The interface of the service can be just the interface of the component with GoPort.
However we may wish this job-specific service can be generated dynamically. That is users can dynamically design and modify how the job is going to work by connecting the available components and then instantiate the design as a job-specific service. This is much like the run-time web service programming;
A simple architecture to support the dynamic service creation is the Factory Pattern. A factory service is the wrapper of ccaffeine framework, user send the factory service what kind of workflow he want to run. To describe the workflow (or component based job), user can just ccaffeine script together with supporting meta information, or we can define a XML syntax. For example the below XML describes a workflow from component Foo to component Bar.
<job>
<!-- simple workflow: from Foo to Bar -->
<components>
<component> Foo </component>
<component> Bar </component>
</components>
<connection>
<source>
<component> Foo </component>
<port> fooUsePort </port>
</source>
<destination>
<component> Bar </component>
<port> barProvidePort </port>
</destination>
</connection>
<Go>
<component> Foo </component>
</Go>
</job>
Once the factory service gets this description,
it loads the needed components if they are not loaded yet;
instantiates them;
connects them by following the description;
finally wraps the Go component to be a web service
and returns a URL or WS-address to the user.
Once user get the URL, he can invoke the service or later send the modification requestion to the factory service to dynamical adjust the connection.
Note: I realized that the GoPort interface has little type information, it is just like main() function, no input type, no output type, So it is pointless to generate the service for the GoPOrt. However to make the service useful for workflow, a typed interface is ddesirable. For example a web service whose operation interface is int-> double is better then the one with general interface string-->string; Usually GoPort is implement by the Driver component, which usually just start the job by invoking the user ports. So can we dynamically generate the dummy Drive component? let us call it GatewayComponent, which just pass the input data to the really component, and get the result back to outside world. If so , then we can wrap any Component instance to be a Web service, whose interface (i.e. WSDL) can be transformed from its SIDL automatically, and the web service wrapper will generate the Gateway Component and connect it to the component via its use port.
Since the job-specific service is web service, we can build the workflow to weave those distributed services together easily by any general workflow composing tools. This architecture seems to provide a reasonable solution to merge the parallel computing with Service Oriented Architecture. For those computation intensive tasks, we deploy them in the ccaffeine as a Job-specifi services so that the computation resource can be shared, whereas the SOA and workflow allow them connect to each other together when cooperation is needed.
A factory service (called Framework Factory Service) ,which can be configured and create the ccaffeine framework based on user's profile, can save the user from the tedious configuration and installation of ccaffeine.
With Framework Factory Service user can build his own working space, called CCA Running Space, in which user can setup his running environment, options and perference. Those environment setting can include
