Greg Wilson and Damien Mandrioli are also blogging about the new Tour de Flex real time dashboard today. Greg is the inspiration behind everything “Tour de Flex”, including the idea of the dashboard. He has the story behind the genesis of this project on his blog. Damien (from IBM/ILOG) did a fantastic job at building the client-side of the dashboard using the very cool ILOG Elixir components, and he walks you through the details on his blog.

My contribution to the project is the “real-time messaging” infrastructure. I provide the details below.

First the overall workflow…

The reason we are combining PHP and Java in this workflow is mostly historical. In the initial version of Tour de Flex, there was no Java involved: Greg was persisting loaded samples data (sample id and timestamp) directly from his PHP page. We later added LiveCycle Data Services to the picture to support the data push requirement of the dashboard, and we took the opportunity to move some code (such as the database persistence) from PHP to Java. Note that we are using LCDS for the performance and scalability of its high-end channels, but the application could also be deployed on BlazeDS.

A more straightforward architecture would be for the client to communicate directly with LCDS. For example, the client could invoke a remote object that would directly publish the loaded sample data (sample id and geolocation of the client) to the message destination. Alternatively, the client could use a Producer object to directly publish the message to the destination. Because some logic (such as geolocating the IP address and persisting the data) has to be executed at the server-side before routing the messages to the subscribed clients, you would have to write a custom message adapter if you used this approach.

We will probably streamline the workflow with one of these two approaches in the future, but in the meantime here is the source code for the servlet (logging and non-essential code removed for brevity):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109

package com.adobe.tdf;
 
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;
 
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
import com.maxmind.geoip.Location;
import com.maxmind.geoip.LookupService;
 
import flex.messaging.MessageBroker;
import flex.messaging.messages.AsyncMessage;
import flex.messaging.util.UUIDUtils;
 
public class TDFServlet extends HttpServlet {
 
	// Unique clientID for the message service
	private String clientID = UUIDUtils.createUUID();
 
	// The geocoding service
	protected LookupService lookupService;
 
	// A DAO to store sample requests in a database
	protected SampleRequestDAO dao = new SampleRequestDAO();
 
	// The LCDS message broker
	protected MessageBroker messageBroker;
 
	// The LCDS messaging destination where real time sample requests information is pushed
	protected String destination; 
 
	public void init() throws ServletException {
 
		ServletConfig config = getServletConfig();
		destination = config.getInitParameter("messaging.destination.name");
		String path = config.getInitParameter("geocoding.database.path");
		try {
			// Load the geocoding database in init() to make sure we load it only once
			lookupService = new LookupService(path, LookupService.GEOIP_MEMORY_CACHE);
		} catch (IOException e) {
			// We swallow the exception here. If the database is not available, the feed
			// will still work but won't provide the location info.
		}	
	}
 
	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
 
		if (messageBroker == null)
		{
			messageBroker = MessageBroker.getMessageBroker(null);
		}
 
		SampleRequest sampleRequest = new SampleRequest();
 
		try {
			sampleRequest.setSampleId(Integer.parseInt(request.getParameter("sampleId")));
		} catch (Exception e) {
			String message = "A valid sampleId is required to process this request";
			throw new RuntimeException(message);
		}
 
		sampleRequest.setTimestamp(new Date());
 
		String ipAddress = request.getParameter("ipAddress");
 
		// Geolocate the IP address and add the info to the message
		if (lookupService != null && ipAddress != null)
		{
	                Location location = lookupService.getLocation(ipAddress);
			if (location != null)
			{
				sampleRequest.setLatitude(location.latitude);
				sampleRequest.setLongitude(location.longitude);
				sampleRequest.setCountry(location.countryCode);
				sampleRequest.setCity(location.city);
			}
		}
 
		try {
			dao.create(sampleRequest, ipAddress);
		} catch (RuntimeException e) {
 
		}
 
		String subtopic = request.getParameter("subtopic");
		if (subtopic == null) subtopic = "flex";
 
