airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Workflow handling in the Application Catalog
Date Tue, 03 Jun 2014 15:38:02 GMT
On Sat, May 31, 2014 at 6:42 AM, Sachith Withana <swsachith@gmail.com>
wrote:

>
>
>
> On Thu, May 29, 2014 at 10:23 PM, Saminda Wijeratne <samindaw@gmail.com>
> wrote:
>
>>
>>
>>
>> On Thu, May 29, 2014 at 1:15 AM, Sachith Withana <swsachith@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> When designing the Application Catalog for single Applications, I ran
>>> into the issue of supporting workflows in the Application Catalog.
>>>
>>> Should we store the workflows ( workflow files) and keep ids, which
>>> would be the handles for those workflows?
>>>
>> Thanks for bringing this up Sachith. In your opinion how do you think the
>> workflow should be represented through the CPI? Workflow string or Thrift
>> object with workflow metadata distinguished or Thrift object with all
>> workflow data distinguished or any other way? I suppose we need to
>> figure-out what should be queried in a workflow.
>>
>
>
> For the functional purposes I think it would be better to store the
> workflow the way it is right now purely because we wouldn't want this to
> affect the Workflow Interpreter behavior. But we can store meta-data about
> the workflows to whatever the features we would want to support. Is there a
> way to get the applications residing in a workflow without explicitly
> passing it to get the meta-data?
>
Workflow nodes specifically does directly correspond to applications but
service descriptors. The current workflow model object have functions to
return these service descriptors.


>
>
>>
>>> We would have to keep track of the applications that are in that
>>> workflow so that the deployment related data would be reused.
>>>
>>> Similarly to the single Applications, the sharing and other features
>>> would be available for the workflows as well.
>>>
>>> Is there any more details that I should be concerned about when
>>> implementing the aforementioned approach?
>>>
>> IMO we can generalize workflows as a composite application with special
>> properties. For example a workflow could simply be another deployment for
>> an Application interface. wdyt?
>>
>
>
> I agree. I'll send you the current design I have which generalize this.
>
>
>>
>>
>>> If we are planning to add searching capability with the workflows as
>>> well, then we'd have to store the applications that are used in the
>>> workflows, separately in the database as well instead of storing it as a
>>> whole.
>>>
>> You mean node information here when you say "applications" right?
>>
>
> yep. wdyt?
>
I think it brings us back to whether want to save the workflow as a single
blob or as separate data for the graph. IMO what we send to the registry
should be a complex workflow object and we should be able to query those
objects from the registry based on their properties. How registry saves
this complex object (as a single blob, metadata+single blob or
metadata+graph data) is immaterial for the user of the registry/app catalog.



>
>>
>>> Any suggestions/comments on the matter is highly appreciated.
>>>
>>> --
>>> Thanks,
>>>  Sachith Withana
>>>
>>>
>>
>
>
> --
> Thanks,
>  Sachith Withana
>
>

Mime
View raw message