2.1. An Overview of BlazeDS
You know by now that BlazeDS helps integrate Flex and Java, but what exactly is BlazeDS? To answer this question, we define BlazeDS using its behavioral and structural characteristics. The behavioral aspects will establish what it's good for, and the structural facets will explain what it's made of.
Behavioral Definition:
BlazeDS enables and facilitates:
Invocation of remote Java methods from a Flex application.
Translation of Java objects returned from a server, in response to the remote method call, to corresponding AS3 objects.
Translation of AS3 objects sent by a Flex application to corresponding Java objects for passing them in as method call arguments.
Communication between a Flash Player instance and a Java server over a TCP/IP-based application-level binary protocol.
Near real-time message passing between a Flex application and a Java server.
Management of the communication channels between Flex and Java.
Management of connection types between Flex and Java.
Provision for adapters for communication with server-side Java artifacts like JMS queues, and persistence layers like Hibernate and JPA. (Some of these are in-built, and some can be obtained from open source projects or can be custom built.)
Pushing data from the server to the client on the server's initiative and not as a response to a request.
Structural Definition:
BlazeDS is a:
Java web application that leverages the Java Servlets specification.
Web application that runs within a Java Servlet container or a Java application server, for example Apache Tomcat, JBoss AS, IBM Websphere or BEA (now Oracle) Weblogic.
Set of services that can be managed using JMX agents.
Remoting and messaging program that can be extended by using its Java API.
Program that intercepts all communication between a Flash Player and a Java server.
Configurable web application that can be clustered and used in cases that desire a higher than normal performance. (The in-built data push mechanism has a few limitations as far as high throughput and high volume goes but there are ways to get around this shortcoming.)
This definition says a lot of things about BlazeDS. If you are a complete newbie, you are possibly overwhelmed by the number of different functions BlazeDS can perform. So, to avoid confusion and make things digestible, I delve next into the role and applicability of BlazeDS within an application.
The first journey into BlazeDS applicability exposition is from the metaphorical aerial height of 30,000 feet.
2.1.1. Viewing Integration from 30,000 feet
From this level, BlazeDS can be viewed as an enabler of two types of interactions between Flex and Java. These are:
Traditional web applications engage in request-response–based communication, where the client (typically the browser and generically identified as the user-agent) makes a request and the server responds to this request. Communication is synchronous, which means that the response comes back in the same cycle as the request. Flex improves on this traditional style of communication and can use this improved style to communicate with a Java server.
Flex facilitates request-response–style communication over asynchronous mode. Read the side note "Think Post Office" to understand the concept of asynchronous communication in Flex through an analogy.
Flex can communicate with a Java server using the asynchronous request-response–style with and without BlazeDS. When communicating without BlazeDS, it's a requirement that the Java server be accessible over a trusted domain. A trusted domain is a domain that defines an appropriate security policy to allow the Flash Player to communicate with the server. The security policy is defined in an XML file, called crossdomain.xml.
When using BlazeDS, the asynchronous request-response communication between a Flex client and a Java server allows for the following:
Requests from Flex clients to server side objects leading to invocation of server side procedures and methods
Return of Java objects marshaled and translated into their AS3 counterparts over the wire
Passing in of AS3 objects, which are marshaled and translated into their Java counterparts, as parameters to the remote Java server procedures
Communication over HTTP using an application-layer binary protocol, called Action Message Format (AMF), that speeds up the data exchange
The second type of interaction between Flex and Java can be over messages, which can be sent by either and received by the other. This facility allows for server initiated data push in addition to the traditional request-response communication.
Think Post OfficeA good way to understand the asynchronous communication in Flex and AIR is to look at the offline communication pattern that unfolds when we post a letter. Say you live in New York at an address that reads as follows: John Doe, 1234 A Famous Avenue, New York, NY 10001, and you wish to send a letter out to your grandmother in San Francisco, California. Her address happens to be: Mother Doe, 4321 Another Famous Avenue, San Francisco, CA 94101. Now you want to make sure that the letter reaches her, so you avail yourself of the "return receipt" facility offered by the postal service. How do you think the letter and the return receipt move through the system? Do you wait at the box where you drop the mail to receive the receipt? Of course not! After you drop the letter in a post box, it gets picked up by the postal service and is put into a sorting queue. From the ZIP code and the address, the postal service figures out that your letter needs to go to a place in San Francisco, CA. So, it's dispatched through some optimal routing mechanism in that direction. Once it reaches CA, it's sorted again so that the correct postal delivery person can hand it over to your grandmother. Because you asked for a return receipt, the postal delivery person also asks your grandmother to sign and confirm the receipt of the letter. Then that return receipt is put back into the postal system. The return receipt has your address, so it moves through the sorting queues and the routing logic back to your place. A different postal delivery person, the one that services your neighborhood and not your grandmother's, puts the return receipt in your mailbox. Finally, your grandmother has the letter and you have the receipt that confirms that she did receive your letter. Wonderful, but what has this letter exchange got to do with Flex? Crudely speaking, the Flex infrastructure works pretty much like the postal system. When you send a request up, locally or remotely, it first returns a token to you and then gets down to invoking your request. It does not wait for the response to come back and does not block any resources. Remember, you don't stand at the drop box to receive the return receipt. When a response returns, the Flex infrastructure reconciles the response to the initiating request, using the token and the responder that is registered against the token. If the response is a success, a "result" event is triggered. A registered responder listens to this event. On "result" event, a listening responder can invoke the appropriate handler and extract the response and apply it as desired. Similarly, if the response is a failure, a "fault" event is triggered. Again the responder listens to this event, and it can handle it in a manner similar to how it handles the "result" event. So, after all, Flex is much like a postal system, only mutated to address the communication needs of distributed objects in the digital age. What do you think? |
Therefore, both the "pull" communication style of requests and responses and the "push" communication style of messages are possible.
Figure 2-1 depicts this 30,000-foot viewpoint in a simple diagram.
Next, we zoom in closer and view BlazeDS from the 10,000-foot level.
Figure 2.1. Figure 2-1
2.1.2. Viewing Integration from 10,000 feet
As we drill into the artifacts on the Flex client side that make the request-response and message-based communication possible, we end up with list that includes the following:
HTTPService
WebService
RemoteObject
MessageService
The first two on this list, HTTPService and WebService, work with and without BlazeDS. BlazeDS and these two components come together when there is a need to proxy calls to a server destination that does not define a security policy as required by the Flash Player. You will learn more about BlazeDS proxy service in the next chapter.
RemoteObject and MessageService, on the other hand, are the primary Flex-side workhorses in the context of BlazeDS. RemoteObject facilitates request-response communication and MessageService enables publish-subscribe based message exchange. RemoteObject acts as a proxy or a stub for server-side services and distributed objects. MessageService provides a handle to a remote messaging destination and a message queue.
Figure 2-2 shows the Flex and Java integration story from the 10,000-foot level.
We continue to zoom further, till we reach the 1,000-foot level. At this level, things are close enough to get a view of some of the details.
2.1.3. Viewing It Closely from 1,000 Feet
You may benefit from looking at Figure 2-3 first. Figure 2-3 attempts to lay out the individual elements involved in the interchange between Flex and Java.
Figure 2.2. Figure 2-2
Figure 2.3. Figure 2-3
At a cursory level, you are familiar with the flow and the involved components from last couple of subsections. We will dig much deeper into these facets in the rest of this book. However, for now I will stop digging and move to the tasks around getting and setting up a BlazeDS instance.
I am firmly in favor of your setting up BlazeDS, understanding the essential configuration, and working out a small preliminary example, before you start diving deeper. Learning by doing can be very effective, and I am keen to help you try that method out when learning BlazeDS using this book.