		// Publish the message to specified destination and subtopic.
		AsyncMessage msg = new AsyncMessage();
		msg.setDestination(destination);
		msg.setHeader("DSSubtopic", subtopic);
		msg.setClientId(clientID);
		msg.setMessageId(UUIDUtils.createUUID());
		msg.setTimestamp(System.currentTimeMillis());
		msg.setBody(sampleRequest);
		messageBroker.routeMessageToService(msg, null);
 
		PrintWriter out = response.getWriter();
	        out.println("<html><body>ok</body></html>");
 
	}
 
}

The servlet is responsible for three things:

1. Geolocate the IP address of the client requesting the sample. We currently use the MaxMind Geolocation API. The API is straightforward and the results seem pretty accurate.
2. Save the information about the loaded sample in a database. We keep track of historical data to be able to support future data visualization projects.
3. Publish the data about the loaded sample to a message destination. The servlet uses the Message Service Java API to directly push messages to the Flex destination (lines 97 to 104). Note that the same API exists for ColdFusion, so CF developers could use a CF page instead of this servlet to push messages to the client.

Channels

The messaging destination is set up to support different communication channels: RTMP, long polling, and regular polling. The client-side developer can decide which channel to use to communicate with the server. For example, if you wanted to use RTMP as the primary channel, fall back to long polling if the RTMP connection fails, and fall back to regular polling if the long polling connection fails you could set up your client-side ChannelSet as follows:

1
2
3
4
5

<mx:ChannelSet id="channelSet">
	<mx:RTMPChannel id="rtmp" url="rtmp://hostname:2037"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amflongpolling"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amfpolling"/>
</mx:ChannelSet>

In the “Flex / BlazeDS Integration Project” session (Monday), I’ll provide a brief introduction of the Spring framework and the “Dependency Injection” pattern, followed by a deep dive into the brand new “Spring / BlazeDS integration project”.

My second session (on Wednesday) is “Model Driven Development with Flash Builder 4 and LCDS 3”. (The next version of Flex Builder will be named Flash Builder 4. The name of the Flex framework and the Flex SDK doesn’t change: it’s still Flex). In this session I will present a new and exciting feature in Flash Builder 4 and LiveCycle Data Services 3. Using the combination of these two products, you can build data-driven applications using a Model-Driven Development approach. In other words, you don’t have to write any server-side code: the data access logic is derived from a simple data model that is easily created and updated using new tooling in Flash Builder 4. This solution is designed to work for simple and very complex applications. I presented a sneak peek of this new feature at MAX last year, and we made a lot of progress since then.

I hope to see you there.

Christophe

• The Test Drive now includes an annotation-based configuration sample (the Company Manager sample). Spring annotations such as @Service, @RemotingDestination, @Autowired, @RemotingInclude, and @RemotingExclude make it really easy to configure your beans and make them available through Remoting. As an example, here is the source code for the CompanyDAO class:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

  package flex.spring.samples.company;   import java.sql.ResultSet; import java.sql.SQLException; import java.util.HashMap; import java.util.List; import java.util.Map;   import javax.sql.DataSource;   import org.springframework.flex.remoting.RemotingDestination; import org.springframework.flex.remoting.RemotingExclude; import org.springframework.flex.remoting.RemotingInclude; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.jdbc.core.simple.ParameterizedRowMapper; import org.springframework.jdbc.core.simple.SimpleJdbcInsert; import org.springframework.jdbc.core.simple.SimpleJdbcTemplate;   import flex.spring.samples.industry.IIndustryDAO;   @Service("companyService") @RemotingDestination(channels={"my-amf"}) public class CompanyDAO implements ICompanyDAO {   private final SimpleJdbcTemplate template; private final SimpleJdbcInsert insertCompany;   private IIndustryDAO industryDAO;   private final ParameterizedRowMapper<Company> rowMapper = new ParameterizedRowMapper<Company>(){ public Company mapRow(ResultSet rs, int rowNum) throws SQLException { Company company = new Company(); company.setId(rs.getInt("id")); company.setName(rs.getString("name")); company.setAddress(rs.getString("address")); company.setCity(rs.getString("city")); company.setState(rs.getString("state")); company.setZip(rs.getString("zip")); company.setPhone(rs.getString("phone")); company.setIndustry(industryDAO.findById(rs.getInt("industry_id"))); return company; } };   @Autowired public CompanyDAO(DataSource dataSource, IIndustryDAO industryDAO) { template = new SimpleJdbcTemplate(dataSource); insertCompany = new SimpleJdbcInsert(dataSource).withTableName("COMPANY").usingGeneratedKeyColumns("ID"); this.industryDAO = industryDAO; }   @RemotingInclude public Company findById(int id) { return template.queryForObject("SELECT * FROM company WHERE id=?", rowMapper, id); }   @RemotingInclude public List<Company> findAll() { return template.query("SELECT * FROM company ORDER BY name", rowMapper); }   @RemotingInclude public List<Company> findByName(String name) { return template.query("SELECT * FROM company WHERE UPPER(name) LIKE ? ORDER BY name", rowMapper, "%" + name.toUpperCase() + "%"); }   @RemotingInclude public Company create(Company company) { Map<String, Object> parameters = new HashMap<String, Object>(); parameters.put("name", company.getName()); parameters.put("address", company.getAddress()); parameters.put("city", company.getCity()); parameters.put("state", company.getState()); parameters.put("zip", company.getZip()); parameters.put("phone", company.getPhone()); parameters.put("industry_id", company.getIndustry().getId()); Number id = insertCompany.executeAndReturnKey(parameters); company.setId(id.intValue()); return company; }   @RemotingInclude public boolean update(Company company) { int count = template.update("UPDATE company SET name=?, address=?, city=?, state=?, zip=?, phone=?, industry_id=? WHERE id=?", company.getName(), company.getAddress(), company.getCity(), company.getState(), company.getZip(), company.getPhone(), company.getIndustry().getId(), company.getId()); return (count == 1); }   @RemotingExclude public boolean remove(Company company) { int count = template.update("DELETE FROM company WHERE id=?", company.getId()); return (count == 1); }   }

