Application design - penny for your thoughts?

Hi guys

My primary product at the moment is epos software for bars and restaurants.

The next part of the software package I need to design is a way for waiters to use PDA's to take orders and send the orders back to the epos terminals.

Each terminal exposes a WCF service, so that is how I plan to communicate, but I have the following choices about how I do this.

1> Write an app using .netCF 2.0 that communicates with the epos terminals over web services? This obviously has the disadvantage that it for whatever reason a epos terminal needs to contact the PDA, it cant, because in web services, there is no return path.

2> Write the app so that it is a ASP.net application that runs on one of the terminals. This means that the PDA's don't need any installation, but then I need to consider how to get IE on the pda into full screen and keep it that way, and also, it is not guaranteed that the ePOS terminals will have IIS installed, so I would need to look at something like Cassini (?)

3> Write the app using .netCF 3.5, so that I can expose a wcf service on the PDA as well, therefore allowing bidirectional comms.


Do any of you guys have any feedback on my thoughs above, or indeed have any better ideas on how I can achieve this?

Thanks

i'd go with <1>. it's the most simple IMO.

but, there are some curious statements that you put there.
In <1> you said that the epos terminal can't contact the PDA. thats correct, but why do you want the epos terminal be able to contact the PDA in the first place? In server-client model, server only serves what client ask, they never ask client to do something. so i think there might be a problem in your design. try redesign it so that server doesnt have any dependancies on client. make client always trying to synchronize to server. think about it like the internet, you have your client browsers and the server.

In <2>, I don't understand whats the difference with <1>. its basically the same solution only on ASP.Net and Web Browser.

In <3>, but then you'd have to store the client end points in the server and to relate end points with client sessions. and then you'd have to set up clients to listen ports. and then you'd have to deal with possibility of deadlocks... messy stuffs..

Thanks for your feedback.

In 1>, The main reason that a terminal would need to contact a PDA is to pull back transaction data, and sign the user off of the PDA.

 

e.g. if the user has ordered items on he pda, they will expect to be able to go over to the epos terminal (could be any terminal within the network) and sign-on.

They would then expect all of the items they have just ordered to appear on-screen.

 

At the moment, when ordering items on the PDA, the list of items is cached on the PDA for speed, rather than making a network round-trip every time, which would be far too slow.

Therefore, in scenario 1, the waiter would have to invoke a command to send the information over to the terminals. Sounds simple to you and I, but in my market people complain about ANY extra button presses they are expected to make, so they expect everything to happen automagically, as if the software 'knows' when they are ready to proceed etc.

If you think that my reasoning is flawed or whatever, then feedback would definitely be welcome on this one!

im not sure that i understand your system very well. but arent the pdas are connected by somekind of wi-fi system? so, when the waitress/bartenders (whatever) collect the customer order, they recorded it into their pdas. And then when it is confirmed, they'd just click a 'submit' button, which is at this point only you'll connect to the network and contact the server via webservice. no wasteful network roundtrips, simple, user doesnt have to walk to terminals, efficient.

you can make an application on their pdas where everytime it boots up, it'll automatically synchronize to the server and get informations (for instance: todays special menus) and then cache the informations so they wont have to contact the server for every new order.

but maybe, my assumptions are wrong? if you must absolutely go to the terminal to submit your order, then i guess it will be necessary to have somekind of system to detect that a pda is in the vicinity of the  terminal, right? can the pda detect this event also? or only the terminal can detect it?

ps: i wonder why others (read: c9 gurus) doesnt give their replies. i found your problem is very interesting. id even like to built a system like that myself.

 

jh71283 wrote:



Thanks for your feedback.

In 1>, The main reason that a terminal would need to contact a PDA is to pull back transaction data, and sign the user off of the PDA.

 

e.g. if the user has ordered items on he pda, they will expect to be able to go over to the epos terminal (could be any terminal within the network) and sign-on.

They would then expect all of the items they have just ordered to appear on-screen.

