I'd have no problem implementing this, but I have a few concerns:

• There could be problems transmitting to clients on a WAN if they're behind a firewall or NAT.  Ports may be restricted, or the internal IP may be unreachable.
• The servers could quickly become a bottleneck.  Message senders would have to block/wait until the server had finished its transmit attempt.  The more clients were registered, the worse performance would get.
• Server resources could be wasted trying to transmit to unavailable clients.
• When a client is sent a point message, it must explicitly consume it.
• The specification is a little vague about what happens to unconsumed point messages.

Is there a reason you need a 'push' mechanism?  It might be worth considering a polling approach something like this:

• Client registers with server and receives unique cookie
• Client periodically calls a 'GetMessages' webmethod on the server, passing its cookie.
• If unconsumed messages exist, they're returned to the client in a single XML collection and marked as consumed on the server (or deleted?)
• The server would maintain a reference to the client's 'last received' broadcast message (it's easy to identify which broadcast messages have been received by everyone, and are safe for deletion).

This could resolve the potential issues highlighted above.  Performance on the server would be better as sent messages would simply be stored in the database (effectively queued until a client retrieves them).  Clients would need to do a little work in polling, but in comparison the server could put its feet up and relax.  Deployment to clients would be simpler; there'd be no need to set up a listener for inbound messages.

I've previously implemented a similar messaging subsystem (albeit polling-based, with a single server).  It exceeded our expectations and was used for everything from locking mechanisms to audit trails!

Hope this is of some use.  If I'm barking up the wrong tree, please let me know!

Regards

Chris