[jboss-dev-forums] [Design of JBoss jBPM] - Re: Command facade API

[heiko.braun@jboss.com]

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#4132172

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132172