Flex + Seam integration approaches

[stu2]

I wonder if there's interest in discussing the pros and cons of ways a Flex UI might communicate with a Seam backend.

In a previous thread someone described using the Seam Remoting support and the AjaxFlex bridge http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114080.

Another way would be to expose Seam components as WebServices, as described in Chapter 20 of the Seam Docs, and then consume these directly via the Flex UI.

Another might be to use the Flex Data Services support for directly remoting Spring beans, and using Seam's Spring support as a Flex adapter http://www.adobe.com/devnet/flex/articles/spring_flex_02.html

The latter two seam the most appealing to me, though I haven't yet tried any of these out. Is there anyone on the list who has begun exploring approaches? I wonder what findings have been.

How might security contexts be propagated so Seam can have what it needs for authorization? Are any of these better suited for conversation propagation? A stateful UI removes the need in many cases, but it could certainly still be useful.

Which do you think is the most promising from a productivity standpoint?

Thoughts?

[stu2]

Oh, duh. Ixnay my last suggestion - using the Spring <-> Flex Data Services integration as a crutch. Turns out that's a user-provided adapter between FDS and Spring. So going that route would be silly. It's just a small class you register with FDS via web.xml.

http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&extid=1035406#

What's slick is that it should be straightforward to do the exact same thing for Seam. What's nice about this approach is that it lets Seam components be accessed as strongly typed components directly within Flex. Remoting is handled transparently.

The drawback is that the FDS gateway is not free if you want to deploy it clustered.

Anyway, I'll be exploring this stuff at some point over the next few weeks. I'd like to get a handle on how well Flex works when requirements for richness overstretch Richfaces/IceFaces, etc. I'm particularly curious about the possibility of hybrid apps, where part is classic Seam/JSF, but certain tricky sections are Flex.

[pmuir]

I'm very interested to see what you come up with Stu. Would be great if you can write up what you find (wiki or blog or whatever) and post back!

[stu2]

No tinkering yet, but I've done quite a bit of research.

The approach I'm most drawn to is the optimized flex remoting support. The serverside impl from Adobe (Flex Data Services) costs on the order of $20,000/CPU apparently... #$%^ scratch that. I just stumbled on http://www.graniteds.org/confluence/display/INTRO/Granite+Data+Services, which is open source, and very actively developed. From reading the newsgroup it looks far enough along to be worth pursuing.

And someone's already begun working on a Seam adapter. http://tech.groups.yahoo.com/group/graniteds/message/272. Serverside, the remoting support needs to know how to instantiantiate client-requested objects. So supporting this should just be a matter of creating an appropriate factory. There's already support for Spring, so it shouldn't be very difficult to add this in (I'll tackle it if it isn't done when I'm at that point).

Flex WebService bindings are appealing, but the details look kinda icky at this point. My biggest concern is that the bindings are all dynamically - there doesn't appear to be any wsdl2actionscript type aproach. When sending graphs back and forth, the fragility of typelessness makes me not want to go there. The next beta of Flex Builder 3 supposedly addresses this (btw, that's a $500 tool).

Anyway, I'm just posting this in case others are scoping this out too. When I dig into code I will certainly blog/post about experiences.

[cingram]

I have working code for a factory that will look up Seam comps using Flex Data Services. The code is pretty trivial and is based a lot on the Spring factory. FYI the issue isn't so much looking up the comps from the Factory. It is more getting it integrated with the conversation model of seam as well as the JSF life cycle. You have to provide an adapter that will integrate in to the JSF life cycle. I have some working code for that as well(it is definitely trivial). If you are interested I can post it. I gave up that route for a few reasons 1. Price 2. Size the libs added about 20 extra megs for me. 3. Time I needed to get a working prototype up and going and didn't have alot of time to figure out how to get the conversation model integrated.

[cingram]

http://www.graniteds.org/confluence/display/INTRO/Granite+Data+Services

That does look very promising!!

[stu2]

Nice. Your experience binding seam via FDS sounds similar to that of someone who began the same thing for GDS. The guys developing GDS have listed Seam integration as one of their main priorities for the 1.0 release, as described in http://tech.groups.yahoo.com/group/graniteds/message/539. They also are looking for help. The nice thing about GDS is that the codebase is pretty clean and comprehensible. Looking at their Spring, EJB and hibernate examples make it very clear how to do the Seam one - except for the conversation part of course.

Another aspect of GDS I liked is that its Flex-side binding generator is EJB3 savvy, happily handling enums, annotations, etc. Seems to me like the project needs just a little push for it to become a better-than-FDS AND free option for Flex/Seam remoting. I'm hoping to be in a position to explore this next week, but if you're interested, I'd love to collaborate.

[cingram]

Thats sounds great! I would love to see a push for become a better-than-FDS AND free option for Flex/Seam. I would be glad to help in any way. Shoot me an email and we can see what we can get going.

[navidmitchell]

Hello... I am new to seam and flex but I have been using JSF for about two years. I am also interested in helping.