We have implemented a SonicConnect web service with multiple operations. One operation receives the client request and must execute multiple underlying, independent services. Only one of the underlying services responds to the client. The others perform independent work and simply terminate when finished. Since only one destination can be referenced for the web service operation, I chose to use a CBR service with an XCBR step.
Initially, I used two rules which evaluate to true and routed the first rule to the response service and the second rule to the service which does not need to respond. The destinations of the rules were the process addresses of the processes containing the custom services. Issue was that the process/service which did not respond to the client was always being executed first ahead of the process/service which needed to respond to the client.
I looked a little more at the XCBR file definition and realized I could use one rule and route to multiple destinations. I routed to the same processes/services in the order desired, the response process/service first, and still got the undesired result. The process/service I wanted to execute second still executed first ahead of the one that would craft the client resposne.
Next, I changed the destinations to be the entry endpoints of the processes/services rather than the process addresses, and I got the behavior I was more or less desiring. The processes/services generally execute at either the same time or the response process/service is generally a few milliseconds ahead of the process/service which does not need to respond.
Questions:
Thanks in advance.
Simply wanted to bump this again to see if anyone could shed some light on the behavior noted. Thanks in advance.
re 1) Yes yo can count on the order of execution of the rules
re 2) This comes about because addressing a service (or process) will be executed directly after leaving the XCBR step but in a sequential manner. Which of the addresses get's executed is arbitrary though (backed by a hashset, so entirely depends on the JVMs hash implementation). This is actually also true for endpoints. But the main difference is that addressing an endpoint forces a JMS hop. And sending 2 messages is pretty much simultanious even though it is done in a sequential manner. On the receiving JMS side (entry endpoint) things will be truely parallel.
HTH
Thomas
Thomas, I suspected that the way Progress or the JVM took care of the list of destination for process/service had to do with the order I was seeing execution even with my continued attempts to manipulate the XCBR. It actually appeared alphabetical. I also suspected that I witnessed the behavior I desired when addressing directly to the endpoint because that brought JMS into the picture and the execution would simply be to each as fast as each could receive the message to their process/service listeners. In the case of addressing processes/services directly rather than by their endpoint, that would be fine as long as the execution was not sequential. The sequential nature of it and the fact that I have no control over the order once the XCBR is completed and execution begins kills it. We must address endpoints directly. Thank you.