There are different ways of connecting Web clients written in Flex with the server-side applications being that Java, PHP, Ruby on Rails, ASP or anything else that can generate HTTP responses. Up till today, the  least expensive way was by using Flex objects  HTTPService or  WebService.  You did not have to purchase any expensive communication software to use these two Flex objects. For example, take, say Java Servlet ot JSP, remove the visual portion that it sends to the browser  - let it send the data only – and create a nice Flex front end that communicates with your J2EE server using HTTPService MXML tag.  The same goes for PHP or ASP applications. Or use Apache Axis and have it generate the WSDL  from your server side POJO and use Flex WebService tag  to consume the newly created Web Service.  If you compare an old Web application with an aging woman, this approach is similar to performing  a cosmetic surgery  operation – a fresh looking face on a somewhat  slow performing body.  This solution works for lots of people,  but can you turn this old lady into a young looking responsive girl?  Yes you can, if in addition to the facelift you’ll start pumping the blood ten times faster…by using faster than HTTP protocols.

Adobe has two server-side solutions for this– free open source BlazeDS (implements AMF3 porotocol and messagein) and a commercial component called LiveCicle Data Services ES (LCDS was formerly known as Flex Data Services) that implements AMF 3 and RTMP protocols  that perform effective data compression while exchanging  the data between a Web browser and the server. Some benchmarks show that these protocols would often give you at least ten time speed increase in the data intensive applications.  But is Adobe the only plastic surgeon in town? No, it’s not.

For example, an open source product called Granite Data Services is in the works, and it’ll provide the AMF3 implementation to connect with Java server-side applications (POJO/Spring/EJB3). Yet another player here is also an open source product called OpenAMF, which implements the AMF0 protocol for Flex remoting.  

There is another open source AMF3-based remoting  framework  called Cinnamon targeted at Java/Spring/EJB3 applications.

But today, we’ll be talking about another commercial-grade alternative to AMF Adobe offerings called WebORB.  I’m talking to Mike Piller from Midnight Coders, the company that created WebOrb.

 1.    Mark, I know that you offer WebOrb,  the AMF3 implementation for the server side applications written in .Net, Java, PHP and Ruby on Rails and we'll discuss these a bit later, but let's start with the most important question – do you have any free versions of WebOrb?

Absolutely. WebORB for Java, PHP and Ruby on Rails is entirely 100% free. We do not break up these products into any editions, so all of the functionality comes at no cost. The .NET build of the product has a Standard edition which is free as well. All products offer integration
support for Flex (AMF3), Flash (AMF0) as well as AJAX clients. There are no limitations on the numbers of CPUs it can run on or the number of applications you can deploy in it. For Flex clients, a developer would use the RemoteObject API and can easily remote Java, .NET, PHP or Ruby objects. Additionally, the PHP and Ruby editions are open source (MPL license).

 2.    It would not be fair to say that WebOrb is an alternative to LCDS,  because it does not offer RTMP support, Data Management Services and  other useful features available in LCDS. On the other hand, WebOrb offers something that does not exists in LCDS. Can you briefly list the WebOrb features that in your opinion should be appealing for Flex developers?

Yakov, I believe WebORB for Java is a solid alternative to both LCDS and BlazeDS. It provides support for Flex Remoting and has a very powerful implementation of Data Management. The product includes integration with JMS and supports Flex pub/sub (Consumer/Producer) system. RTMP support offers an alternative mechanism to data delivery (push vs. pull). Since we support client-side polling, all the same applications one can create based on RTMP would work with WebORB anyway. By the way, RTMP support will be available in the next 2 to 3 months. As for Data Management, our approach is makes is very easy to get started as it generates all the client-side (ActionScript) and server-side (Java) code to work with the user-specified database. With the LCDS approach developer has to write all the code including data transfer objects (DTO), query execution code, data mappers, etc. To me it significantly impacts productivity as
developers keep writing the same type of code over and over. And we should use tools to automate that step. I also would like to remind that all of this functionality is available at no charge at all.