Application design question

[David]

Hi all,

I am coming from an ASP.NET background into a windows (and windows mobile)
application project. (The project is currently being scoped, but my skills
may be required.) The project will be written in C# and will use a variety
of platforms (Windows, Windows Mobile, Web Services, ASP.NET etc.)

The application will be presented on two large plasma displays and will need
to provide real time information. If you imagine where you have seen the
bankers in the trading room, you have the screens in front of them providing
real-time share prices. Now my app will be different, but it is the
real-time nature that I need to consider.

There will also be screens for the desks... the plasma displays are mainly
for an overview, like a call center, the desk screens are actually the
interactive part of the whole project.

In the trading room example, the screen is updated and things start flashing
etc.

How is the updating managed (or how should it be managed). My app will have
a database backend. Does the screen just continually poll the database or
use some other method to manage the screen? If so, what does it do?

Also, from a loading perspective, when I design my app, if for example it is
polling the DB, how often should I poll? (I know the question is a little
open ended, but what I am concerned about is potential load... I want it
often enough to look like real time, but not too often that everything
grinds to a halt.

Finally, when developing something like this, is there anything else that I
should consider?

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Larry Smith]

I am coming from an ASP.NET background into a windows (and windows mobile)

application project. (The project is currently being scoped, but my skills
may be required.) The project will be written in C# and will use a variety
of platforms (Windows, Windows Mobile, Web Services, ASP.NET etc.)

The application will be presented on two large plasma displays and will
need to provide real time information. If you imagine where you have seen
the bankers in the trading room, you have the screens in front of them
providing real-time share prices. Now my app will be different, but it is
the real-time nature that I need to consider.

There will also be screens for the desks... the plasma displays are mainly
for an overview, like a call center, the desk screens are actually the
interactive part of the whole project.

In the trading room example, the screen is updated and things start
flashing etc.

How is the updating managed (or how should it be managed). My app will
have a database backend. Does the screen just continually poll the
database or use some other method to manage the screen? If so, what does
it do?

Also, from a loading perspective, when I design my app, if for example it
is polling the DB, how often should I poll? (I know the question is a
little open ended, but what I am concerned about is potential load... I
want it often enough to look like real time, but not too often that
everything grinds to a halt.

Finally, when developing something like this, is there anything else that
I should consider?

Polling is normally very inefficient. It's a waste of time sending in
requests for data that might not have changed. That might not apply in your
case however if the data is changing so frequently that if you did poll,
you're guaranteed to get fresh data each time. It's also easier to code than
an event driven system (since the server doesn't have to track clients -
read on) but the latter is often the way to go. Consider for instance a
system where clients can register with the server (running on your backend)
to receive data every X seconds (or whatever granularity you want) but only
if the data has changed since the last time they received something (note
that they'll pass in X accordingly but this can even be -1 to request all
changes in real time). For example, a given client could connect to the
server and say something like, "fire me a data change event every 5 seconds
but only if the data actually changed since the last time I received it".
The server would then keep track of these requests and everytime the data
changes, it would fire the event to each waiting client accordingly (you can
then update your "desk" and "plasma" monitors). For some clients however
there will be a delay before the event is fired based on the time that was
requested. For instance, if they were last notified 2 seconds ago then based
on a requested 5 second delay, you would have to wait 3 more seconds before
firing the event. OTOH, if 7 seconds has elapsed because the data hasn't
changed for that long then you would have to fire the event immediately (to
that particular client and any others). The devil is in the details of
course (mostly on the server side) but it's not that difficult. Just make
sure you code it efficiently on the server side in particular. It shouldn't
waste time continuously checking which clients need to be notified in some
ongoing loop for instance. It should be scheduled as efficiently as you can.
Also, I strongly recommend writing (or purchasing) this as a generic
scheduler component (object) first (one that can fire events based on
changes to any arbitrary data source) and then construct a scheduler for
your specific data source (DB) on top of this. Your DB scheduler shouldn't
be wired to the same machine as the DB itself however so you can move it to
another machine if ever required. A server would have to be written for the
DB machine however to fire events whenever the required data changes (your
scheduler can connect to this even if located on another machine). In any
case, caution advised about relying on the system clock to do your
scheduling, assuming you're going to implement this by tracking the last
send time for each client (as one potential way). Someone might change the
clock so relying on system ticks or some other mechanism should be
considered (but also consider what happens if the machine goes down).

This is certainly more difficult to implement than having clients
continously request data every X seconds but it's cleaner IMO and I would
probably go with it instead (if you have the time and the $). Ultimately I'm
not familiar with your own situation though (or your precise requirements)
so exercise caution before adopting this or any other solution (from a
stranger on the Internet no less).

 

[David]

Hi Larry,

Thanks for the info...

With how you describe it, doesn't the 'scheduler' (for want of a better
word) poll the DB to raise the events?

