Should I use Remoting or Web Services?

[NipsMG]

I'm not sure which road to pursue here.

I've basically got a whole bunch of PocketPC Clients. Each of these is going to communicate with a web service, and submit barcode scans to it. However, I'd like the clients to pass a callback to a function that will automatically update whenever ANY of the clients updates.

If client A submits a scan, I want the webservice class to fire the callback to client A, B, and C, i.e. fire an event over all instances.

Is this even possible?
How should I look into doing this?

Thanks in advance.

 

[ThatRickGuy]

Wow, that sounds like a fun project! Are these wireless units that will be getting the updates real time? or are they just going to do the update when they get cradled?

-Rick

----------------------

http://www.ringdev.com

 

[NipsMG]

No, it's real time. They all have 802.11g.

 

[ThatRickGuy]

well, with a web service, you could have the field units query back to the web server to get the data.

Or you could try to open a connection/dataset to a central database for all interactions.

You could also set up a socket connection that could push the data, or push an update notification for the unit to call back for data.

I have nada for experience with remoting, so if you go that route, I'd love to hear about it.

Matters on how much you trust your connection. if you want the data to be centralized, or distributed. how you want to handle security.



I just keep telling myself, 1 more month of reports, then onto the fun projects...

-Rick

----------------------

http://www.ringdev.com

 

[NipsMG]

Data is centralized on a server.

Here's the application:

Basically, the user will enter the barcode and a work order number. It will then query the system to see the parts that need to be pulled form the warehouse, and list them in a list right on the pocketPC. As the users go and scan the items, I want the web service to notify ALL clients that a change has been made to that work order. That way, if the other clients are also pulling (In different areas of the warehouse) for tha t order, the client will go get the most recent data and update the list. This way there's instant visibility on the status of the entire kit pull to all clients actively scanning for that work order.

I can easily have ONE client send the instance to a delegate to the web service. but when each client instantiates the web service, they'll all be in separate instances. I don't know how to have Client A say "I scanned" and have Client A's instance of the class tell client B and C's instances to send it a message saying "I've updated!".

 

[ThatRickGuy]

Here's a workflow question for you, when Client A changes item 123, do you want Client B to get a message saying "Item 123 has changed!" or do you want the changes to be reflected the next time Client B looks at item 123?

If you want Client B to notify the user, you either need an active system where the server can update the client, or a passive system where the Client continuously checks the server for updates.

If you just want Client B to reflect the changes when they are view, you only need a passive system that contacts the server anytime it pulls data.

-Rick

----------------------

http://www.ringdev.com

 

[NipsMG]

I want an active system.

There's a list of 12 items on all 3 clients screens.

Client A scans an item.

The webservice automatically notified Client A, B and C of a change.

There are now 11 items on all 3 screens.

 

[chiph]

This is doable via either method, but there are some issues that would need to be addressed:

1. Since the handhelds will be in a warehouse, there's a good chance they will be out of network range at some point.

2. The handhelds aren't running a server, so having the central computer call them directly is not really workable.

To solve these, you need to implement a store & forward style architecture. Instead of pushing change notifications out to the handhelds immediately, you store them on the server, and the next time the handheld does something on the server, you return it a list of updates in addition. So the conversations would work something like this:

Handheld1 downloads scan list from Server
Handheld2 downloads scan list from Server

Handheld1 scans Item1 & tells Server to remove it from inventory
Server removes Item1 from inventory, and adds it to Handheld2's update list
Server sends (empty) update list to Handheld1

Handheld2 scans Item2 & tells Server to remove it from inventory
Server removes Item2 from inventory, and adds it to Handheld1's update list
Server sends Item1 update to Handheld2

This should work 99.9% of the time -- the only potential problem is when Handheld1 and Handheld2 both attempt to scan the same item right after each other. But in reality, if the item isn't on the shelf, then the 2nd handheld wouldn't have anything to scan, so it's pretty self-correcting.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[NipsMG]

That kind of works, but what about:


Handheld 1 scans the last item. The people operating handhelds 1 and 2 are both responsible for making sure items get scanned. Operator of handheld 1 leaves out the side warehouse door to the floor. Operator of handheld 2 checks display, and still sees the last item there that Handheld 1 scanned because he hasn't submitted anything lately. Handheld 2 operator goes frantically searching warehouse because he can't find Operator of Handheld 1, and he can't find the last part on his screen, because Haldheld1 operator already took it.

It's got to be realtime. I would just much rather do it through callbacks then through polling. If I have to, I will, but I'd rather complicated coding to get it done the way I want. If I can't do it that way, oh well.. *shrug*.


--NipsMG

 

[rayray00]

Have you looked into using MSMQ?

I have limited experience with it, but it sounds like the following would work:

Device A Scans workorder and sends MSMQ message to server. Server processes message and according to logic, sends response to client apps that have subscribed/registered to the MSMQ. Clients recieve message and update UI accordingly.

Also, MSMQ should handle leaving the wireless bubble or losing connectivity, as the messages persist in the queue and could be processed when back in range...

Depending on your mobile platform, that may be a fairly solid approach. I know that you can intall MSMQ on PocketPC devices.

-Ray!