Problems with HelloWorld executing

[gfs.sprl]

It is really a shame I guess but I can't seem to be able to make the
engine work on the basic helloWorld example;

My test class code:

public WorkflowEngine() {
engine = new MemEngine();
engine.addNodeType( "helloWorld", HelloNode.class );

try {

File xml = new File("/main/webapp/WEB-INF/bootstrap.xml");
engine.getLoader().load(xml);

} catch (LoadException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (JAXBException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Graph graph = engine.getRepository().getLatestGraph("hello-world");
GraphProcess process = engine.startProcess(graph);

LoggingManager.println(process.getState().toString());

}

my bootstrap helloWorld:

<?xml version="1.0"?>
<process-definition name="hello-world"
xmlns="http://sarasvati.googlecode.com/
ProcessDefinition">

<node name="hello" type="helloWord" isStart="true"/>

</process-definition>


And finally the Node class:

public class HelloNode extends MemNode {

@Override public void execute (Engine engine, NodeToken token)
{
System.out.println( "Hello, world!" );
engine.completeExecution( token, Arc.DEFAULT_ARC );
}
}



I execute this code and get no errors. When showing the state of the
graph it says it has completed but no "Hello, World" message in my
console. What am I missing here? I tried to see whether there was a
guard preventing this node to execute and go directly into Completed
state, but nothing. A plain null meaning Accept (cf javadoc).


Thanks


PS. Where can I get the xml dtd for workflow-descriptions?

[gfs.sprl]

I think that the problems comes from the fact that my helloworld nodes
aren't recognised as such.

[Paul Lorenz]

Your process definition has type "helloWord". It's missing the 'l' for world :)

So, should Sarasvati throw an exception when it encounters an unknown type? Right now it will return the default type (node) when a specific type hasn't been registered.

To answer your last question, Sarasvati uses XML Schema, rather than a DTD. It can be found in  common/ProcessDefinition.xsd in the download.

cheers,
Paul

[gfs.sprl]

No W-A-Y!

I can't believe this didn't jump into my face... In my defense this
came right from your example on googlecode! You really should make
attention to this kind of subtilities; this might scare potential
users away after all if they can't even make a simple demo work who
knows what else might go wrong.


Btw. What's your position on the "using petri nets to model business
processes" question? JBoss guys who wrote jBPM say this approach isn't
very well suited for business processes and wrote their jBPM engine
following what they call GOP (Graph Oriented Programming). This
actually means they provide the equivalent of your graphs and
processes, but without the automated token-execution mechanism
embedded. Everyone is free to implement whatever paradigm he feels he
likes best.

Second question... Why not implementing sarasvati on top of the jBPM
engine? That would _in my view_ certainly make it more attractive for
other developers who would feel like they're backed by a big player
behind their code, don't you think so?



Regards

On Jul 30, 3:31 pm, Paul Lorenz <plor...@gmail.com> wrote:
> Your process definition has type "helloWord". It's missing the 'l' for world
> :)
>
> So, should Sarasvati throw an exception when it encounters an unknown type?
> Right now it will return the default type (node) when a specific type hasn't
> been registered.
>
> To answer your last question, Sarasvati uses XML Schema, rather than a DTD.
> It can be found in  common/ProcessDefinition.xsd in the download.
>
> cheers,
> Paul
>

[Paul Lorenz]

On Thu, Jul 30, 2009 at 1:14 PM, gfs.sprl <gfs....@gmail.com> wrote:

No W-A-Y!

I can't believe this didn't jump into my face... In my defense this
came right from your example on googlecode! You really should make
attention to this kind of subtilities; this might scare potential
users away after all if they can't even make a simple demo work who
knows what else might go wrong.

Well, shoot. That's embarrassing :) Docs are now fixed, thank you for pointing that out.
 

Btw. What's your position on the "using petri nets to model business
processes" question? JBoss guys who wrote jBPM say this approach isn't
very well suited for business processes and wrote their jBPM engine
following what they call GOP (Graph Oriented Programming). This
actually means they provide the equivalent of your graphs and
processes, but without the automated token-execution mechanism
embedded. Everyone is free to implement whatever paradigm he feels he
likes best.

Sarasvati was built to replace a proprietary petri-net based workflow engine at my company. It served us well, but had some issues. I consider Sarasvati to be based on graph oriented programming with some niceties of our petri-net based engine stirred into the mix.

I think petri nets are capable of modeling any business process you like, but there are abstractions that get in the way and clutter things up. Also, it doesn't seem to lend itself well to a straightforward, well performing implementation. Sarasvati was designed to provide mappings that are as close to the ideal model as possible. It was also designed to be easy to implement.
 

Second question... Why not implementing sarasvati on top of the jBPM
engine? That would _in my view_ certainly make it more attractive for
other developers who would feel like they're backed by a big player
behind their code, don't you think so?

Before starting on Sarasvati, I tried working with jBPM, but found too many small things I disliked. They may have fixed them with the 4.0 release, but it's a little late now :) I think implementing the Sarasvati feature set on top of jBPM would be possible. However, some features like backtracking and some of the visualizations would be a lot messier. I'm quite happy with the abstractions that Sarasvati is built on. Also, in my entirely biased opinion, the Sarasvati code base is clean and minimal. That I'm happy with the abstractions and code base are more important to me than the corporate backing provided by jBPM. (Not trying to slam jBPM here. These things are very personal, and I'm sure they feel the same way about their design and code).

Sarasvati as a project will succeed if it
  1) provides the features people need
  2) is well documented and easy to use
  3) is responsive to its users
  4) develops a decent sized developer community

cheers,
Paul

[sgw.y]

> 1) provides the features people need

I must admit sarasvati does exactly what I expected it to do (well at
least I hope) and is very very lightweight which I also appreciate
very much.

> 2) is well documented and easy to use

That's the first thing that really got me even bother looking at the
engine. Clean and neat + some background theory.

> 3) is responsive to its users

Well... Here we are speaking

> 4) develops a decent sized developer community

I wish you good luck :-)






On Jul 30, 8:36 pm, Paul Lorenz <plor...@gmail.com> wrote:

[Paul Lorenz]

On Thu, Jul 30, 2009 at 3:10 PM, sgw.y <fron...@gmail.com> wrote:

>   1) provides the features people need

I must admit sarasvati does exactly what I expected it to do (well at
least I hope) and is very very lightweight which I also appreciate
very much.

>   2) is well documented and easy to use

That's the first thing that really got me even bother looking at the
engine. Clean and neat + some background theory.

>   3) is responsive to its users

Well... Here we are speaking

>   4) develops a decent sized developer community

I wish you good luck :-)

Thank you!