BlazeDS server architecture
BlazeDS server architecture
The BlazeDS server is contained in a J2EE web application. A Flex client makes a request over a channel and the request is routed to an endpoint on the BlazeDS server. From the endpoint, the request is routed through a chain of Java objects that includes the MessageBroker object, a service object, a destination object, and finally an adapter object. The adapter fulfills the request either locally, or by contacting a backend system or a remote server such as Java Message Service (JMS) server.
The following illustration shows the BlazeDS server architecture:
Endpoints
BlazeDS servlet-based endpoints are inside the J2EE servlet container, which means that the servlet handles the I/O and HTTP sessions for the endpoints. Servlet-based endpoints are bootstrapped by the MessageBrokerServlet, which is configured in the web.xml file of the web application. In addition to the MessageBrokerServlet, an HTTP session listener is registered with the J2EE server in the web application's web.xml file so that BlazeDS has HTTP session attribute and binding listener support.
BlazeDSFlex client applications use channels to communicate with BlazeDS endpoints. There is a mapping between the channels on the client and the endpoints on the server. It is important that the channel and the endpoint use the same message format. A channel that uses the AMF message format, such as the AMFChannel, must be paired with an endpoint that also uses the AMF message format, such as the AMFEndpoint. A channel that uses the AMFX message format such as the HTTPChannel cannot be paired with an endpoint that uses the AMF message format. Also, a channel that uses streaming must be paired with an endpoint that uses streaming.
You configure endpoints in the services-config.xml file in the WEB-INF/flex directory of your BlazeDS web application. For more information about endpoints, see Channels and endpoints .
MessageBroker
The MessageBroker is responsible for routing messages to services and is at the core of BlazeDS on the server. After an endpoint initially processes the request, it extracts the message from the request and passes it to the MessageBroker. The MessageBroker inspects the message's destination and passes the message to its intended service. If the destination is protected by a security constraint, the MessageBroker runs the authentication and authorization checks before passing the message along (see Configuring security ). You configure the MessageBroker in the services-config.xml file in he WEB-INF/flex directory of your BlazeDS web application.
Services and destinations
Services and destinations are the next links in the message processing chain in the BlazeDS server. The system includes four services and their corresponding destinationsBlazeDS:
- RemotingService and RemotingDestination
- HTPProxyService and HTTPProxyDestination
- MessageService and MessageDestination
Services are the targets of messages from client-side Flex components. Think of destinations as instances of a service configured in a certain way. For example, a RemoteObject component is used on the Flex client to communicate with the RemotingService. In the RemoteObject component, you must specify a destination id property that refers to a remoting destination with certain properties, such as the class you want to invoke methods on. The mapping between client-side Flex components and BlazeDS services is as follows:
- HTTPService and WebService communicate with HTTPProxyService/HTTPProxyDestination
- RemoteObject communicates with RemotingService/RemotingDestination
- Producer and Consumer communicate with MessageService/MessageDestination
You can configure services and their destinations in the services-config.xml file, but it is best practice to put them in separate files as follows:
- RemotingService configured in the remoting-config.xml file
- HTTPProxyService configured in the proxy-config.xml file
- MessageService configured in the messaging-config.xml file
For more information on RPC services (HTTPProxy Service and RemotingService) and MessageService, see the following topics:
Adapters and assemblers
Adapters, and optionally assemblers, are the last link in the message processing chain. When a message arrives at the correct destination, it is passed to an adapter that fulfills the request either locally or by contacting a backend system or a remote server such as a JMS server. BlazeDS uses the following mappings between destinations and adapters/assemblers:
- RemotingDestination uses JavaAdapter
- HTTPProxyDestination uses HTTPProxyAdapter or SOAPAdapter
- MessageDestination uses ActionScriptAdapter or JMSAdapter
Adapters and assemblers are configured along with their corresponding destinations in the same configuration files.
Although the BlazeDS server comes with a rich set of adapters and assemblers to communicate with different systems, custom adapters and assemblers can be plugged into the BlazeDS server. Similarly, you do not have to create all destinations in configuration files, but instead you can create them dynamically at server startup or when the server is running; for more information, see Run-time configuration .
For information about the BlazeDS server-side classes, see the Javadoc API documentation.