5 Replies Latest reply: Feb 9, 2009 3:01 PM by Gary Brown RSS

Representing paths triggered by non-observable events

Gary Brown Master

 

You will probably notice some empty service descriptors - these are placeholders for actions resulting from exiting the loop (i.e. the loop associated with sending the request for quote to multiple suppliers). There is also another point that you may notice, the first 'SwitchAction' which routes the inbound events has a path with no associated message type. This is because this path is triggered by a different type of event - in this case where all of the quote responses have been received from the suppliers, we then want to return the quote list back to the buyer. Both of these points will be the subject of dev forum posts in the near future.



[Jeff Yu] Yeah, I think with the 'empty message type' in 'SwitchAction' will be a little bit confused, it seems to me like the default branch for 'SwitchAction'.


The above are snippets from the design discussion page for Process Governance.

The issue here is that the path associated with the switch case that has no message type is going to be triggered based on an internally evaluated condition (i.e. when all quotes have been received).

If we don't include an entry for this path in the root 'SwitchAction', then we need to have a different way of defining that this path is a part of the top level stateless behaviour.

In the case of paths triggered by the receipt of a message, then these are documented in this root SwitchAction. The current (version 3) of the worked example on the wiki deals with the non-message triggered path by also including it in the top level SwitchAction - but as Jeff points out, this is confusing because there is no associated message type (or indication what the event is that will trigger the path).

Another approach may be to mark the specific service descriptor in some way? Would prefer not to add another action type for this - wonder whether the relevant "service" element could have an appropriate attribute?

 <service category="org.pi4soa.esbbroker.esbbroker" name="ESBBrokerProcess_Broker__7" trigger="internal" >
 <listeners>
 <jms-listener busidref="busId8" maxThreads="1" name="org.pi4soa.esbbroker.esbbroker-ESBBrokerProcess_Broker__7"/>
 </listeners>
 <actions>
 <action class="org.jboss.soa.overlord.jbossesb.actions.stateless.SendMessageAction">
 <property name="operation" value="makeEnquiry"/>
 <property name="messageType" value="quoteList"/>
 <property name="clientRole" value="Buyer"/>
 </action>
 </actions>
 </service>



where 'trigger' attribute indicates the source of the event that will invoke this service descriptor - either internal or external (default). Could use a different attribute name/value.

But not sure how higher level Graphical Editors would be able to deal with this?

Thoughts?

Also is there a more appropriate name that 'SwitchAction', for an action that is essentially routing messages based on their type?

  • 1. Re: Representing paths triggered by non-observable events
    Mark Little Master

    Can you explain why you would prefer to not add another type? I was thinking about:

     <property name="paths">
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__1">
     <message type="enquiry"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__4">
     <message type="quote"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__7">
     <message type="__timeout" value="10000"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__8">
     <message type="buy"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__9">
     <message type="CreditCheckOk"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__10">
     <message type="bookingReference"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__11">
     <message type="CreditCheckInvalid"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__12">
     <message type="cancel"/>
     </case>
     </property>
    


    which would flag that Broker__7 is triggered after a timeout of 10000 units. The aim would be to turn all events into messages, even if only at the abstract level.

  • 2. Re: Representing paths triggered by non-observable events
    Gary Brown Master

    I was thinking about that type of approach, which is why I had left the entry in the top level SwitchAction in the examples I had generated.

    The issue is that in some cases (possibly most) the trigger condition may not be something that can be expressed - as in your example where it is based on a timeout.

    For example, in the example referenced on the Process Governance design discussion page, the trigger event is an internally evaluated conditon that determines when all of the async responses are received back from the suppliers that have been contacted.

    I don't think we want to complicate the 'stateless' notation by trying to express this type of condition in an observable way, so the question is how should we document this, to make it clear that this SwitchAction path is triggered by such a non-observable event.

    It may be just a case of adding a description field, e.g.

    <case service-category="..." service-name="..." >
     <event description="When all supplier quotes have been received" />
    </case>
    


    Is this acceptable? I think the main point is we need to distinguish this type of path from ones triggered by message types, as in the current (version 3) of the example, it looks like the message type simply has been forgotten.



  • 3. Re: Representing paths triggered by non-observable events
    Jeff Yu Master

    The proposed approach, which is using '<event...>' tag seems good to me.

    Thanks
    Jeff

  • 4. Re: Representing paths triggered by non-observable events
    Mark Little Master

    Yes, let's go with the event approach. We can always revisit later if necessary.

  • 5. Re: Representing paths triggered by non-observable events
    Gary Brown Master

    Version 4 of the example now includes:

     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__4">
     <message type="quote"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__7">
     <event description="Event trigger to send quoteList message type(s)"/>
     </case>
     <case service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__8">
     <message type="buy"/>
     </case>