We have been consulting/training on LCDS for some time now there is a common need for an overview from a working perspective which helps decide whether to go with it or not.
This article is one such effort to shed some light on how it all works
LCDS is a Java web project which enables Flex/AIR clients to invoke Java methods, concurrently update clients, and supports proxy. It mainly contains 2 things
- A webserver
- A socket – server
So why is LCDS required?
One of the reasons for which it (and BlazeDS) are widely used is: Clients like Flex/Flash/AIR can publish data in an AMF format. AMF is a binary protocol and hence the footprint of data is lighter so it travels much faster over the network.
Java does not have native support to understand AMF (which is an Open Spec. protocol). LCDS contains a suite of Java classes which deserializes AMF data and passes it to Java as a Java data type.
It primarily has 4 types of services:
- (HTTP)Proxy Service
- Remoting Service
- Messaging Service
- Data Management Service
All these services are supported by protocols. A protocol defines how data is passed to the Java layer.
3 key protocols supported are are:
- HTTP
- AMF
- RTMP
You can also use variants like AMFX (non – binary XML version of AMF). These protocols are used to pass message objects via a Channel. A message object is the entity that Flex want’s to send across
There are various channels that support these protocols
AMF, Secure AMF, HTTP, RTMP, Secure RTMP, NIO – AMF, NIO RTMP and others.
You can select a channel depending on the type of communication you want to establish.
Each of these Channels are associated with end points. So a message objects travels over a channel and hits an end point on the LCDS server. Making an endpoint unique for a channel
There are 2 types on end-points:
- Serverlet based end point (typically the MessageBroker Servlet) – Uses a webserver
- Socket based end point – these are more scalable (NIO/RTMP) – Uses a socket server
Once a message has hit the end point, It starts its journey inside the LCDS server. Here it goes through a series of layers starting from
- The MessageBroker -Here is where authentication takes place, and the service is identified for the message
- The Service is identified and one of these HTTPProxyService/RemotingService/DataService/MessagingService is invoked Depending on the destination of the message.
- This destination is set by Flex in the message when it serializes it. The association between Flex and your Java Service is mapped using a destination.
Flex – LCDS Destination – Java
- Finally the Adapter kicks in. This is the entity responsible of invoking the Java class and passing data. This Adapter depends on the service that you use
- Typically for a DataService (read Data Management Service) there is another layer of Assembler which could be either a standard from LCDS or custom created depending on the back-end or the data tier.
LCDS has in built assemblers for Hibernate and others.
The entire flow can be summarized as:
Flex LCDS Communication
That, in a nutshell, speaks about LCDS. Most things also apply for BlazeDS. If you have queries/suggestions/comments. Please feel free to put them in the comments section.
Y