News: Amber v1.4 SDK: Alternative J2EE Presentation Layer Released

  1. Amber is an 'alternative presentation layer' targeted at J2EE apps with complex UI requirements. Amber utilises a light applet-based front-end and server-side processing approach to provide users with a "desktop-style" GUI running in a browser window. Amber is 100% Java and integrates easily with all J2EE-compliant EJB containers.

    Check out Amber.

    Press Release
    Clearfield Research Ltd has just released the Amber v1.4.0 SDK, an alternative presentation layer targeted toward J2EE sites that have complex user interface requirements.

    Amber utilises a light applet-based front-end and server-side processing to provide users with a fully functional "desktop-style" GUI running in a browser window. Amber is 100% Java and integrates easily with all J2EE-compliant EJB containers.

    See for yourself! Demos and a free downloadable trial are now online at


  2. Too many of these J2EE Presentation Layers...which one to use?
  3. We are aware there are a number of J2EE presentation options on the market, so that is why we have provided a downloadable demo. If you want to look a bit further, please feel free to download the demo and see if it fits your needs.

  4. Hi all,

    Can you tell the urls to some of those alternatives?

  5. Another alternative is Facado.

    You can check out this JAVA/XML based UI framework at http://www.nexusedge.com/facado.html

    With FaçadoTM, providing highly interactive event-driven interfaces, an organisation can now develop or move their business transaction systems onto the Web, keeping the event driven multi-window view (Multi-Document Interface), drag-n-drop, intelligent verifications-validations rules and collaborative look and feel on the Web browser.

    In essence, FaçadoTM delivers efficiently a smart Web desktop environment for your Web browser e-business system that is familiar to your users.

  6. Also check out the DEMO at this URL to see the power and flexiblity of Facado ...


  7. Sounds a little like Bongo, released by Marimba in '97.

    "That which has been is what will be, That which is done is what will be done, And there is nothing new under the sun."

    Ecclesiastes 1:9 - NKJV

  8. Bongo vs Amber[ Go to top ]

    The fundamental intention of Bongo is to build a standalone presentation module. Application logic has to be linked to this module, and the whole lot downloaded to each client. (Try integrating this into an EJB :-) )

    Amber, on the other hand, is fundamentally a thin GUI client in a browser which gives users a rich, functional application with minimal datacomm traffic where the application functionality itself is server-based.
  9. That's the problem with applets - out of 5 demos only one actually worked (paint your house) in my IE6 with 1.4 plugin.

  10. Apologies for this bug. This has now been fixed and the Amber demos should now work fine.

    Our intention is that Amber will work in all browsers with all Java versions later than 1.1

  11. I was only able to get the enterprise application (Airways) to work because I am behind a firewall. It is a good concept (as are applets and webstart) but in addition to the accessibility issues, it took several seconds to return a dozen records which is not acceptable.

  12. Amber Response Times[ Go to top ]

    As with all network applications, response times are dictated by the speed of the medium. I suspect the geographical separation is the problem here, as the demo server is a long way from the US.

    By running a traceroute, you can determine how much of the dead time comes solely from the network, and how much is being swallowed by the back-end server. I know that Amber uses socket-socket connections, and on close or fast networks, Amber applications respond almost instantaneously. Over an intranet or close internet connection, performance is very snappy. If you download the demo and try it out, you'd get a more representative picture.

  13. I think the poor performance is due to having the classes download seperately instead of having them packaged in a .JAR.