• The Test Drive is now using the M3 build of Spring 3 (as opposed to M2 in the previous builds of the Test Drive).
• I modified the configuration of the long polling channel to support more persistent connections per domain based on the browser capabilities.
• And of course compared to the M2 build, this version of the Test Drive includes a number of Messaging samples.

  Using the Messaging integration, setting up a destination can be as easy as:

  <flex:message-destination id="chat" />

  And here is how you configure a destination mapped to a JMS topic:

  <flex:jms-message-destination id="jms-chat" jms-destination="chatTopic" />

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1v2.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

I will be joined by Mark Fisher from SpringSource and we will talk about Flex, Spring, BlazeDS and the integration of these technologies. Spring BlazeDS integration RC1 was released last week. One of the key features in RC1 is the integration of the Message service, and Mark is the lead developer on that feature.

I hope to see you there if you live in the greater Boston area.

Thu, May 14 6:00pm
Sun Microsystems - 1 Network Way, Burlington, MA
NEJUG Link

SpringSource just released the RC1 build for the Spring / BlazeDS integration project. The key new feature in RC1 is the integration of the BlazeDS Message Service.

I updated my Spring BlazeDS Integration Test Drive to showcase the messaging integration.

In addition to Remoting and Security samples, the Test Drive now includes the following Messaging samples:

• Chat: Messaging basics
• Simple Data Push: A simple data push example
• Traderdesktop: A more sophisticated data push example showing how to use subtopics
• JMS Chat: A chat application using a JMS topic and exchanging messages with a Swing-based client
• Collaboration: An example showing how to use messaging to remotely drive another client’s application

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

As always, I’d love to hear your feedback and your ideas to improve this Test Drive.

I will probably have another version next week with a couple of additional samples and more documentation for the Message Service, but I already wanted to make this version available to allow you to experiment RC1 samples.

Christophe

You can now download the source code here.

As a reminder, you can watch a screencast showing the key features of the application here (go full screen for a better viewing experience. Also make sure HD is on).

You must create a Ribbit developer account (free) to be able to use the phone service. Once you have a Ribbit account, click the Options menu item in Salesbuilder and enter your Ribbit user id and password.

You will also need to install the ILog swc if you want to compile the application.

1. Ribbit integration: allows you to make and receive calls from within the application
2. KapIt Visualizer component to represent the org chart
3. ILog calendar component

