You are linking concepts that are not necessarily linked.
1. Delivery model
a) Publisher/subscriber - publisher calls out to known subscribers (stored
as metadata).
b) Broadcast - message fired out in broadcast fashion. Very flexible and
easy to set up clients, as there is no need to register
2.Interface
a) With publisher/subscriber you can use web services (remoting, most
likely, as ASMX requires HTTP and is most easily set up with IIS) or set up
some form of DCOM structure. You can also employ a custom listener, but that
is overhead.
b) Even broadcast can use web services, but it is likely to end up being
very chatty no matter what you use.
Either way, do not constrain the "listening" interface to the delivery, as
they are not necessarily chained.
In addition, the client can ping back to the server to find out if there are
changes and reflect the changes. It is a bit less "real time", but can still
facilitate quick changes.
---
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
[quoted text, click to view] "Neil B" wrote:
> Hi all,
>
> This sounded like a really easy R&D challenge but .NET is leaving me
> with too many options and I don't have six months to experiment and find
> the best one. Hence I would like to lean on this board's expertise.
> Environment is C#/.NET/SQLServer2k/VisStudio .NET.
>
> I have several remote applications that are delivering data to a central
> server. This server process is archiving the data in an SQL 2000 db. Now
> I also have one to about a dozen fixed clients on a WAN, which need to
> be notified when a change takes place to the central database so they
> can update their UI to reflect the changes.
>
> What is everyone's suggestion for doing this? Any resources out there
> you can point me at?
>
> I've run the gamut from remoting, to serialising the DataSets (which
> scares me due to the amount of data that may start going over the
> channel), to considering whether the remote clients should be writing
> directly to the db (although bandwidth limitations tend to prohibit
> TCP-like connections), to wondering why there doesn't seem to be any way
> for a client to simply connect to an SQL database and be told when
> changes occur... and so on.
>
> Is there something I've missed? This seems like a straightforward
> client-server requirement.
>
> Any help gratefully appreciated, and thanks in advance.
>
> Neil B
