His solution for avoiding the latency in the perceived serialization of the requests was to set endpoint URIs that changed slightly by using fake parameters. This is a interesting way to solve the issue. Macromedia provides method parameters to handle this more elegantly, but with coding penalty.

When declaring your RemoteObject tag, the concurrency parameter can be set on a child method to enable three operating behaviors:

1: mutliple - (default) this is what Peter experienced; existing requests are done in serial and the developer is responsible for ensuring the consistency of the returned data by managing the events that occur. What Peter could of done:
“function myHandler(event)
{
var call = event.call
if (call.marker == “option1″) {
//do option 1
}
else
…
}”
… and this would handle the result stream appropriately.

2: last - any subsequent requests will interrupt and supersede the prior ones (not very useful in practice, but good if someone repeatedly clicks an “add to shopping cart” button).

3: single – this is another one that can be used, only a single request is made, and the subsequent requests will generate a fault. Of course, we would have provided a fault handler for the RemoteObject, and parsing the returned string allows us to resend the request after a self-imposed timeout. Peter would have received his first response back in two seconds instead of 30 seconds though!

I think the endpoint was originally conceived if load-balancing was to be used. If your services will not operate, programmers can specify another URI to handle the call to override the default gateway endpoint in the tag of the tag specified in the flex-config.xml file.

Well nice blog, keep on Flexing!