I recorded a quick screencast to show the new (and previous features) of the application. You can watch it in the player below, however, I highly recommend you click here to watch it in HD (go full screen for a better viewing experience. Also make sure HD is on).

Click on the badge below to install the application.

NOTE: You must create a Ribbit developer account (free) to be able to use the phone service. Once you have a Ribbit account, click the Options menu item in Salesbuilder and enter your Ribbit user id and password.

The question often arises after an application stops working when you move it to another server. This is one of the most frequently asked questions related to BlazeDS and LCDS, so I figured I would answer it here. There is nothing really new in this post, but hopefully this will be a good point of reference.

When you create a new BlazeDS or LCDS project in Flex Builder, you are typically told to select J2EE as the “Application Server Type” and then check “use remote object access service”. This adds a compiler argument pointing to the location of your services-config.xml. If you check the Flex Compiler properties of your Flex Builder project, you’ll see something like this:

-services “c:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml”

When you then compile your application, the required values of services-config.xml are baked into the SWF. In other words, services-config.xml is read at compile time and not at runtime as you may have thought intuitively. To abstract things a little bit, you can use tokens such as {server.name}, {server.port}, and {context.root} in services-config.xml. However, {context.root} is still substituted at compile time, while {server.name} and {server.port} are replaced at runtime using the server name and port number of the server the SWF was loaded from (which is why you can’t use these tokens for AIR applications).

Fortunately, the Flex SDK provides an API that allows you to configure your channels at runtime and entirely externalize your services configuration from your code (you definitely don’t want to recompile your application when you move it to another server). At a high level, it works like this:

1
2
3
4

var channelSet:ChannelSet = new ChannelSet();
var channel:AMFChannel = new AMFChannel("my-amf", "http://localhost:8400/lcds-samples/messagebroker/amf");
channelSet.addChannel(channel);
remoteObject.channelSet = channelSet;

This is still not what we want because the endpoint URL is still hardcoded in the application. At least in this case it’s obvious that it is. So, the last step is to pass that endpoint URL value at runtime. There are a number of ways you can pass values to a SWF at runtime (flashvars, page parameters, etc). The approach I usually use is to read a configuration file using HTTPService at application startup. That configuration file includes (among other things) the information I need to programmatically create my channel set at runtime. Here is a basic implementation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	applicationComplete="configSrv.send()">
 
	<mx:Script>
	<![CDATA[
 
	import mx.controls.Alert;
	import mx.messaging.channels.AMFChannel;
	import mx.messaging.ChannelSet;
	import mx.rpc.events.ResultEvent;
 
	private var channelSet:ChannelSet;
 
	private function configResultHandler(event:ResultEvent):void
	{
		var xml:XML = event.result as XML;
		var amfEndpoint:String = "" + xml..channel.(@id=="amf").@endpoint;
		if (amfEndpoint == "")
		{
			Alert.show("amf channel not configured", "Error");					
		}
		else
		{
			channelSet = new ChannelSet();
			var channel:AMFChannel = new AMFChannel("my-amf", amfEndpoint);
			channelSet.addChannel(channel);
			ro.channelSet = channelSet;
			ro.getProducts();
		}
	}
 
	]]>
	</mx:Script>
 
	<mx:HTTPService id="configSrv" url="config.xml" resultFormat="e4x" result="configResultHandler(event)"/>
 
	<mx:RemoteObject id="ro" destination="product"/>
 
	<mx:DataGrid dataProvider="{ro.getProducts.lastResult}" width="100%" height="100%"/>
 
</mx:Application>

The configuration file looks like this:

1
2
3
4
5
6

<?xml version="1.0" encoding="utf-8"?>
<config>
	<channels>
		<channel id="amf" endpoint="http://localhost:8400/lcds-samples/messagebroker/amf"/>
	</channels>
</config>

NOTE: With that type of runtime configuration in place, you can create plain Flex Builder projects (you can select None as the application server type).

This particular example is not extremely flexible. It assumes I will always work with an AMF channel and therefore the only thing my application needs to know at runtime is the AMF channel endpoint URL. For RemoteObject that’s a fairly safe bet, however for messaging-related classes (Producer and Consumer), you may also want to externalize the type of channel you use (AMF Polling, long polling, streaming, RTMP, etc.). Before you start creating that kind of dynamic configuration system, you may want to take a look at the Flex ActionScript framework that does that very well.

