With your modest requirements, use BlazeDS, which is an open source scaled-down version of LCDS and it implements AMF. If you'll use it with Clear Data Builder, your code development cycle will dramatically shorten. Read this article: [visit link]

Hi,
I am new to flex/RIA. I am exploring different design choices especially in client server communication. On client side we will be using Flash based RIA (using Actions scripts).
There will be some simple forms (like for login, registration, payments etc) and some simple reports including with several graphs and charts. Each chart might have 1000 to 1500 data points etc. There are not video or audio content as such. On server side we have Servlets, java API and some EJB’s to provide the business logic and real time prices/content (price update is usually every 10 seconds) /data. Some of the content will be static as well.

I have following questions in my mind. Is it worth it to use RTMP/AMF channels for the followings?

1. For simple forms processing (Mapping Actions scripts classes to Java classes). Like to display/retrieve/update data for/from registration forms.
a. If yes, why? Am I going to be stuck with LCDS? Is it worth it? What could be the cons for heavy usage/traffic scenarios
b. If not what are the alternates? Should I create the web services? Or only servlets are sufficient (ie. Only HTTP+Java based server side with no LCDS+RTMP+AMF)? All forms need to communicate on secure channel.
2. For pushing the real time prices/content which we may need to update every 15 seconds on user interface using graphs and charts. Can I do it with some standard J2EE/JMS way with RIA (Flex) on front-end? i.e. Flash application will keep pulling data from some topic. Data can be updated after few secs or few minutes which can’t be predicted.
3. Are there any scalability issues for using RTMP? What happens if concurrent users increase 10 times within a year?
4. What are the real advantages of using RTMP/AMF instead of simple HTTP/HTTPS probably using xml based objects
5. Do I need to use LCDS if I am using AMF only on client side? Basically I mean if I am sending an object in form of xml from a servlet. Can some technology in Flash (probably AMF) in client side map it an Action script object?
6. What are the primary advantages of using LCDS in a system? Is there any alternate solutions? Can I use some standard solutions for data push technologies?

I would like that my server side implementation can be used by multiple types of clients e.g. RIA browser based, mobile based, third party software (any technology) etc.

I appreciate if you can kindly refer me to some reading materials which can help me deciding the above. If this is not the right place to post this message then please do refer me to the place where I can post such questions.

Thanks and Kind regards,
Jalal

You do not need FDS to connect to your JSPs, just use HTTPService without proxy, for example: [visit link] You can also connect to your POJO using OpenAMF - an open source implementation of the AMF) protocol. We use it in one of the versions of our Web Reporter ClearBI.

I have searched high and low for a resource describing how to use FLex2 without FDS and keeping the pojo beans as a backend server. In other words, how do I configure my jsps to add mx tags and display flex fragments using standard getters and settings in my java beans without going through FDS?

Balu,
The note is quite cryptic. Please feel free to contact us at support@faratasystems.com.

Kind Regards,
Victor

hi..
i have one problem, that is in my flash project is not open through tomcat server. In flash i am loding xml.what can i do for accessing my swf.

Thanks for your reply, Victor. Yes, it's the configuration problem and now I've figured it out. Thanks.

Sally,

Must be the configuration issue. Feel free to contact me my faratasystems.com e-mail and I will help you out.

Kind Regards,
Victor Rasputnis

Hi,

There is an error: Couldn't establish a connection to "Portfolio", when I try to run this example. I copied the code exactly. What's the reason for this error?

Hi,
I could not make much use of this article since midway it just wanders from actually giving us an insight into the integration.

I get a few listings containing codes ... but am not able to figure out what goes where!

I have been workin with flash using flash remoting and WSAD for the IDE.

But I could not get any further after the first page.

Vitaliy,

Thank you for your feedback. Let me start with one "platform" statement: Flex is the application server solution with service oriented client layer built on top of the Flash Player.

Now, I will jump to the point where you started agreeing with us and from there will walk through the list of concerns all the way back.

<<4. Flash has no threads, no thread management.>>

I find this rather hard to justify as it is.
Multithreading capabilities are implemented in browsers as well as in the Flash Player. You may question, however the level at which these capabilities are available to a programmer.

After all, the beauty of XMLHTTPRequest is that it is asynchronous, isn't it? Otherwise we'd be saying JAX instead of AJAX :). Similarly, the same asynchrony has been available with Flash Remoting since 2002 or 2003, if I am not mistaken. Here is the link just for the reference
[visit link]

Let's take your use case - "some calculation". Must be something CPU worthy, I guess. The question is where does it belong in the distributed system, regardless of the Swing/Flash debate. Perhaps on the server, closer to datasources? Then, using remoting capability of Flex/Flash, I would suggest a POJO running not only in a separate thread, but also on a separate machine, across the wire!

