Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Asynchronous Completion Token

Asynchronous Completion Token

Ratings: (0)|Views: 29 |Likes:
Published by newtonapples

More info:

Published by: newtonapples on Mar 12, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





26.11.1999 ACT.doc
Asynchronous Completion Token1
© Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved
Asynchronous Completion Token
 Asynchronous Completion Token
design pattern efficientlydispatches processing actions within a client in response to thecompletion of asynchronous operations invoked by the client.
Also Known As
Active Demultiplexing [PRS+99]
Consider a distributed Electronic Medical Imaging System (EMIS)[PHS96] consisting of multiple components, such as
image servers
,which store and retrieve medical images [JWS98].
The performanceand reliability of an EMIS is crucial to physicians, medical staff, andpatients using the system. Therefore, it is important to monitor thestate of EMIS components carefully. Specialized agent componentsaddress this need by propagating events from other EMIS compo-nents, such as image servers, back to management applications. Ad-ministrators can use these management applications to monitor,visualize, and control [PSK+97] the EMIS’s overall status and perfor-mance.For example, a management application can request that an agentnotify it every time an image server on a host accepts a new network connection. Typically, such a request is issued by invoking an
1.Other components in a distributed EMIS include modalities, clinical and diag-nostic workstations that perform imaging processing and display, hierarchical storagemanagement (HSM) systems, and patient record databases [BBC94].
: ManagementApplication
Monitoring Station
: ImageServer: Agent
toad --> cobratoad --> snakelizard --> cobra
© Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved
26.11.1999 ACT.doc
asynchronous operation on one or more agents in the system. Whenan agent on a particular host detects a new connection to the imageserver, it sends a
completion even
to the management application sothat it can depict the new connection graphically on its monitoringconsole display.However, a management application may have requested manydifferent agents to send it notifications asynchronously for manytypes of events, each of which may be processed differently in themanagement application. For each completion event, therefore, themanagement application must determine the appropriate action(s),such as updating an administrators display or logging the event to adatabase.One way a management application could match up asynchronousoperation requests with their subsequent completion event responseswould be to spawn a separate thread for each event registrationoperation it invoked on an agent. Each operation would block synchronously, waiting for its agents responses. The action and stateinformation required to process agent responses could be storedimplicitly in the context of each thread's run-time stack.Unfortunately, this synchronous multi-threaded design incursseveral drawbacks. For example, it may lead to poor performance dueto context switching, synchronization, and data movementoverhead.
As a result, developing management applications usingseparate threads to wait for each operation completion response canyield inefficient and overly complex solutions. Yet, the managementapplication must associate service responses with client operationrequests efficiently and scalably to ensure adequate quality of servicefor all its agents.
An event-driven system where clients invoke operations asynchro-nously on services and subsequently process the responses.
When a client invokes an operation request asynchronously on one ormore services, each service indicates its completion by sending aresponse back to the client. For each such completion response, theclient must perform the appropriate action(s) to process the results of 
2. The Example section of the Reactor pattern (97) describes the drawbacks of synchronous multi-threading in more detail.
26.11.1999 ACT.doc
Asynchronous Completion Token3
© Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved
the asynchronous operation. Thus, we must define a demultiplexingmechanism to associate service responses with the actions to beperformed by the client. To address this problem we must resolve thefollowing three
:When a service response arrives back at a client, it should spendas little time as possible determining the action(s) and state neededto process the completion of the associated asynchronousoperation. In particular, searching a large table to associate aresponse with its request can be unacceptable if the performanceof the client degrades significantly.It is hard for a service to know what information its clients need toprocess operation completions because it does not necessarilyknow the context in which clients invoked asynchronous opera-tions. Therefore, it should be the responsibility of the client, not theservice, to determine what actions and state to associate with com-pletion responses.There should be as little communication overhead as possiblebetween client and service to determine which action to perform inthe client when the asynchronous operation completes. This isparticularly important for clients that communicate with servicesover bandwidth-limited communication links, such as modemconnections or wireless networks.
Associate application-specific actions and state with responses thatindicate the completion of asynchronous operations. For everyasynchronous operation that a
invokes on a
, create an
asynchronous completion token
(ACT) that uniquely identifies theactions and state necessary to process the operation’s completion,and pass the ACT along with the operation to the service. When theservice replies to the client, its response must include the ACT thatwas sent originally. The client can use the ACT to identify the stateneeded to process the completion actions associated with theasynchronous operation.
The following participants form the structure of the AsynchronousCompletion Token pattern:A
provides some type of functionality.A
invokes operations on a service asynchronously.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->