Hi John, >>> I'm currently sticking to the distinction between listen / participant.
I think I understand what listen expression, participant and the counterpart of the participant the Listener are doing but some times it is a little bit confuding for me. For instance I would expect that a Listener class is a kind of a listening participant. The listen expression is like a interceptor which is not only related to listen for incomming request (apply or reply). I like the opportunities of this expression but I would prefer another naming. >>> This 0.9.16 version of the 'listen' expression may be bound to >>> participant names (topic names / channel names) that don't formally >>> exist (as registered participants). Does that mean I can bound it to a Listener which participant counterpart doesn't exist ? I have also some other questions but I will clarify this first. Best regards, Andreas On 6 Nov., 07:31, "John Mettraux" <[EMAIL PROTECTED]> wrote: > Oops, clicked on "send" too soon. Continuing here anyway.... > > I have noticed something : whenever you have a participant that sends > something you name it like "something_sender", and if it's supposed to > receive, it's named "something_else_receiver". Somehow, we can forget > the :behaviour attribute, it's not necessary. > > It seems you have ActiveMQPublisherParticipant and > ActiveMQSubscriberParticipant, these two classes of participants are > aligned on send / receive, the behaviour is not given in the process > definition but at participant registration. In the process definition, > you choose the right participant, and that's it. > > Your receiver participant implementation can play the role of a > 'listen' expression, it gets activated by receiving a workitem, and > somehow replies only when there is an incoming message that "matches" > the workitem. (I think that such a participant has to handle multiple > workitems, and couldbe capable of matching workitems with previous(ly > stored) messages). > > The "activating" workitem has the 'flow expression id' you're looking > for, you simply have to replace the payload of the workitem with the > one coming for the "active message". (you may think of the flow > expression id of the workitem as its "header", don't touch it). > > (seehttp://jmettraux.wordpress.com/2007/09/24/reply-there/) > > Don't hesitate to simplify : > > participant :escalation_sender, :msg => "The duedate will be in > two days..." > to > escalation_sender :msg => "The duedate will be in two days..." > > and > > subprocess :ref =>"supplierCommunication", :DunsNr => > "${f:dunsnr}", :processData => "${f:TenderDataList.${f:dunsnr}}" > to > supplierCommunication", :DunsNr => "${f:dunsnr}", :processData => > "${f:TenderDataList.${f:dunsnr}}" > > It makes for more concise process definitions. > > What do you think ? > > Cheers, > > -- > John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
