4 Replies Latest reply on Jun 17, 2008 2:01 AM by jeff.yuchang

    Remove RetrieveSessionAction from conversation based Actions

    jeff.yuchang

      Originally, there was an action called "RetrieveSessionAction" which is in the first action pipeline for every service in the POC. The properties of this action contain is 1) the "identity" for retrieving the Session for "Message Link", and also 2) contain the current "service-category" and "service-name" to unschedule.

      for the 2) point, we can get the current "service-category" and "service-name" from the configTree.getParent(), so for any conversation based action, we will determine if it is the first conversation based action, if it is, we will get the "service-category" and "service-name" and then get it unscheduled. There is no issue with this right now.

      For the 1) point, if we remove the "RetrieveSessionAction", we still need to have the "Identity" information in the Actions somewhere. otherwise, we are unable to get the session for the "message link"[1]. Currently, yes, we almost have "ReceiveMessageAction" for every "message link", but that is an occasion that we will just have the "SwitchAction", wich means the received message type would be either types that defined in the "SwitchAction", right now, this action doesn't have the "identity" information, that is where I still need the "RetrieveSessionAction" in the POC[2].

      So here, I'd like to say that "message link" action, which can be validated the incoming message in one way, include the "ReceivedMessageAction" and "SwitchAction". For these two actions, it needs to be shown in the first action pipeline, and will have the "Identity" information, unschedule the "current service" function as well. Provided this, we can remove the "RetrieveSessionAction".


      Thoughts?

      Thanks
      Jeff


      [1]: "Message Link" is the situation that "A" participant will send a message to "B" participant to make the business flow continue. Because the exchanged message won't contain any conversation information but the "Identity".

      [2] http://anonsvn.jboss.org/repos/soag/trunk/samples/esb/purchasing/

        • 1. Re: Remove RetrieveSessionAction from conversation based Act
          objectiser


          Just to clarify your last point - are you suggesting that any (conversation based) action should potentially be able to define identity information, in case they are used as the first action within a message link triggered action pipeline?

          If so, then I think this should be fine. So in the example you mentioned, there would just be a SwitchAction, which would define the identity infomation to use in resolving the correct session, which will then result in the inbound message being routed to another action pipeline based on the switch paths.

          • 2. Re: Remove RetrieveSessionAction from conversation based Act
            jeff.yuchang

            Yes, right now just only two actions that I came up with are "RecieveMessageAction" and the "SwitchAction", will be shown in as "message link"..

            • 3. Re: Remove RetrieveSessionAction from conversation based Act
              objectiser

              It is possible that any control action (e.g. IfAction, SwitchAction, ParallelAction) could be the first action within an action pipeline triggered based on a message link.

              So although there are some actions that would not be valid (e.g. a SendMessageAction - as it would need to be preceded by a ReceiveMessageAction to acknowledge the inbound message), these can be detected with static validation.

              In general I think it would be better to define the 'identity' properties against the generic conversation based action based class, so that any conversation based action could express identity information as required.

              • 4. Re: Remove RetrieveSessionAction from conversation based Act
                jeff.yuchang

                OK, this solutions sounds good to me, we can make a restrictions in later, such as only first action should be of capability to have the "identity" information in the static conformance check.