Christophe Coenraets

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>

I’ll be presenting two sessions at Flex 360 Indianapolis next week.

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

I made some additional changes to the Spring BlazeDS Integration (RC1) Test Drive:

• 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

UPDATE: An updated version of this Test Drive is available here

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

Many people have asked for the source code of the new version of Salesbuilder that includes Ribbit (phone service) integration, an offline calendar (using the ILog component), and the KapIT visualizer component.

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.

http://ria.dzone.com/articles/introduction-spring-blazeds

I updated my Salesbuilder sample Flex/Adobe AIR application with a couple of new interesting features:

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

Read the rest of this entry »

A typical source of confusion when developers start working with RemoteObject or other BlazeDS/LCDS related classes is where and most importantly *when* the configuration of your services is being read.

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).

Read the rest of this entry »

In part 1 of this series, we saw how Flex AS allows you to externalize the configuration and the wiring of objects. In part 2, we discussed how you can “autowire” view properties. We intentionally kept the example simplistic by directly injecting the contact RemoteObject into the views. In real life, however, you generally don’t want to tie your views to a specific service implementation… The views should be independent from your data access strategy: RemoteObject, HTTPService, WebService, mock service, etc.

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:

Read the rest of this entry »