Mihai has posted 2 posts at DZone. View Full User Profile

The Architecture of Flex and PHP Applications

06.01.2010
| 41020 views |
  • submit to reddit

I've been working with web related technologies since the late '90s, and my first server side technology was PHP. Later on, I did ColdFusion and Java development, but I always considered myself a PHP developer. When AJAX came along, I started working with frameworks like Prototype and script.aculo.us, and I began building my own frameworks.

At the end of 2006, I had my first taste of Flex development. It was kind of a crash course, because I had about 4-6 weeks to create a demo application for the upcoming version of FDS (Flex Data Services, now called LiveCycle Data Services). Although I was new to Flex and FDS, the project went well, and I really enjoyed the development and learning process.

However, enjoyable as it was, it was different. I mean that when I did ColdFusion or Java web development, it didn't feel different compared to PHP; it was more a question of finding the right APIs and getting acclimated with the specifics of the language. Later on, when I started doing AJAX on top of DHTML, it wasn't that different either. You still create most of the website using the same techniques with the help of a server-side language, and you just throw in some spices here and there (in this case, some AJAX widgets).

When I did my first web project using Flex, boy oh boy, it was quite a switch! The clean separation between the client and the server, (the business logic on the client side in addition to business logic on the server side), client-side technology that is compiled instead of interpreted, two languages on the client, all these required a different mind-set from traditional web development.

And this is my reason for writing this article. I want to share with you some of the things that are specific to Flex in relation to PHP. And I want to show you how common tasks for building HTML/PHP applications are done with Flex and PHP.

 

Client/server architecture

If you want to categorize Flex applications, you can say that Flex applications follow SOA architecture model, where Flex is used to create the client and you connect the client to data using services.

Let's go back to browsers and how web applications are delivered. When the browser makes a request, the server uses a combination of static content (HTML/CSS/JS code) and scripts (these scripts may query a database or call other scripts, but in the end they output HTML/CSS/JS) to prepare a page. This page gets loaded and rendered by the browser. A key element here is that, usually this page (or response) has the presentation markup and the data baked into the same message.

When a new state of the application is to be presented, the browser makes a new request and the server prepares the page. The client "just" renders the data.

Flex applications works differently. The server sends the compiled Flex application (the SWF file) that runs inside the browser using the Flash Player plug-in. Usually, this SWF file holds only the client-side business logic. If data are need (from a database for example) the Flex application makes a request for those data. The server sends only the data (this can be in XML, JSON, AMF3 format), and the client knows how to represent this data visually. What we have here is a service oriented architecture: The Flex application is the client―a client that can consume data services from the server. The application can change state without refreshing the page or reloading the SWF file in the browser. The application is a client that can do more than "just" render data. Thus using Flex and Flash Player it is possible to create almost anything that makes sense to deploy on the web, from games to applications, to widgets that are integrated within "classic" web applications, and more (see Figure 1).

Figure 1. Flex and PHP architecture

 

Connecting Flex clients to PHP back-ends

As a PHP developer, you have a very direct way to read data, parse them, and display them on the screen. Connecting to a MySQL database is one of the first things any PHP developer learns.

What about Flex? I have to disappoint you, because you don't have direct access to data stored in a database. Why is there no direct way of reading data from a database? Because of the old saying "You should never trust the client!" Suppose the client is a Flex component that knows how to connect to the MySQL server. How do you store the credentials so that it wouldn't be easy to steal them and have the database compromised? Set a different user/password for each user and give them this information? This is just one of the reasons why it is not a good idea to have a client technology that can connect directly to a database server, without using an application server in the middle.

Basically, in Flex applications you rely on server-side scripts to manage the databases. Flex offers you a way to call the server pages and get back the answer in Flex. Basically, you can connect a Flex client to a PHP back-end in two ways: over HTTP or using sockets.

Over HTTP, there are four different ways to connect to a server data source: REST style services, web services (WSDL/SOAP), remoting (or RPC), and XML-RPC (see Figure 2).

 

Figure 2. Flex – PHP HTTP based communication

You can use the HTTPService class to use REST style services. You can send POST variables when you do a request, and the response can be XML, JSON (there is a third-party library for parsing JSON), or custom formatting.

If you have web services on the server (SOAP/WSDL), you can use the WebService class.

But the most interesting method is remoting (using the RemoteObject class). There are three reasons why I think it is the coolest method. First, using remoting you can leverage any PHP class you have on your server by calling any public method. Basically, from the Flex side you use an instance of RemoteObject as if it were the remote PHP class. Second, you can map the data model from the PHP side to an ActionScript data model, and have the conversion done automatically. This is extremely important, because when you use typed objects, you get the benefits of compile-time error checks and code completion. This means code that is easier to read and less prone to bugs. And third, the messaging format for this method, AMF3 (Action Message Format) is a binary format, which can be much faster and smaller compared to SOAP/XML/JSON, especially for big sets of data. The format itself is open, and anyone can read the white papers and implement programs that use it.

AMF3 is faster because it encodes data. For example, if the same string is repeated in a data set, it is encoded one time, and all other occurrences of the string are references. If a number is smaller than four bits, only the minimum number of bytes required are used (see Figure 3).

 

Figure 3. Remoting or RPC

 

Remoting is natively supported by Flex, however on the server side the story is not the same. PHP doesn't support remoting and AMF3 natively. This is why you need a server side library to enable remoting for a PHP web server. There are four available libraries, all are free, and I wrote tutorials about how to use each of them: Zend AMF, AMFPHP, WebORB for PHP, and SabreAMF. And here you can read a post that compares them.

The last method used by people for integrating Flex with PHP is the light-weight web services XML-RPC. This is for example what Drupal offers out-of-the-box if you want to create modules that uses Flex or AJAX. In order to use XML-RPC you need a library for both the client (xmlrpcflash) and the server (phpxmlrpc).

If you want to connect using your own protocol built on top of sockets, you can use sockets communication. You can create a socket server on the PHP side, and from the client you can connect to this server and exchange data. Just a reminder―when creating Flex applications that target the desktop (running on Adobe AIR and not in the browser) you can create socket servers on the client side too. Here is a good article about working with sockets with Flex and PHP.

AttachmentSize
fig1.jpg37.87 KB
fig2.jpg19.46 KB
fig3.jpg44.88 KB
fig4.jpg17.38 KB
fig5.jpg27.95 KB
fig6.jpg80.4 KB
Published at DZone with permission of its author, Mihai Corlan.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)