Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
OSGi without the Eclipse
It's become common to equate OSGi with Eclipse or Equinox, but in fact other OSGi implementations exist. This post from JW
blogger Oleg Mikheev fills a much needed gap - walking through the process of developing a Hello World bundle with Apache Felix and the IDE of your choice.
Featured Whitepapers
| Memory Analysis in Eclipse |
| Enterprise AJAX - Transcend the Hype |
Letters to the Editor
"Enhance Your J2EE Presentation Layer"
Joseph Shomphe
LETTER_HEAD: What's the advantage of Flash?
Joseph,
You contend that the applet solution is at a disadvantage to Flash because it requires the user to install a Java runtime. Doesn't the Flash solution also have this limitation? Doesn't the user need Flash Player installed? It seems like the Flash Player and the Java runtime share the same role.
Alex McCarrier
AUTHOR_REPLY:
Alex,
You are definitely correct about the client system requiring pre-installed software. The advantage of Flash over Java is twofold:
- According to Macromedia's figures, about 98 percent of all browsers have Flash already installed (see http://www.macromedia.com/software/flash/survey/whitepaper/page8.html for more information)
- Macromedia Flash Player 6 is extremely small: download time estimate is one minute with a 56 K modem, and the file size is 404 KB
Joseph Shomphe
END_REPLY
LETTER_HEAD: Flash and JMS
Joseph,
Does the Flash MX client support Java Message Service (JMS)? In other words, can a Flash MX client subscribe to a topic and dynamically receive data without requesting it?
Konrad Hernblad
AUTHOR_REPLY:
Konrad,
The Flash client does not really support any Java APIs. Flash Remoting allows you to invoke an exposed Java 2 Platform, Enterprise Edition (J2EE) method, and the results return in a Flash native format via an asynchronous callback method.
The flow for a Flash-to-J2EE method invocation looks like this:
- Flash client sends an asynchronous message over HTTP to the Flash Remoting application installed on a J2EE application server
- Since this message is asynchronous, the Flash application can continue without waiting for the result from the application server
- Remoting application unmarshals the request and synchronously invokes native Java method
- Java method is called and returns results to Remoting application
- Remoting application converts and marshals results to Flash client
- Since the method call was asynchronous, the Flash client gets notified that results are ready for the initial message, and the callback routine is invoked on the Flash client
Since Flash Remoting is inherently asynchronous, you can easily call a long-running method on the J2EE application server at any time. The Flash client will automatically be notified when the method completes. This assumes, however, that the Flash client initiates the transaction. In your case, you need the opposite: the server calls back to the client without ever invoking a method.
What are your reasons for using JMS? Can you describe your application a bit more?
Joseph Shomphe
END_REPLY
Joseph,
Thanks for your reply and detailed explanation. I am working on a type of intranet solution that will allow clients to listen to messages on a certain topic. With JMS and Swing, it is fairly easy, but Swing graphical user interface (GUI) development can sometimes get hairy in terms of code management. All IDEs use proprietary markers and so forth to manage their auto-generated code, so it might be difficult to switch IDEs later. Also, Flash apparently has a lot of components you can use to easily make nice screens and effects, whereas Swing might require custom building those components as GUI beans if they don't exist.
