Question

I’ve been giving a application to work on that uses a Java EE application for the backend, Flash for the front end, and BlazeDS to connect the two. I have never used Flash or BlazeDS, and am trying to get my head around how BlazeDS works.

So far, I understand that when you connect to BlazeDS in FlashBuilder, the remoting-config.xml file is scanned to determine what services exist on the Java end. FlashBuilder asks which of these services you want to import, and what “service package” and “data type package” you want to use.

When you select your Java ExampleService, BlazeDS will create _Super_ExampleService.as and ExampleService.as and put them in your “service package” location. ExampleService.as is empty but extends _Super_ExampleService.as (which basically is a Flash service that you can use to call the methods in your Java service). If you need to add extra methods, you would add them to ExampleService.as. (Hopefully this is all correct, please correct me if I’m wrong)

My problem is I cannot figure out what BlazeDS does for value objects.

When you select ExampleService in FlashBuilder (let’s assume it’s a service for the Example entity), what value objects does BlazeDS create? I would expect Example.as and _SuperExample.as. However, _ExampleEntityMetadata.as also appears.

My questions are basically:

1. How does BlazeDS determine what value objects to create? Does it scan the DB, scan the project for @Entity annotations, scan some config file, scan the service to determine what objects it works with, etc?
2. What purpose does each of the 3 classes serve? It looks like the same setup with the service (change the non-“_Super” one if needed), but there is now that 3rd file.
3. I noticed the value objects do not always correspond directly to the Java entities (has additional properties, missing properties, etc). Why is this?
4. How are the value objects used in conjunction with the services?

I also had some general questions:

1. When you connect to a service in FlashBuilder, what are you actually doing? The first time, I imagine BlazeDS makes the necessary services and value objects. But what if they’re already there (say you already connected, or you pulled down code and connected for the first time)? Does connecting just make the services available in your copy of FlashBuilder?
2. Is it guaranteed that BlazeDS will always generate the services and value objects the same way? Like line for line?

Answer 1

I ended up just buying a Kindle book on Amazon and reading through some of the chapters (specifically, chapter 26). Here is basically what I learned:

• Over the course of time, Adobe products evolved and separated until “LifeCycle Data Services” (LCDS) was established. This technology sits on the server and provides various features.
• Adobe released “BlazeDS” as a free version of LCDS (with fewer features).
• The feature that I am using of BlazeDS is the “Remoting Service” (there is also the “Message Service” and “Proxy Service”). The remoting service allows you to call Java service methods from your Flash front end. Data is passed between Flash and Java via a binary format called “Action Message Format” (AMF).
• SUMMARY BlazeDS sits on the server and allows Flash and Java to communicate via AMF.

In order to be able to call the Java methods in Flash, do the following (note: I assumed default naming):

• Create a normal Java POJO (some restrictions: need a default constructor, methods must be public to be available, etc).
• In remoting-config.xml, add a destination for the service. You’ll notice there is a channel called my-amf. If you look in services-config.xml, you’ll see the corresponding channel definition and that it uses AMF and points to your running application (using dynamic expressions).
• When configuring the Flash Builder project, you provide the location of your web application so it knows where it’s suppose to send requests to.
• SUMMARY You allow Java communications by creating your Java service, configuring it in remoting-config.xml, and letting your Flash project know your webapp location (so it can know where to find the Java objects).

At this point, you can call your services manually in MXML or ActionScript, like below (assume we have an ExampleService in Java mapped as exampleService in remoting-config.xml).

//MXML
<s:RemoteObject id="myExampleService" destination="exampleService" />
<s:Button label="Call a Method" click="myExampleService.myMethod()" />

//ActionScript
var myExampleService:RemoteObject = new RemoteObject("exampleService");
myExampelService.myMethod();

*Note: There is much more to learn about the above (and similar things), like handling results, etc. But I won’t get into that.

Now, to connect to pass data between Flash and Java, it becomes serialized. The conversion from Flash types to Java types is not perfect. For example, a Flash Array turns into a Java List/Map. And a Java List/Map turns into a Flash ArrayCollection/Object. Because of this, you can use a “value object” design pattern. Basically, you create a Flash object that mirrors a Java object that your services deal with. So if you had an Example Java class, you would create maybe a ExampleVO Flash class. You’d need to annotate the Flash class with [RemoveClass(alias="my.package.Example")], etc.

To make life easier however, you can automatically generate these files. BlazeDS communicates with Flash Builder via “Remote Development Service” (RDS) protocol. In your web.xml file, you can enable a RDSDispatchServlet. Once RDS is enabled, you can make data connections in Flash Builder (Data > Connect to BlazeDS).

And, as an answer to the question, the book states:

By default, if a Java class's public method returns an instance of a strongly
typed value object class, the connection wizard creates a matching ActionScript
value object class. The conversion of the server-side data to ActionScript value
object happens at runtime and is managed by the generated code.