QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Tag Archives: BlazeDS

My Presentations at Adobe MAX 2011

This year I had the distinct honor of being asked to present at Adobe’s MAX conference.  The conference was an absolute blast.  From the Keynotes to ALL the other sessions I attended, the thing went off without a hitch.

I gave two presentations this year — one for the 360|MAX Unconference and one for the Develop Track at MAX. 

Getting Data From Here To There (with Flex)

This session was not recorded, but fairly well attended.  You can see my slides here.   In this session I talked about the different communications methods available to Flex developers, and I started to lay out a basic matrix of when to use what type of communication method, and what the pros and cons were of each type.  Not all of my demos worked due to a broken J2EE server, but I think everybody got the idea.  I don’t have great downloads for that presentation as most were specific to my server setups.

Getting Physical With Flash (Hardware Hacking)

This session was a blast to present.  We had about 140 people in the room who seemed to be really into it.  I presented on integrating the Arduino hardware prototyping kit into Flash/Flex in addition to showing how to integrate the Microsoft Kinect into Flash/Flex. I came armed with about 6 electronics projects that I showed people to inspire them to create their own.

Video Player - MAX 2011 Preso

You can download the PPT here.

You can find most of the downloads featured on my blog, but I will update this post and post the direct links to everything at a later date.

Thanks again to the entire MAX staff for making the show run so smoothly from both the speaker’s perspective and from the attendee’s perspective.  A+ work led to an A+ experience :)

Connecting your Flex application to BlazeDS or LiveCycle DS

If you have ever attended one of my presentations on BlazeDS, LiveCycle DS, or Flex/ColdFusion, you have heard me talk about how bad the data-connectivity wizards are in ALL of the IDEs available for the Flex SDK.  Even the new Flash Builder 4.5 dosen’t address the white-hot mess they call the data connectivity wizards that they started including in 4.0 (Side note:  I love most of the features in Flash Builder — I use it every day, but some of the wizards they included to make life easier really don’t).

Even including the services-config.xml document as a configuration option in your application will often lead you to troubles in the long-run.  This is included for you when you tell Flash Builder that you want to use ColdFusion or Java as your server model.  When you do this, the compiler inspects your services-config.xml configuration document on your server, and builds a table of the channels (endpoints) and destinations that are configured on the server.  You can then call the destination by name in theortags and not have to worry about how your client actually connects back to the server…

… untill you need to move your application…

… or you need connect your AIR application to your server…

… or you have a mobile or television application that needs resources on your server…

… or your server’s configuration changes.

Read more of this post

Destination properties available at runtime

In my last blog post I mentioned that there were various properties available when you create your own BlazeDS / LiveCycle DS destination at runtime.  The properties available to you are based on which type of adapter you are using.

Each set of properties is baked into a ConfigMap instance that you pass to the initialize() method of the adapter.  In my research, I’ve found that there are some adapters that fire up ok without any properties defined (these tend to be the open-source ones), and some which cause all sorts of issues unless you have certain magical properties defined (these tend to be the closed-source ones).

In addition to the regular properties, there are also “ServerSettings” and “NetworkProperties”, which are not covered here.  By not setting those properties, your destination will assume the defaults.

So, what are the available properties that you can set?  Below is a list of the service/adapter/properties:

  • remoting-service    (used for Flash Remoting, Remote Object connections, and “AMF” connections)
    • ColdFusionAdapter “cf-object”   (used to connect AMF messages to CFCs)
      • access  (as ConfigMap)
        • use-mappings    (true/false) ***
        • method-access-level   (“public”/”remote”) ***
      • property-case  (as ConfigMap)
        • force-cfc-lowercase   (true/false)
        • force-query-lowercase  (true/false)
      • use-accessors (true/false)
      • use-structs (true/false)
    • Java Adapter “java-object”   (used to connect AMF messages to Java classes)
      • include-methods (if defined, this is the list of methods that are allowed to be called)
      • exclude-methods (a list of methods that are blocked from being called. do not use with include-methods)
      • method
      • name
  • messaging-service   (used for realtime messaging applications)
    • cfgateway  (used to have ColdFusion mediate messages on the destination)
      • gatewayid  (the dot-location to the cfc that will handle the message) ***
      • gatewayhost  (used to define which host is hosting the cfcs, if it is not localhost — for example if your BlazeDS server is different from your CF server)
      • allowedIPs (which servers are allowed send data onto the destination back to the clients)
      • remote-username  (bakes in this username into all the packets sent to CF)
      • remote-password  (bakes in this password into all the packets sent to CF)
    • actionscript
      • (there are no properties for ActionScript.  Send in an empty ConfigMap)
    • jms
      • jms (as ConfigMap)
        • destination-type
        • message-type
        • connection-factory
        • destination-jndi-name
        • delivery-mode
        • message-priority
        • preserve-jms-headers
        • acknowledge-mode
        • max-producers

There are also services for proxying and data-management, however I’ve never used them (well, I have used data-management a lot, but since the licensing changes to LCDS, it’s pretty much dead to me).  I don’t know much about the jms adapter, so I can’t really say what all the properties mean, but I do know they are there. 

