«

Hi,
I'm new to web services, and I'd like to know if they (web services) have
the ability to have events where clients (for example a windows client) can
register to its event?

In other words, is it possible for a windows client to subscribe to a web
service event? So that if some data is updated on the web service, it can
inform the windows client.

Thanks in advance,

Tim.

> Web service is nothing more than sending a piece of data to a remote
> machine and getting something in response, if at all.

No, that's not true at all. A WebService is a remote procedure call via
http and soap. The call and the response are made in XML. In order for a
client to know what there is to call and how to call it, a standardized XML
document (the WSDL) describes the service.

Simple data exchange (even if done with xml) is not a web service.


>
> Not sure but you may want to have a look at Web Service Extensions
> (Extensions... not Enhancements, but a part of Enhancements).
>
> --
> Happy Hacking,
> Gaurav Vaish | http://www.mastergaurav.org
> http://www.edujini.in | http://webservices.edujini.in
> -------------------
>
>
> "Timothy V" <> wrote in message
> news:...
>> Hi,
>> I'm new to web services, and I'd like to know if they (web services) have
>> the ability to have events where clients (for example a windows client)
>> can register to its event?
>>
>> In other words, is it possible for a windows client to subscribe to a web
>> service event? So that if some data is updated on the web service, it can
>> inform the windows client.
>>
>> Thanks in advance,
>>
>> Tim.
>>
>
>

A WebService is not a continuously running piece of code. So, your basic
question is not really valid. No data would be updated "on the web
service". Data in a data store could be updated, but the web service
(remember: not contiually running), would have to be invoked periodically to
query the data and see if any changes have been made.

You could certainly build a client that periodically calls the web service,
but the service isn't the data, so if the data changes, the service is
ignorant of that.


"Timothy V" <> wrote in message
news:...
> Hi,
> I'm new to web services, and I'd like to know if they (web services) have
> the ability to have events where clients (for example a windows client)
> can register to its event?
>
> In other words, is it possible for a windows client to subscribe to a web
> service event? So that if some data is updated on the web service, it can
> inform the windows client.
>
> Thanks in advance,
>
> Tim.
>

So you are saying that if I want to do what I proposed, I'd have to poll the
web service?

As an example (keep in mind my limited knowledge of web services), I wanted
the web service to subscribe to a FieldChanged event, so that once that
field changed, the web service would be notified, also firing an event of
its own, which the client would have subscribed to, receiving that that data
from the web service.


"Scott M." <s-> wrote in message
news:...
>A WebService is not a continuously running piece of code. So, your basic
>question is not really valid. No data would be updated "on the web
>service". Data in a data store could be updated, but the web service
>(remember: not contiually running), would have to be invoked periodically
>to query the data and see if any changes have been made.
>
> You could certainly build a client that periodically calls the web
> service, but the service isn't the data, so if the data changes, the
> service is ignorant of that.
>
>
> "Timothy V" <> wrote in message
> news:...
>> Hi,
>> I'm new to web services, and I'd like to know if they (web services) have
>> the ability to have events where clients (for example a windows client)
>> can register to its event?
>>
>> In other words, is it possible for a windows client to subscribe to a web
>> service event? So that if some data is updated on the web service, it can
>> inform the windows client.
>>
>> Thanks in advance,
>>
>> Tim.
>>
>
>

> So you are saying that if I want to do what I proposed, I'd have to poll
> the
> web service?

Yes.

> Point Number One: Web Services may or may not require SOAP and WSDL. I may
> be wrong.

Yes, you are wrong. The W3C standard that describes a web service includes
SOAP and WSDL's.

> But then I think binary web services are also a possibility. It's just
> that working with Web Service using SOAP over HTTP is the most common way
> of working with web services... Correct me if I am wrong.

Sorry, wrong again. The binary data you speak of must be serialized into
XML and transmitted over HTTP (using SOAP and WSDL's). If you are
communicating in any other way, you are not using Web Services. If you
think about it, all computer communication is binary at the lowest possible
level. That doesn't make all communications web services.

> Also, I was - yes - technically wrong in saying about 'simple data
> exchange'. But then, I am kind of absolutely correct also.

I don't see how anything you've said is correct when describing Web
Services.

> Again, it's just that when you talk about WSDL -- it's just that it is the
> de-facto standard for the format for information interchange using Web
> Services.

Not the de-facto standard, THE standard (http://www.w3.org/TR/wsdl).

> Again... correct me if I am wrong.

Web Services are standardized by the W3C. What you describe may very well
work for data exchange, but (as I've said) data exchange is not the
definition of a Web Service. To use Web Services, you must make
standardized XML calls (that adhere to the WSDL) over HTTP and SOAP. The
call (request) is for some remote procedure to be processed (not just data
to be sent). The response comes back as XML over HTTP and SOAP according
to what the WSDL contract indicates.