architecture of OpenWFEru
yaro
single ruby runtime? If yes I think it is a critical disadvantage,
since one process can break the whole system. Is the architecture of
OpenWFEru described in diagrams anywhere?
yaro
John Mettraux
On Thu, Mar 27, 2008 at 7:21 PM, yaro <jaros...@gmail.com> wrote:
>
> It seems OpenWFEru is written entirely in ruby. Does it run on a
> single ruby runtime?
yes, usually.
a process instance can fire process instances on other process engines
elsewhere.
> If yes I think it is a critical disadvantage,
> since one process can break the whole system.
How would you do it then ?
This problem is common to many software applications. OpenWFEru has an
error journal that copes with errors in single process instances.
Application isolation is a good technique as well.
> Is the architecture of
> OpenWFEru described in diagrams anywhere?
No, but the glossary is a good starting point :
http://openwferu.rubyforge.org/glossary.html
I'd be glad to document some aspects of the project, maybe you could help.
Best regards,
--
John Mettraux -///- http://jmettraux.openwfe.org
yaro
>
> > It seems OpenWFEru is written entirely in ruby. Does it run on a
> > single ruby runtime?
>
> yes, usually.
>
> a process instance can fire process instances on other process engines
> elsewhere.
>
I had a quick look at the webpage, but I'm missing information what
exactly it supports
- for example means to start processes from elsewhere (whether it is
done via web services),
whether clustering is supported and how it works in a few words. I'm
not interested in source
code examples, or how to install it. When user looks at the page, he
needs to know exactly
what advantages does the project give to him over other BPM engines
without having to study
too much documentation.
> > If yes I think it is a critical disadvantage,
> > since one process can break the whole system.
>
> How would you do it then ?
>
> This problem is common to many software applications. OpenWFEru has an
> error journal that copes with errors in single process instances.
>
> Application isolation is a good technique as well.
>
were
looking for a replacement. One of the reasons we decided to abandon
Oracle BPEL
was because of the XML language which is impossible to read and
absolutely no
code reusability (who would fix all those namespaces in copied
code...). It might
be interesting for you to know why we didn't choose OpenWFEru - we
consider stability
and high availability a must (Oracle BPEL is not stable in cluster
mode, and there
are also bugs when it runs in single node mode). We don't consider
OpenWFEru stable enough
because it uses single ruby runtime (if not running in a cluster) to
execute all processes.
It can never be stable enough due to this flaw. Process isolation is
very important, so
that no matter what one process does, it cannot in any way influence
execution of other processes.
We decided to develop our own engine executing processes written in
our DSL, with the possibility
of executing Ruby code directly. There is no XML that defines process
(except XSD for input and output)
- since we think it is bad for code reusability.
Classic ruby code is much easier to read and more reusable. Processes
are executed from EJB, and
jruby runtimes are cached to isolate different versions of processes.
If one process instance somehow
manages to break a jruby runtime (due to some action or bug in
runtime), other processes will be unaffected.
Using multiple ruby runtimes of course has higher memory requirements
and there is initial delay when 1st
loading a new runtime. Right now its closed source and not so far like
OpenWFEru (it has no web, processes
can only be invoked from java via EJB or from other proceses).
Ruby is a nice language, solving many tasks is often much easier than
in other languages, therefore it is
advantageous if process can contain ruby code directly (and use
various gems). However if you want stability
in OpenWFEru, you can never allow process to contain ruby code
directly (so it can't do things like String=nil or
shutdown the runtime). Using multiple ruby runtimes to execute
processes (with 1 runtime only for certain process or version)
is a better option in my opinion since it brings better potential
stability. I think OpenWFEru is an interesting
project, but I'm affraid due to the decision to use single ruby
runtime, stability will always be limited. I'm not
sure this can be solved in any way if most of the code is written in
ruby directly.
> > Is the architecture of
> > OpenWFEru described in diagrams anywhere?
>
> No, but the glossary is a good starting point :http://openwferu.rubyforge.org/glossary.html
>
execution engine, job scheduler work.
Also a short page about why people should use your project. I can
compile a list of annoyances in Oracle BPEL
if you are interested, which could help you to convince people to use
your solution.
Yaro
John Mettraux
>
> On Mar 27, 11:35 am, "John Mettraux" <jmettr...@openwfe.org> wrote:
> > Hello,
> >
>
> > On Thu, Mar 27, 2008 at 7:21 PM, yaro <jarosla...@gmail.com> wrote:
> >
> > > It seems OpenWFEru is written entirely in ruby. Does it run on a
> > > single ruby runtime?
> >
> > yes, usually.
> >
> > a process instance can fire process instances on other process engines
> > elsewhere.
> >
>
> How is clustering realized, via database or network communication?
It's not clustering, it's distribution. It's realized via network
communication, but you can change the listener/dispatcher pair,
> I had a quick look at the webpage, but I'm missing information what
> exactly it supports
> - for example means to start processes from elsewhere (whether it is
> done via web services),
> whether clustering is supported and how it works in a few words. I'm
> not interested in source
> code examples, or how to install it. When user looks at the page, he
> needs to know exactly
> what advantages does the project give to him over other BPM engines
> without having to study
> too much documentation.
Maybe the "page" is a filtering device to attract only the
hard-working developers.
You have to realize that OpenWFEru is not a company. I use it in my
work for my company but I'm otherwise not sponsored at all. It's a
"tolerated" activity for me.
That gives me a certain freedom, and part of this freedom is that I am
free not to bullshit people over what its real capabilities. And I
won't try to sell you any training / custom development / enterprise
edition license. And the code is accessible and well commented (see
http://www.ohloh.net/projects/4749)
I cannot afford a professional salesguy to come over and bullet point
you. The documentation may be rough, but well, it's not a "brochure".
The license is BSD so you can steal OpenWFEru without remorse.
I don't need clustering now, so I haven't written about it. And I
haven't encountered someone who needed it yet (apart from you).
> We have a very negative experience with Oracle BPEL 10.1.3.3.0 and
> were
> looking for a replacement. One of the reasons we decided to abandon
> Oracle BPEL
> was because of the XML language which is impossible to read and
> absolutely no
> code reusability (who would fix all those namespaces in copied
> code...). It might
> be interesting for you to know why we didn't choose OpenWFEru - we
> consider stability
> and high availability a must (Oracle BPEL is not stable in cluster
> mode, and there
> are also bugs when it runs in single node mode). We don't consider
> OpenWFEru stable enough
> because it uses single ruby runtime (if not running in a cluster) to
> execute all processes.
Why don't you run multiple engines each in their own VM ? OpenWFEru is
cheap enough to allow that.
> It can never be stable enough due to this flaw. Process isolation is
> very important, so
> that no matter what one process does, it cannot in any way influence
> execution of other processes.
> We decided to develop our own engine executing processes written in
> our DSL, with the possibility
> of executing Ruby code directly. There is no XML that defines process
> (except XSD for input and output)
> - since we think it is bad for code reusability.
> Classic ruby code is much easier to read and more reusable. Processes
> are executed from EJB, and
> jruby runtimes are cached to isolate different versions of processes.
> If one process instance somehow
> manages to break a jruby runtime (due to some action or bug in
> runtime), other processes will be unaffected.
> Using multiple ruby runtimes of course has higher memory requirements
> and there is initial delay when 1st
> loading a new runtime. Right now its closed source and not so far like
> OpenWFEru (it has no web, processes
> can only be invoked from java via EJB or from other proceses).
Sincerely, I'm quite happy that you took the time to tell me about why
you didn't choose OpenWFEru.
> Ruby is a nice language, solving many tasks is often much easier than
> in other languages, therefore it is
> advantageous if process can contain ruby code directly (and use
> various gems). However if you want stability
> in OpenWFEru, you can never allow process to contain ruby code
> directly (so it can't do things like String=nil or
> shutdown the runtime).
A BPMS is not an engine alone, I'm not talking cluster or grid...
There is a staging sub-system and a production sub-system. A process
should be used on the production system only when it passed the
staging phase.
And don't forget that with ruby it's quite easy to write test cases,
see for example :
http://jmettraux.wordpress.com/2008/01/04/the-trouble-ticket-process/#more-388
where a process is implemented and then tested.
Furthermore, OpenWFEru evaluates the Ruby process definitions (don't
forget we have XML process definitions as well) in a constrained env.
It's one of my background tasks to enhance this constrained way, but
it's not that easy : Ruby, JRuby, and all have different ways to deal
with "other processes", throw in differences in OSes and then remember
that I'm trying to provide an engine which runs out of the box for
easy evaluation... I'm having great hopes for Ruby 1.9 and especially
Rubinius...
By default OpenWFEru prevents you from launching process definitions
via a URL. And the code being quite open, it's easy for you to let
only "trusted" processes get in the engine's launch ramp.
> Using multiple ruby runtimes to execute
> processes (with 1 runtime only for certain process or version)
> is a better option in my opinion since it brings better potential
> stability.
Ok ok, why not :
---8<---
require 'rubygems'
require 'openwfe/engine'
OTHER_PROCESS = <<-EOS
puts 'hello from the other process...'
EOS
engine = OpenWFE::Engine.new
engine.register_participant :other_process do
puts `ruby -Ilib/ -e "#{OTHER_PROCESS}"`
end
fei = engine.launch <<-EOS
class MyProcess < OpenWFE::ProcessDefinition
sequence do
other_process
end
end
EOS
engine.wait_for fei
--->8---
I actually did not start a second engine in the "other" Ruby runtime,
but I guess you will understand.
> I think OpenWFEru is an interesting
> project, but I'm affraid due to the decision to use single ruby
> runtime, stability will always be limited.
Do you think that this "decision" is written in the stone ?
> I'm not
> sure this can be solved in any way if most of the code is written in
> ruby directly.
I'm glad you shared your concerns. Too bad you guys decided to
implement it in your own way, I'm sure the whole OpenWFEru community
would have had appreciated your contribution.
> > > Is the architecture of
> > > OpenWFEru described in diagrams anywhere?
> >
> > No, but the glossary is a good starting point :http://openwferu.rubyforge.org/glossary.html
> >
>
> I think you should draw a couple of diagrams showing how the web,
> execution engine, job scheduler work.
> Also a short page about why people should use your project.
The documentation is increasing in size, and in quality (I hope).
Thanks for those suggestions.
> I can
> compile a list of annoyances in Oracle BPEL
> if you are interested, which could help you to convince people to use
> your solution.
I'd love to read that list, please contribute it to this mailing list,
there is certainly a lot to learn from it. Thanks in advance.
Thanks for taking the time to write down this feedback, really
appreciating that. Best regards,
yaro
>
> It's not clustering, it's distribution. It's realized via network
> communication, but you can change the listener/dispatcher pair,
> haven't encountered someone who needed it yet (apart from you).
and full or partial load sharing. For high availability its enough if
process that ran can continue running or be restarted on another node
if one fails with all variables stored in it. Although maybe not many
people need it, in my company we design all applications for high
availability. I would say high availability is necessary nowadays, I
don't understand why anyone would design a system that couldn't work
as master-master or master-slave at least. It would be nice if it was
mentioned somewhere, how to achieve high availability on openwfe.
>
> Maybe the "page" is a filtering device to attract only the
> hard-working developers.
>
> You have to realize that OpenWFEru is not a company. I use it in my
> work for my company but I'm otherwise not sponsored at all. It's a
> "tolerated" activity for me.
>
> That gives me a certain freedom, and part of this freedom is that I am
> free not to bullshit people over what its real capabilities. And I
> won't try to sell you any training / custom development / enterprise
> I cannot afford a professional salesguy to come over and bullet point
> you. The documentation may be rough, but well, it's not a "brochure".
>
> The license is BSD so you can steal OpenWFEru without remorse.
>
quick information about its advantages. And nobody wants to steal
OpenWFEru.
>
> Furthermore, OpenWFEru evaluates the Ruby process definitions (don't
> forget we have XML process definitions as well) in a constrained env.
> It's one of my background tasks to enhance this constrained way, but
> it's not that easy : Ruby, JRuby, and all have different ways to deal
> with "other processes", throw in differences in OSes and then remember
> that I'm trying to provide an engine which runs out of the box for
> easy evaluation... I'm having great hopes for Ruby 1.9 and especially
> Rubinius...
>
only
due to its seamless integration with java. In C ruby you can invoke
java
as well via a gem, but its not so seamless.
>
> I'm glad you shared your concerns. Too bad you guys decided to
> implement it in your own way, I'm sure the whole OpenWFEru community
> would have had appreciated your contribution.
>
Oracle BPEL. Still, OpenWFEru can be very useful for people who don't
mind the potential problem with single ruby runtime - if you write
all processes correcly so they cant interfere with each other it can
work well and simplify many tasks. But we try to avoid even potential
problems. Our engine is not meant to be sold, it will very likely
become
open source in a few months so people can benefit from it and
contribute.
We made our own solution, because we felt it will best suit our needs,
and
be quicker than studying somebody elses code and adding features to
it.
>
> I'd love to read that list, please contribute it to this mailing list,
> there is certainly a lot to learn from it. Thanks in advance.
>
> Thanks for taking the time to write down this feedback, really
> appreciating that. Best regards,
>
and post it in a separate thread.
Yaro
John Mettraux
On Fri, Mar 28, 2008 at 3:33 AM, yaro <jaros...@gmail.com> wrote:
>
> On Mar 27, 1:29 pm, "John Mettraux" <jmettr...@openwfe.org> wrote:
> >
> > It's not clustering, it's distribution. It's realized via network
> > communication, but you can change the listener/dispatcher pair,
>
> > I don't need clustering now, so I haven't written about it. And I
> > haven't encountered someone who needed it yet (apart from you).
>
> What I understand under clustering is high availability of the system
> and full or partial load sharing. For high availability its enough if
> process that ran can continue running or be restarted on another node
> if one fails with all variables stored in it. Although maybe not many
> people need it, in my company we design all applications for high
> availability. I would say high availability is necessary nowadays, I
> don't understand why anyone would design a system that couldn't work
> as master-master or master-slave at least. It would be nice if it was
> mentioned somewhere, how to achieve high availability on openwfe.
Like I said, it's too bad you never considered bringing your expertise
to the OpenWFEru community. Still, I appreciate this post-mortem
feedback.
> > Maybe the "page" is a filtering device to attract only the
> > hard-working developers.
>
> Common, more users = more bugs fixed, more feedback.
You are right.
On the other hand, OpenWFEru has more documentation than many open
source projects out there (look for example at :
http://code.google.com/p/sipxtapi/ )
> > That gives me a certain freedom, and part of this freedom is that I am
> > free not to bullshit people over what its real capabilities. And I
> > won't try to sell you any training / custom development / enterprise
> > edition license. And the code is accessible and well commented (see http://www.ohloh.net/projects/4749)
>
> > I cannot afford a professional salesguy to come over and bullet point
> > you. The documentation may be rough, but well, it's not a "brochure".
> >
> > The license is BSD so you can steal OpenWFEru without remorse.
>
> It's not about lying to people about its capabilities, but providing
> quick information about its advantages. And nobody wants to steal
> OpenWFEru.
There is a thin line between enumerating advantages and producing
marketing bullshit. I try not to cross it.
By the way, you started this mail thread by immediately bashing
OpenWFEru, let's soften that a bit : what are the advantages you
perceived from OpenWFEru ? It could help me compile this list you
require.
> Don't you think jruby 1.1 has better future than C ruby? We use jruby
> only
> due to its seamless integration with java. In C ruby you can invoke
> java
> as well via a gem, but its not so seamless.
Ah yes, I saw on the JRuby JIRA, thanks a ton, 90% of the OpenWFEru
instances I'm running in my day job are on top of JRuby, I'm trying to
contribute them with reports and unit tests whenever I'm in
integration mode.
Well, quoting you : "more users = more bugs fixed, more feedback"
If it runs on all the Rubies, I get more users and more feedback.
Then, the solution for High Availibility you're wishing for is "JRuby
only" if I understand correctly ?
> > I'm glad you shared your concerns. Too bad you guys decided to
> > implement it in your own way, I'm sure the whole OpenWFEru community
> > would have had appreciated your contribution.
>
> Simply OpenWFEru doesn't meet our demands after our experience with
> Oracle BPEL. Still, OpenWFEru can be very useful for people who don't
> mind the potential problem with single ruby runtime - if you write
> all processes correcly so they cant interfere with each other it can
> work well and simplify many tasks. But we try to avoid even potential
> problems.
We could start talking about the ROI of such efforts...
As the code I included in my previous reply showed, it's not that
difficult to make OpenWFEru HA, I guess you are right, I should expand
that example into a piece of documentation...
> Our engine is not meant to be sold, it will very likely
> become
> open source in a few months so people can benefit from it and
> contribute.
So you are just here on this list to enumerate the current
deficiencies of OpenWFEru and grab users for the projects that your
company is sponsoring ?
I have the impression that you're doing a showcase here to validate
your decision to develop your solution in-house as opposed to leverage
an existing open-source project.
It's OK to develop your own solution, you should not feel guilty for
that, caring for your needs first is a good tactic.
I appreciate the critique, but I find it harsh.
> We made our own solution, because we felt it will best suit our needs,
> and
> be quicker than studying somebody elses code and adding features to
> it.
Still, I don't get it, you are a Java shop that had a bad experience
with Oracle BPEL, you're willing to benefit from Ruby/JRuby. You start
from scratch the development of a workflow engine. Why don't you take
a look at jBPM (http://labs.jboss.com/jbossjbpm/), it would easy for
you to "play it" from JRuby. You then would just have to implement the
HA thing or stick with the JBoss one.
They recently released a new "process virtual machine" in
collaboration with French Bull :
http://processdevelopments.blogspot.com/2008/03/first-release-of-process-virtual.html
I'm sure your CTO would appreciate such a shortcut.
Also jBPM can grok BPEL somehow, it would attract a bigger [standard
hungry] community for your open source project. Ah, my bad, I forgot
about the bad BPEL experience.
> > I'd love to read that list, please contribute it to this mailing list,
> > there is certainly a lot to learn from it. Thanks in advance.
> >
> > Thanks for taking the time to write down this feedback, really
> > appreciating that. Best regards,
>
> I will compile the list of disadvantages of Oracle solution
> and post it in a separate thread.
Thanks ! Looking forward to this contribution.
Kind regards,
yaro
> You are right.
>
> On the other hand, OpenWFEru has more documentation than many open
> source projects out there (look for example at :http://code.google.com/p/sipxtapi/)
>
users. If you had a closer
look at it, you would have found out the public API is documented
enough (in the sipxtapi.h file, or generated
html, and there are multiple examples how to use it. It's not my fault
some internal classes aren't
documented, I didn't code them. I'm not the original author, and I'm
not going to write extensive documentation
for internals of the project.
>
> By the way, you started this mail thread by immediately bashing
> OpenWFEru, let's soften that a bit : what are the advantages you
> perceived from OpenWFEru ? It could help me compile this list you
> require.
in ruby without XML definition, and that they can contain any ruby
code
which makes any difficult operations possible. Although in Oracle
BPEL, it
is possible to execute embedded java, it's not so seamless. Your
process code is
easier to read than pure XML, graphical representation is not so
necessary.
Another advantage is code reusability.
>
> Then, the solution for High Availibility you're wishing for is "JRuby
> only" if I understand correctly ?
>
interpreter.
>
> As the code I included in my previous reply showed, it's not that
> difficult to make OpenWFEru HA, I guess you are right, I should expand
> that example into a piece of documentation...
>
start
new runtimes from old one due to initial delay. We don't need process
engine
that will need several seconds to execute a simple process.
>
> So you are just here on this list to enumerate the current
> deficiencies of OpenWFEru and grab users for the projects that your
> company is sponsoring ?
>
know the exact date when it could be. Don't be affraid, I won't come
and tell people go to http://xyz because it's better. It's not, it's
good for us
but everybody has different requirements.
> I have the impression that you're doing a showcase here to validate
> your decision to develop your solution in-house as opposed to leverage
> an existing open-source project.
>
its
the cheapest for us (in time spent on it) and best suits our needs.
There are certainly
other open source projects that achieve a similar goal, but they
aren't suitable for us.
Other companies might on the other hand find them very useful and I
have nothing against that.
>
> Still, I don't get it, you are a Java shop that had a bad experience
> with Oracle BPEL, you're willing to benefit from Ruby/JRuby. You start
> from scratch the development of a workflow engine. Why don't you take
> a look at jBPM (http://labs.jboss.com/jbossjbpm/), it would easy for
> you to "play it" from JRuby. You then would just have to implement the
> HA thing or stick with the JBoss one.
>
the first
alpha release was on March 19, 2008. I'm not irresposible to use alpha
in production.
You know we had very bad experience with Oracle BPEL, we didn't want
to use another
possibly buggy solution, having to wait 1/2 year until they produce a
stable code.
If I look at how long it is taking to develop stable JBoss 5.0, it
won't be soon for jBPM.
>
> I'm sure your CTO would appreciate such a shortcut.
>
> Also jBPM can grok BPEL somehow, it would attract a bigger [standard
> hungry] community for your open source project. Ah, my bad, I forgot
> about the bad BPEL experience.
>
people find it out.
We nearly broke our "teeth" with it, and we are done with it. But if
BPM is implemented in
a different way, it can work.
Yaro
John Mettraux
>
> > You are right.
> >
> > On the other hand, OpenWFEru has more documentation than many open
> > source projects out there (look for example at :http://code.google.com/p/sipxtapi/)
>
> That is just my private version of sipxtapi that I make available to
> users. If you had a closer
> look at it, you would have found out the public API is documented
> enough (in the sipxtapi.h file, or generated
> html, and there are multiple examples how to use it. It's not my fault
> some internal classes aren't
> documented, I didn't code them. I'm not the original author, and I'm
> not going to write extensive documentation
> for internals of the project.
:)
(If you had had a closer look at OpenWFEru you would have noticed it
has a listen/dispatch concept for inter-engine communication)
> > By the way, you started this mail thread by immediately bashing
> > OpenWFEru, let's soften that a bit : what are the advantages you
> > perceived from OpenWFEru ? It could help me compile this list you
> > require.
>
> The first advantages I can think of is that processes can be written
> in ruby without XML definition, and that they can contain any ruby
> code
> which makes any difficult operations possible. Although in Oracle
> BPEL, it
> is possible to execute embedded java, it's not so seamless. Your
> process code is
> easier to read than pure XML, graphical representation is not so
> necessary.
> Another advantage is code reusability.
>
> > Then, the solution for High Availibility you're wishing for is "JRuby
> > only" if I understand correctly ?
> >
>
> No. High availability solution should be independent of ruby
> interpreter.
OK OK, but you don't understand why people don't got the JRuby way.
Interesting.
In the case of HA limited to JRuby, would you run multiple JVMs or
multiple RVMs ?
> > As the code I included in my previous reply showed, it's not that
> > difficult to make OpenWFEru HA, I guess you are right, I should expand
> > that example into a piece of documentation...
>
> That code was pretty useless, its unusable in production. You can't
> start
> new runtimes from old one due to initial delay. We don't need process
> engine
> that will need several seconds to execute a simple process.
This code was not meant to be production ready. I could expand it and
make it a decent example, but no stress as you don't need any example.
anymore.
If I meant it to be production ready, I would have written a test case
along. It was meant to start a discussion. Failed.
> > So you are just here on this list to enumerate the current
> > deficiencies of OpenWFEru and grab users for the projects that your
> > company is sponsoring ?
>
> I cannot grab any users since our code is not open source, and I don't
> know the exact date when it could be. Don't be affraid, I won't come
> and tell people go to http://xyz because it's better. It's not, it's
> good for us
> but everybody has different requirements.
Right. Thanks anyway for FUDding around here.
> > Still, I don't get it, you are a Java shop that had a bad experience
> > with Oracle BPEL, you're willing to benefit from Ruby/JRuby. You start
> > from scratch the development of a workflow engine. Why don't you take
> > a look at jBPM (http://labs.jboss.com/jbossjbpm/), it would easy for
> > you to "play it" from JRuby. You then would just have to implement the
> > HA thing or stick with the JBoss one.
>
> jBPM is incompatible with our solution. It is also not mature enough -
> the first
> alpha release was on March 19, 2008. I'm not irresposible to use alpha
> in production.
jBPM has other releases, they've been around since 2002. You're not
forced to go with the latest and shiniest.
So what workflow philosophy are you going to follow ? Process
calculus, Petri Net, State Machine ? Maybe your processes are simple
and don't need to play the whole workflow pattern range.
yaro
> In the case of HA limited to JRuby, would you run multiple JVMs or
> multiple RVMs ?
>
node,
since JVM is much more resource demanding if coupled with RVM than
multiple RVMs
on the same JVM. So 1 JVM with multiple RVMs per server node. Multiple
RVMs are
there for parallel process execution and process isolation. This
solution used to be
quite demanding with Jruby 1.0.3 (on permgen), but since Jruby 1.1RC2
and RC3
it is possible.
>
> Right. Thanks anyway for FUDding around here.
>
won't ever see me
here again.
>
> So what workflow philosophy are you going to follow ? Process
> calculus, Petri Net, State Machine ? Maybe your processes are simple
> and don't need to play the whole workflow pattern range.
>
need).
I'm not going to discuss details since I don't like being accused of
fudding your
project or promoting our solution.
Yaro
John Mettraux
On Sat, Mar 29, 2008 at 1:26 AM, yaro <jaros...@gmail.com> wrote:
>
> >
> > In the case of HA limited to JRuby, would you run multiple JVMs or
> > multiple RVMs ?
> >
>
> You certainly need to run multiple JVMs - but usually 1 JVM per server
> node,
> since JVM is much more resource demanding if coupled with RVM than
> multiple RVMs
> on the same JVM. So 1 JVM with multiple RVMs per server node. Multiple
> RVMs are
> there for parallel process execution and process isolation. This
> solution used to be
> quite demanding with Jruby 1.0.3 (on permgen), but since Jruby 1.1RC2
> and RC3
> it is possible.
Now how do you envision that with Ruby MRI ?
If you deliver a solution that provides HA for JRuby and for Ruby MRI,
it's worth packaging it for its own sake, ie separating the HA aspect
from the workflow aspect. I'd be glad to use such a solution,
especially if its open source license is MIT or BSD.
> > Right. Thanks anyway for FUDding around here.
> >
>
> If you don't like to hear my criticism, just say so straight and you
> won't ever see me
> here again.
I like to hear criticism, I need it.
But yours is not following a constructive process, your decision is
already taken and you don't seem to understand that it's possible to
have high availibity with OpenWFEru, please re-read your first mail,
you had already condemned OpenWFEru 2 months ago. Why are you wasting
your time now ?
After all, you are not forced to run all your business processes on 1
instance of OpenWFEru. Creativity.
If you start a critique be ready to assume some counter-critique. It
is not sound to say : "our decision of developing our own solution
cannot be refuted".
And after all, I can't see your code, no reciprocity.
Oracle BPEL failed on you because "code reusability was not possible",
but what about services and processes reusability ?
Does your CTO accept the risk occasioned to the company by you
developing an HA solution and a BPM solution ? Such things are hard to
test, and now you have two of them. Sounds more risky than leveraging
an existing open source solution.
I understand that you're smart enough not to go into production with
alpha code, but well, ...
You could have focused on HA and used an existing workflow / BPM
solution. IMHO, that would have saved money for your company.
Regarding your critique process, I think it would have been cool if
you had come two months ago and nicely started a discussion about how
to leverage OpenWFEru with HA requirements. Then maybe at some point
you would perhaps have decided to go your own way.
I'm pained that the timing of your critique leaves no chance for my
project, and that your contribution is simply limited to a "critical
disadvantage" notification, why were you otherwise requiring
architecture documents ? The mass has been told two months ago, you
don't need to read architecture documents for something you won't use.
> The core of process engine is already finished (it has all features we
> need).
> I'm not going to discuss details since I don't like being accused of
> fudding your project or promoting our solution.
Please take some time to consider the way you entered this mailing
list and engaged the discussion, you'll maybe understand my behaviour.
Sorry, I'm not a machine.
I'm looking forward reading your code and your documentation and
bringing my critique on your project users' mailing list. If you allow
that kind of touristic activity.
Have a nice week-end and my best regards,