Ostatnimi czasy dużą popularność przy tworzeniu bogatych aplikacji internetowych (RIA) zdobywa podejście, w którym warstwę widoku pisze się z użyciem Fleksa lub innej technologii ułatwiającej budowanie interfejsów, a warstwy logiki biznesowej i dostępu do danych implementuje się przy pomocy Javy. Dodatkowo Java jest bardzo często wspierana przez bardzo popularne frameworki – Spring oraz Hibernate.

Do łączenia aplikacji klienckiej napisanej we Fleksie z aplikacją serwerową napisaną w Javie zazwyczaj używa się darmowego BlazeDS lub komercyjnego LiveCycle ES, oba te narzędzia są autorstwa firmy Adobe i udostępniają wiele ciekawych możliwości. Chyba najszybszym i najlepszym sposobem połączenia Fleksa z Javą jest wykorzystanie tzw. remote objects. Jest to po prostu zdalne wywoływanie metod obiektów napisanych w Javie z poziomu Fleksa, cała komunikacja odbywa się przy użyciu bardzo wydajnego, binarnego protokołu AMF (Action Message Format).

Dotychczas, aby z poziomu Fleksa skorzystać z beanów tworzonych przez Springa z użyciem wstrzykiwania zależności, należało wykonać wiele niekoniecznie prostych i oczywistych operacji. Domyślnie sam BlazeDS tworzy skonfigurowane w jego plikach obiekty, co w tym przypadku było działaniem niepożądanym. Trzeba było skonfigurować odpowiednią fabrykę dla BlazeDS, tak aby pozwolił on zająć się tworzeniem odpowiednich obiektów kontenerowi Springa. Były to dość złożone operacje i potrafiły spowodować pojawienie się wielu siwych włosów nawet u doświadczonych developerów.

Sytuacja diametralnie zmieniła się pod koniec zeszłego roku, gdy SpringSource wypuściło na światło dzienne nowy projekt – Spring BlazeDS Integration. Na razie jest to jeszcze dość świeży projekt, jednak pozwala już na użycie beanów tworzonych przez Springa w aplikacjach napisanych we Fleksie przy stosunkowo niewielkim wysiłku. W najbliższych planach jest m.in. implementacja mechanizmu Spring Security, bardzo pożądanego przez developerów tworzących aplikacje Fleksowe.

Aktualnie, przy użyciu Spring BlazeDS Integration, udostępnienie obiektów tworzonych przez Springa sprowadza się do kilku prostych kroków:

1.Po stronie Javy:

a) ustawienie odpowiedniego listenera w pliku web.xml:

<listener>
	<listener-class>flex.messaging.HttpFlexSession</listener-class>
</listener>

b) praktycznie standardowa konfiguracja springowego servletu w pliku web.xml:

<!-- The front controller of this Spring Web application -->
<servlet>
	<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<init-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/config/web-application-config.xml</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>

<!-- Map all /spring requests to the DispatcherServlet for handling -->
<servlet-mapping>
	<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
	<url-pattern>/spring/*</url-pattern>
</servlet-mapping>

c) dodanie odpowiedniego MessageBrokera w pliku konfiguracyjnym podanym powyżej jako parametr (web-application-config.xml):

<!-- Bootstraps and exposes the BlazeDS MessageBroker -->
<bean id="mySpringManagedMessageBroker"
	class="org.springframework.flex.messaging.MessageBrokerFactoryBean" />

Będzie on używał pliku konfiguracyjnego BlazeDS z domyślnego miejsca (WEB-INF/flex/services-config.xml). Aby zmienić to miejsce, należy dodać do powyższego beana następujący parametr:

<property name="servicesConfigPath" value="classpath*:services-config.xml" />

d) dodanie mapowania do MessageBrokera z BlazeDS (również w web-application-config.xml):

<!-- Maps request paths at /messagebroker to the BlazeDS MessageBroker -->
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	<property name="mappings">
        	<value>
                	/messagebroker/*=mySpringManagedMessageBroker
            	</value>
	</property>
</bean>

e) dodanie kanału odpowiadającego powyższej konfiguracji w pliku services-config.xml:

<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
	<endpoint url="http://{server.name}:{server.port}/{context.root}/spring/messagebroker/amf"
		class="flex.messaging.endpoints.AMFEndpoint"/>
	<properties>
		<polling-enabled>false</polling-enabled>
	</properties>
</channel-definition>

f) przykładowa definicja obiektu, który ma zostać wystawiony Fleksowi (znowu web-application-config.xml):

<!-- Implementation of HelloService -->
<bean id="blazeHelloService" class="pl.espeo.blog.HelloServiceImpl" >
</bean>

<!-- Expose the blazeHelloService bean for BlazeDS remoting -->
<bean id="helloService"
	class="org.springframework.flex.messaging.remoting.FlexRemotingServiceExporter">
	<property name="messageBroker" ref="mySpringManagedMessageBroker"/>
	<property name="service" ref="blazeHelloService"/>
</bean>

Po takim skonfigurowaniu z poziomu Fleksa powinien być dostępny obiekt o nazwie „helloService” jako remote object.

2.Po stronie Fleksa:

a) odpowiednia konfiguracja do współpracy z BlazeDS – ustawienie projektu do korzystania ze standardowego pliku services-config.xml

b) obiekt „helloService” użyty we Fleksie:

<mx:RemoteObject id="helloSrv" destination="helloService"/>

Po prawidłowym ustawieniu plików konfiguracyjnych w obu aplikacjach można bezproblemowo cieszyć się springowymi beanami dostępnymi z poziomu Fleksa. Dokumentację dotyczącą projektu Spring BlazeDS Integration można przeczytać na stronie projektu:

http://www.springsource.org/spring-flex