The article discusses integrating with frameworks such as Spring, and persistence backends such as Hibernate.

Summary

This article introduced a number of concepts with the intention of exposing you to some of the tradeoffs and potential pitfalls when using a RIA such as Flex. Whether you use Flex or another RIA implementation, there are major considerations to take into account when architecting an application with this technology. When evaluating an RIA framework make sure it is extensible enough to meet the demands of the application. Furthermore, carefully evaluate integration issues that might need attention when transmitting objects between and RIA and a Java backend.

Integrating Macromedia Flex with Java

Can the same thing be done with Laszlo? Or is this one of the feature advantages of Flex?

The only thing you need to integrate spring + hibernate in other technologies if there is no plugin is :
* getting the servlet context
* passing the servlet context to webapplicationcontextutils
class to get a spring webapplicationcontext
*then with webapplicationcontext you can find your beans.

For those of you willing to consider embracing Flex as an enterprise-ready rich-client technology, but who would be reticent about embracing a technology if they had to throw away their best-practice J2EE development, then I'd like to draw your attention to some open-source projects that recently emerged from iteration::two.

First of all, we recently open-sourced "Cairngorm", an RIA Microarchitecture that is based on the Core J2EE Patterns that we have found relevant to the delivery of Enterprise RIA. Cairngorm is an object-oriented ActionScript 2.0 implementation of a number of collaborating patterns, such as Front Controller, Service Locator, Command Pattern, Business Delegate, Value Object, View Helper, etc. This allows for best-practice development of client-side business logic and workflow, that would previously have lived in the application server. You can find more details currently at:

http://www.richinternetapps.com/archives/000094.html

Additionally, for those of you that have a discipline of unit-testing or test-driven development in your J2EE tier, who might have understandable reticence to moving business logic over the wire onto the client, we have recently released the FlexUnit unit-testing framework for Flex applications - this allows you to unit-test any client-side classes, using an identical workflow to JUnit. Again, more details can be found here:

http://www.richinternetapps.com/archives/000091.html

A great deal of myths abound, regarding the speed, performance, accessibility, etc, etc, of rich-client interfaces delivered into the "Flash Virtual Machine" in the browser. For those with preconceptions about what delivering an RIA with Flex actually means, I'd suggest spending a little time seeing what Flex *actually* delivers, and how it enables the J2EE developer to offer it, before denigrating it.

There is a serious enterprise development community, who have cared about best-practice J2EE development, and now infuse that practice in a forward-looking manner, to this emerging if not emerged discipline of RIA development.

The article describes Macromedia's AMF protocol. The OpenAMF (www.openamf.org) project is an open source implementation of the AMF protocol.

If you are still building traditional Flash applications using the Flash MX IDE, take a look at Flash Remoting:

http://wiki.java.net/bin/view/Javapedia/FlashRemoting

No need to make my apps slower. And really noone cares for flash on the sites anymore. The fad was over years back. Dont try to put life in a dead technology. Besides a few flashy websites there is no use.

gosh !! you really did not understand anything about RIA !!!

make slower what ?

you are trying to say that tabbing in a RIA is slower than doing a complete round trip to the server ?

or trying to say that that moving a slider is slower than doing tens of round trips ?

are you trying to say thar client-server and desktop apps are slower than web apps ?

I don't know which internet you use, but mine is awash with the multitude of ways that Flash can be used. As for slow, that's down to understanding the technology and using it efficently & correctly - Java could be deemed slow when simply it is just a project not written efficently.

I would suggest you look into the capabilities of a Flash UI before dismissing it so quickly - ActionScript is a powerful language and allows for alot of flexability, and when our clients are provided a HTML interface and a Flash one (functionally the same) - they buy the Flash one every time.

Finally, dead technology? I beg to differ, with Video / Audio streaming and conferencing through Flash Communication Server and Flash Remoting, the browser has never been such a multimedia environment - and best of all, you'll find it on almost as many machine as have browsers.

It would be very foolish to count Flash out of the technology market just yet, keep an open mind.

I can see a million opportunities for Flash (or a "Flash-like" technology) to fill the gaps where HTML falls down. If only Flex wasnt so expensive/Laszlo supported Flash 7/etc etc...

I can see a million opportunities for Flash (or a "Flash-like" technology) to fill the gaps where HTML falls down. If only Flex wasnt so expensive/Laszlo supported Flash 7/etc etc...

Sure, Flex accelerates use of Flash. But can do without as well.. just by using Flash scripts, we built a complete J2EE Server Dashboard. Very rich UI with extensive stats & plots. Try the dashboard's live demo at- http://demo.pramati.com/index.htm

Cheers,
Ramesh
www.pramati.com

That management UI is actually pretty slick, and this is from someone who generally doesnt like flash, and is also generally reluctant to click on a vendor talking about their own product.

Miko

Hi Rory,

Have you had a look at Canoo's UltraLightClient?
http://www.canoo.com/ulc/

UltraLightClient is a library to build Rich Internet Applications (RIA) in Java.

Canoo offers a clear and simple pricing model:
A ULC developer license costs 1495 $, runtime distribution is free.

regards,
Sandra

Checkout Sulu. Similar in concept but better. For example, an application written using Sulu can use any protocol to connect to the backend not just http and a proprietary protocol like AMF. Jython is the main scripting language. There is plan for support other languages like JRuby. Sulu XUL will be 100% compatible with Mozilla XUL.

oops for got the URL
http://sulu.sourceforge.net

Let me know when they support an internationally standardized language like ECMAScript. Honestly, that's one of the things I like about Laszlo's selection of it. (1) I already know ECMAScript, (2) it's a standard.

Pluggable languages sound nice and all, but that means the particular client you're using has to understand it which will only work fi there is only one client.

I'm looking forward to an RIA world where there are standards and many clients competing to be the best implementation of thats tandard.

hmm... is there any complete implementation of ECMAScript? According to http://en.wikipedia.org/wiki/ECMAScript, there seem to be only partial implementations.

It would be relatively simple to integrate http://www.mozilla.org/rhino/ into sulu, however I have a distaste for javascript as a language. I wrote some applications using Mozilla XUL and javascript. I really like Mozilla XUL, but writing application logic with javascript just doesn't agree with my mindset. Python and Ruby is closer to how I think. The goal is to be able to use any language that's available for the JVM. It will be possible to invoke objects across languages by just exposing interface.

If you write a patch to integrate rhino, I'll be happy to apply it.

-son

The goal is to be able to use any language that's available for the JVM. It will be possible to invoke objects across languages by just exposing interface.If you write a patch to integrate rhino, I'll be happy to apply it.-son

Son, you probably already know this, but just in case....

IBM's Bean Scripting Framework already does a lot of the heavy lifting in integrating more than one back-end scripting runtime. Rather than writing a patch to support Rhino, why not write one to support BSF, and you'll get most JVM scripting languages thrown in for free?

From the article:

Son To: Why Python? Because it's an elegant language and because I know it well. JavaScript is an ugly language... Because Mozilla only has good support for JavaScript I had to create SuZilla to avoid writing business logic in JavaScript. I am thinking of using BSF so that other languages can be added, but I don't know too much about BSF.

Pluggable languages sound nice and all, but that means the particular client you're using has to understand it which will only work fi there is only one client.

You are right. SuZilla (XUL browser built using Sulu) is not intended to be a universal browser though it can be embedded in a browser as a java applet. The primary goal is to allow me to write Swing application declaratively like a web page and to deploy it like a web page.