Also, any links on anything I can read up about this would be very much
appreciated. Naturally, from an ASP.NET background, the event is driven from
the client rather than the server (same situation as polling). If the server
is pushing instead, I have a whole new way of programming to learn (i
guess).

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Paul]

http://msdn.microsoft.com/en-us/library/t9x04ed2.aspx

you may find this interesting.

 

[David]

Cool, bookmarked. Thank you.
--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Larry Smith]

Thanks for the info...

With how you describe it, doesn't the 'scheduler' (for want of a better
word) poll the DB to raise the events?

No. Wherever the data originates from, presumably the DB machine itself, it
will fire an event whenever the relevant data changes. You can have multiple
events if you want (as one example), each returning a specific set of data.
You set this code up as a server so that it can fire these events to any
client that registers for them. In this case it's your scheduler object that
registers as a client, possibly the first time a "desk" or "plasma" client
connects to it (read on). You can therefore locate the scheduler anywhere
you want including the same machine as the DB. This gives you the freedom to
move it to a middle-tier machine if ever required. Even if you never do,
it's much cleaner to keep it as a separate component. It's not inextricably
tied to the DB machine that is. In any case, your "desk" and "plasma"
machines would then connect to the scheduler object directly. Whenever any
data changes on the DB side, it fires an event to all registered clients
which in this case is just your scheduler object (not the "desk" or "plasma"
clients). In turn, your scheduler would then fire an event to its own
clients (your "desk" and "plasma" machines) but does so only according to
the schedule previously discussed (on a per-client basis). This is the basic
design I'd start thinking about if I were doing this myself.

Also, any links on anything I can read up about this would be very much
appreciated. Naturally, from an ASP.NET background, the event is driven
from the client rather than the server (same situation as polling). If the
server is pushing instead, I have a whole new way of programming to learn
(i guess).

Sorry, I don't have any specific links but it's a fairly straightforward
pattern. Have a look at the ADO.NET events for trapping updates however,
though you don't necessarily need this (you yourself usually know when and
where the updates occur because you're coding them). In any case, to
summarize, someone on the DB side updates something. It then fires an event
to any client that registered to be notified of that update. This is your
scheduler object wherever that may be (the DB machine or another machine).
You scheduler object therefore receives all updates. It now fires an event
to its own clients which are your "desk" and "plasma" machines. It only does
so according to each client's individual schedule however. This is a very
clean approach IMO but of course the mechanics are what you'll need to
wrestle with.

 

[David]

Sorry, I don't have any specific links but it's a fairly straightforward
pattern. Have a look at the ADO.NET events for trapping updates however,
though you don't necessarily need this (you yourself usually know when and
where the updates occur because you're coding them). In any case, to
summarize, someone on the DB side updates something. It then fires an
event to any client that registered to be notified of that update. This is
your scheduler object wherever that may be (the DB machine or another
machine). You scheduler object therefore receives all updates. It now
fires an event to its own clients which are your "desk" and "plasma"
machines. It only does so according to each client's individual schedule
however. This is a very clean approach IMO but of course the mechanics are
what you'll need to wrestle with.

Thanks Larry...