To satisfy this requirement, we will create an IContactService interface, and two classes that implement that interface:

1. ContactRemoteObjectService uses RemoteObject to access contact data
2. ContactMockService encapsulates mock data as a way of testing the application without backend data

For the purpose of this sample application, IContactService is defined as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package insync.services
{
import insync.model.Contact;
import mx.rpc.AsyncToken;
 
public interface IContactService
{
	function getContactsByName(name:String):AsyncToken;
 
	function save(contact:Contact):AsyncToken;
 
	function remove(contact:Contact):AsyncToken;
}
}

ContactRemoteObjectService is implemented as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

package insync.services
{
import insync.model.Contact;
 
import mx.controls.Alert;
import mx.rpc.AsyncResponder;
import mx.rpc.AsyncToken;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.rpc.remoting.mxml.RemoteObject;
 
public class ContactRemoteObjectService implements IContactService
{
	private var remoteObject:RemoteObject;
 
	public function ContactRemoteObjectService(remoteObject:RemoteObject) 
	{
    		this.remoteObject = remoteObject;
	}
 
	public function save(contact:Contact):AsyncToken
	{
		var token:AsyncToken = remoteObject.save(contact);
		token.contact = contact;
        	token.addResponder(new AsyncResponder(save_result, faultHandler));
        	return token;
	}
 
	public function remove(contact:Contact):AsyncToken
	{
		var token:AsyncToken = remoteObject.remove(contact);
	        token.addResponder(new AsyncResponder(remove_result, faultHandler));
        	return token;
	}
 
	public function getContactsByName(name:String):AsyncToken
	{
		var token:AsyncToken = remoteObject.getContactsByName(name);
	        token.addResponder(new AsyncResponder(getContactsByName_result, faultHandler));
        	return token;
	}
 
 
	/* Result Handlers ---------------------------------------------------------------*/
 
	private function save_result(event:ResultEvent, token:AsyncToken=null):void 
	{
		// For a create operation, assign the generated primary key to the id property 
		// of the contact object
		event.token.contact.id = event.result.id;
 
		// Dispatch an event on the async token. This allows the caller of the method to register as
		// a listener for the result event of the specific method call. (See ContactForm.mxml for an example.
		event.token.dispatchEvent(event);
	}		
 
	private function remove_result(event:ResultEvent, token:AsyncToken=null):void 
	{
		event.token.dispatchEvent(event);
	}		
 
	private function getContactsByName_result(event:ResultEvent, token:AsyncToken=null):void 
	{
		event.token.dispatchEvent(event);
    	}		
 
	private function faultHandler(event:FaultEvent, token:AsyncToken=null):void
    	{
    		Alert.show(event.fault.faultString + "\n" + event.fault.faultDetail, "Error Invoking RemoteObject");
    	}
 
}
}

NOTE: There is nothing specific to the Spring AS framework in this class, except that the remoteObject property will be injected by the framework. This simple implementation is tied to the Flex framework and specifically the rpc API: the contract between the service and other components of the application relies on mx.rpc classes (AsyncToken and ResultEvent). You can replace this basic implementation with your own. Spring AS also provides an abstraction API for working with asynchronous method calls that is not tied to the Flex framework (see the AbstractRemoteObjectService class). Spring AS aims to be an AS framework and not specifically a Flex framework.

ContactMockService is implemented as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

