BlazeDS, LCDS and Flex-Java Interaction

Question: What is BlazeDS?
Answer: In very simple terms, BlazeDS is a open source java web-application that is helpful in integration of Flex (and AIR) with Java Server Environment. It leverages the Java Servlet specification and can run within a Java Servlet container or a Java Application server (for example Tomcat, JBoss, Weblogic etc). It provides remoting and messaging facilities and is very configurable (can be clustered and gives decent performance).

Question: What are the differences between BlazeDS and LCDS?
Answer: LCDS stands for Live Cycle Data Services. BlazeDS and LCDS are different in following ways:
1. BlazeDS is 100% Java and can run just about anywhere. But LCDS has some native code.
2. BlazeDS is open source and completely free whereas LCDS has good support and a hefty price tag.
3. BlazeDS has scaling limitations (especially when using messaging) but LCDS is highly scalable.
4. When using remoting it is faster in LCDS  because it uses nio (new input output) end point where as BlazeDS uses servlet based endpoints. More

Question: What are end points and channels?

Answer: A ‘channel’ is the term used for the client-side code to manage the connection, and the ‘endpoint’ is the term used for the server-side code or configuration that manages the connection. So for a Flex client to communicate with LCDS (or BlazeDS), a channel must be defined for the client side to communicate with the endpoint on the server-side.

http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcconfig_2.html

Question: How can we specify channels on client side and server side?

Answer: Well,  on the server side we have a file services-config.xml which has a mapping of channels (client side) and endpoint (server side). The client does not specify the endpoint class, but whenever client makes any remoting (or other RPC) request it has an associated channel to be used. Also keep in mind that the channel also specified the end point URL. There are many ways, one such way is:

<RemoteObject id="ro" destination="Dest">

    <mx:channelSet>

        <mx:ChannelSet>

            <mx:channels>

                <mx:AMFChannel id="myAmf"

                    uri="http://myserver:2000/myapp/messagebroker/amf"/>

            </mx:channels>

        </mx:ChannelSet>

    </mx:channelSet>

</RemoteObject>

On the server side we must have a channel definition in the services-config.xml file that specifies the endpoint class to use with the specified endpoint URL.

<!-- Simple AMF -->

<channel-definition id="myAmf"

    type="mx.messaging.channels.AMFChannel">

    <endpoint url="http://{server.name}:8400/myapp/messagebroker/amf"

        type="flex.messaging.endpoints.AmfEndpoint"/>

</channel-definition>

<!-- Simple secure AMF -->

<channel-definition id="my-secure-amf"

    class="mx.messaging.channels.SecureAMFChannel">

    <endpoint url="https://{server.name}:9100/dev/messagebroker/

        amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>

</channel-definition>

<!-- Simple HTTP -->

<channel-definition id="my-http"

    class="mx.messaging.channels.HTTPChannel">

    <endpoint url="http://{server.name}:8400/dev/messagebroker/http"

        class="flex.messaging.endpoints.HTTPEndpoint"/>

</channel-definition>

<!-- Simple secure HTTP -->

<channel-definition id="my-secure-http" class="mx.messaging.channels.SecureHTTPChannel">

    <endpoint url=

        "https://{server.name}:9100/dev/messagebroker/

            httpsecure"

        class="flex.messaging.endpoints.SecureHTTPEndpoint"/>

</channel-definition>

The MessageBrokerServlet assists in all that mapping of channel to endpoint, moving to proper adapter, executing service and then sending result back to client.


Question: What is that nio vs servlet end point all about?Answer: BlazeDS uses servlet-based end point where as LCDS uses servlet-based as well as nio enpoints.The J2EE servlet container manages networking, IO, and HTTP session maintenance for the servlet-based endpoints. NIO-based endpoints are outside the servlet container and run inside an NIO-based socket server. NIO-based endpoints can offer significant scalability gains. Because they are NIO-based, they are not limited to one thread per connection. Far fewer threads can efficiently handle high numbers of connections and IO operations.
http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcconfig_2.html

Question: What is lazy loading and how does it help in improving performance?

Answer: Lazy Loading is available in LCDS and not BlazeDS. In simple terms if we have 100000 rows in result set then we can specify to load 1000 rows at one time. When user scrolls past those 1000 rows the new set of 1000 rows will be loaded. More will be added to this question soon. 

