In our environment we have many SLAM gadgets, possibly 10,000. Each SLAM exposes a web service and communicates to the clustered application servers exposing web services using a standard xml format. One troublesome restriction is that for each SLAM, an incrementing command id must be included in the message, message order maintained, and monotonically incremented. If the SLAM receives messages out of order, the response ACK has an error code and the request is not processed. Message responses from the SLAM’s are ACK’s. There is a time to live for each message and, when processing the request, if the time to live has expired, the SLAM will ACK with an appropriate error, not processing the request. Retries and the time to live are message dependent and set by the caller; with the restriction that a retry flag is set and the command id increments.
1. Various solutions have been discussed including a database table which would basically have a busy flag, a timeout, and the command id for each SLAM id.
2. Somehow storing references to stateful session beans pinned to each SLAM and storing state in those references specific to each SLAM has been discussed.
3. The threaded state machine wrapped in a JCA adapter is also on the table.
4. Send the messages concurrently and, if the SLAM responds with the out of order message try again.
We must consider a long run architectural solution which is scalable and fail safe. The SLAM’s are 24 X 7 and the application servers which support them must also be available 24 X 7 and be able to be upgraded without service interruption. Message volume could be extremely high from all SLAMS, but there will only be rare cases where there will be two concurrent messages to be sent to the same SLAM. The SLAM code is not available. The webservice interface for each SLAM is likely backed by an non-order maintaining queue.
4. has the advantage of the simple approach and will probably work, but we have the possiblity of a SLAM for which there are many concurrent requests getting bombarded with out of order messages. This may be a livable rarity but cannot be determined in advance of deployment.
1. is probably the most dependable solution but requires table access for all those SLAMS that just have one request for that rare case where a specific SLAM has multiple requests. Also, the blocking could be problematic where responses were slow.
3. Ouch, but is the most dependable and efficient solution.
2. The pinning of a stateful session been to each SLAM has advantegous beyond handling the concurrent requests, including state management without db access. This is like a shopping cart for each SLAM, but not from a client but within the application server. I know of no such implementations. Since the SLAMS live forever and can be added and removed, I don't know how exactly this would be implemented or if even practical within a clustered appserver environment.
Comments, other alternatives.
[Message sent by forum member 'quill49' (quill49)]
http://forums.java.net/jive/thread.jspa?messageID=280359