Architecture: One Producer, Many Consumers

  • Thread starter Thread starter Neil B
  • Start date Start date
N

Neil B

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
 
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!
***************************
 
How about using web service for your WAN clients.
They can call the web service when they need to see the update.

David
 
Back
Top