Hi Damian,
As far I know, the WS-RM implementation uses MSMQ queues to support the
scenarios that you mention. (Similar to the TCP stack, which uses memory
buffers to detect those problems)
Everytime a client sends a message to a service, it first stores that
message in a outbound MSMQ queue, then it waits for an acknowledge. If it
does not receive an acknowledge message, it gets the message from the queue
and tries to resend it. This process is repeated until it receives the
service's acknowledge. The same happens on the service side, the service
keeps the acknowledge messages in a queue.
If a message get corrupted or packets are dropped, the service will not
receive the original message and therefore it will not send back a
acknowledge message to the client. (This description is simpler, but it may
help you to understand the overall process, the RM specification looks more
complex than this description).
Regards,
Pablo Cibraro.
[quoted text, click to view] "Damian" <damian.gonsalves@gmail.com> wrote in message
news:1162900534.689763.321500@m73g2000cwd.googlegroups.com...
> Hi there
>
> We've been asked at our company to implement some form of reliable
> messaging. Now I have already downloaded the WSE-RM specifications and
> installs and begun playing with it, but i was just curious as to what
> happens in WSE 3.0 when messages do get corrupt and packets are
> dropped.
>
> It will take us a while to implement WSE RM so until then i was just
> wondering what support WSE 3.0 has out of the box for scenarios like
> this.
>
> Any info would be helpful
>
> Thanks
> Damian
>