Hi Bruce, Yep, I agree with your assessment of workflows. I am going to add a Wiki page containing our thoughts on the workflow system that helped inform the design of the OODT workflow manager. Paul Ramirez and I cooked it up in 2004-05, but haven't put it on the Apache site yet as we are still transitioning some of the material/code.
We'll get it up though soon and the great thing is I think we're in alignment in thinking. Thanks for your thoughts! Cheers, Chris On Apr 26, 2011, at 4:47 AM, Bruce Barkstrom wrote: > As an outside thought, you might want to think of a workflow as > a kind of graph whose vertices are either processes or "files" (metadata > perhaps being one kind of file - if you want to think of database transactions > as "files", you can add those to the category of "file"). The edges in the > graph are events. Maybe you want to have an inventory of vertices or > an inventory of edges. If you want to think about a hierarchical graph, > that might be useful as well, although the data structure and access > methods might be a bit more complex. > > If you want a graph (or collection of graphs - one graph per workflow), > you might use hashing on the ID's to access either vertices or edges. > > Interesting problem. > > Bruce R. Barkstrom > > On Mon, Apr 25, 2011 at 11:00 PM, Verma, Rishi (317I) > <[email protected]> wrote: >> Hi Paul, >> >> Thanks a lot for your suggestions. >> >> I agree, the second approach is probably the way to go. Although, would it >> be more beneficial to save and return a single 'event' ID instead of >> multiple workflow instance IDs? I'm under the assumption that workflow >> behaves something akin to a job submission system. This assumption may be >> incorrect, but it might be beneficial to just get back a single unique ID >> for the launch of a workflow top-level event as opposed to getting back a >> list of IDs... >> >> So perhaps within XmlRpcWorkflowManager.handleEvent, we could generate and >> save a unique ID for the single event? This ID could be queried by a client. >> >> Thanks! >> rishi >> >> On Apr 25, 2011, at 1:25 PM, Ramirez, Paul M (388J) wrote: >> >>> Hey All, >>> >>> Thought this might be useful to the larger OODT community. >>> >>> >>> >>> Hey Rishi, >>> >>> I talked with Mike about this last week but never got back to him with a >>> concrete answer. However, after putting some more thought into it there are >>> 2 approaches I can think of. >>> >>> First Approach: >>> 1) Put some type of user generated id in the metadata object that gets into >>> the workflow instance metadata >>> 2) Page through the lists of workflow instances that the workflow manager >>> has and identify those with your tag. Remember an event can kick off more >>> than one workflow. >>> 3) Any that have metadata that match your user generated id are your >>> workflow instances you're interested in. >>> >>> Second Approach: >>> 1) Add a new method to the client and server so that list of workflow >>> instance ids is returned >>> >>> Looking at XmlRpcWorkflowManager.java >>> >>> >>> public boolean handleEvent(String eventName, Hashtable metadata) >>> throws RepositoryException, EngineException { >>> LOG.log(Level.INFO<http://Level.INFO/>, "WorkflowManager: Received >>> event: " + eventName); >>> >>> List workflows = null; >>> >>> try { >>> workflows = repo.getWorkflowsForEvent(eventName); >>> } catch (Exception e) { >>> e.printStackTrace(); >>> throw new RepositoryException( >>> "Exception getting workflows associated with event: " >>> + eventName + ": Message: " + e.getMessage()); >>> } >>> >>> if (workflows != null) { >>> for (Iterator i = workflows.iterator(); i.hasNext();) { >>> Workflow w = (Workflow) i.next(); >>> LOG.log(Level.INFO<http://Level.INFO/>, "WorkflowManager: >>> Workflow " + w.getName() >>> + " retrieved for event " + eventName); >>> >>> Metadata m = new Metadata(); >>> m.addMetadata(metadata); >>> >>> try { >>> engine.startWorkflow(w, m); // This returns a workflow >>> instance which has an id that could be saved and returned >>> } catch (Exception e) { >>> e.printStackTrace(); >>> throw new EngineException( >>> "Engine exception when starting workflow: " >>> + w.getName() + ": Message: " >>> + e.getMessage()); >>> } >>> } >>> return true; >>> } else >>> return false; >>> } >>> >>> This should probably be a new method on both the client and server and >>> should be supplied as a patch. The method would return either List<String> >>> or List<WorkflowInstance> probably the latter but maybe someone else will >>> chime in. Of course this would have to have the accompanying client method >>> but it shouldn't be that big of an update. >>> >>> My instincts would say that second approach is probably the way to go. >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> >>> On Apr 25, 2011, at 11:39 AM, Verma, Rishi (317I) wrote: >>> >>> >>> return ((Boolean) client >>> .execute("workflowmgr.handleEvent", argList)) >>> .booleanValue(); >>> >>> Is there a way to obtain and query for a workflow 'instance ID'? >>> >>> Thanks! >>> Rishi & Mike >>> >>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
