scott <scottw <at> qbik.com> writes:
imagine a distributed system that needs a db server. or more accurately the system needs an implementation of a specific data model that supports the operation of the system. an "interface" needs to be available. this interface must be able to cope with requests from multiple threads, it must be asynchronous (does not block clients) as anything else would be create a terminal bottleneck.
it would seem quite natural for the "interface" to be an active object, accepting requests from multiple client threads and returning results as they become available. at the very least the "interface" (active object) should be a distinct thread. internally there may be more threads processing the actual db queries (whatever is optimal for the underlying db i/f).
Yeah, this makes sense to me. Jeff's telephony example also seems to fit conceptually; I think the degree to which an Active Object (TM) perspective fits a given task depends on the granularity of the objects, and the apparent atomicity of the object. A representation of a telephone makes a much cleaner active object than a bunch of related resources cobbled together as class MyImportantObject.
yes. this code has legs!
cheers, scott
Well, no, actually - as I discovered when trying to generalise it :) I do have a better version, which I'll post when I'm happy with it. Matt