|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Architecture: One Producer, Many ConsumersThis 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! *************************** Show quote "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 > How about using web service for your WAN clients.
They can call the web service when they need to see the update. David Show quote "Neil B" <goateebl***@hotmail.com> wrote in message news:424c3da9_2@nnrp1.news.uk.psi.net... > 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  |
|||||||||||||||||||||||
Other interesting topics