This should still be done from the PDA -- rather than the terminal pulling the data from the PDA, the PDA shoudl push the data to the terminal (only the PDA knows when the user has entered data, so the terminal wouldn't know when to pull).

jh71283 wrote:



At the moment, when ordering items on the PDA, the list of items is cached on the PDA for speed, rather than making a network round-trip every time, which would be far too slow.

Therefore, in scenario 1, the waiter would have to invoke a command to send the information over to the terminals. Sounds simple to you and I, but in my market people complain about ANY extra button presses they are expected to make, so they expect everything to happen automagically, as if the software 'knows' when they are ready to proceed etc.

If you think that my reasoning is flawed or whatever, then feedback would definitely be welcome on this one!

OK, so you could asynchronously send the items one-by-one as they are entered, but then you'd have to assume they were sent correctly (or background poll to get the result), or you could do the bulk sending when they 'close the order page' (basically they press a button, but you don't tell them it's a button so they don't complain about buttons).

I would probably go for asynchronously sending each item, but that will require a technique to verify orders in the background so they don't get 'lost'. 
Perhaps a half-way house would be to asynchronously send data items, but keep a local copy on the PDA -- then if they find the order got lost, they could use the 'panic button' on the PDA to re-send the data synchronously while they're at the terminal.
It depends on how likely you think it will be that data gets lost and what their tolerance will be for error recovery (customers will always make out that they have zero tolerance for error, but as long as you can reduce from their current error rate, you can usually talk them round).

PDA projects are always fun

Herbie

Dr Herbie wrote:

(basically they press a button, but you don't tell them it's a button so they don't complain about buttons).

Haha I like your thinking

I have though of another way I could do this, which would leverage the power of this new 'Sync Services for ADO.net' stuff, whereby I can have the PDA merge the database changes straight into the terminals database, and it also gives me a nice (hopefully efficient) way of loading up the product information etc when the application loads up.

I think I am just going to have to be bullish towards the users on this one, and tell them that they cannot expect the system to do something, unless it gets told to do so (i.e. the 'Submit Order' button)

However, (and this will be another topic in a minute, I feel a rant coming on....) from what I can tell, Sync Services for ADO is not yet available for the Compact Framework....

WCF webservices can be bidirectional. So I why not 1

odujosh wrote:

WCF webservices can be bidirectional. So I why not 1

bidirectional means like when i call a webmethod theyd give me the return value? i think what jh71283 means is that the call can be initiated from the client as well as from the server. which means youll have to have two channels to monitor. 

Dr. Herbie wrote:

This should still be done from the PDA -- rather than the terminal pulling the data from the PDA, the PDA shoudl push the data to the terminal (only the PDA knows when the user has entered data, so the terminal wouldn't know when to pull).

yes, this is what i suggested. you said it more clearly. thx.

Dr. Herbie wrote:

OK, so you could asynchronously send the items one-by-one as they are entered, but then you'd have to assume they were sent correctly (or background poll to get the result), or you could do the bulk sending when they 'close the order page' (basically they press a button, but you don't tell them it's a button so they don't complain about buttons).

jh71283 wrote:

I think I am just going to have to be bullish towards the users on this one, and tell them that they cannot expect the system to do something, unless it gets told to do so (i.e. the 'Submit Order' button

  
here's a tip, dont tell them. at least dont tell them what technically goes behind, tell them that it is for finalizing the order so that they dont make mistakes when entering orders. you can tell them its for last-confirmation, or you can lie to them by saying it's for 'clearing' the screen. you can set the text on the button to say 'Done', and theyd understand (i hope).

Dr. Herbie wrote:

I would probably go for asynchronously sending each item, but that will require a technique to verify orders in the background so they don't get 'lost'. 

why? id rather go with bulk operation. it helps easen the transaction process. if you go sending each item to the server, then the server have to maintain state on the current order items. i find it not a very easy solution to implement, and you should do webservices as stateless as you can. we dont want it to be chatty, do we? 

also think about failures, if we keep the transaction as a one time operation, there might be inconcistencies in the session kept by the server (or even in the database, push the order items directly to the db). unclosed sessions, multiple objects synchronization (coz you keep one in your pda, and one in your server),... i dont know. i think it will be much more trouble than its worth.

jh71283 wrote:

'Sync Services for ADO.net'

.. nifty stuffs. too bad its not officially released yet (theres only CTP). considering that it targets OCS (Ocassionally Connected Systems), i do think that it will work with .Net CF because it is where OCS scenario usually comes out (eg: synchronizing your desktop outlook with your pda?). i dont know if this is going to be agood solution. (coz, i have never played with it). try building a proof-of-concepts for your solution (one with Sync Services, and one without). see how much overhead (or efficiency) that it will give you if you want to incorporate it. personally, id go without it. your system is simple enough that introducing another framework just feels like overdoing it.