In this Test Drive, you run a series of short sample applications that demonstrate the key features of Spring BlazeDS Integration. This Test Drive is a continual work in progress and will be updated with each release of the project. Please submit your feedback to the Spring BlazeDS Integration team via the project forum.
These samples have been developed in collaboration between Adobe and SpringSource, with contributions from:
This version of the Test Drive uses a layered Spring configuration, with the core domain services and supporting infrastructure loaded in a root application context via the ContextLoaderListener, and both the Flex integration and the Spring MVC RESTful @Controllers configured separately via the DispatcherServlet's child application context. This layered approach with explicit separation of concerns is by no means required, but it does have some benefits over a non-layered approach such as opening up the option of writing out-of-container integration tests for the core domain services without having to load the web infrastructure.
This guide assumes you have built and imported all of the Eclipse projects from {Spring BlazeDS Integration Distribution Root}/projects/spring-flex-samples/spring-flex-testdrive (See the reference docs for instructions on building and running the samples)
Open main.mxml in the spring-blazeds-101/src/main/flex directory to look at the source code of the client.
Open the following files to look at the source code for the server side of the application:
Note that in this first sample, we use a simplistic DAO implementation with low level JDBC code and no real abstraction. This was done intentionally to provide a bare-bones example that focuses exclusively on the Spring/BlazeDS Integration plumbing. In all the other examples of this Test Drive, we use the JdbcTemplate abstraction of the Spring framework to build the data access objects.
Using RemoteObject, you can directly invoke methods of Java objects deployed in your application server, and consume the return value. The return value can be a value of a primitive data type, an object, a collection of objects, an object graph, etc.
Using Spring BlazeDS Integration, Spring beans are exposed using the <flex:remoting-destination />
configuration tag. See the "product" bean definition in app-config.xml and the remoting destination that references it in flex-servlet.xml
Java objects returned by server-side methods are deserialized into either dynamic or typed ActionScript objects. In this example, we don't have an explicit ActionScript version of the Product Java class. Product objects are therefore deserialized into dynamic objects. In InSync03 below, we start working with strongly typed model objects.
Open insync01.mxml in the insync01/src/main/flex directory to look at the source code of the application.
Open the following files to look at the source code for the server side of the application:
Click here to run the application
Open insync02.mxml in the insync02/src/main/flex directory to look at the source code of the application.
This version is similar to InSync01, but demonstrates how to use the ResultEvent and FaultEvent to have a finer control over RemoteObject calls.
Open insync03.mxml, Contact.as, and ContactForm.mxml in the insync03/src/main/flex directory to look at the source code of the application.
In this version, we work with strongly typed contact objects. The Contact.as class is the ActionScript representation of org.springframework.flex.samples.contact.Contact.java. The [RemoteClass(alias="org.springframework.flex.samples.contact.Contact")] annotation in Contact.as is used to indicate that instances of Contact.as sent to the server should be deserialized as instances of org.springframework.flex.samples.contact.Contact at the server side, and that similarly, instances of org.springframework.flex.samples.contact.Contact retrieved from the server should be deserialized as instances of Contact.as.
Open insync04.mxml in the insync04/src/main/flex directory to look at the source code of the application.
Open insync05.mxml and ContactForm.mxml in the insync05/src/main/flex directory to look at the source code of the application.
This version enables the user of the application to add contacts. In ContactForm, we remotely invoke the create() method of ContactDAO when dealing with a new contact, and the update() method when updating an existing contact.
Open insync06.mxml, ContactForm.mxml, and ContactEvent.as in the insync06/src/main/flex directory to look at the source code of the application.
In this version, ContactForm dispatches events when a contact has been created, updated, or deleted. Other components of the application can register as listeners to these events to perform a specific task when a contact is created, updated or deleted. In this case, the main application registers as a listener to these events and refreshes the contact DataGrid to make sure it reflects the changes made in ContactForm.
Open rest.mxml, ContactForm.mxml, ContactEvent.as, and RestInvoker.as in the insync-rest/src/main/flex directory to look at the source code of the application.
Open the following files to look at the source code for the server side of the application:
Just as in inSync06, ContactForm dispatches events when a contact has been created, updated, or deleted. Other components of the application can register as listeners to these events to perform a specific task when a contact is created, updated or deleted. The main application registers as a listener to these events and refreshes the contact DataGrid to make sure it reflects the changes made in ContactForm.
The major difference in this version is that the server side interface consists of RESTful HTTP endpoints, rather than direct RPC interfaces. The RestInvoker object abstracts away the details of communication. It uses URLStream instead of RemoteObject for marshalling data to and from the REST URLs. Note that there are several workarounds due to the Flash player's inability to set the Accept header or to use the PUT and DELETE HTTP methods. These workarounds take advantage of existing Spring MVC facilities such as HiddenHttpMethodFilter and ContentNegotiatingViewResolver.
The RESTful HTTP calls are handled by ContactsController. The results of each request are written back as AMF thanks to the configuration of the AmfView, and the "create" and "update" methods are able to take a Contact as a method parameter thanks to the use of @RequestBody in conjunction with AmfHttpMessageConverter.
Open companymgr.mxml, Company.as, Industry.as, and CompanyForm.mxml in the companymgr/src/main/flex directory to look at the source code of the application.
Open the following files to look at the source code for the server side of the application:
Note that the CompanyDAO and IndustryDAO beans are not defined in web-application-config.xml but are configured using annotations (@Service
,
@RemotingDestination
, @Autowired
, @RemotingInclude
, and @RemotingExclude
). This application is similar to inSync, but demonstrates object associations: the Company class has a property of type Industry.
Open chat.mxml in the chat/src/main/flex directory to look at the source code of the application. The Message Service manages a set of destinations that Flex clients can publish and subscribe to. Flex provides two components, Producer and Consumer, that you use to publish and subscribe to a destination. To subscribe to a destination, you use the subscribe()
method of the Consumer class. When a message is published to a destination that you subscribed to, the message
event is triggered on the Consumer.
Open testdrive/src/main/webapp/WEB-INF/flex-servlet.xml to look at the message service configuration. The message service is configured using <flex:message-service />
inside <flex:message-broker />
. The "chat" destination is configured using <flex:message-destination id="chat" />
This example demonstrates how to use the message service to push data from the server to the client. At the server-side, a Java component publishes simulated real time values to a message destination. The Flex client subscribes to that destination and displays the values in real time.
Open simplepush.mxml in the simplepush/src/main/flex directory to look at the source code of the application.
Open the following files in a text editor to look at the source code for the server side of the application:
In SimpleFeed.java, the MessageTemplate class is used to publish messages to the "simple-feed" destination.
Traderdesktop is a more sophisticated data push example showing how to use subtopics to selectively subscribe to specific messages. In this case, the user can subscribe to updates for specific stocks only. At the server side, a Java component publishes simulated market data to a messaging destination.
Open traderdesktop.mxml in the traderdesktop/src/main/flex directory to look at the source code of the application.
Open the following files in a text editor to look at the source code for the server side of the application:
This application is identical to the regular chat application above. The only difference is the destination: "jms-chat". At the server-side, the "jms-chat" destination is mapped to a JMS topic.
Open jmschat.mxml in the jmschat/src/main/flex directory to look at the source code of the application.
Open testdrive/src/main/webapp/WEB-INF/flex-servlet.xml to look at the message service configuration. Note that the "jms-chat" destination is mapped to the "chatTopic" (sampletopic.flex.jms.chat) JMS topic that is configured in testdrive/src/main/webapp/WEB-INF/spring/infrastructure-config.xml. In this application, we use an embedded ActiveMQ message broker configured by the connectionFactory bean. You don't have to start ActiveMQ in a separate process.
This application uses the same frontend as the two chat applications. However, in this case messages are sent between the client and a server-side POJO. There are separate inbound and outbound destinations, and these are mapped to Spring Integration channels.
Open messaging.mxml in the spring-messaging/src/main/flex directory to look at the source code of the client.
Open testdrive/src/main/webapp/WEB-INF/flex-servlet.xml to look at the message service configuration. Note that the "si-receive" and "si-send" destinations are mapped to the "toFlex" and "fromFlex" Message Channels respectively. Those are configured in testdrive/src/main/webapp/WEB-INF/spring/integration-config.xml. Also, in that configuration file you will see the "inbound-channel-adapter" and "service-activator" Spring Integration components and the "counter" bean definition they reference. The Counter source code is located within testdrive/src/main/java in the "org.springframework.flex.samples.integration" package.
Open collaboration.mxml in the collaboration/src/main/flex directory to look at the source code of the application.
Open testdrive/src/main/webapp/WEB-INF/flex-servlet.xml to look at the message service configuration.
Open secured.mxml in the secured/src/main/flex directory to look at the source code of the application.
Open the following files in a text editor to look at the the server side configuration:
Note that the "find*" methods of securedProductService are secured in app-config.xml. A basic authentication provider is defined in security-config.xml, and the BlazeDS support is enabled by the <flex:secured>
tag in flex-servlet.xml.