Pushing data from the server to the client

  • Thread starter Thread starter DW
  • Start date Start date
D

DW

Hi,

Here is my question. I want to push security prices to the desktop from the
server. Whenever there is a new price in the database, the server notifies
the client. How can this be done in the following situations using MS .NET
Winforms on the desktop:

1. Using .NET Web Services on server

2. Using Java Web Services on server

3. Using .NET Remoting on server

Thanks.

- David W.
 
First thing that comes to mind, is I'd consider having a TcpServer on your
client that listens.. have your server connect and send it a command - like
"UPDATE" when there is a change. When your client recieves that, it hits
your web service or uses remoting. Seems like you could use a
publish/subscribe pattern here too - but *how* is the tricky part. Because I
assume you need real-time - and that's what makes it funny. If you are doing
this on a per-security basis, that is going to be BRUTAL, on the server, on
your app and on the network.

But also, I am willing to bet you are using delayed quotes, because
real-time quotes are super-expensive and difficult to get at programatically
(from my experience) but delayed quotes you can get from anywhere, and if
you are a brokerage firm, you even have a few options no doubt.

If that's the case, why not just have a cache of prices locally and just go
get updates every few minutes? That way, you will always have information on
the client machine, and it's never any older than lastcheck +
originaldelay.. so say if you check every 2 minutes and your original quotes
are delayed 20 minutes, the data is never older than 22 minutes, sometimes
less.??

And as far as Java vs. .NET web services - I had the pleasure recently to
see textbook technology at work - we use a vendor, they wrote a web service
that I didn't have access to yet (because of infrastructure issues). They
gave me the .wsdl file for the web service (which was written in Java). So I
mocked up a facade web service on my side in .NET that had this interface
and wrote to it. I developed to that interface for a couple months and the
consumer was all in .NET (C#)!!

On the day when I could finally access thier web service, I literally just
changed the URL from my facade, to point to them and it worked perfectly
right away, and has continued to work ever since.

So having a .NET or Java web service as your back-end should be completely
invisble to you.

Remoting doesn't sound like a reasonable idea because you'd have to have the
remoting dll on each client machine and the stub on the server. The
connection management of Remoting is almost non-existent, so it's very
difficult to manage "what" your application is doing over the wire or over
in the client app. There is also quite a bit of overhead per connection with
Remoting, so you'd also have a practical limit based on CPU and RAM of your
server..

HTH..
 
Are there any good resources in existence that explain how to set up a push
model using .Net Remoting and/or .Net Web Services?
 
Are there any good resources in existence that explain how to set up a push
model using .Net Remoting and/or .Net Web Services?
 
RCS,

Can you "subscribe" to a Java webservice using a delegate and a callback and
have data pushed from the Java webservice to your client? Thanks.

- David
 
Not as far as I know. Whenever I've needed that (and that's twice) - I
created a TcpClient/TcpServer to handle this.
 
I don't think this will be fundamentally work - mainly because http is
connectionless and assumes no connection other than right at the moment of a
request. So I believe that you can't have a http-based "push" technology,
it'd have to be your own version (like the other "push" technologies have
been).

You COULD completely do this in sockets (.net network libraries), just not
with HTTP I believe
 
You could have WSE service running on the client that has one method
UpdatePrices(someXmlDoc). The server could then call (using WSE) all the
clients. The clients would need to subscribe to the service before hand and
the server would need to maintain some table of client endpoints. Another
option would be to "ping" the client to pull. So instead of pushing the
data first, just call a Ping() or Alert() method on the client and close.
This kicks off the client to get the new prices from the WSE service on the
server side. This may allow easier security integration as you "flip" it
back to normal pattern where the client must authenticate to the server
using UT or SCT tokens before calling protected methods such as
GetNewPrices(). If security is not an issue, then may not matter which way,
but I think I like the second way better as it gives you the option to
include server authentication using std WS-Security or
WS-SecureConversation.
 
Back
Top