I have marked some properties with a ***.  If you see that, you need to include it, or you will get varied results in creating the destination at runtime (most likely, it will fail the first time you send data to it, rather when you create it).

Creating runtime remoting destinations in BlazeDS and LiveCycle Data Services

Ok, lets dive right into a really geeky topic… destinations in BlazeDS and LiveCycle Data Services.

For one of my customers, I was given the requirement to create a runtime destination in BlazeDS.  BlazeDS, along with its bigger brother LiveCycle allow you to create destinations in one of two ways — via the configuration XML files (services-config.xml, and related files), or via Java calls.  I won’t talk about the XML file method because it is extremely well documented.  However, the biggest disadvantage of the XML file method of creating destinations is that you usually have to reload or reboot your server in order for the changes to take affect. 

Runtime Destinations are not permanent — they do not persist during restarts.  They are also not magically added to the XML documents either.  Their creation is also often blocked on shared hosting servers as well.  But besides that, they act and smell just like ones created by the XML documents.  Why would you want to use them?   There are quite a few reasons for wanting them — for example to help secure your server by only exposing your destinations on demand, or by providing private destinations to clients so there is no way that data can be shared (in that case you COULD use subtopics, but that is controlled by the client).  In my case I was asked to provide a solution where the client would not have to change any configuration files when they installed our application.  We were using ColdFusion 9 as our back-end server, but these techniques work for Java based solutions too (you would just have to change the Syntax a bit).

I’ll start off by saying that the documentation is extremely poor (I wish Adobe would make this stuff clearer one day!), but with the help of two people, Sven Ramuschkat and Marko Simic, I was able to get to the point where reading the source code made sense.

The first step in creating the dynamic destination was getting the instance of the Message Broker.  The Message Broker in BlazeDS/LCDS is the guy who does all the work for remoting, messaging, data services and proxying.  You can access it in ColdFusion with the following commands

this.blazeDSClass = createObject("java", "flex.messaging.MessageBroker");
this.blazeDS = this.blazeDSClass.getMessageBroker(javacast("null", ""));

Read more of this post

Flash Builder Client-Side Data Management vs. LCDS

One question I am asked fairly regularly is this : “Now that Flash Builder will include what they call Client-Side Data Management, why would anybody need Adobe’s LiveCycle Data Services?” 

Until this latest version of Flash/Flex Builder and Flex, there was a very clear distinction for when you needed LiveCycle Data Services and when you could simply use BlazeDS.  If you wanted seemless interactions between your database and your client, you by default went to LCDS.  If all you cared about was sharing data between clients, then you could get away with BlazeDS.

With the upcoming version of Flash Builder there is a new set of wizards called the DCD or the Client-Side Data Management Wizards.  These wizards will emulate a lot of the functions and features that were previously only available to LCDS users.  Things like having changes to an ArrayCollection (via a DataGrid) auto-commit to the database are now available, as well as data pagination and some other time-saving features.  All of this work is done on the client-side with little work on the server.

You don’t get all the features of LCDS, however.  LCDS’s Data-Management features allow you to have the concept of ‘managed’ data on the server.  This means that you have a middle-ware application that stores a copy of your data in RAM and keeps track of which clients are accessing which parts of that data.  The concept allows you to do things like real-time conflict-resolution (client-side only supports last-in-wins) where both clients are notified if the data is changed in any connected client.  It also allows for real-time data updates — for example, if you have client-A update their data, client-B who is also viewing that data is instantly notified that their view is old and updated with the changed set.  This is immensely critical where you have data that is viewed and possibly updated in realtime by multiple people — and it is only available in LCDS.  LCDS also allows you to do lazy-loading out of the box, which is not available in the client-side version.

Adobe’s LiveCycle DS 3 also introduced the “Data Modeling” workflow in this past release.  This plugin to the Eclipse framework allows users to model their database (or pull in an existing database and have it modeled for them) and make changes to that database, regardless of what database server is in the backend.  This is using UML-like diagramming, and is extremely powerful.  LCDS Data Modeling View can then take that UML model and auto-create forms (with validation), data views, etc. with a few clicks of the mouse.  With this model, no server-side coding is required at all.

Flash Builder’s Client-Side Data Management emulates the form-building aspect of this, however it is not nearly as automated or point-and-click.  It will write some stub classes for you, and set you up with the basics, but things like validation have to be written by hand.  Furthermore, you have to customize your back-end server coding to match how DCD expects your classes/cfcs to work. 

Pretty much, to sum it up, if you need you plan on having your clients view and edit the same piece of data at the same time, you may still want to consider LCDS.  If you don’t want to write any back-end code, LCDS is also worth looking at as well.  Otherwise, see what Client-Side Data Management can do for you.  But remember, Adobe no longer offers their Community Edition / 1 CPU edition / Free Edition / Office Edition, so LCDS has become quite costly to get into.  I wish that wasn’t the case :(

Follow

Get every new post delivered to your Inbox.

Join 28 other followers