Saturday, July 14, 2012

What the hell is that channel and endpoints crap in BlazeDS/LCDS?

Well. this post is a simple explanation about channels and endpoints and what they exactly do. I will not go into all that geeky stuff. In the simplest terms, a channel is a client side object that is needed to talk to server. A channel basically contains (better say encapsulates) the connection behavior and other important properties that are needed to interact with server. An endpoint is corresponding server side code needed for the channel. A channel gets connected to specific endpoint exposed by the server. A channel of type A cannot connect to endpoint of type B, it has to connect to type A only.


<channels>
...
<channel-definition id="samples-amf"
        type="mx.messaging.channels.AMFChannel">
        <endpoint url="http://servername:8400/myapp/messagebroker/amf"
            type="flex.messaging.endpoints.AMFEndpoint"/>
</channel-definition>
</channels>


The mapping between channels and endpoints is defined in services-config.xml file situated on server. An example is shown above. We can define multiple channels (channelset) and if one is not available client will fall back to the next in the list.


How channels are assigned to Flex component?
When we compile our application with compiler -service option,  it contains all of the information from the configuration files that is needed for the client to connect to the server. Sometimes developers use this option with Flash builder and think they do not need any channel for their remote object as they are not specifying one. But actually in this case the whole work of mapping and assigning is done internally by Flex.


Otherwise we can create channel manually. It happens generally in the following scenarios:

  • We do not compile our MXML file using the -services MXML compiler option. This is useful when we do not want to hard code endpoint URLs into our compiled SWF files on the client.
  • We want to use a dynamically created destination (the destination is not in the services-config.xml file) with the run-time configuration feature. 
  • We want to control in our client code the order of channels that a Flex component uses to connect to the server.

We can assign the channel to a remote object in MXML and action script. And we all know that. We can read more about it here.

Now we have two main kinds of channels: AMF and HTTP. Actually HTTP channel is by no means connected to HTTP protocol. Even AMF uses HTTP protocol only over TCP.  They both use same http protocol. The main difference is the data transferred over AMF would be binary whereas for HTTP channel it would be in XML format(AMFX format, which is the text-based XML representation of AMF)This channel only exists for customers who require all data sent over the wire to be non-binary for auditing purposes. There is no other reason to use this channel instead of the AMFChannel for RPC-based applications.

There are mainly following type of channels.

Non-polling AMF and HTTP channels

Used for RPC services.

Piggybacking on AMF and HTTP channels
In piggybacking server is not completely dependent on polling of the client at fixed interval. Rather when it receives a non-command message (using a producer ore remote object) , it (server) will send any pending data for client messaging or data management subscriptions along with the response to the client message.

Polling AMF and HTTP channels
Poll the server at fixed interval and get data if any.A polling AMF or HTTP channel is useful when other options such as long polling or streaming channels are not acceptable and also as a fallback channel when a first choice, such as a streaming channel, is unavailable at run time.

Long polling AMF and HTTP channels
It is like polling, but here if client polls a server and does not find any data it won;t come back immediately. Rtaher the request will be parked on the server for some pre-defined time and will come back if data comes or wait time elapses. If wait time is too long it will keep the server thread (blazeds is servlet based and every client uses one thread for it) blocked for long and when all the available server thread are blocked the new clients won't be able to connect. This is primarily a restriction with server, if a server can have 1000 free thread blazeds can support 100 parallel clients.

Streaming channels
Streaming AMF and HTTP channels work with streaming AMF or HTTP endpoints.

This is a brief introduction and more can be read about them here




No comments: