Transparency with FlexRemotingServiceExporter

[Helena]

I hope I am not taking the statement, "the FlexRemotingServiceExporter will be able to work transparently.." out of context but the sample below from the reference docs adds a layer of complexity to spring configuration. Example: I have 100 java services wrapping dao's etc, configured in Spring, plus their flex handler services to pipe the remoting calls. Wrapping each service in a FlexRemotingServiceExporter adds to configuration mayhem. Could we simply declare the FlexRemotingServiceExporter, annotate the services as @RemoteService or new similar type of annotation that wires it to FlexRemotingServiceExporter as a wrapper, where it does its job allowing dynamic creation of remoting destinations? But by the sample below it would add a lot of overhead to massive enterprise apps such as the one I am currently working on. We are partnering with Adobe on our framework, and I had just proposed to write a Spring Extension for this when 2 weeks later read the press release, so I look forward to seeing this module develop.



From: Spring BlazeDS Integration Reference Guide

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

Would it help to set a parent bean and save the implementors from adding the wrapper to each?

<bean name="fxExporter" abstract="true" "class="org.springframework.flex.messaging.remoting.FlexRemotingServiceExporter">
     <property name="messageBroker" ref="mySpringManagedMessageBroker"/>
</bean>

and then set
<bean id="product" parent="fxExporter" class="org.springframework.flex.messaging.remoting.FlexRemotingServiceExporter">
    <property name="service" ref="productService"/>
</bean>

I know this is just the first foundation release so this is just a suggestion (cutting down on configuration as you can already do dynamic destinations for java-flex at present). What i AM looking forward to is the JMS module with Flex Messaging. I've got this working now with Flex -Livecycle Data Services - AMQ - JMS, and hope this module will simplify implementations going forward.

cheers

[jeremyg484]

Yes, we will definitely be adding an annotation-based option that does not require the XML definition of a FlexRemotingExporter for each bean. We will also be adding an XML namespace that simplifies the process of applying the exporter in XML config.

[Helena]

thanks Jeremy

[k.v.ahuja]

Yes, we will definitely be adding an annotation-based option that does not require the XML definition of a FlexRemotingExporter for each bean. We will also be adding an XML namespace that simplifies the process of applying the exporter in XML config.

The annotation support is great. But, can i recommend another approach, where we can have a common exporter which takes a list of services as input and exposes them all. I have a project where i can not use annotations freely.