Current implementation of reference invocation is based on a channel. A channel is one-way communication mechanism. I am not sure how much is it a valid use-case to have two-way communication in Drools, but two-way communication would be nice.

(04:11:20 PM) errantepiphany: trohovsk: Drools Channels are indeed one-way. We have a SwitchYard Service Channel that invokes SwitchYard service references. It's just there as a convenience.
(04:11:25 PM) errantepiphany: trohovsk: If you want to do anything fancier in Drools, you should probably create a helper class, or a drools function, or similar, that executes the service reference.
(04:11:55 PM) kcbabo: errantepiphany: agree - part of this is using functionality that makes sense for a given implementation type
(04:12:20 PM) kcbabo: errantepiphany: we shouldn't force a round peg into a square hole for some of these use cases
(04:13:31 PM) errantepiphany: kcbabo: we could create a static function that could be imported by drl code that wanted to use it. They would just have to use "import function" in their drl: http://goo.gl/NrmNCc
(04:15:07 PM) errantepiphany: kcbabo: that could be a way of in-out vs. just in-only meps from drl.
(04:17:04 PM) kcbabo: errantepiphany: possible - functions appear to require compilation as part of building the knowledge package
(04:17:27 PM) kcbabo: errantepiphany: so class path would have to be managed in that case
(04:17:43 PM) kcbabo: errantepiphany: actually, the timing of the compilation is an assumption on my part
(04:17:59 PM) kcbabo: errantepiphany: I guess it could happen at runtime as well, but the same consideration applies
(04:18:22 PM) errantepiphany: kcbabo: True. And really, creating a function isn't that hard to do in regular code. and people could just reuse the SwitchYardServiceInvoker (which both our Channel and WorkItemHandler impls reuse).
(04:18:36 PM) kcbabo: errantepiphany: I guess the idea would be that the function returns the body of the out message
(04:18:46 PM) errantepiphany: yup
(04:18:49 PM) kcbabo: errantepiphany: which could grow into asking for context properties as well
(04:19:06 PM) kcbabo: I don't think we could make an assumption on which parts are actually inserted as facts
(04:19:08 PM) errantepiphany: kcbabo: or the function could return the Exchange
(04:19:24 PM) kcbabo: so that's something that the user would have to do in their RHS code once they get the result
(04:19:34 PM) errantepiphany: kcbabo: or we just stay out of making assumptions, and people write their own functions…
(04:19:43 PM) kcbabo: right
(04:20:08 PM) errantepiphany: kcbabo: That's the problem with creating this stuff for specific use-cases. They make sense for some people, but not everyone. And assumptions are dangerous.
(04:20:31 PM) kcbabo: errantepiphany: agreed