Hi Curtis,
As of now, think of the Web Service stack much like you would a simple RPC
stack. In a SOAP based web service, the client can make a request to the
service. It can do this and wait for a response. It can do this and not
wait for a response. If it waits for a response, the thread that is
servicing the connection is blocked until the response is received
(response on same connection).
In a classical "eventing" view of the world, a caller can raise an event (a
method call) asynchronously (e.g. not wait for a response). This is
sometimes known as a one-way call. In this regard, a non-blocking, no
response web service call (One Way) behaves much like an event, and this is
easy for a caller/client to do.
More problematic today is the server side event where a client establishes
a subscription to an event, and provides an address where notifications can
be sent to wheneven need be. Today, there is no part of the ASP.NET stack
that provides a direct analog to this ability, since the client would have
to implement an addressible SOAP endpoint. This can be problematic on
smaller clients, and in situations involving firewalls.
One can approximate this right now by providing a caching ability on a
service side, and have the client periodically poll for notifications via a
same-connection response web method call that goes to the server, checks
for notificaitons, and returns any undelivered notifications and then marks
them as delivered.
In Indigo, the code-name for the next generation web service stack, a spec
called WS-Eventing has been written to provide a more traditional eventing
way of programming. The caller will need to either be active to receive an
event, or participate in a "turn on the client" query that checks for
outstanding notifications that could not be delivered normally.
I hope this helps
Dan Rogers
Microsoft Corporation
--------------------
