Using a good solution to cache your web application can increase the performance by 70%.

There are several good PHP caching solutions however, in this example we are going to use the Zend Framework Cache system with the power of Memcached.

What is memcached?
The Memcache module provides handy procedural and object oriented interface to memcached, highly effective caching daemon, which was especially designed to decrease database load in dynamic web applications.

Getting started.

So in the same way that we include any Zend Framework packages we need to include the Zend/Cache.php. Follow an example code:

<?php
require_once 'Zend/Cache.php';

$frontendOptions = array('lifeTime' => 20);
$backendOptions = array(array('host' => 'localhost','port' => 11211, 'persistent' => true));

$cache = Zend_Cache::factory('Core', 'Memcached', $frontendOptions, $backendOptions);

if (!$result = $cache->get('time') ){
$time = date('r');
echo "generated: " . $time;
$cache->save($time, 'time');
} else {
echo "cache hit: ". $cache->get('time');
}

?>

In the first 3 lines of this example we created our instance of the Zend_Cache class and configured the frontend and backend driver:

require_once 'Zend/Cache.php';

$frontendOptions = array('lifeTime' => 20);
$backendOptions = array(array('host' => 'localhost','port' => 11211, 'persistent' => true));

The frontend specifies only the lifetime that the cache data must be valid. For the Backend options we have to set up the localhost, the port and whether the daemon of memcached must be persistent.

The rest of code simply set and get a cached data.

Zend_Cache uses a modular approach to specify the frontend and backend drivers. The frontend driver determines what data is gathered and from your PHP script. The backend driver determines how the data is stored. In this example we are using the "Core" frontend driver, which is the top-level frontend driver which provides functionality that all other frontend drivers inherit. The "Memcached" backend driver provides memcached-based storage for your cached data.

In conclusion
The cache system can boost a lot the performance of your Ajax based application.
Using a memory based backend driver will speed up your code cache execution since the filesystem will not need to be touched during the execution of your scripts. Using memcache you will also be able to share your memory between machines enabling a cluster of machines to share the same cache.
There is also no support for SHM or database backends, and the frontend drivers available are not as numerous or mature as other Cache systems (such as PEAR::Cache).

Adobe has just announced the BlazeDS beta release. On Adobe Labs today we can read that "BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe® Flex™ and Adobe AIR™ applications for more responsive rich Internet application (RIA) experiences."

As a matter of fact, BlazeDS is an open source part of LiveCycle Data Services, while the complete Live Cycle suite will still be closed source and subject to Adobe’s Licensing policy.

The source code will be available for download in early 2008 (http://labs.adobe.com/technologies/blazeds/).

Adobe has also published AMF binary data protocol specification, on which the BlazeDS remoting implementation is based.

BlazeDS introduces the concept of HTTP streaming, that enables clients to maintain persistent connections with backend servers. HTTP streaming will practically allow the same data push functionality that is available with the LiveCycle Data Services, with the difference that the streaming will not use the RTMP messaging channel.

Among the news, Adobe will offer Adobe LiveCycle Data Services, Community Edition, a subscription offering that includes certified builds of BlazeDS, access to Adobe enterprise support resources and additional benefits, such as product warranty and infringement indemnity, as well as additional developer support.

After the release of the Flex SDK open source, Adobe gives further signals of willingness to pursue the construction of a stronger and wider developers' community.

Model-Glue is a family of frameworks that helps developers to create Rich Internet Application easily and with less coding than other frameworks.
Model-Glue was first developed for ColdFusion, it enforces Model-View-Controller design, eases implicit invocation, does repetitive work for you, and plays well with other open-source ColdFusion frameworks.
The author of Model-Glue, Joe Rinehart, used Cairngorm for a while, then decided to write a port of Model-Glue for Flex; the goal of this project is to reach the same level of abstraction of Cairngorm without its repetitive tasks.
According to the author, this framework is:

1.Easy to understand. UI components and consumers dispatch events. Controllers listen for events and take action.

2.Streamlined. You'll write less code without sacrificing flexibility.

3.Adaptable. You can code fast and loose, catching errors at runtime, or strict and controlling, catching errors when compiling.

4.Strong but Simple. Model-Glue is based on Model View Controller and Implicit Invocation - but not at all complicated.

5.Open. All code is released under the Apache Software License 2.0, meaning that it's free to download, use, and alter.

During my researches on the web, I found a lot of enthusiastic people that have seen a dramatic improvement over Cairngorm, so I decided to look deeper into it.
Model-Glue: Flex is in an early stage of development, at the time of writing is available the alpha1 version; you can download it from the project home page: http://www.model-glue.com/flex.cfm
In the package you can find the library source and a couple of application examples; there is also a little text file with some quickstart tips. I had some problems following the documentation, probably because it is not completely in sync with the code, but I could easily create a flex library project with the framework source code. The second step was to compile the first “Hello world” application, with a button whose click is associated with a simple Alert.
The main application has a sample Panel with a Button:


<mx:Panel width="95%" height="95%" title="Model-Glue Application Template" verticalAlign="middle" horizontalAlign="center">


<mx:Button label="Say Hi!" click="new ModelGlueEvent('greeting').dispatch();" />
</mx:Panel>


The button click dispatches a ModelGlueEvent. In this application we have also a reference to the configuration:


<config:ModelGlueConfiguration />


ModelGlueConfiguration is a mxml component which contains the associations events-messages-listeners. In Caingorm we have a FrontController that associates events with commands; Model-Glue is quite different: here we have events, every event has a handler, a handler can broadcast different messages that have listeners; the code will make all clearer:


<ModelGlue xmlns="com.firemoss.modelglue.tags.*" xmlns:event="com.firemoss.modelglue.tags.event.*" xmlns:control="control.*" xmlns:mx="http://www.adobe.com/2006/mxml">


<eventHandlers>

<!-- An event handler is an architectural event, such as a user logging in. -->

<event:Handler name="greeting">

<event:broadcasts>

<!-- A message is a statement that something has happened or that an action is needed. -->

<event:Message name="greetingRequested" />

</event:broadcasts>

</event:Handler>

</eventHandlers>

</ModelGlue>


In the <eventHandlers> section we have an event handler for the “greeting” event, dispatched on the Button click; this handler broadcasts a Message named “greetingRequested”. In the <controllers> section we have a controller which includes a MessageListener; this listener associates a Message type with a controller function. So the main difference is that in Cairngorm you end up with a one to one mapping, in Model-Glue you end up with events that dispatch different events (messages), which can have different listeners; things are completely decoupled here and seem more flexible.

With regard to interaction with remote services, there are some differences too. With Cairngorm we are used to create Commands that call Business delegates, that call remote services and add a responder to this remote call. Model-Glue:Flex proposes "Autoproxies", that make a remote call similar to prototype's style of making Ajax calls; the author explains this solution here: http://www.firemoss.com/blog/index.cfm?mode=entry&entry=6F23C9CC-3048-55C9-43654A79D887EB8A

Model-Glue: Flex is a promising framework, but I cannot say that is better than Cairngorm yet, I have to play with it and above all try to use it in a medium-complex project.