package insync.services
{
import insync.model.Contact;
import mx.collections.ArrayCollection;
import mx.rpc.AsyncResponder;
import mx.rpc.AsyncToken;
import mx.rpc.events.ResultEvent;
 
public class ContactMockService extends MockService implements IContactService
{
	private var contacts:ArrayCollection = new ArrayCollection();
 
	private var nextId:int;
 
	public function ContactMockService() 
	{
		var contact:Contact = new Contact();
		contact.id = 1;
		contact.firstName = "Christophe"; 
		contact.lastName = "Coenraets";
		contacts.addItem(contact);
 
		contact = new Contact(); 
		contact.id = 2;
		contact.firstName = "Lisa"; 
		contact.lastName = "Taylor";
		contacts.addItem(contact);
 
		contact = new Contact(); 
		contact.id = 3;
		contact.firstName = "John"; 
		contact.lastName = "Smith";
		contacts.addItem(contact);
 
		nextId = 4;
	}
 
	public function save(contact:Contact):AsyncToken
	{
		if (contact.id == 0) // New contact
		{
			contact.id = nextId++;
			contacts.addItem(contact);
		}
		var token:AsyncToken = createToken(contact);
        	token.addResponder(new AsyncResponder(resultHandler, null));
        	return token;
	}
 
	public function remove(contact:Contact):AsyncToken
	{
		var result:ArrayCollection = new ArrayCollection();
		for (var i:int=0; i<contacts.length; i++)
		{
			var current:Contact = contacts.getItemAt(i) as Contact;
			if (current.id == contact.id)
			{
				contacts.removeItemAt(i);
				break;
			} 
		}
		var token:AsyncToken = createToken(contacts);
	        token.addResponder(new AsyncResponder(resultHandler, null));
        	return token;
	}
 
	public function getContactsByName(name:String):AsyncToken
	{
		var result:ArrayCollection = new ArrayCollection();
		for (var i:int=0; i<contacts.length; i++)
		{
			var contact:Contact = contacts.getItemAt(i) as Contact;
			if (contact.fullName.indexOf(name)>=0)
			{
				result.addItem(contact);
			} 
		}
 
		var token:AsyncToken = createToken(result);
	        token.addResponder(new AsyncResponder(resultHandler, null));
        	return token;
	}
 
	private function resultHandler(event:ResultEvent, token:AsyncToken = null):void
	{
		event.token.dispatchEvent(event);	
	}
 
}
}

To keep the views independent from a specific implementation of the service, we provide them with a property of the interface type (IContactService). Depending on the Spring AS application context, a specific implementation of the service is injected. For example, ContactForm is defined as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:controls="insync.controls.*"
	width="100%" height="100%"
	label="{contact.id>0?contact.fullName:'New Contact'}">
 
	<mx:Script>
	<![CDATA[
 
	import mx.rpc.events.ResultEvent;
	import insync.events.ContactEvent;
	import insync.services.IContactService;
	import insync.model.Contact;
 
	[Autowired]			
	public var contactService:IContactService;
 
	[Bindable] 
	public var contact:Contact;
 
	private function save():void
	{
		contact.firstName = firstName.text;
		contact.lastName = lastName.text;
		contact.email = email.text;
		contact.phone = phone.text;
		contact.address = address.text;
		contact.city = city.text;
		contact.state = state.text;
		contact.zip = zip.text;
		contact.pic = picture.source;
 
		contactService.save(contact).addEventListener(ResultEvent.RESULT,
			function(event:ResultEvent):void
			{
				// Display a status message. Added here to provide an example where
				// a specific contact view needs to be notified of the success or failure
				// of a service operation. 
				status.text = "Contact saved successfully";
				setTimeout(function():void{status.text=""}, 1500);						
			});
	}
 
	private function remove():void
	{
		contactService.remove(contact);
	}
 
	]]>
	</mx:Script>
 
	<mx:Form>
		<mx:FormItem label="Id">
			<mx:TextInput text="{contact.id}" enabled="false"/>
		</mx:FormItem>
		<mx:FormItem label="First Name">
			<mx:TextInput id="firstName" text="{contact.firstName}"/>
		</mx:FormItem>
		<mx:FormItem label="Last Name">
			<mx:TextInput id="lastName" text="{contact.lastName}"/>
		</mx:FormItem>
		<mx:FormItem label="Email">
			<mx:TextInput id="email" text="{contact.email}"/>
		</mx:FormItem>
		<mx:FormItem label="Phone">
			<mx:TextInput id="phone" text="{contact.phone}"/>
		</mx:FormItem>
		<mx:FormItem label="Address">
			<mx:TextInput id="address" text="{contact.address}"/>
		</mx:FormItem>
		<mx:FormItem label="City">
			<mx:TextInput id="city" text="{contact.city}"/>
		</mx:FormItem>
		<mx:FormItem label="State">
			<mx:TextInput id="state" text="{contact.state}"/>
		</mx:FormItem>
		<mx:FormItem label="Zip">
			<mx:TextInput id="zip" text="{contact.zip}"/>
		</mx:FormItem>
	</mx:Form>
 
	<controls:PictureInput id="picture" top="14" left="350" styleName="pictureFrame"
		pictureWidth="160" pictureHeight="160"
		source="{contact.pic}" />
 
	<mx:Label id="status" left="8" bottom="50"/>
	<mx:HBox left="8" bottom="8">
		<mx:Button label="Save" click="save()"/>
		<mx:Button label="Delete" click="remove()"/>
	</mx:HBox>
 
