Accessibility

Table of Contents

  1. Introduction
  2. RPC services and the messaging architecture
  3. RPC services configuration
  4. Changes to the RPC services MXML API
  5. Using channels with RPC services
  6. ActionScript 3.0 data types and serialization

Using RPC services in Flex Data Services 2

RPC services and the messaging architecture

The new messaging architecture in Flex 2 introduces several new concepts to RPC services. This section explains the high-level differences from Flex 1.5 and outlines the equivalent features in Flex 2.

In Flex 1.5, a developer uses MXML tags to connect to RPC services. Several attributes are specified, such as the service name, the endpoint to which the request should be sent, and so forth. Each RPC service in Flex 1.5 makes use of different technologies, so configuration options and terminology differ between each service. For example, a RemoteObject tag specifies named or unnamed sources and connects to an Action Message Format (AMF) gateway, whereas HTTPService and WebService tags use named services or raw URLs and connect to an HTTP proxy using text-based query parameters or XML.

Flex 2 introduces several enhancements to this model that both make the model more consistent across different channels and offer greater flexibility to developers. On the client side, developers can use either MXML tags or pure ActionScript APIs to declare service connections. If the connection is client-side only, the URI for the service is specified as a parameter. If the connection takes advantage of Flex Data Services, developers specify a logical destination associated with the desired service. Services represent various distinct capabilities, such as mediated web service calls or messaging integration. On the server, all destinations are configured through configuration files. A destination includes information about the endpoint to which a destination connects, the various messaging options that are used for all connections, as well as the channel that is used for communication. Channels represent a communication mechanism, typically specifying the protocol and a few options, such as whether the channel uses polling and the desired polling interval.

All communication with the various services provided is mediated by a common message broker that directs messages to the appropriate service. The type of message and the destination selected are used by the message broker to select the appropriate service and to ensure that the service can handle the message. RemoteObject messages are routed to the Remoting Service, and HTTPService and WebService messages are routed to the Proxy Service. Table 1 compares Flex 1.5 services concepts and their Flex Data Services 2 equivalents.

Table 1. Comparison of Flex 1.5 and Flex Data Services 2 concepts
Flex 1.5 Services Concepts Flex Data Services 2 Equivalent

Named and Unnamed Services

In Flex 1.5, the developer is encouraged to give services a name to act as an alias; however, the client can also provide the details of a service (such as a third-party URL or the source of an object) dynamically in an unnamed manner.

Destinations

A destination is equivalent to a Flex 1.5 named service. The term service now refers to the encompassing feature; destinations refer to the ultimate endpoints. All requests must be sent to a destination on the relevant service (Remoting Service, Proxy Service, Message Service, and Data Service).

The Proxy

The desired endpoint for HTTPService and WebService requests is typically a remote third-party service. However, the security sandbox of Flash® Player restricts requests to the domain in which the application was loaded. To avoid requiring a crossdomain.xml policy file on each remote site, Flex 1.5 provided developers with a built-in Proxy Servlet to relay their requests to the appropriate endpoint.

Proxy Service

Security sandbox restrictions still apply to all services, although HTTPService and WebService use the message broker to relay requests through the Proxy Service.

The Proxy Service is no longer used by default; the default value of the useProxy property is false. With useProxy to false, the message broker is not contacted and the destination property is not used. Instead, the developer must set a url property for HTTPService tag or specify a wsdl property for the WebService tag. The developer selects a special direct channel to make non messaging-based requests to third-party endpoints.

To use the proxy, the developer must set useProxy to true on HTTPService or WebService. Setting a destination on HTTPService or WebService automatically sets useProxy to true.

When using the Proxy Service, requests can be made over any channel. Channels are registered as endpoints to the message broker. HTTP-based channels send messages to a message broker servlet. Channels based on Real Time Message Protocol (RTMP) send messages to dedicated TCP/IP ports; the message broker manages sockets listening on these ports.

AMF Gateway

The endpoint for RemoteObject requests is an AMF gateway servlet.

Remoting Service

There isn't a dedicated channel for RemoteObject; requests to the Remoting Service can be made over any channel.
Page 2 of 6
Previous Page
Next Page