We like the flash based uis as well, but we're probably going to go with OpenLaszlo. I think it addresses some of your concerns, particularly the point about proprietary technology, since it's open source, and documentation, since there's plenty of documentation.
As to your second point, about integration with seam...we're planning on using the web service interface to seam components (which doesn't exist yet...we're waiting on http://jira.jboss.com/jira/browse/JBSEAM-505 ) to communicate with laszlo, which can consume web services.
The right way to integrate things like Flex is probably to do it via Seam Remoting. At one stage James had this working for flex, but we never ended up getting to see the code. Micheal Neale has managed to integrate GWT using the same means.
I will definitely look into Seam Remoting. But I am curious why that is necessary. I know next to nothing about Flex, but I understand there are Java objects, essentially DTO's, that are mapped to ActionScript objects for display in Flex. Why can't these be conventional Seam-managed POJO's?
DavidInTx, why are you waiting on Seam WS as opposed to using Seam Remoting now? I am curious what Seam Remoting lacks in the context of your needs.
If you can rely on flash 8 being installed, then it doesn't make much difference. Here's how you would do it via remoting
var customers = EnternalInterface.call(Seam.Component.getInstance("customerAction").getAllCustomers());
and here's what you would do for Web Services:
<soap name="mySOAP" wsdl="http://myServer/customerAction.wsdl"> <handler> var customers = mySOAP.proxy.getAllCustomers(); </handler> </soap>
Thanks for the explanation, DavidInTx.
In your experience, can you use all the compelling Seam features like JAAS security, transactions, and conversation scope with Flex ActionScript components?
Of course, every technology has a space in which it is appropriate, and no technology is perfect for every situation. I am just not sure which framework, Seam or Spring, is better suited to integration with Flex. There are a good number of resources on Flex-Spring integration and none on Flex-Seam integration, but I believe that is more a function of Spring's age and popularity than any real technological superiority to Seam.
Besides DavidInTx obviously, does anyone have experience leveraging either Spring or Seam with Flex? Is there a better choice?
With respect to:
I was just curious if anyone had begun work on a more standard bridge between the two - perhaps via the 'factory mechanism':
Seems like Flex/EJB3/JPA2 (using mx:webservice/EJB3WS with no FDS) would be a nice, clean RIA/JEE approach.
Curious - what is the status of http://jira.jboss.org/jira/browse/JBSEAM-505 - any idea of when this would be part of GA and be included in the Seam documentation?
There is one example project in cvs which is already has web services built in--seambay (careful--it's not seampay, which is another example project). However, as seambay is not included in the copyexamples task in the build.xml in cvs, you'll have to do the following:
1. Check out seam from cvs.
2. Modify the build.xml that is directly under the main seam directory. Specifically, search for
<target name="copyexamples" description="Copy examples to dist dir">
and then add
<include name="seambay/**/*" />
to the list of examples to be copied.
3. run "ant dist" in the main seam directory, which contains that build.xml that you just modified. You will get a jboss-seam-1.3.0-ALPHA directory created next to the jboss-seam directory you checked out from cvs.
4. Go into the jboss-seam-1.3.0-ALPHA directory, and modify your build.properties file to point to your jboss location. (Seambay doesn't work with tomcat--that may be why it's not included in copyexamples by default).
5. Still in the jboss-seam-1.3.0-ALPHA directory, go to examples/seambay, and type "ant deploy".
6. Start up jboss, and point to localhost:8080/seam-bay, and play with the example. In particular, register via the regular ui, and then go to the test page and send ws requests as desired.
7. I didn't see any documentation regarding whether or not the wsdl is supposed to be published somewhere. However, when I was watching the jboss startup logs, I saw this message:
10:46:52,401 INFO [WSDLFilePublisher] WSDL published to: file:/C:/Program Files/jboss-4.2.0.GA/server/default/data/wsdl/seam-bay.ear/seam-bay.jar/AuctionServiceService62575.wsdland sure enough, the wsdl was there. Note that the numbers (62575) seem to change each time I restart jboss.
Just re-read the thread -- looks like you were already all over this :-).
How goes it? Got ur Flex UI + SeamWS system at this point?
No, I had set it aside while waiting for http://jira.jboss.org/jira/browse/JBSEAM-505 to be resolved. Up until yesterday, Seambay did provide a web service interface via @WebMethod annotations, which got picked up and exposed via JBossWS, but there was no integration into the seam lifecycle via things like conversations.
However, yesterday, org.jboss.seam.interceptors.WebServiceInterceptor was checked into seam cvs, and seambay was modified to work with the conversation id that the WebServiceInterceptor gets for it, so I'm guessing that progress is being made on 505.
Just for interest sake I have uploaded a very small example of using OpenLaszlo (which compiles into swf) with Seam to the JBossSeam page on the wiki some time ago.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSeam. Look at the example under OpenLaszlo + Seam - a basic example using OpenLaszlo to create a swf object (explode in examples/remoting)
I've been working with Flash since 5.0 and building quite a few Apps (e-Learning, CRM, Transport&Logistics etc.) on it.
The approaches used by Flex and OpenLazlo have been around some time now and on the first look it seems to be a great idea using them for RIA but there are also some downsides which you should consider first:
- target audience:
if the target audience, especially the clients (OS, Hardware) involved, is not known by you, there is a good chance to run into the following problems:
*Plugin not installed, not allowed (e.g. large companies, public sector, industry)
*Crashing/Hanging Webbrowser: Flash is not canny - you pay for the user-experience in means of ram, cpu -> be aware that the gc is quite lazy and after heavily usage of Flash-Apps mem-usage is running high -> problems started at ~150mb mem and 1 hour intensiv usage.
if its truly RIA you are heading for then you'll have some sort of desktop-style apps, not just small widgets embedded in plain html which leads to the following difficulties:
*no HTML in flash: don't try rendering iframes via dhtml on top of flash-objects in the circumstance that you have to display html content somewhere. so you have to stick to flash and forget about html. Sure, some things from html work - e.g. font tags, but many things won't work
*same with active-x controls of course
be aware that its quite painfull planning some sort of CMS within your RIA.
because flash is vector based several fonts and font-sizes are really hard to read - so its simpler to stick to the system font which makes it not so fancy again.
text-2-speech readers have major problems with flash. So if you are developing for .gov or .org you should inform yourself about the legislation of your customers country.
because of their development process in quite a short period of time (as1, as2, as3) every version has certain bugs that you'll have to work around.
- flash is great for multimedia-based content in specific target groups on predefined and confined specs.
the more your app should be able to grow, the broader the target audience and tasks your app has to fullfill the more you'll doubt your initial decision
Thx for the tips, livenow!
Looks like Flex3 will be overcoming many of the shortcomings you note:
Of course, the dark-side is strong as well - Silverlight (aka wpf/e) will undoubtedly give Flex3/AIR and others a run for their money