On 9/5/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
On 9/5/06, Edgar Poce <[EMAIL PROTECTED]> wrote:
> On 9/5/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
> > If Graffito provides a support for managing JCR nodes and an High
> > level content object model (which can be customized), how can we
> > define some services like Workflow, publishing, ... ? In theory,
> > thoses services needs to implement some process based on content
> > objects.
> > I think it will not be possible to support both approach. What do you
> > think about that ?
>
> Maybe there can be an integration if
> 1. the workflow is serialized in the repository,
> 2. the semantics of its node types is publicly known (e.g. scxml)
> 3. and the repository garantees, by securing the content, that the
> process will be respected,
>
* What if a workflow process required multiple repositories ? In you
case, you will certainly use only one content repo but the worfklow
service have to work with multpiple content repo (JCR based or not).
A first level of integration would be on process definitions. What I'm
trying to say is that as long as process definitions are stored in the
repository with public semantics, any client can create new process
definition via graffito api, a "content" portlet (as the wysiwyg
prototype), webdav, etc.
A second level of integration would be to store process instances in
the repository. Local and remote clients could create a new process
instance, or take a running process instance, acquire a lock on it,
and signal the process. The process logic can modify one repository,
many, or none. The API of the workflow depends on the engine, I mean
that the BPM framework would be responsible of running the processes.
* What if we are not using a JCR store ?
* When you are moving into a specific workflow state, you may run some
code to manage the content (move a content, delete, update, ...). How
to do it (with the JCR API or the Graffito API ?
I evaluated a couple of workflows for my daily job an I use JBPM
pretty much. AFAIK, in any BPM engine, it doesn't matter whether
actions in transitions modify jcr nodes, graffito objects, send mails,
or whatever.
Running the process is responsability of the BPM engine, the jcr
implementation wouldn't be responsible of running the process, it
would be responsible only of storing the process definitions and
process instances.
> great!. btw, It's probably a good example for trying to integrate both
> approaches.
>
the approach is quite different. We are using the Graffito API.
btw, the graffito api will be extended with workflow capabilities?
what engine, if any, are you using in the contribution?.
br,
edgar
--
Best regards,
Christophe
