New Flash Remoting Product for Java Developers

Discussions

News: New Flash Remoting Product for Java Developers

  1. Midnight Coders, LLC announces the availability of the first beta of FlashORB - an alternative to Macromedia Flash Remoting. FlashORB Java Edition can expose any Java Object, EJB, Web Services or any other server-side component for Flash MX clients.

    FlashORB is fully compliant with the Action Message Format (AMF) protocol and allows seamless integration with all Flash MX Remoting clients. It has 2 execution modes (standalone and hosted) and an extensible variety of supported service types. FlashORB provides a rich set of qualities and features for building distributed client-server systems. Some of the features are:

    - service inspection framework
    - support for built-in and custom activation modes
    - custom service adapters
    - integration with multiple web services frameworks
    - remote references

    One of the most powerful features of FlashORB is support for service activation. FlashORB supports three activation modes (Session, Request and Application) and also provides a very simple way to define custom activation modes. Service activation support makes it very easy to implement various object activation schemes with no custom programming.

    For more information about the product or to download an evaluation copy visit http://www.flashorb.com

    Threaded Messages (17)

  2. I know there is a PHP remoting implementation http://www.amfphp.org/ . Are there any similar open source projects for java?

    What are the advantages of using remoting over loading xml objects?

    -M
  3. Free alternative[ Go to top ]

    http://www.openamf.org/

    Keep in mind that all this flash remoting stuff is mostly marketing. You will likely run into problems (all reverse engineered protocols) and don't expect to transfer "complex" objects in any other form than a simple hashmap.
  4. Support for complex types[ Go to top ]

    Christian,

    One of the core differences of FlashORB is that it has full support for complex types. The product automatically transforms objects sent from the Flash clients into the complex types from the method signature.

    cheers,
    Joe
  5. Re: Support for complex types[ Go to top ]

    Well, I've worked on a project the last couple of months with flash remoting and FlashORB wasn't out at that time. So we had to choose OpenAMF and add our own fixes (which are now integrated into the main branch) for security and some other minor issues.

    I couldn't believe my eyes when I first looked at flash remoting and found that _no_ security checks were in place! With the old OpenAMF (and AFAIR with the MM remoting server extensions), any client can call any Java method on any object via Reflection. No, I don't want to go back and check this again, I'm glad it's working for me now ;)
  6. I have tried Flash ORB, and I already see how much easier it is to
    expose Objects with Flash ORB.

    - Support fort Complex Types

    I think this alone makes the product way better than FlashRemoting.
    It is a real mess to expose existing Business Services for flash.
    Writing Adapters to perform conversions from HashMap to existing
    Value Objects is a huge, huge disadvantage of Flash Remoting.

    Good job MidnightCoders !!!

    Looking forward to .Net version of the product.

    Flash Developer
  7. http://carbonfive.sourceforge.net/flashgatekeeper/api/com/carbonfive/flashgateway/security/package-summary.html

    "FlashGatekeeper provides Flash Remoting security features. It is an implementation of a Servlet 2.3 Filter that limits the services that can be invoked by Flash clients through Macromedia Flash Remoting MX for J2EE and for ColdFusion J2EE Edition on any Java application server."
  8. Macromedia Flash Remoting MX is an application server gateway that provides a network communications channel between Flash applications and remote services.
    Using Remoting User can directly read the Java,.Net,PHP Objects into flash client.
    So no Parsing issues which are in XML Objects ie. If we are having xml with more than 1000 nodes the flash will throw an error.
    Simply Remoting is bypass for XML parsing.
  9. How about performance ?[ Go to top ]

    With all due respect to all the team behind this I would like to know the performance metrix. Flash itslef is kind of slow to work with & on top of that you have remoting. Please let me know.

    thanks
     - Sean
  10. FlashORB benchmarks[ Go to top ]

    Hi Sean,

    We are working on a set of benchmarks comparing our product performance with such of the competing technologies. We will be publishing it as soon as 1.0 is released. If you're interested in a copy in advance, please email me at orbman at flashorb.com

    thanks,
    Joe
  11. 1) You can already connect Flash to service layers using just Flash itself, and don't need Remoting in order to do it. I don't want another gateway on my server, I simply want my web and services layer. Using Flash's XML, LoadVars, and XMLSocket I can access those without bothering with AMF and without dealing with a gateway regardless of whether that gateway comes from a big vendor everyone hates, a small vendor who feeds off the scraps tossed aside by that big vendor, or even from an open source group.

    2) From a friend in current MM betas it looks like Flash Remoting and AMF are discontinued anyway and that they managed to get the Flash player running native SOAP faster than they got AMF running. Complex types? Heck if it supports XML Schema why should I care who created the best proprietary way of transferring objects.

    3) Performance? You can only improve the server side performance and you have no control over the Flash player at all, so developing add-ons and claiming they're better than what MM can do is as silly as saying you can develop a better version of .NET for Windows XP than Microsoft can. Any gains are temporary, not worth investing in beyond hobbyist dabbling, and in many cases like this one, deprecated and obsolete nearly as soon as they're created.
  12. Flash Remoting FUD[ Go to top ]

    Folks,

    We have been using Flash Remoting in anger since the beta, are shipping enterprise apps with Flash UIs, and have been impressed with what can be achieved with Flash Remoting. FlashORB is an interesting product ... it potentially provides an out-of-the-box solution to a number of the problems that have to be addressed with native Flash Remoting. Flash Remoting is nothing other than the network-transport layer...and services/libraries that utilise this framework can address all of the concerns raised above.

    First of all; XML versus Flash Remoting. To transfer data with XML requires that complex graphs of data (value objects) need to be XML serialised and deserialised between the client and the server. The Flash Player isn't the best place IMHO to be doing XML (de)serialisation, and it's overhead on the server-side as well.

    Flash Remoting provides a well-defined protocol for passing objects back and forth. Some of the J2EE community increased the value of Flash Remoting with the open-source ASTranslator project, which allows the passing of value objects, and collections of value objects, across the client-server divide. We have our source at http://carbonfive.sourceforge.net/astranslator/ and the implementation of the translator is covered in good detail in Reality J2EE which I wrote for Macromedia Press last year. Using ASTranslator, we can pass data to a flash presentation tier and back again, in the same well-defined best practice ways we would with a JSP tier. We can integrate a flash client upon a sound J2EE architecture from the business delegate or session facade downwards, with Flash imposing no additional requirements on our architecture or implementation.

    Yes, there are security issues with Flash Remoting that we all discussed to death in the community; the solution was to use security policy files, but a more elegant and better solution arose from Alon Salant at Carbonfive, in the FlashGatekeeper project mentioned elsewhere.

    As for the FUD about performance and deprecation of Flash Remoting ?!? Well, Flash Remoting is nothing other than a protocol for passing data in a binary fashion in the HTTP header between Flash and J2EE, and is nothing more than a library of code on the client and server. It's released, that can't be taken back. Regarding performance, our experience is that it's possible to write clients badly, adhere to bad practices on the user interface design and implementation, employ poor developers who fail to account for the technologies and their limitations, and write terrible performing applications. More importantly, it's our experience that a decent Flash developer and designer can produce an intuitive, interactive and responsive user interface, that loads quickly and provides the user-experience akin to a desktop applicaiton. In face, we've found that when selling such applications, we've almost lost clients who have seen and used the application, and dismissed it on the grounds that they don't want something that has to be installed on the client (it doesn't have to be installed on the client, but their experience in using the application leads them to falsely believe otherwise).

    So in short; XML/LoadVars requires too much performance out of the client, and requires that we write our own serialisers and deserialisers. Flash Remoting takes care of that for us. Add in ASTranslator and FlashGatekeeper, or take a look at FlashORB, and we can pass graphs of value objects, control security as per EJB -- down to the method level if we want, according to J2EE security roles. Performance is fantastic - as good as JSP - and the experience delivered surpasses that that can be achieved with an HTML UI.

    I don't work for Macromedia or Flash Remoting, I just develop bespoke enterprise Rich Internet Applications, and have found Flash and Flash Remoting to be the best tool for the job for the last 12 months.

    Steven Webster
    Technical Director, iteration::two
    Author, Reality J2EE - Architecting for Flash MX
  13. Re:Flash Remoting FUD[ Go to top ]

    While informative, this note discusses only the current state of Flash but didn't respond to what's coming and what's apparently in beta now.

    > First of all; XML versus Flash Remoting. To transfer data with XML requires that complex graphs of data (value objects) need to be XML serialised and deserialised between the client and the server. The Flash Player isn't the best place IMHO to be doing XML (de)serialisation, and it's overhead on the server-side as well.
    >

    Until or unless MM updates this in the next player which people in their betas are saying they have.

    > As for the FUD about performance and deprecation of Flash Remoting ?!? Well, Flash Remoting is nothing other than a protocol for passing data in a binary fashion in the HTTP header between Flash and J2EE, and is nothing more than a library of code on the client and server. It's released, that can't be taken back.

    Wrong. When MM releases a new Flash player it gets distributed across the world overrwriting previous players. If a better alternative exists like binary native soap or something else that they can somehow make perform better and can get out to their developer community through their tool, then amf is deprecated. If MM primarily supports and services other new alternatives then remoting is also deprecated as a valid business investment. And of course if MM decides not to support amf in the future player or if it changes amf, then it is completely gone, not that I think this last thing will happen. The flash player is not a jvm, and the swf format may be openly documented but it is not a standard, it can be changed at any time and redeployed globally by a single vendor without notice to any of you secondary flash consultants or MM bottom feeders.
  14. Re:Flash Remoting FUD[ Go to top ]

    Based on ur discussion i feel that there is going to be one more "Download Latest Flash player " link on most of the new applications in future. I hate that thing. So many users sitting at home ( not so techy ) have so much trouble doing it ( specially on so many different browsers ).
    MM people have no better way of doing this transition ?
    Can they not do it seemlessly ?
    I know I m kind of going off the topic , but thats one of the core problems with FLASH / FLASH players on browsers - installing one or getting latest one .. it sucks ........
  15. Flash Remoting FUD[ Go to top ]

    Why would you use a proprietory product with limited devtools to develop an enterprise app ? I can understand creating those annoying animations using flash but and enterprise app in flash? What possible justification do you hae for not using DHTML or even Java applets and opting for (definitely very anoying) Flash ?
  16. Flash Remoting FUD[ Go to top ]

    i agree with u.
    this remoting seems too annoying and i m sure its going to be hamper the performance to a great extent - the whole design seems ot have too many layers / data conversions & exchanges - it cannot be fast.
    but may be i m wrong.
    anyway I wont be using it for anyting other than a fancy site, that too if really needed.
  17. Flash Remoting and Flash MX 2004[ Go to top ]

    http://www.flash-remoting.com/articles/fr2004pt1.cfm
  18. Help needed[ Go to top ]

    I am currently undertaking a project for my MSc. I am creating an audio player that will play streaming mp3s accross the web. This, I have managed easily with Flash. Now what I want to do, is provide an equaliser that the user can adjust client side.
        
        Obviously this is working with the sound at a level that is too low for flash. I have chosen to write this equaliser (filter) using Java. This enables me to take a sound file, alter it and send it on to the sound card.
        
        My problem now is using java to pick up the sound coming from the flash mp3 player. I know that there are classes in the Java Media Framework that can pick up audio streams from devices. However I havn't yet been able to catch streaming sound from the Flash player. I don't think this is one of the default devices that javax.media.CaptureDeviceManager.getDeviceList() detects. Maybe I can add it somehow.

        I have now started looking at interfacing Java Backends with Flash. My hope was that I'd be able to create the Flash player from within a Java application and so have control over the sound object. I am less hopeful of this after searching the web.

        Is there any way that I could pass an object from Flash to a Java Applet on the client side?