</mx:Canvas>

Although very simple, the InSync application allows you to open multiple contact views. It’s therefore important for a specific view to be able to know that a specific operation succeeded or failed. For example, in this case, we show a status message when the save operation succeeded.

If you want to work with the Mock Service implementation, you’d define applicationContext.xml as follows:

1
2
3
4
5
6

<?xml version="1.0" encoding="utf-8"?>
<objects>
 
	<object id="contactService" class="insync.services.ContactMockService" 
 
</objects>

If you want to switch to the RemoteObject implementation, you’d change the applicationContext.xml as follows. No need to change anything in the application, and no need to recompile.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="utf-8"?>
<objects>
 
	<object id="remoteObject" class="mx.rpc.remoting.mxml.RemoteObject"	abstract="true">
		<property name="endpoint" value="http://localhost:8400/lcds-samples/messagebroker/amf" />
		<property name="showBusyCursor" value="true" />
	</object>
 
	<object id="contactRemoteObject" parent="remoteObject">
		<property name="destination" value="contacts" />
	</object>
 
	<object id="contactService" class="insync.services.ContactRemoteObjectService">
	    <constructor-arg>
	        <object id="myContactRemoteObject" parent="remoteObject">
	            <property name="destination" value="contacts" />
	        </object>
	    </constructor-arg>
	</object>
 
</objects>

In this version of the application, we achieved an important goal: we decoupled the views of the application from any specific service implementation (and we can easily change the implementation we want to use). Decoupling the service layer from the other layers of your application is Spring AS’ primary objective.

Beyond that, you are free to implement the design patterns that you like, or that best fit the requirements of your application and the makeup of your development team. For example, you may prefer a design pattern where the view doesn’t have a reference to a service or controller (even if that reference is defined as an interface).

One additional benefit of using a Mock Service is that I can host the application configured with the MockService and let you play with it without having to worry about my database.

Click here to run the application. (View Source is enabled)

Installation instructions

NOTE: If you already installed the application provided with part 2 of this series, you can skip steps 1, 3, 4, 5 and 6.

1. Install the BlazeDS turnkey server. (To be clear: you don’t have to use BlazeDS to use Spring ActionScript… That’s just what this sample is using.)
2. Download insyncspringas3.zip, and unzip it on your local file system.
3. Copy insyncspringas3/java/classes/insync to blazeds/tomcat/webapps/samples/WEB-INF/classes/insync.
4. Add the following destination to blazeds/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml:

1 2 3 4 5 6

<destination id="contacts"> <properties> <source>insync.dao.ContactDAO</source> <scope>application</scope> </properties> </destination>

5. Copy insyncspringas3/sampledb/insync to blazeds/sampledb/insync
6. Edit server.properties in blazeds/sampledb, and modify the file as follows to add the insync database to the startup procedure.

   1 2 3 4 5 6 7

   server.database.0=file:flexdemodb/flexdemodb server.dbname.0=flexdemodb server.database.1=file:insync/insync server.dbname.1=insync server.port=9002 server.silent=true server.trace=false

7. Start the database (startdb.bat or startdb.sh)
8. Start BlazeDS
9. In Flex Builder, create a new Flex project called insyncspringas3. You don’t have to select any “Application server type”.
10. Copy spring-actionscript.swc and as3reflect.swc from insyncspringas3/flex/lib to the lib directory of your project
11. Copy the files and folders from insyncspringas3/flex/src to the src directory of your project
12. Open applicationContext.xml and make sure the remoteObject endpoint value matches your server setup.
13. Run the application