[RT] Workflow

So I've been seriously MIA on staying current with Wyona or helping out, but
thankfully it hasn't seemed to matter :-)  My apologies regardless.  I had
some misgivings about how I was building the system I am pulling together for
my new company and decided to do it on EJB.  The detour took "a few" weeks
longer than I had expected.  But it was worthwhile.  EJB seems to be one
letter short of a swear word for many people, but it seems to be the best
alternative to .NET.  As well, wrapping EJB with Web Services is pretty
trivial.

I'm bringing this up because one of the things I've had a tough time with is
how important something like a CMS is in an enterprise and how divergent the
interfaces to access it are.  I guess JSR-170 will go a long way toward
unifying the interfaces, even if nothing is done to make them remotely
accessible.  In an ideal enterprise, there is no document that is published
in an enterprise that is not a part of a CMS, hopefully a single CMS.  So
things like XSL interfaces and JSP tags and Java interfaces and concurrent
remote access and... all this needs to be considered and handled eventually
if adoption is going to be universal.  And it needs to be accessible across a
network from a separate JVM, somehow.

But what about workflow?  Isn't a single workflow engine almost more
important?  It seems to me that I could have an enterprise with several
heterogeneous CMS systems but still have them scripted by a single workflow
engine.  It seems less functional to have several workflow engines, since the
workflow engine is the source of the workflow scripts as well as the source
of the events.  So the gravity of a workflow engine choice seems to be
strong, right?  

There is a pretty good thread on ServerSide at
http://www.theserverside.com/home/thread.jsp?thread_id=13800 about
OpenSymphony's OSWorkflow.  Has anyone looked at it yet to understand why it
could not work for the needs of Wyona?  I would presume that has happened but
there has not been the time to share the experiences yet.  But I think before
OSWorkflow is discounted and another project started, consideration needs to
be given two whether the difficulty in building a workflow engine that can be
universally accessed is going to be harder than fixing the ones that already
are.  When that is considered, fixing OSWorkflow whereever it might be broken
seems to make more sense than rewriting it again.

One of the things that I like about the OpenSymphony stuff is their attention
to being EJB compatible (but not required).  You'll notice in this thread
that they only require a J2EE web container, but can take advantage of EJB
when it exists.  Many people do not like EJB because of performance reasons,
but many people did not like Java over C++ only four years ago.  Today, I
can't imagine anyone considering using FastCGI for a new website.  Wyona
should last longer than four years, and I think it will do that by having
interfaces that are accessible throughout an organization that deploys it.
EJB and .NET are the best ways of doing this today, and I don't think anyone
here is going to say that we should be working on the latter.  Regardless,
you can go either direction with OpenSymphony and it's probably a good thing
to emulate in any project that hopes to get enterprise-wide traction.

"phone lines are open for your thoughts" :-)

-b