Release of BlazeDS is a great help from the Flex enterprise adoption perspective. The high licensing costs of the server side components has been a major obstacle for Flex adoption for some of our clients over the last 2 years. As most solution providers, we had to roll out third-party replacements of Adobe's AMF implementation - mostly built around openAMF and other open source products. With BlazeDS available within few month, the performance, support and the future of the codebase is no longer a concern, and should greatly simplify Flex adoption by enterprises.

On the technical side, BreezeDS provides a lightweight replacement for LiveCycle Data Services ES. The remoting part seems to be identical to the LCDS offering. If you just use BlazeDS WAR, just roll out a regular "LCDS-like" deployment, and the chances are it will work without the need to do any changes. For the messaging and data management services, however, there are significant differences. You might want to analyze those before plunging into either product.

The client-side of the messaging stays very much the same - you use the same Producers and Consumers, so there are virtually no changes in the client code. The BlazeDS is packaged with a pre-configured Tomcat server with messaging built-in (an open source ActiveMQ), greatly reducing the complexity of the initial setup.

The implementation of the server piece is very different though. Unlike LCDS that launches an independent Java socket server within each application, BlazeDS uses the regular Web server sockets. LCDS uses non-blocking IO that offers better scalability (we had it @ 10000 users / CPU till we maxed out on the outgoing bandwidth). With LCDS, you need either a separate port or an IP address to handle the data stream. BlazeDS does not use non-blocking IO - so you can not expect to have more than a few hundreds users per CPU at best. On the positive side, it makes the process of application development a bit simpler as the session context becomes available.

With BlazeDS going open source and abundance of Java expertise in the market place you can expect non-blocking I/O offerings from third parties shortly after the BlazeDS release. It would also mean faster recoverability of the connections that is important for the real-time applications.

The Data Management Services interface is COMPLETELY omitted from the current BlazeDS offering. This is bad. While it is understandable from the marketing standpoint, it will hurt Adobe in the long run. Some trivial, non-functional classes have to be included in both client and server version of BlazeDS libraries. All datatypes that go over the wire and allow users to maintain compatibility between BlazeDS and LCDS are desperately needed. A short list would include ChangeObject interface, DataSyncException and such that are used in the custom server and client code.

I could care less about a Hibernate Assembler and implementation classes but high-level WIRE PROTOCOL has to be the same. As a solution provider, I have to go with the lowest denominator of what is available across platforms, and lack of common classes interfaces hurts the code portability. Given the current license restrictions on the "mx" and "flex" namespaces in the current open source sdk it makes impossible to provide such solution in the nearest future.

Other thing people often forget about the PDF support in LCDS, which won't be available in BlaseDS. The printing support in Flex is very light, and PDF generation is often a preferred solution for printable documents. Fortunately, you can split your application deployment now and have dedicated "print server" with LCDS or any other Adobe enterprise product that includes that capability.