On Sat, May 31, 2014 at 6:42 AM, Sachith Withana <[email protected]> wrote:
> > > > On Thu, May 29, 2014 at 10:23 PM, Saminda Wijeratne <[email protected]> > wrote: > >> >> >> >> On Thu, May 29, 2014 at 1:15 AM, Sachith Withana <[email protected]> >> 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 > >
