We monitor a variety of forums, lists, blogs, etc., and sometimes we see a really brilliant answer that causes us to say “I wish we’d said that in the docs!” With that thought in mind, here is the first of a series of “Wish I’d Said That…” postings and it comes from Adobe Engineer Kevin Hoyt in response to a question about MySQL connectivity to Flex. However, Kevin goes way beyond that and offers a great overview of data access in Flex, along with considerations for choosing one over the other.
So, without further ado, ladies and gentlement, Kevin Hoyt!
Question: What is the most direct connection to MySQL with FDS and Flex where queries can be made against the DB?
This is a pretty broad question as there are a number of ways to connect to data from a Flex application. Generally speaking however, Flex applications are services-centric (SOA) and in that respect always require some degree of middleware to access a database. The most common means of connecting to data are:
In these scenarios the customer might have a middleware resource such as a JSP page or servlet that gets a GET/POST request from a Flex application (HTTPService class). That server resource would then access the database using whatever means are traditional to that middleware – JDBC in the case of Java. The results of data access can then be formatted into XML (where one might more traditionally format the results in an HTML table) and returned as the response to the initial request. Flex/Flash Player have excellent XML handling capabilities and can then manipulate the data for display in the application UI.
The great thing about this approach is that it acts as a lowest common denominator. I’ve mentioned a Java-centric approach here, but this could easily be implemented using any number of technologies. Essentially anything that can get an HTTP request and return XML as the response.
This is really just a more formalized/standardized version of the XML-RPC approach. Rather than accessing a JSP specifically, a Flex application can access a web service endpoint. Per a specification, that service knows the format in which the data was sent, and how to format a response. Most middleware technologies these days support exposing logic/objects as web services. In this case, virtually any of these services can be consumed by a Flex application (WebService class).
The great thing about web services is that since they follow a standard, the application doesn’t have to know about the infrastructure details. This is especially great for B2B composite applications where there needs to be (or already exists) a high degree of abstraction. There is a trade-off however over XML-RPC in that SOAP is often very verbose and heavy across the wire, which can also mean more client-side memory requirements and processing/parsing time.
Within the context of FDS, we figure that rather than rework your business logic as XML or SOAP (which is ultimately XML itself), why not just access the business logic directly? This saves developers time in having to write potentially tedious code to expose existing logic as XML. In the case of a Java application server, a Flex application can access a Java object directly by remote invocation of a method on a designated object (RemoteObject class). That object on the server can then deal with it’s native data types as arguments, query a database from those arguments, and return it’s native data types as a value (i.e. return a List of Contact objects).
Above and beyond this ease of use, is the speed with which this communication happens across the wire. Data exchanges still happen over HTTP/S but the data itself is serialized into a binary representation. This ultimately means less data needs to go across the wire, that data requires less client memory, and there’s less processing time for the data.
There’s comes a point in RIA development (or client/server if that’s your customer’s background) that more complexity is introduced on the client. After all, with Flex, we now have a client that can work on data quite independent of a server after the initial request(s). How are we to be sure that the data that has changed on one client hasn’t been changed somewhere else (on another client)? Writing RPC-oriented code (the three aforementioned examples) this can get really tricky to deal with on a per application basis. The data management features of FDS abstract all this from the developer. You can literally write a client application that handles real-time synchronization across connected clients in just a few lines of code.
This description doesn’t do justice at all to the other great features that FDS can provide developers. Implicit paging through large datasets is another common use-case.
Internally the data management scenario looks very similar to the remoting option save that there’s an additional layer called an “assembler” that acts as the touchpoint between the Flex client application, the FDS installation on the server, and the server resources that are accessing data. At a low level however it is common that developers have their objects leverage JDBC to access various types of database systems to include MySQL.
To the point of getting updates from the database to the client – the first question to ask is what is making the update to the database? Would this be another Flex application? If so, then this would fall squarely under common FDS data management features. In short, you’d get this type of cross-client update through push (or polling) automatically as a feature. If there’s another (external) process that’s updating the database, then you’ll want to leverage the capability of FDS to tie into JMS for client notification. At a high level, the process can make a change to the database and then drop a message on the queue stating that something has changed. That message will be propogated (via push most commonly) to all the clients. The clients can then take whatever action they need to update their copy of the data.