Because ActionScript code executes asynchronously, if you allow concurrent calls to a service, ensure that your code handles the results appropriately. By default, making a request to a web service operation that is already executing does not cancel the existing request. In a Flex application in which a service can be called from multiple locations, the service might respond differently in different contexts.
When you design a Flex application, consider whether the application requires disparate data sources, and the number of types of services that the application requires. The answers to these questions help determine the level of abstraction that you provide in the data layer of the application.
In a simple application, user interface components call services directly. In applications that are slightly larger, business objects call services. In still larger applications, business objects interact with service broker objects that call services.
To understand the results of asynchronous service calls to objects in an application, you need a good understanding of scoping in ActionScript. For more information, see the Adobe Flex 3 Developer Guide.
Flex is a service-oriented framework in which code executes asynchronously, therefore, it lends itself well to the Asynchronous Completion Token (ACT) design pattern. This design pattern efficiently dispatches processing within a client in response to the completion of asynchronous operations that the client invokes. For more information, see www.cs.wustl.edu/~schmidt/PDF/ACT.pdf.
When you use the ACT design pattern, you associate application-specific actions and state with responses that indicate the completion of asynchronous operations. For each asynchronous operation, you create an ACT that identifies the actions and state that are required to process the results of the operation. When the result is returned, you can use its ACT to distinguish it from the results of other asynchronous operations. The client uses the ACT to identify the state required to handle the result.
An ACT for a particular asynchronous operation is created before the operation is called. While the operation is executing, the client continues executing. When the service sends a response, the client uses the ACT that is associated with the response to perform the appropriate actions.
When you call a Flex remote object service, web service, or HTTP service, Flex returns an instance of the mx.rpc.AsyncToken class. If you use the default concurrency value of multiple, you can use the token returned by the data service's send() method to handle the specific results of each concurrent call to the same service.
You can add information to the token when it is returned, and then in a result event listener you can access the token as event.token. This situation is an implementation of the ACT design pattern that uses the token of each data service call as an ACT. How you use the ACT design pattern in your own code depends on your requirements. For example, you could attach simple identifiers to individual calls, or more complex objects that perform their own set of functionality, or functions that a central listener calls.
The following example shows a simple implementation of the ACT design pattern. This example uses an HTTP service and attaches a simple variable to the token.
<mx:HTTPService id="MyService" destination="httpDest" result="resultHandler(event)"/>
<mx:Script>
<![CDATA[
...
public function storeCall():void {
// Create a variable called call to store the instance
// of the service call that is returned.
var call:Object = MyService.send();
// Add a variable to the token that is returned.
// You can name this variable whatever you want.
call.marker = "option1";
...
}
// In a result event listener, execute conditional
// logic based on the value of call.marker.
private function resultHandler(event:ResultEvent):void {
var call:Object = event.token
if (call.marker == "option1") {
//do option 1
}
else
...
}
]]>
</mx:Script>
Another common requirement when using data services is the dependency of one service call on the result of another. Your code must not make the second call until the result of the first call is available. Make the second service call in the result event listener of the first, as the following example shows:
<mx:Script>
<![CDATA[
// Call the getForecastWithSalesInput operation with the result of the
// getCurrentSales operation.
public function resultHandler(evt:ResultEvent):void {
ws.setForecastWithSalesInput(evt.token.currentsales);
//Or some variation that uses data binding.
}
]]>
</mx:Script>
<mx:WebService id="ws" destination="wsDest"...>
<mx:operation name="getCurrentSales" result="resultHandler(event)"/>
<mx:operation name="setForecastWithSalesInput"/>
</mx:WebService>
Send me an e-mail when comments are added to this page | Comment Report
Current page: http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/rpc_httpws_12.html