9.1. Contextual Overview

To understand the extension point architecture, it is best to review the BlazeDS server-side architecture first. That way, the overall context and environment of the adapters is well understood. You are familiar with the BlazeDS server-side architecture from the last few chapters. Here, I only rapidly recap the key aspects of that architecture.

BlazeDS is a Java web application. It receives requests and messages from a Flex application via its Java Servlets–based endpoint. An endpoint is accessible via a URL. Each endpoint supports communication with a particular channel type, which represents the client side of Flex application. A particular channel is distinguished by the protocol and data exchange format it supports. For example, a channel-endpoint pair could support binary transmission over AMF or text-based exchange using AMFX. Also, a channel-endpoint pair could support pure request-response communication, exchange of messages, or request polling. Once a request or message arrives via an endpoint, it is intercepted and handled by the message broker, which is the central coordinator of all communications in BlazeDS. The message broker routes requests and messages to services and destinations. A service and destination pair acts as the server-side target for a message from a Flex client. For example, a RemotingService is the target of a message from a Flex RemoteObject. Associated with this RemotingService is a configured RemotingDestination. The service and destination pair abstracts a server-side entity, say a POJO, and provides a handle to such a POJO so that a Flex client can invoke methods on it. The last element in the communication chain between the destination and the server-side entity is an adapter. The adapter is the final infrastructure element within BlazeDS that serves a request and acts as the translator between the service and the server-side entity. Figure 9-1 illustrates this.

Figure 9.1. Figure 9-1

From a configuration and usage standpoint, an adapter, built-in or custom, is configured in services-config.xml and is used with one of the services and destinations. The adapter is wired to a destination in one of the configuration files that pertains to proxy service, remoting, or message service. The configuration files for proxy service, remoting, and message service are proxy-config.xml, remoting-config.xml, and messaging-config.xml, respectively. In BlazeDS, these three configuration files are included in services-config.xml.

A configured adapter's lifecycle is managed by BlazeDS. BlazeDS instantiates and initializes an adapter instance and allows you to expose it as a JMX resource. Built-in adapters are, by default, wired as JMX managed resources. Adapters are instantiated and configured during the MessageBrokerServlet bootstrapping process.

Figure 9-2 depicts how an adapter is used and wired up in a BlazeDS instance.

Figure 9.2. Figure 9-2

Now that you have a sense of where and how an adapter is used in a BlazeDS instance, you can progress to learning more about the BlazeDS API. You will use the API to create your own custom adapter.