This thread has been hijacked by the discussion about the WS facade. However I would like
to get back my initial concern, which is the current command API in place and especially
the detyped nature of the pattern.
I stumbled across a quiet good explanation of my concerns here:
http://fiatdev.com/2005/06/15/the-ambiguous-command-anitpattern
In short here's few things that are really bad with the pattern as it's used right
now:
* Ambiguity: Both command parameters as well as return values are ambiguous. You actually
need to know the command implementation and the final receiver in order to work with the
API
* The orig pattern works best for unidirectional, fire/forget style invocations. I.e.
things that should be queued. But we are looking at a broad range of uses cases here.
* Currently it exposes too much implementation details. If you combine this with lack of
type safety, you get the perfect mess. No control what so ever.
From my understanding the command API should become a central piece to
interact with JBPM. In that case I would reconsider this approach and maybe drop the
command pattern at all and actually chose quiet the opposite solution:
Use well
specified, strongly typed API that allows the callee to work with a blackbox JBPM.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132172#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...