> > Am 29.10.2013 um 02:08 schrieb David T. Lewis <le...@mail.msen.com>: > >> I have some experience with this, not related to Smalltalk but maybe >> still relevant. I have worked with systems that were designed around >> networked message passing, implemented on platforms like MS-DOS with >> time >> slicing kernels, Series I, OS/2, etc. These systems were designed to >> operate >> with asynchronous message passing protocols. The asynchronous designs >> were >> intended to support primitive OS environments, including MS-DOS with >> software interrupts for multitasking. >> >> These are production-critical manufacturing applications, and in the >> course >> of modernizing them I have reimplemented the network protocols in Java >> and >> moved them to new computing platforms. Along the way I have found that >> the >> asynchronous designs could always be replaced by bidirectional >> send-receive >> transactions running in the context of a thread or process. Even the >> systems >> that appeared to be most complex have turned out to work perfectly well >> when modeled as synchronous send-receive transactions on a bidirectional >> communication channel. The software is much simpler to understand and >> debug >> when structured in this manner. >> >> My conclusion is that designing around asynchronous, loosely coupled >> channels sounds like a good idea, but in practice it leads to >> unnecessary >> complexity, and to systems that are difficult to debug and support. >> > I agree. That was the reason for me to look out for a simpler approach. At > least for testing. Can you elaborate on the bidirectional send-receive > transaction. Im not sure I understand what happens there. I explained my > case a bit more in my response to Igor. >
I modeled the problem in terms of communication sessions, with message objects that can be sent and received on a session. By transaction (poor choice of terms here) I mean an object with an evaluate method that uses a session to send a message object and receive a response message object, and that answers an object that encapsulates the result of that completed transaction (including errors if any). Early in the project I implemented a kind of session that handled asynchronous send and receive, keeping track of thread synchronization and matching response objects to request objects. I expected this to be necessary for interaction with old MS-DOS and OS/2 based applications that had been written in that manner, and that were entirely asynchronous and interrupt driven by design. I practice, I have never actually needed to use this asynchronous type of processing, because the simple synchronous session has always been proved sufficient even when interacting with systems that appeared to be (and were designed to be) completely asynchronous and event driven.
