Occasionally Connected Scenarios-How much power is too much power for the client?
Introduction
I am on a Microsoft Patterns and Practices advisory board to explore and provide guidance on the well-known and popular CQRS Design Pattern. We are exploring occasionally disconnected scenarios as part of the project.
As new versions of Windows role out and more mobile platforms are practical, managing disconnected scenarios will increase in importance.
| Team Lead - Grigori Melnik | https://blogs.msdn.com/b/agile/archive/2012/02/24/microsoft-s-cqrs-journey-project-to-take-community-contributions.aspx |
| CQRS Journey | https://cqrsjourney.github.com/ |
| Advisory board | https://cqrsjourney.github.com/advisors/members/# |
| Apache 2.0 | https://opensource.org/licenses/Apache-2.0# |
The Biggest Challenge for the client – Defining the decision-making power available to the client if disconnected
The biggest challenge in occasionally connected scenarios is empowering the client when they are not connected. Just because the network is down, doesn’t mean the client still has to do serious work.
This means the client application will occasionally make mistakes because it doesn’t have the most up to date information. Let’s face it – that is just a fact of life – sometimes you make decisions with limited information. The question ultimately becomes, how bold are your decisions and how long has it been since you get the latest information.
Concrete Example-Conference Software
Imagine that you create software run conferences. This software handles all aspects of running a variety of conference types, handling such things as registration, badge printing, scheduling, calendars, and so on.
 |
For example, how would you handle the situation where the network is down an conference registrant wants to upgrade their registration and attend the panel discussion? The client software will need to update the badge to allow entry into the event. But because the network is down you inadvertently sell an extra ticket when the event was already sold out. |
You can also call it occasionally connected scenarios
Questions that you’ll have to answer along the way of developing a solution.
| Question 1 | What are issues when the client is disconnected? |
| Question 2 | How does the client manage events that are pending? |
| Question 3 | When the client reconnects, what is important to do? |
Power to the client !
Assuming the client is disconnected, are you going to allow seat purchases? Isn’t that risky since the event may have sold out? Maybe you decide that if the client connected within the last hour and there was 10% seats left at that time, then it would be ok to sell additional seats when disconnected from the registration databases.
The client will need to queue outgoing events when disconnected
The client will need to update the server after re-connecting. Changes to local data will need to be persisted up to the cloud.
Interestingly, there are some challenging decisions here. There are at least 2 choices like this:
| Choice 1 [preferred by me] |
|
| Choice 2 |
|
The client may not be able to send outgoing events
A local, persistent database is clearly needed to store event-related .
| What the client needs | Why it needs it |
|---|---|
| Client Needs a local store | Needs local access to registrants, schedules, room locations, etc |
| When connected the client receives seat availability events | These events either increase or decrease available seats at events. The client needs to be kept up-to-date about available seats. |
| These events get queued up at the server when the client is not connected | Upon reconnection the client will need to process incoming events. The client may not be able to see this events when the network is down. |
The client will adjust it's local store based on incoming events
Two types of Queues - Incoming and Outgoing
But this is only possible when there is a connection. Notice there are queues to support incoming and outgoing events. This event mechanism is used to synchronize clients and servers. You can leverage the Windows Azure Service Bus to implement this pattern. I will do this in a future post.
Sequence Diagram Exploration
How does the client manage event processing when occasionally disconnected? Get ready to view this in detail in a little while.
We will allow clients to oversell seats at events
The caveat is that it has only a one hour window where an oversell can take place. We could even add more rules. For example, we could say that client workstations can sell tickets assuming they have connected within the hour, plus there were at least 10% of seats left last time we checked.
Two type of events
Seat Sold and Seat Available Events.These events could be sent by the client or could be received by the client from the server.
Here is a workflow that demonstrates how seats are sold
Service interruption may occur anywhere in the timeline.Notice that we have a Client A and and a Client B.
The sequence diagram is fairly basic:
| Occasionally, the client gets the most up to date events around event and seat availability. |
| Assume the client is up to date. It thinks it has one seat left. |
| After the client loses a connection, the last seat is sold by another client. |
| But the client doesn't know better and sells that last seat anyway. |
Client A reconnects and needs to merge events
The key question to ask “What will the client do once it realizes it oversold seats to an event?”
The client is allowed one hour to override oversold scenarios
The client may need to notify onsite staff for oversold scenarios.
Lingering Questions
Overselling an event is not an easy problem to resolve. If a mistake is made, it may not be resolvable at all.
Pick your poison – some decisions aren’t easy
There is a discrete number of behaviors the occasionally connected client can pursue once it discovers and event is oversold:
| It can phone call the person and reverse the seat sale, canceling the scan-able badge. That would probably not be wise from a customer satisfaction point of view. |
| It can let the oversold ticket work anyway and notify local staff about an extra seat |
| It could refuse service to a registrant in a disconnected state. |
In closing, you can see that the biggest challenge in a disconnected scenario is defining what the client should be allowed to do if in a disconnected state.The things a client can accomplish could also be fine-tuned based on other factors, such as:
- What percent full was the event at last count?
- What is the ticket sales rate overtime? Statistics could be used to predict if an event is selling out quickly.
Implementing this software is the next goal. Stay tuned.
Download for Azure SDK |