Now, just out of curiousity, let's try to play without the server, with Flash alone. Here is another take: can you have another "servant" application run by the Flash Player within the same hosting HTML page? Can you interop via LocalConnection object to invoke methods, pass parameters - all with complete marshalling of complex datatypes to native objects?
Wouldn't it be hapenning in the different thread?

So, perhaps we can come to a more accurate statement: There is no pre-emptive multithreading within single Flash VM. This might be indeed an issue if we had to take distributed computing out of the picture.

But we don't have to, do we?

<<3. There are no skins for different components...>>

This one is simpler. If you are, in fact, talking about Flex, which has a totally different code base from Flash controls, the statement is outright ungrounded. Flex controls support pretty advance skinning, although my fascination to the subject went south after I skinned a couple of controls.

But then there goes another part <... Adobe .. main interest is in popularizing visual effects..>

Well, this is one very popular illusion, I might say. How about this answer: Adobe Flex offers developers
a JMS adapter that enables to create a producer or consumer with one line of XML code? How _visual_ is that?

<<2. Flash components are closed source...>>

I have a secret to tell. Flex comes with full sources. Look at them, step them through, do whatever you please.

Just do not tell Adobe I told you :). Seriously, are we sure we are talking about the same products here?
Our article was about FLEX.

<<1. Flash components are badly written ...>>

Vitaliy, as a person with many years of software vendor experience I can only tell: Thou shall not judge...
If indeed we are both talking about Flex, I find their components extremely well done. Not that I doubt
for a split second that you can find a handful of cracks in each of them. But, being an expert, you naturally see how to avoid a problem - in another split second, don't you?

Also, now that you have the full source code of the controls (you do, I kid you not), what stops you from overriding any given method and create your own Accordion or whatever? Flex community and Flex engineers are very friendly people which will gladly accept and appreciate any good ideas you might want to offer.

And as to your references to problems with Flash Player itself, here is
another news: Flash Player 9 (Flex 2 comes with it) is a complete
reengineering of the Flash engine, including API. New Player has "dual
mode", i.e. it can play old stuff as well.

<<0. There are number of Java XUL implementations...>>

Since apparentlly this is a response to MXML-based code generation I would offer only one comment:

Flex is an Enterprise Class Solution. Most likely we did not make all points right in the article and,
frankly, we could not. It particular, we have not explained the power of data binding.

But even if we had, Vitaliy, you really owe it to yourself to try it. I think you will love it.

Very Friendly,
Victor Rasputnis

Hello,
I have been working both with Java Swing and ActionScript while creating gui. Here are my observations that defy your statements in the article.
1. "Imagine the amount of Java code you'd need to write to achieve the same functionality." - WRONG, there are a number of Java XUL implementations ([visit link]) Swixml is one of my favorite (www.swixml.org/).
2. "...but we wouldn't have to worry about routing all events to the event-dispatch queue." - WRONG, in Java you use listeners and handler functions to attach to the gui events, events are routed automatically. Creating custom events in ActionScript would take just as much effort as in Java (or probably less, since it has Observer,Observable and other utility classes in the rt library, unlike Flash).

Now the drawbacks of using Flash (components v.2) over Java:
1. Flash components are badly written, there are many undocumented bugs that you would never overcome. Eg. try adding a combobox to an accordion pane, or a menu inside of a scrollpane. The most awful truth about Flash components is that they are badly integrated with one another and putting them inside one another will most likely result in something quite unpredictable (only frozen layers from a component can be seen, focus frame cannot be set, drop down layers are displayed underneath another nearby components, etc.)
2. Flash components are closed source and even if you care to dig into the truth you wouldn't risk changing anything because the bug is in the layered structure of flash drawing and some constraints on using the depths of those layers.
3. There are no skins for different components, and it's unlikely that Adobedia will come up with something unbuggy in the next release, since their main interest is encreasing feature set and popularizing some visual benefits, but it's a hell to programmers. (Some 4+ releases on my history have proven that at least to me).
4. Flash has no threads, no thread management. If you start some calculation or even a simple data manipulation or object creation during some visualization process you get a freezer.

All the rest about the small size, video/audio, web integration, cross-platformedness is true, but I wouldn't use Flash in a project with complex GUI.
Regards,
Vitaly

Forgot about Flex. I have run through and test the product from the very beginning to the end. This product is seriously handicapped.

I would suggest you either to use Flash directly, use Java or even the new Microsoft Expression Interactive Designer based on .Net framework

A typical Java developer knows that when you need to develop a GUI for a Java application, Swing is the tool. Eclipse SWT also has a number of followers, but the majority of people use Java Swing. For the past 10 years, it was a given that Swing development wouldn't be easy; you have to master working with the event-dispatch thread, GridBaglayout, and the like. Recently, the NetBeans team created a nice GUI designer called Matisse, which was also ported to MyEclipse. Prior to Matisse, JBuilder had the best Swing designer, but it was too expensive. Now a good designer comes with NetBeans for free.