[jbpm-dev] Proposal for jBPM5 first release

[Bernd Rücker]

Shit, I forget a really good argument: If you look at the lifecycle of an
application it will maybe (hopefully?) live for a long time. It may
survive the Java-Code ;-) Serialized objects always have the risk, that
you cannot deserialize them later, for whatever reasons (serialVersionUID,
JVM changes, Java is dead, ...). Simple Database table don't have that
problem.

-----Ursprüngliche Nachricht-----
Von: jbpm-dev-bounces at lists.jboss.org
[mailto:jbpm-dev-bounces at lists.jboss.org] Im Auftrag von Bernd Rücker
Gesendet: Donnerstag, 27. Mai 2010 08:54
An: 'Staub, Edward'; 'Kris Verlaenen'
Cc: jbpm-dev at lists.jboss.org
Betreff: Re: [jbpm-dev] Proposal for jBPM5 first release

Hi Kris.

Unfortunately a bit busy these days but let me add one remark on the
persistence: Serializing Java Objects for persistence is never a good
idea! Independent of what you do. Never!
You cannot search for stuff, you cannot index special attributes, you
cannot look into it in the Database, your DBA will hate you and as Ed
wrote, monitoring or reporting simply ignores API very often. If you think
of huge environments - where at least some projects of ours operate -
having a proper database schema is absolutely necessary. I am pretty sure
otherwise they will kick me out of the door before I finished the word
Blob :-)

Cheers
Bernd

-----Ursprüngliche Nachricht-----
Von: jbpm-dev-bounces at lists.jboss.org
[mailto:jbpm-dev-bounces at lists.jboss.org] Im Auftrag von Staub, Edward
Gesendet: Mittwoch, 26. Mai 2010 16:16
An: Kris Verlaenen
Cc: jbpm-dev at lists.jboss.org
Betreff: Re: [jbpm-dev] Proposal for jBPM5 first release

Kris,

I mainly wrote to try to get a rise out of other folks, if any of these
are common concerns, so that the release is a good fit for the most
people.
If you don't get a rise out of anyone else, ignore this!

> 1.) Open persistence

I suspect the main value here would be in reporting, monitoring, and
extensibility.
In particular, app-specific tables that contain process data
can be joined to generic-workflow data.  Most reporting tools
(e.g., BIRT unextended) want to go straight to the database - API's are
irrelevant.


> 2.) Isolated or collaborative custom nodes.

You wrote that "I don't think there's a real difference here."
- I disagree fairly strongly in principle, though if no one else needs
the delta between them, it doesn't matter.

a.) In JBPM, interacting with the engine provides means for extending
workflow
semantics.  This is a very public, documented, exampled part of the API,
which it isn't (IMO) in Drools.  Consider, for example, the
ForEachActionHandler,
which provided the action of a Drools-Flow "ForEach" block in JBPM3.  This
was just an ordinary contribution that could have been written by
"anybody"
(I exaggerate, of course).

b.) Consider implementers who are trying to facilitate use of JBPM in
particular
application spaces.  They aren't writing workflows themselves (much) -
they are
trying to make writing workflows easy in the context of their domain.
There are rich domain-specific data-models, API's, and persisted data
that the implementer wants to make work seamlessly with JBPM.  In this
case,
they are likely to want to have use something like Drools-Flow Globals to
provide
ubiquitous access to API session handles, etc.  They don't want to require
every
In Drools-Flow WorkItems aren't even allowed access to Globals.


> 3.) Custom Decision Handlers.

> Kris wrote: "The disadvantage of using Java classes for describing
decisions like
that is that you tend to end up with a lot of lower-level decision
code."

I guess I'm ok as long as the expression language can be easily extended
to add
app-specific methods implemented in Java.  For example,
I'd want to be able to carry around db connection parameters in one
variable,
a primary Foo key in another variable, and be able to write a Java
getFoo(connection-parameters, key) method to get the
record into either a map or a DTO.  (A connection pool is presumed.)


> 4.) Use of rules for decisions.

> Kris wrote: " The vision is that you should be able to combine processes
and rules
seamlessly...  you shouldn't see
processes and rules (and event processing for that matter) as completely
separate technologies but rather different ways of modeling your
business logic which you can easily combine."

All good - GREAT, in fact.


> 5.) A roadmap for web services.

Disappointing, though expected.  Riftsaw isn't a viable option for us -
our customers
are all on WebLogic or WebSphere, and introducing another appserver
wouldn't fly.

I don't have a suggestion here.  I can tell you, though, that the lack of
a good
web-services play is perhaps the most important reason our organization
hasn't
adopted JBPM or Drools-Flow.  It's a huge marketecture issue.

-Ed


_______________________________________________
jbpm-dev mailing list
jbpm-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev
_______________________________________________
jbpm-dev mailing list
jbpm-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev