Thank you for this point of view from the industrial world!
Before reading your answer I invested some time in browsing the
presentation done by Vincent and Tugduall Grall from eXo Platform (as
Guillaume pointed out in this same thread). First of all, I must
recognize that I didn't consider eXo as an option. I remember that more
than a year ago I tried to take a look at eXo, but I finally decide to
postpone this option: I was not able to understand how XWiki and eXo
interact. My fault!
Pascal, have you chosen Magnolia after comparing it with eXo? Or, have
you tried eXo?
Pascal Voitot wrote:
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez]
Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
I don't have a precise answer and I don't want to say stupid things because
I'm not exactly an expert at workflow design even if I use that often :)...
My feeling is that these technologies are born from the industrial server
movement... you know, a bit like J2EE servers... in a charicatural sentence,
I would say:"the bigger the better"... you take all the problems as a whole
and you provide a global solution for all problems... and then some people
say:"don't you think we could have something a bit more lightweight which
fulfills only what we need while keeping the possibility to use the big
server when we need it?"... and people find new ideas, concepts and designs
to make things more lightweight and you get things like Spring for example
(which is no more so lightweight anyway) and it makes change J2EE servers
because these ideas are not so stupid...
So now you take the great subject of automaton with states, workflows,
orchestrations, business process management and you create a tool allowing
to model any process corresponding to the theory, you participate to some
standardization meetings to make things a bit more abstract. Finally, you
get something powerful, huge, complex that can do everything you need but
also you don't need.
In fact, if you look carefully, these questions about process management are
almost everywhere in the industry but there are no good solutions. There are
some professional tools but they cost so much that you can't even imagine
paying that just to design a small publishing workflow...
BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business
Process Management is becoming a kind of holy grail for marketting people in
the software industry... but not sure technical people agree ;););)
Ok, that's all for now...
Let's think about one of this huge initiatives facing a even bigger
problem. A number of vast firms establish a partnership, identify and
define the huge problem, devote a huge amount of resources and get their
solution. They must use this solution! Some people, being outside of the
partnership (auto-excluded or not being able to join it for one or other
reason) start thinking in this not so stupid way you talked about.
They/he/she act as the core of a new initiative to which, little by
little, new developers and users become involved with the initiative.
They become a team, trust each others, feel comfortable working together
and solve their day-by-day issues using a new via (Ok, ok, this could
sound a bit like Alicia's World, but if harmony, ethics and moral issues
are not applied here, I won't be able to explain what this happens!
Business are at the core, but they are not enough)
For me, for us, XWiki is one of this "not so stupid ideas" :-) And we
feel confortable working here. The answers that we are trying to answer
now are devoted to decide why we must keep trying to solve our "business
issues" with XWiki, team and software, at the core of our toolscape.
Of course we do realize that XWiki needs more resources to go further
and, mainly, developers could spend some less hours tied to their
computers! :-) Let's keep trying to do something useful.
In the last week, a number of Open Source initiatives has jumped in our
scenario as options to solve not-well-developed-yet XWiki issues (eXo,
Magnolia, Bonita, iText, jBPM,...)
Sergiu proposed a really simple way of solving the problem of
"publishing authorization". We need something a bit more complicated,
perhaps just facilitate that the responsible/responsibles of a document
receive a warning when the people involved with the creation of a
document agreed on its contents and that the publication of that
document will be effective when responsibles, let's say, check an
agreement box. I think this problem is far from needing any kind of
fancy workflow framework and can be solved within XWiki without much
work. We will keep an eye on any further development on integration with
other projects and try to finally update to 2.x and start contributing
to development.
There are workflow engines in the opensource world but
I don't know them
precisely so I can't say they are simpler or better...
This is my point of view from the industrial world :)
Thanks for your thoughts and your work!
Greetings,
Ricardo
--
Ricardo RodrÃguez
Your EPEC Network ICT Team