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 <[email protected]> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