Paul answered here with a link to MS about sql dependency, which looks like
it could do it. I did a search for SqlDependency and found this simple
project on codeproject. It looks like this is almost what I need.
http://www.codeproject.com/KB/database/chatter.aspx (obviously, it won't be
a chatter app, but the app will need to work in a similar way)

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Larry Smith]

Paul answered here with a link to MS about sql dependency, which looks

like it could do it. I did a search for SqlDependency and found this
simple project on codeproject. It looks like this is almost what I need.
http://www.codeproject.com/KB/database/chatter.aspx (obviously, it won't
be a chatter app, but the app will need to work in a similar way)

Careful about jumping into bed with a specific DB unless you plan on a
lifetime marriage.

 

[David]

Yes, I understand where you are coming from and my own apps, I try and make
them more flexible... but in the case of this particular application, it
will be based on SQL Server.

I would like to learn more about the technique though, as I also tend to use
MySQL as well.

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[jehugaleahsa]

Yes, I understand where you are coming from and my own apps, I try and make
them more flexible... but in the case of this particular application, it
will be based on SQL Server.

I would like to learn more about the technique though, as I also tend to use
MySQL as well.

--
Best regards,
Dave Colliver.http://www.AshfieldFOCUS.com
~~http://www.FOCUSPortals.com- Local franchises available







- Show quoted text -

David, also be aware that database events (dependencies) aren't
necessarily real-time either. They might be fast, but they generally
don't specify whether events are raised immediately, queued up, or
whatever. Look at the database's documentation to see if, at all, they
say what should be the expected delay time. Our experience with Oracle
has been that the delay time is not fixed and isn't suitable for our
real-time scenario.

We have a real-time SCADA system in one of our substations, which
displays metering information for our power lines. It tells use what
the demand going over a particular line is, when a line goes down,
etc. We poll our meters every second, roughly. Rarely does one second
seem to make that big of a difference. Getting this time span can
actually be very important to your system's development process, so it
is good to have a rough idea of what you are shooting for. For
instance, if the time limit is very low (less than a second), I would
schedule timing tests at the end of each iteration that will identify
performance bottlenecks. Of course, premature optimization is the root
of all evil, so limit your optimizing until the timing test. Buy a
good profiler!

We have two programs that work off the database concurrently. One is
responsible for dialing up a meter, downloading its data and inserting
it into the database. The other is responsible for reading the
database and displaying the information on (you guessed it) giant
monitors. Talking to meters across a phone line is pretty slow, so the
information is generally a few seconds out-of-date. The other program
simply hits the near-by database and gets all the records that have
been inserted/updated since the last poll, using the last value if
nothing is available. The second program is more real-time than the
first.

Mind you that we don't use transactions since we want the records to
appear as soon as they are available. If you are displaying real-time
financial information, be careful here.

 

[Tim Layton]

David, it all depends on what portion of the project you are going to be
working on. However your C# skills will definitely be used if you do any
windows mobile development and there are several resources that can help you
get up to speed. Here are a few in case you need them.

Windows Mobile MSDN Home
http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
Everything you need to get started, code, test and deploy your applications
can be found on the Windows Mobile MSDN portal.

Windows Mobile Community Team Lead
http://blogs.msdn.com/croman/
Constanze Kratel is a Community Program Manager with the Microsoft Windows
Mobile team. She blogs about everything mobile and what's going on for mobile
developers.

Windows Mobile Development Team Twitter is at http://twitter.com/wmdev

Windows Mobile Team Blog at http://blogs.msdn.com/windowsmobile/ is a great
place to stay up to date on Windows Mobile.

Windows Mobile MSDN Code Gallery
http://code.msdn.microsoft.com/Project/ProjectDirectory.aspx?TagName=Windows Mobile
The Code Gallery is a great place to jumpstart your development knowledge as
well as source some help.

Smart Device Development Forums
http://social.msdn.microsoft.com/Forums/en-US/category/smartdevicedevelopment/
The Smart Device Development Forums is a great place to learn, share and ask
questions when you need help.

Windows Marketplace for Mobile Forums
http://social.msdn.microsoft.com/Forums/en-US/mktplace/

Windows Mobile Developer Portal at http://developer.windowsmobile.com/