Question: Can Flex and Java interact without BlazeDS/LCDS?
Answer: Flex is used to write AS (ActionScript) and MXML code which is finally complied to get SWF (executable in Flash environment) file. When user makes a request this SWF is loaded into client machine. Afterwards this is more of a request-response model.We need to use BlazeDS or LCDS services if our application uses AMF based method to communicate with Java i.e. RemoteObject etc else they are not needed. More.

Question: What are the main services provided by LCDS?
Answer: Main services provided by LCDS are remoting, HTTP/Web Service (Yes you can also connect to Webservice directly from Flex using import/export wizard in FB), messaging and Data Management. Out of them Data Management is not available in BlazeDS and also remaining services use NIO for LCDS and BlazeDS has servlet-based endpoint. And as with any servlet, every request blocks one thread on server side and even messaging is not highly scalable in blazeDS.0
http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcconfig_5.html
http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=lcconfig_5.html

Question: What are the main services provided by BlazeDS?
Answer: It provides remoting, messaging and HTTP/Web service. Check the following:
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=lcconfig_2.html
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=lcconfig_2.html

Question: Does BlazeDS/LCDS use asynchronous request-response style?
Answer: Yes, rather Flex can communicate with a Java server using the asynchronous request-response-style with and without BlazeDS.

Question: How the interaction between Flex and Java happens?
Answer: 

[Image is taken from: http://www.ibm.com/developerworks/java/library/wa-flex4javaapps/index.html?ca=drs-]
Check the following posts for better understanding of Flex-java interaction:
http://www.ibm.com/developerworks/java/library/wa-flex4javaapps/index.html?ca=drs-
http://tamanmohamed.blogspot.com/2011/05/enterprise-java-flex-applications.html

Question: How remoting works?
Answer: We have some good places already on net:
http://www.brucephillips.name/blog/index.cfm/2008/6/22/Using-Flex-BlazeDS-and-Java-Together--A-Simple-Tutorial
http://rectius.com.br/blog/?p=886

Question: What servlet works at the heart of BlazeDS? And what exactly is performed by this servlet?
Answer: MessageBroker Servlet

Question: BlazeDS Spring integration.
Answer: The following are really helpful:
http://java.dzone.com/articles/spring-blazeds-integration


Question: We know Blazeds is servlet-based and it interacts with Flex/Air application using various services (remoting etc). and using endpoints and channels etc. How exactly can we define the architecture of blazeds?
Answer: When we want to create a flex application using BlazeDS, we need to make some changes on client side (flex application) as well. It includes defining channels, remote object components etc. On the server side we have the complete blazeds with supporting libraries and some configuration files (e.g services-config etc). So we can divide the architecture of a blazeds application in two parts: client side and server side.

A flex component uses channel to communicate to the server. All the communication between the client and server happens via messaging. Even remoting uses messaging internally. All the messages have client and server side implementations (for value objects etc) as these messages are serialized and de-serialized on both  sides.We can also create messages directly on server side and then can push them to client side, one example will be covering that later.
BlazeDS uses two patterns for sending and receiving messages: the request/reply pattern and the publish/subscribe pattern. RemoteObject, HTTPService, and WebService components use the request/reply message pattern, in which the Flex component makes a request and receives a reply to that request. Producer and Consumer components use the publish/subscribe message pattern. In this pattern, the Producer publishes a message to a destination defined on the BlazeDS server. All Consumers subscribed to that destination receive the message.

On the server side is the real magic. We have end points corresponding to channels on client side. We have the heart of blazeds MessageBroker servlet, we have adapter and much more.

As we discussed earlier, flex client makes request over a channel, and then the request is routed to the respective end point on blazeds server. From the endpoint the request is routed to message broker object, 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 JMS server.

Question: What adapters are used by remoting, messaging and HTTPProxy destination generally?
Answer: BlazeDS uses the following mappings:

• RemotingDestination uses JavaAdapter
• HTTPProxyDestination uses HTTPProxyAdapter or SOAPAdapter
• MessageDestination uses ActionScriptAdapter or JMSAdapter

We can also define our custom adapters and assemblers can also be plugged into the blazeds server.Also we can create all the destinations in configuration files or can also define them at runtime.


More questions coming soon.....keep visiting.