Posts Tagged ‘uml sequence diagram’


May 27, 2012 2 comments

As the UML sequence diagram below shows, an “unnamed” Nature object with an infinite lifeline asynchronously creates and, uh, kills Human_Being objects at will. Sorry about that.

So, what’s this preserveSelf routine that we loop on until nature kicks our bucket? I’m glad you asked:

Have a nice day! 🙂

Push And Pull Message Retrieval

March 30, 2011 Leave a comment

The figure below models a two layer distributed system. Information is exchanged between application components residing on different processor nodes via a cleanly separated, underlying communication “layer“. App-to-App communication takes place “virtually“, with the arcane, physical, over-the-wire, details being handled under the covers by the unheralded Comm layer.

In the ISO OSI reference model for inter-machine communication, the vertical linkage between two layers in a software stack is referred to as an “interface” and the horizontal linkage between two instances of a layer running on different machines is called a “protocol“. This interface/protocol distinction is important because solving flow-control and error-control issues between machines is much more involved than handling them within the sheltered confines of a single machine.

In this post, I’m going to focus on the receiving end of a peer-to-peer information transfer. Specifically, I’m going to explore the two methods in which an App component can retrieve messages from the comm layer: Pull and Push. In the “Pull” approach, message transfer from the Comm layer to the App layer is initiated and controlled by the App component via polling. In the “Push” method, inversion of control is employed and the Comm layer initiates/controls the transfer by invoking a callback function installed by the App component on initialization. Any professional Comm subsystem worth its salt will make both methods of retrieval available to App component developers.

The figure below shows a model of a comm subsystem that supplies a message queue between the application layer and the “wire“. The purpose of this queue is to prevent high rate, bursty, asynchronous message senders from temporarily overwhelming slow receivers. By serving as a flow rate smoother, the queue gives a receiver App component a finite amount of time to “catch up” with bursts of messages. Without this temporary holding tank, or if the queue is not deep enough to accommodate the worst case burst size, some messages will be “dropped on the floor“. Of course, if the average send rate is greater than the average processing rate in the receiving App, messages will be consistently lost when the queue eventually overflows from the rate mismatch – bummer.

The UML sequence diagram below zeroes in on the interactions between an App component thread of execution and the Comm layer for both the “Push” and “Pull” methods of message retrieval. When the “Pull” approach is implemented, the OS periodically activates the App thread. On each activation, the App sucks the Comm layer queue dry; performing application-specific processing on each message as it is pulled out of the Comm layer. A nice feature of the “Pull” method, which the “Push” method doesn’t provide, is that the polling rate can be tuned via the sleep “Dur(ation)” parameter. For low data rate message streams, “Dur” can be set to a long time between polls so that the CPU can be voluntarily yielded for other processing tasks. Of course, the trade-off for long poll times is increased latency – the time from when a message becomes available within the Comm layer to the time it is actually pulled into the App layer.

In the”Push” method of message retrieval, during runtime the Comm layer activates the App thread by invoking the previously installed App callback function, Cb(Msg), for each newly received message. Since the App’s process(Msg) method executes in the context of a Comm layer thread, it can bog down the comm subsystem and cause it to miss high rate messages coming in over the wire if it takes too long to execute. On the other hand, the “Push” method can be more responsive (lower latency) than the “Pull” method if the polling “Dur” is set to a long time between polls.

So, which method is “better“? Of course, it depends on what the Application is required to do, but I lean toward the “Pull” Method in high rate streaming sensor applications for these reasons:

  • In applications like sensor stream processing that require a lot of number crunching and/or data associations to be performed on each incoming message, the fact that the App-specific processing logic is performed within the context of the App thread in the “Pull” method (instead of the Comm layer) means that the Comm layer performance is not dependent on the App-specific performance. The layers are more loosely coupled.
  • The “Pull” approach is simpler to code up.
  • The “Pull” approach is tunable via the sleep “Dur” parameter.

How about you? Which do you prefer, and why?

Extended Business Model

In CEO Tony Hsieh’s new book:  “Delivering Happiness“, Tony describes the original business model as “drop-ship”. As the UML sequence diagram below shows, a customer would place an order at the website, Zappos would relay the order directly to the shoe manufacturer’s warehouse, and the order would be fulfilled and shipped directly from ground zero. It was a low cost model for Zappos, but it limited sales growth since many shoe manufacturers didn’t have the information systems in place to execute their end of the model. In addition, sales were limited to the inventory that warehouses held in storage, not necessarily what Zappos’ customers wanted.

During the initial stage of growth, was often short on cash (surprise!) and often just a month or two away from goin’ kaput (surprise, again!). The Zapponians needed to increase sales in order to increase cash flow. During a brainstorming session in a local bar (not in a committee of BMs, CCRATS, BOOGLs, consultants, and other self-important dudes) they came up with the idea of extending their existing business model.

Man creates by projection, nature creates by extension – Unknown

The sequence diagram below shows the extended business model that Tony “chez” et al decided to move toward. In a nutshell, Zappos would purchase or lease a warehouse and stock its own inventory based on trend information extracted from its website. As simple as it looks, the devil is in the details. Buy and read the book to learn how they pulled it off – despite being cash poor and close to going tits-up.

If changing our business model is what’s going to save us, then we need to embrace and drive change. – Tony Hsieh

How many times have you heard or spoken the “embrace change” words above but never experienced or executed any follow through?

%d bloggers like this: