Viewing By Category : Adobe LiveCycle / Main
December 17, 2020
Spring BlazeDS Integration 1.0.0.M1 Released

SpringSource just announced that the first public development milestone build of Spring BlazeDS Integration, the newest member of the open source Spring portfolio, is now available.

See Jeremy Grelle's announcement to the Spring community here:

http://www.springsource.org/node/904

Springy BlazeDS goodness!

Damon

December 9, 2020
Adobe Collaborates with SpringSource with BlazeDS and LCDS

Adobe and Springsource announced yesterday the integration betweeen the Flash Platform and SpringSource. More details can be found in the press release here: http://www.springsource.com/node/1077

Some highlights:

1. REST support for BlazeDS and LCDS end points.
2. An option to configure BlazeDS and LC DS components using Spring configuration.

Some Benefits:

1. Create your business logic once and access it over AMF from Flex and REST from AJax/HTML clients.
2. Easy to expose your existing spring beans over AMF to Flex clients. This should help in migrating existing Enterprise Java applications to leverage Adobe Flex/AIR.

Note that this new integration adapter from Spring will work with existing versions of BlazeDS and LCDS. I'll post more details as more info becomes available.

Damon

November 18, 2020
New in Gumbo: Client Side Data Services

One of the main themes of the Gumbo release is RAD for Data Centric Developers. The new Client Data Management (CDM) feature coming in Flex 4 super-simplifies how you work with data on the server.

Developers using LiveCycle Data Services have known for years about the incredible power and productivity that the Data Management features of LCDS provide for data-centric applications.

The LiveCycle Data Services and Flex Builder teams have been worked very closely together and with Gumbo, all Flex developers can now make use of at least the client-side functionality provided by this powerful and mature feature set.

However, Gumbo Client Side Data Services, when combined with LiveCycle Data Services backing your Gumbo applications, will provide cutting edge productibity PLUS enterprise scalability, power, real-time messaging, change management, conflict management, client-client sync, paging, and all the other powerful capabilities LiveCycle Data Services provides today. (And the next major release of LiveCycle Data Services will add some exciting new major capabilities in the 2009 timeframe).

Using the new Services Explorer in Gumbo, you can now bind UI components in your application to operations on the server. CDM then manages a CDM data store bound to this operation, allowing on-demand fetching of data for easy and efficient scrolling through large collections of data, change tracking allowing users to “un-do” actions, and automation of the common CRUD (create, read, update, & delete) functions that usually need to be hand-coded.

Creating, updating, and deleting data is done within the CDM data store so that when you’re ready to update the back end system, a single call to the client data management’s commit() method handles synchronizing all of the changes for you. It all works against multiple server types (like LiveCycle Data Services, ColdFusion, PHP, as well as SOAP and XML over HTTP) and produces straightforward ActionScript interfaces that you can use yourself, or simply let the tool do the work for you.

The next version of LiveCycle Data Services will work seamlessly with Gumbo, adding support for something called Adobe data model. This is similar to a UML, but developers can also define behaviors such as validations, etc. Validations can be defined once on the model, but will be validated on the Flex client as well as the LCDS server.

You no longer have to create AS VO and service classes, they are automatically generated for you from the model. The generated code is visible to developers and can be easily extended to provide your own behavior.

The really cool thing is that when you use LiveCycle Data Services on the server side, you no longer have to implement custom Java assembler code to provide data management capabilities.

For each model entity defined, we automatically create the assemblers on data model deploy from Gumbo - all out of the box. The LiveCycle Data Services server uses the data model to provide this functionality.

The data model can be deployed from Flex Builder (or dropped to a folder in LCDS) to an active LC DS server dynamically. You don’t have to worry about configuring destinations, writing Java code, etc. We automatically create the destinations from the data model and you're done. Nothing could be simpler.

FlexBuilder will provide a new feature called the Services Browser. The data model will be available as services from which you can drag and drop to a design view to create Flex applications.

Stay tuned for more, but 2009 promises to be a VERY exciting year for RIA developers. RAD and RIA meet enterprise-caliber data centric development.

Finally.

Damon


Adobe LiveCycle Data Services 2.6.1 Now Available

Just freshly released and made live available for download today is the Adobe LiveCycle Data Services ES 2.6.1 release. Get it here: http://www.adobe.com/products/livecycle/dataservices.

This release consists mainly of bug fixes, but also includes an update to the "Integrating Flex applications with portal servers" chapter from the "Adobe LiveCycle Data Services ES 2.6 Developer Guide" which contains new information about using a portal server in a federated portal architecture. Download the PDF file to obtain this update.

This release also includes and update to the "Using the Remoting Service" chapter from the "Adobe LiveCycle Data Services ES 2.6 Developer Guide" describes a resolution to bug BLZ-231 for using the AMFConnection API to call remote objects from Java applications. Download the PDF file to obtain this update. For more information on the AMFConnection Java class, see the AMFConnection API reference.

See the LCDS 2.6.1 Release Notes for a list of What's New and Fixed Issues. Also see the LCDS 2.6.1 Installation Instructions for instruction on upgrading and installing.

Damon

November 17, 2020
Anil Channappa, Product Manager for BlazeDS and LCDS is Blogging

Anil is now blogging about LiveCycle Data Services and BlazeDS at http://www.anilchannappa.org

Welcome to the Blogosphere, Anil!

Damon

November 3, 2020
Seth Hodgson (LCDS Team) is Now Blogging!

Seth Hodgson, Engineer Extraordinaire on the Adobe LiveCycle Data Services and BlazeDS engineering team (and one of the smartest people I know) is now online at:

http://greetingsfromoakland.blogspot.com

Welcome Seth!!

From Seth's about page:

"I'm a computer scientist living in beautiful Oakland, CA with my wife and daughter and I work on LiveCycle Data Services, BlazeDS and Flex at Adobe. This is a personal blog, opinions expressed are my own and don't reflect those of my employer." :)

Damon

October 21, 2020
Capacity Planning Guide Now Available for LiveCycle Data Services 2.6

Just published: the Adobe LiveCycle Data Services 2.6 Capacity Planning Guide.

With LiveCycle Data Services 2.6, you can create Adobe Flex applications that can deliver thousands of messages per second to thousands of end users simultaneously:

This document presents the results of software benchmark tests performed by Adobe engineers on my LiveCycle Data Services team and show how LiveCycle Data Services 2.6 can scale linearly and perform under load using various messaging scenarios that represent real-world situations. It provides a starting point for those who need to plan a hardware and software infrastructure that scales in a linear fashion to meet peak period demand.

Check it out here: Adobe LiveCycle Data Services 2.6 Capacity Planning Guide

Damon

August 29, 2020
Flex Developers: BlazeDS Livedocs HTML Now Updated

The BlazeDS Livedocs HTML is now updated to match the PDF. Both are now based on the LiveCycle Data Services 2.6 doc and are accessible here:

http://opensource.adobe.com/wiki/display/blazeds/Developer+Documentation

This update also includes much better organization of the chapters to explain the RPC and messaging concepts.

Thanks to the documentation team!

Damon

August 20, 2020
Using Flex SDK 3.1 with BlazeDS and LCDS 2.6

Flex SDK 3.1 was released recently, and for those of you using BlazeDS and Adobe LiveCycle Data Services wanting to use it, the following should help.

To use Flex SDK 3.1 with the latest stable build of BlazeDS 3, all you need to do is compile using SDK 3.1. No additional steps are required.

If you would like to build and use BlazeDS 3.1 which has Flex SDK 3.1 integrated in it, synch to http://opensource.adobe.com/svn/opensource/blazeds/tags/3.1.0

If you would like to compile LCDS 2.6 applications with Flex SDK 3.1, follow the instructions here: http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=build_apps_4.html#170990

(Courtesy of Kumaran Nallore, QE manager on the LCDS team)

Damon

August 5, 2020
BlazeDS and LCDS: Channels, Channels Everywhere (Redux)

I originally posted this back in January, but with LCDS 2.6 now released, it's worth noting again. Here it is again, for anyone who missed it:

=================================================

BlazeDS, and the released 2.6 update to Adobe LiveCycle Data Services, add several additional channel/endpoint options to the mix of available channels currently available for communication between Flex RIA's and backend server technologies. With all the available channels and endpoints, (and more coming!) the question of how to decide which one (or which set) to use for a particular application becomes relavent.

Seth Hodgson, Engineer Extraordinaire on the LiveCycle Data Services team compiled the following helpful discussion and general guidelines that will probably make it into product documentation, etc for the next release, but I thought I'd share it now to help anyone who could use this now to navigate the available connectivity options.

So...thanks Seth!

Ok, on to the post....

Now, if you’re just doing remote procedure calls (RemoteObject or proxied HTTPService or WebService) or Data Management without auto-sync, than use the AMFChannel. Simple, performant call/response semantics over HTTP.

The HTTPChannel (probably should have been named the AMFXChannel) is exactly the same as the AMFChannel behaviorally, but serializes data in an XML format called AMFX. This channel only exists for customers who require all data sent over the wire to be non-binary for auditing purposes. There’s no other reason to use this channel over the AMFChannel for RPC-based apps.

So if your app is only making RPC calls to the server, the answer is simple. You can stop reading here and get back to developing your app using one of the two options above (most likely the AMFChannel).

Real time data push to web clients doesn't have as simple an answer as the RPC scenario unfortunately. There are a variety of trade-offs and pros and cons that need to be taken into consideration. Although the answer isn't as simple, it's still fairly prescriptive based on the needs of your app and the tables below should help you select the right channel(s) and get back to work. One thing to remember. If your application uses real time data push, but also does some RPC as well, you do not need to use separate channels. All of the channels below can send RPC invocations to the server just fine. Use a single ChannelSet (possibly containing just a single channel) for all of your RPC, messaging and data management components.

We'll start with recommendations in my order of preference for BlazeDS and follow that with recommendations for LCDS.

BlazeDS
1. AMFChannel/Endpoint configured for Long Polling (no fallback needed)

The channel issues polls to the server in the same fashion as our traditional polling, but if no data is available to return immediately the server “parks” the poll request until data arrives for the client or the configured server wait interval elapses.

The client can be configured to issue its next poll immediately following a poll response making this channel configuration feel very “real-time”.
A reasonable server wait time would be 1 minute. This eliminates the majority of busy polling from clients without being so long that you’re keeping server sessions alive indefinitely or running the risk of a network component between the client and server timing out the connection.

Pros Cons

Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.

When many messages are being “pushed” to the client this configuration has the overhead of a poll roundtrip for every pushed message (or small batch of messages that queue between polls). Most applications are not pushing data so frequently for this to be a problem.

The Servlet API uses blocking IO so you must define a upper bound for the number of long poll requests parked on the server at any single instant. If your number of clients exceeds this limit, the excess clients will devolve to simple polling on the default 3 second interval with no server wait. Say your app server request handler thread pool has a size of 500. You could set the upper bound for waited polls to 250 or 300 or 400 depending on the relative amount of non-poll requests you expect to service concurrently.


2. StreamingAMFChannel/Endpoint (in a ChannelSet followed by the polling AMFChannel below for fallback)

Because HTTP connections are not duplex, this channel sends a request to “open” a HTTP connection between the server and client, over which the server will write an infinite response of pushed messages. This channel uses a separate transient connection from the browser’s connection pool for each send it issues to the server. The streaming connection is used purely for messages pushed from the server down to the client. Each message is pushed as an HTTP response chunk (HTTP 1.1 Transfer-Encoding: chunked) .

Pros Cons

No polling overhead associated with pushing messages to the client.

Uses standard HTTP ports so firewalls don’t interfere and all requests/responses are HTTP so packet inspecting proxies won’t drop the packets.

Holding on to the “open” request on the server and writing an infinite response is not “nice” HTTP behavior. HTTP proxies that buffer responses before forwarding them can effectively swallow the stream. Assign the channel’s ‘connect-timeout-seconds’ property a value of 2 or 3 to detect this and trigger fallback to the next channel in your ChannelSet.

No support for HTTP 1.0 clients (not that this matters; does anyone still use a 1.0 client?). If the client is 1.0, the open request is faulted and the client falls back to the next channel in its ChannelSet.

The Servlet API uses blocking IO so like long polling above, you need to set a configured upper bound on the number of streaming connections you’ll allow. Clients that exceed this limit will not be able to open a streaming connection and will fallback to the next channel in their ChannelSet.


3. AMFChannel/Endpoint with simple polling enabled (no Long Polling) and piggybacking enabled (no fallback needed)

Same as our traditional, simple polling support but with piggybacking enabled when the client sends a message to the server between its regularly scheduled poll requests the channel piggybacks a poll request along with the message being sent, and the server piggybacks any pending messages for the client along with the response.

Pros Cons

Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.

User experience is more “real-time” than with just simple polling on an interval.

Doesn’t have thread resource constraints like long polling and streaming due to the Servlet API’s blocking IO.

Less “real-time” than long polling or streaming; requires client interaction with the server to receive pushed data faster than the channel's configured polling interval.



LiveCycle Data Services
1. RTMPChannel/Endpoint (in a ChannelSet with fallback to NIO AMFChannel configured to Long Poll)

The RTMPChannel creates a single duplex socket connection to the server and gives the server the best notification of the player being shut down. If the direct connect attempt fails the Player will attempt a CONNECT tunnel through an HTTP proxy if one is defined by the browser (resulting in a direct, tunneled duplex socket connection to the server). Worst case, it falls back to adaptive HTTP requests that "tunnel" RTMP data back and forth between client and server, or it fails to connect entirely.

Pros Cons

Single, stateful duplex socket that gives clean, immediate notification when a client is closed. The HTTP-based channels/endpoints generally don't receive notification of a client going away until the HTTP session on the server times out; that's not great for a call-center application where you need to know whether reps are online or not.

The player internal fallback to HTTP CONNECT trick to traverse an HTTP proxy if one is configured in the browser gives the same pro as above, and is a technique that just isn't possible from ActionScript or Javascript.

RTMP generally uses a non-standard port so it is often blocked by client firewalls. Network components that do stateful packet inspection may also drop RTMP packets, killing the connection. Fallback to HTTP CONNECT through a proxy or adaptive HTTP tunnel requests is difficult in our deployment scenario within a Java servlet container which generally already has the standard HTTP ports bound; requiring non-trivial networking configuration to route these requests to the RTMPEndpoint.


2. NIO AMFChannel/Endpoint configured for Long Polling (no fallback needed)

Behaviorally the same as the servlet-based AMFChannel/Endpoint but uses an NIO server and minimal HTTP stack to support scaling up to thousands of connections.

Pros Cons

The same pros as mentioned above, along with much better scalability and no configured upper bound on the number of parked poll requests.

Because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


3. NIO StreamingAMFChannel/Endpoint (in a ChannelSet followed by the polling AMFChannel below for fallback)

Behaviorally the same as the servlet-based StreamingAMFChannel/Endpoint but uses an NIO server and minimal HTTP stack to support scaling up to thousands of connections.

Pros Cons

The same pros as mentioned above, along with much better scalability and no configured upper bound on the number of streaming connections.

Because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


4. NIO AMFChannel/Endpoint with simple polling enabled (no Long Polling) and piggybacking enabled (no fallback needed)

Same as the description above.

Pros Cons

Same as the pros above, and it shares the same FlexSession as other LCDS NIO AMF/HTTP endpoints

Same cons as above and because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


The NIO AMF/HTTP endpoints use the same client-side Channel classes as their servlet-based endpoint counterparts. They just scale better than the servlet based endpoints. If the web app is not servicing general servlet requests, you can configure the servlet container to bind non-standard HTTP/S ports leaving 80 and 443 free to be used by your LC DS NIO endpoints. Because LC DS is a super-set of BlazeDS, you still have access to the servlet-based endpoints if you want to use them instead.

Reasons to use the servlet-based endpoints would could be because you need to include 3rd party servlet filter processing of requests/responses or need to access data structures in the application server's HttpSession (the NIO HTTP endpoints are not part of the servlet pipeline, so while they provide a FlexSession in the same manner that RTMP connections do, these session instances are disjoint from the J2EE HttpSession.

Hope that helps!

Damon

July 30, 2020
BlazeDS Developer Guide Updated

Thanks to Michael Peterson and the LiveCyle Data Services / BlazeDS documentation team, an updated PDF version of the BlazeDS Developer Guide is now available here:

http://livedocs.adobe.com/blazeds/1/blazeds_devguide/blazeds_devguide.pdf

This revised Developer Guide contains all of the content from the new LiveCycle Data Services 2.6 Developer Guide that applies to BlazeDS. Note: Only the PDF version of the Developer Guide is updated. The Livedocs HTML is not updated.

Much of the documentation has been revised and reorganized, and there are completely new sections on:

Getting Started
- Introduction
- Building and deploying

Architecture
- General architecture
- Channels and endpoints
- Managing session data

Thanks Mike!

Damon

July 23, 2020
AIR Data Synchronization via LiveCycle Data Services ES 2.6

John C. Bland II has posted a nice Adobe LiveCycle Data Services 2.6 article on AIR Data Synchronization via LiveCycle Data Services ES 2.6.

Find it here: http://www.insideria.com/2020/07/air-data-synchronization-via-l.html

John comments, "Give the LCDS team a hug when you see them." For the record, we do accept hugs :)

Damon

July 21, 2020
LiveCycle Data Services 2.6 Released

A few days ago my team released LiveCycle Data Services 2.6 (aka "Update 1"), adding some key features and scalability and performance enhancements.

Find out more here here

The Release Notes can be found here.

We're very proud of this release and kudos to the team on a great job!

Damon

April 21, 2020
Adobe LiveCycle Data Services + Flex Power Tour de Georgia Bike Race

Yep, we're at it again. I blogged previously about Adobe's sponsorship of the Tour of California bike race, and this week Adobe LiveCycle Data Services 2.6 (Beta) and Flex is powering the Tour of Georgia bike race, running on clustered servers at Media Temple.

Again, special thanks go to Allan Padgett, who is deeply involved at all levels, Ed Solovey, Alex Glosband, Seth Hodgson and Jeff Vroom from my team (LiveCycle Data Services Engineering) for their hard work on this, tweaking the site, and finding a few issues of additional "bulletproofing" that will make it into the final LC Data Service 2.6 product as a result of the experience of powering the two Tour race events.

Briefly, the Tour Tracker is a Flex application written in Flex 3 connected to a cluster of 12 LiveCycle Data Services servers and a network of servers provided by Akamai. GPS data comes from units on the cars and on the bikes, using the cellular network to send GPS via UDP back to one of our LCDS servers. Chat is via LCDS messaging. Play by play is via LCDS Data Management. Photos are using the Flickr API.

Check it out live here:
http://www.tourdegeorgiatracker.com/

Damon

April 15, 2020
New Data Services Stress Testing Framework Available on Adobe Labs

Hot off the press, a new version of the Data Services Stress Testing Framework has been posted to Adobe Labs.

The Data Services Stress Testing Framework helps developers using LiveCycle Data Services ES 2.6 load test their applications. This tool was formerly known as the Flex Stress Testing Framework. It has been updated for LiveCycle Data Services ES 2.6 and has many new features and bug fixes.

Grab it here!

http://labs.adobe.com/wiki/index.php/Data_Services_Stress_Testing_Framework

Damon

April 10, 2020
Zero to Hero in 1HR: BlazeDS on Amazon EC2

A great little post on the step-by-step instructions to get BlazeDS up and running on Amazon's EC2 service for Flex RIA apps:

http://weblog.cahlan.com/2020/04/easy-setup-guide-for-blazeds-zero-to.html

Damon


Useful Adobe LiveCycle Data Services and BlazeDS Links


LiveCycle Data Services ES 2.6 Public Beta Live on Labs!

Just posted to Adobe Labs, we've made available a public Beta of Adobe® LiveCycle® Data Services ES 2.6, the Adobe server-based technology that streamlines the integration of rich Internet applications (RIAs) with LiveCycle Services, J2EE applications, and business logic.

Check it out here: http://labs.adobe.com/technologies/livecycle_dataservices2_6

This release aligns with the releases of Adobe Flex® 3 and Adobe Flex Builder™ 3. It provides new and enhanced capabilities for enterprise developers building application utilizing Flex and LiveCycle. A complete list of new features is contained in the documentation. Below are some highlights.

New and enhanced features include:

- Alignment with Flex 3
- Improved LiveCycle Foundation Integration Features
- Improved RTMP Performance and Scalability
- Scalable HTTP Based Channel
- Data Management Paging Improvements
- Data Management Offline Improvements
- Data Management Improved Subtype Support
- Data Management and Hibernate Improvements

Nota that the complete list of new features and enhancements and fixes is located in the documentation. We sincerely appreciate your participation in the public Beta release, and as always, look forward to your feedback!

Damon

April 7, 2020
Load Testing Flex apps using RadView WebLOAD

I’ve heard from customers that they really need a solid load testing solution for their RIA Flex apps, and while RadView is just coming into the Flex scene, they do bring a key part of a successful RIA application deployment to the table - load testing – to the table. Your Flex app might be great looking, but how does it perform under load? Can you handle peak traffic periods? RadView’s WebLOAD can help you answer these questions and go live with confidence.

I'm certainly the first one to point out that there are multiple vendors beginning to support the load testing of Flex applications (Load Runner among them), however, I can vouch for the fact that RadView has been extremely responsive, these guys have a great and robust solution, and we’ve worked with them closely on several initiatives and will likely do more work together to better serve our mutual customers.

As Flex is being adopted by more and more leading enterprises, application performance has become critical for the success of Flex implementations. RadView has worked closely with Adobe to develop an Add-On for load and performance testing of Flex applications.

The first version of the WebLOAD Flex add-on supports the HTTPChannel (passes messages in the AMFX XML format) and the AMFChannel (supporting AMF0 & AMF3). Hence it supports using RPC-style services. It can also support messaging, if you configure your application to fallback to one of the polling options (just for the sake of testing). Future planned versions will support the StreamingAMFChannel and later the RTMPChannel to cover messaging and data management services natively, covering all the bases for RIA load testing, as it were.

Something I thought was pretty cool when they came in house to demo their AMF solution was how WebLOAD handles AMF messages and formats them in its IDE, used to edit and debug your test scripts. The binary messages are serialized into JavaScript objects (JavaScript being WebLOAD’s native scripting language), and using smart filtering techniques enables the script developer to easily parameterize them and add verification functionality to the script.

When running the load test against your application, you can use WebLOAD’s Performance Measurement Manager to collect server-side statistics from both BlazeDS and LCDS (together with the other servers that run your application) to see how they behave under load.

Check it out and download the eval version + Flex Add-on here: http://www.radview.com and give it a try with your application. (NOTE: You do need to ask for a license that includes the Flex Add-on, by emailing support@radview.com).

Hope that helps!

Damon

March 28, 2020
Adobe LiveCycle ES vs LiveCycle DS vs BlazeDS - Clearing Up the Confusion

Adobe's Greg Wilson clears up any confusion around Adobe enteprise product naming.

Check it out here: http://gregorywilson.wordpress.com/2020/03/27/livecycle-ds-vs-livecycle-es-clearing-up-the-confusion

Thanks Greg!

Damon

March 7, 2020
BlazeDS Nightly Builds Now Available

The BlazeDS Nightly Builds are now available on the BlazeDS Open Source site. Thanks to Kumaran Nallore on the BlazeDS/LCDS team for his efforts in getting this done!

You can access the Nightly Builds page directly here:

http://opensource.adobe.com/wiki/display/blazeds/download+blazeds+3

This page has also been made accessible from the BlazeDS Home Project page as well in the Downloads section, select the link called "Download BlazeDS now".

These are the last successful builds as of about 2:00 AM EST daily, which is when the build process that pushes the nightly build is scheduled to run. Please note that these builds have no correlation with any approved or certified builds.

Enjoy!

Damon

February 27, 2020
Tour of California Report: Flex + Flash + LiveCycle Data Services + FMS == WOOT!

Last week I blogged about how Adobe was again a major sponsor of the Tour of California bike race, which happens at the end of February each year, and how this year’s race was powered by Flex and LiveCycle Data Services 2.6 (yes, the *BETA*) running on clustered servers at Media Temple.

Here's a quick update circulated internally by Allan Padgett now that the race has concluded:

In short, all of the hard work the Flex, Flash, LCDS and FMS teams have done have enabled the creation of, in the words of one viewer, "One of the best things I've ever seen on the web." We went from 5,000 users last year to over 60,000 simultaneous users EVERY day this year. And we have had inquiries from events around the world asking if Adobe technology can help them too.

Quite simply, no other technology in the world today could have allowed this to be done so quickly with such a small team. AeG, Amgen and the entire cycling community are incredibly grateful that something like this is possible.

Here are just a few of the emails that we have received. I hope they show everyone that, while ship dates and numbers are what makes Adobe run, changing people's lives is what makes the people at Adobe run.

"This is what the web is all about and what I would have envisioned for the web back in 1996. Great job. Thank you for highlighting the shape of things to come."

"Tour of California coverage was great, and the Adobe TourTracker is one of the best software applications I've ever seen! Thanks to all for a great experience,"

"This is pretty much da bomb. Thanks."

Special thanks go to Allan Padgett, who was deeply involved at all levels, Ed Solovey, Alex Glosband, Seth Hodgson and Jeff Vroom from my team for their hard work transforming an application that was ready for 5,000 users last year into a "12-server cluster beast" that on the final day handled over 80,000 simultaneous users!

Additional thanks to Michael Gough, Chris Ewert, Mike Hone, Jim Pravitz, and Gever Tulley. It DOES take a village.

More details if you are curious...

The Tour Tracker provides in real time: live video of the race, GPS information about the riders, updates from the cycling press, official and fan photos of the race, and a chat room for viewers to share the experience. In addition to the race-day data feeds, it also provides detailed previews about each day of the race, biographies of all the riders, and a way to review previous days.

This is the second year that Adobe has offered AeG, the owner of the Tour, the "Adobe Tour Tracker" for their event. Briefly, the Tour Tracker is a Flex application written in Flex 3 connected to a cluster of 12 LiveCycle Data Services servers and a network of FMS servers provided by Akamai. GPS data comes from units on the cars and on the bikes, using the cellular network to send GPS via UDP back to one of our LCDS servers. The video streams go from the camera on a motorcycle to a plane flying overhead to a truck on the ground to satellite in the sky and finally to Akamai's FMS network. Chat is via LCDS messaging. Play by play is via LCDS Data Management. Photos are using the Flickr API.

Check it out live here:
http://www.amgentourofcalifornia.com/docroot/tourtracker2020/AdobeTourTracker.html

Damon

February 25, 2020
Adobe Flex/RIA Developers: BlazeDS (Open Source Remoting and Messaging) is Now Available

BlazeDS (and Flex 3 SDK, Flex Builder 3 and AIR 1.0) are now available. As someone put it recently, "The Web will truly never be the same". Congrats to the Flex SDK, Flex Builder, AIR teams and our BlazeDS / LiveCycle Data Services team!

Find BlazeDS at it's new home here:

http://opensource.adobe.com/wiki/display/blazeds/BlazeDS

As a reminder, the Adobe RSS News Aggregator now has a dedicated "Channel" for BlazeDS and LiveCycle Data Services news feeds. Look for it to be "on fire" with Flex 3, AIR and BlazeDS discussions! :)

Find it here: HERE.

Damon

February 19, 2020
BlazeDS Smart Category Added to the Adobe MXNA News Aggregator

We've added and made public a new "Smart Category" on the MXNA Adobe News Aggregator site for BlazeDS and LiveCycle Data Services, called "BlazeDS".

Search terms this Smart Category looks for include "BlazeDS", "Blaze", "LCDS", LiveCycle Data Services" and "LiveCycle DataServices".

Look for it HERE.

Damon

February 18, 2020
Live Flex/LCDS 2.6 BETA California Bike Tour Tracker

Adobe is a major sponsor of the Tour of California bike race, which happens at the end of February each year. This year’s race is powered by Flex and LiveCycle Data Services 2.6 *BETA* running on 8 clustered servers at Media Temple.

Check it out here:
http://www.amgentourofcalifornia.com/docroot/tourtracker2020/AdobeTourTracker.html

Special thanks to LCDS Engineering team members Alexander Glosband and Ed Solovey who worked through the weekend with Adobe's Allan Padgett to make this event successful (so far!) :)

Enjoy the race!

Damon


BlazeDS and the Developer Community

A great little intro article by Zach Stepek on BlazeDS and what it means for the developer community has been posted on the Adobe "Edge" newsletter site here.

If you're just getting your feet wet with Rich Internet Applications and Flex and wanting to take your apps to the next level, BlazeDS is for you, and best of all, like the Adobe Flex SDK, it's open source and free.

So what is it? BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe® Flex™ and Adobe AIR™ applications for more responsive rich Internet application (RIA) experiences.

The evolution to more engaging RIAs has created the need for better data connectivity options. Remoting simplifies the reuse of existing server logic automatically marshalling calls between the Flash client and the Java methods on the server. In addition, the use of a AMF binary data transfer format increases performance, allowing applications to load data up to 10 times faster than with text-based formats such as XML or SOAP.

Previously available only as part of Adobe LiveCycle® Data Services ES, Adobe is contributing the proven BlazeDS technologies to the community under the LGPL v3. BlazeDS gives the rapidly growing Adobe developer community free access to the powerful remoting and messaging technologies developed by Adobe.

Reasons to Adopt BlazeDS

The following are the top reasons to adopt BlazeDS:

1. Easily connect Flex and Adobe AIR™ applications built using Flex and Ajax to existing Java server logic
2. High performance data transfer for more responsive applications
3. Real-time server push over standard HTTP Full pub/sub messaging that extends existing messaging infrastructure
4. Free and Open source!
5. Range of data services solutions available from Adobe to support a wide range business and application requirements

Adobe has published the AMF binary data protocol specification, on which the BlazeDS remoting and messaging implementation implementation is based, and is committed to partnering with the community to make this protocol available for every major server platform.

For now, until BlazeDS is finalized, get more information on BlazeDS and download the Release Candidate, check out the BlazeDS pages on Adobe Labs here:

http://labs.adobe.com/technologies/blazeds

Also keep an eye out on the Adobe Open Source site, for further details on BlazeDS and Adobe's open source plans as they are posted:

http://opensource.adobe.com

Damon

January 18, 2020
BlazeDS and LCDS: Channels, Channels Everywhere

BlazeDS, and the upcoming update to Adobe LiveCycle Data Services, add several additional channel/endpoint options to the mix of available channels currently available for communication between Flex RIA's and backend server technologies. With all the available channels and endpoints, (and more coming!) the question of how to decide which one (or which set) to use for a particular application becomes relavent.

Seth Hodgson, Engineer Extraordinaire on the LiveCycle Data Services team compiled the following helpful discussion and general guidelines that will probably make it into product documentation, etc for the next release, but I thought I'd share it now to help anyone who could use this now to navigate the available connectivity options.

So...thanks Seth!

Ok, on to the post....

Now, if you’re just doing remote procedure calls (RemoteObject or proxied HTTPService or WebService) or Data Management without auto-sync, than use the AMFChannel. Simple, performant call/response semantics over HTTP.

The HTTPChannel (probably should have been named the AMFXChannel) is exactly the same as the AMFChannel behaviorally, but serializes data in an XML format called AMFX. This channel only exists for customers who require all data sent over the wire to be non-binary for auditing purposes. There’s no other reason to use this channel over the AMFChannel for RPC-based apps.

So if your app is only making RPC calls to the server, the answer is simple. You can stop reading here and get back to developing your app using one of the two options above (most likely the AMFChannel).

Real time data push to web clients doesn't have as simple an answer as the RPC scenario unfortunately. There are a variety of trade-offs and pros and cons that need to be taken into consideration. Although the answer isn't as simple, it's still fairly prescriptive based on the needs of your app and the tables below should help you select the right channel(s) and get back to work. One thing to remember. If your application uses real time data push, but also does some RPC as well, you do not need to use separate channels. All of the channels below can send RPC invocations to the server just fine. Use a single ChannelSet (possibly containing just a single channel) for all of your RPC, messaging and data management components.

We'll start with recommendations in my order of preference for BlazeDS and follow that with recommendations for LCDS.

BlazeDS
1. AMFChannel/Endpoint configured for Long Polling (no fallback needed)

The channel issues polls to the server in the same fashion as our traditional polling, but if no data is available to return immediately the server “parks” the poll request until data arrives for the client or the configured server wait interval elapses.

The client can be configured to issue its next poll immediately following a poll response making this channel configuration feel very “real-time”.
A reasonable server wait time would be 1 minute. This eliminates the majority of busy polling from clients without being so long that you’re keeping server sessions alive indefinitely or running the risk of a network component between the client and server timing out the connection.

Pros Cons

Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.

When many messages are being “pushed” to the client this configuration has the overhead of a poll roundtrip for every pushed message (or small batch of messages that queue between polls). Most applications are not pushing data so frequently for this to be a problem.

The Servlet API uses blocking IO so you must define a upper bound for the number of long poll requests parked on the server at any single instant. If your number of clients exceeds this limit, the excess clients will devolve to simple polling on the default 3 second interval with no server wait. Say your app server request handler thread pool has a size of 500. You could set the upper bound for waited polls to 250 or 300 or 400 depending on the relative amount of non-poll requests you expect to service concurrently.


2. StreamingAMFChannel/Endpoint (in a ChannelSet followed by the polling AMFChannel below for fallback)

Because HTTP connections are not duplex, this channel sends a request to “open” a HTTP connection between the server and client, over which the server will write an infinite response of pushed messages. This channel uses a separate transient connection from the browser’s connection pool for each send it issues to the server. The streaming connection is used purely for messages pushed from the server down to the client. Each message is pushed as an HTTP response chunk (HTTP 1.1 Transfer-Encoding: chunked) .

Pros Cons

No polling overhead associated with pushing messages to the client.

Uses standard HTTP ports so firewalls don’t interfere and all requests/responses are HTTP so packet inspecting proxies won’t drop the packets.

Holding on to the “open” request on the server and writing an infinite response is not “nice” HTTP behavior. HTTP proxies that buffer responses before forwarding them can effectively swallow the stream. Assign the channel’s ‘connect-timeout-seconds’ property a value of 2 or 3 to detect this and trigger fallback to the next channel in your ChannelSet.

No support for HTTP 1.0 clients (not that this matters; does anyone still use a 1.0 client?). If the client is 1.0, the open request is faulted and the client falls back to the next channel in its ChannelSet.

The Servlet API uses blocking IO so like long polling above, you need to set a configured upper bound on the number of streaming connections you’ll allow. Clients that exceed this limit will not be able to open a streaming connection and will fallback to the next channel in their ChannelSet.


3. AMFChannel/Endpoint with simple polling enabled (no Long Polling) and piggybacking enabled (no fallback needed)

Same as our traditional, simple polling support but with piggybacking enabled when the client sends a message to the server between its regularly scheduled poll requests the channel piggybacks a poll request along with the message being sent, and the server piggybacks any pending messages for the client along with the response.

Pros Cons

Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.

User experience is more “real-time” than with just simple polling on an interval.

Doesn’t have thread resource constraints like long polling and streaming due to the Servlet API’s blocking IO.

Less “real-time” than long polling or streaming; requires client interaction with the server to receive pushed data faster than the channel's configured polling interval.



LiveCycle Data Services
1. RTMPChannel/Endpoint (in a ChannelSet with fallback to NIO AMFChannel configured to Long Poll)

The RTMPChannel creates a single duplex socket connection to the server and gives the server the best notification of the player being shut down. If the direct connect attempt fails the Player will attempt a CONNECT tunnel through an HTTP proxy if one is defined by the browser (resulting in a direct, tunneled duplex socket connection to the server). Worst case, it falls back to adaptive HTTP requests that "tunnel" RTMP data back and forth between client and server, or it fails to connect entirely.

Pros Cons

Single, stateful duplex socket that gives clean, immediate notification when a client is closed. The HTTP-based channels/endpoints generally don't receive notification of a client going away until the HTTP session on the server times out; that's not great for a call-center application where you need to know whether reps are online or not.

The player internal fallback to HTTP CONNECT trick to traverse an HTTP proxy if one is configured in the browser gives the same pro as above, and is a technique that just isn't possible from ActionScript or Javascript.

RTMP generally uses a non-standard port so it is often blocked by client firewalls. Network components that do stateful packet inspection may also drop RTMP packets, killing the connection. Fallback to HTTP CONNECT through a proxy or adaptive HTTP tunnel requests is difficult in our deployment scenario within a Java servlet container which generally already has the standard HTTP ports bound; requiring non-trivial networking configuration to route these requests to the RTMPEndpoint.


2. NIO AMFChannel/Endpoint configured for Long Polling (no fallback needed)

Behaviorally the same as the servlet-based AMFChannel/Endpoint but uses an NIO server and minimal HTTP stack to support scaling up to thousands of connections.

Pros Cons

The same pros as mentioned above, along with much better scalability and no configured upper bound on the number of parked poll requests.

Because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


3. NIO StreamingAMFChannel/Endpoint (in a ChannelSet followed by the polling AMFChannel below for fallback)

Behaviorally the same as the servlet-based StreamingAMFChannel/Endpoint but uses an NIO server and minimal HTTP stack to support scaling up to thousands of connections.

Pros Cons

The same pros as mentioned above, along with much better scalability and no configured upper bound on the number of streaming connections.

Because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


4. NIO AMFChannel/Endpoint with simple polling enabled (no Long Polling) and piggybacking enabled (no fallback needed)

Same as the description above.

Pros Cons

Same as the pros above, and it shares the same FlexSession as other LCDS NIO AMF/HTTP endpoints

Same cons as above and because the servlet pipeline is not being used, this endpoint requires more network configuration to route requests to it on a standard HTTP port if you need to concurrently service HTTP servlet requests. However, it can share the same port as any other LCDS NIO AMF/HTTP endpoint for the app.


The NIO AMF/HTTP endpoints use the same client-side Channel classes as their servlet-based endpoint counterparts. They just scale better than the servlet based endpoints. If the web app is not servicing general servlet requests, you can configure the servlet container to bind non-standard HTTP/S ports leaving 80 and 443 free to be used by your LC DS NIO endpoints. Because LC DS is a super-set of BlazeDS, you still have access to the servlet-based endpoints if you want to use them instead.

Reasons to use the servlet-based endpoints would could be because you need to include 3rd party servlet filter processing of requests/responses or need to access data structures in the application server's HttpSession (the NIO HTTP endpoints are not part of the servlet pipeline, so while they provide a FlexSession in the same manner that RTMP connections do, these session instances are disjoint from the J2EE HttpSession.

Hope that helps!

January 14, 2020
LiveCycle Data Services Perspective

A good blog entry on the Coding Cowboys Blog about Adobe LiveCycle Data Services titled, "Flex (Now LiveCycle) Data Services: A Beginner's Perspective". Check it out here:

http://weblog.cahlan.com/2020/01/flex-now-livecycle-data-services.html

Damon

December 13, 2007
Adobe BlazeDS FAQ

Some pretty exciting stuff happening today as we (Adobe) have announced plans to release source code for its remoting and messaging technologies under a new open source product named "BlazeDS". I'm excited to be a part of this project as we move the Internet forward another notch in terms of richness and usability and bringing it all to the world with even more free and open software.

The public beta is available now for download from Adobe Labs here: http://labs.adobe.com/technologies/blazeds/

Read the Adobe Press Release PDF that went out this morning here.

With BlazeDS, developers can easily connect to back-end distributed data, as well as push data in real-time to Adobe Flex and Adobe AIR applications for more responsive RIA experiences. BlazeDS is being contributed to open source under the Lesser General Public License (LGPL v3) – the same license used by Red Hat/JBoss, which is good.

In addition, the Action Message Format (AMF) protocol specification has been published to open it up for other implementations across other server environments, and we'll be adding an Appendix to the AMF spec doc to include the details of the Small Messages feature new in BlazeDS as well.

What about the product Adobe LiveCycle Data Services product? We'll be offering a LiveCycle Data Services, Community Edition as a subscription offering that includes certified builds of BlazeDS, enterprise support, additional developer support, and may contain additional benefits, such as product warranty and infringement indemnity.

The commercial version of the product, LiveCycle Data Services ES, includes enterprise class capabilities for building advanced customer engagement applications. We haven't yet announced the feature set for the next version of LiveCycle Data Services ES, but a private Beta program begins early next year, and we're very, very excited about it.

Also note that with today's announcement, there are new Beta versions of Adobe Flex and Adobe AIR also available from Adobe Labs as well.

Why is this important?

Organizations are using RIAs to more effectively engage with customers, partners and suppliers across their extended enterprises. This has dramatically increased the requirements for better data connectivity options to back-end systems, improved data transfer performance, and a consistent and simplified programming model for exchanging data between clients and servers.

Contributing the BlazeDS data connectivity technologies to the open source community makes them accessible to all developers, and the documentation of the protocols opens them up for other implementations on non-Java back ends. This enables developers to extend the reach of their applications across different server technologies in a compatible and consistent approach, thereby accelerating application development and increasing application performance.

What is BlazeDS?

Previously available only as part of LiveCycle Data Services ES, BlazeDS is the Remoting and HTTP-based Messaging technology that Adobe is contributing to the community free and open source.

  • Easily connect Flex and AIR applications to existing server logic.

  • High performance data transfer for more responsive applications

  • Real server push over standard HTTP

  • Full pub/sub messaging that extends existing messaging infrastructure

  • Free and open source

What is LiveCycle Data Services, Community Edition?

LiveCycle Data Services, Community Edition allows organizations to take advantage of open source BlazeDS, but with all the trust and Adobe backing required for business-critical applications.

  • Includes access to the latest BlazeDS technology as it is tested and released, as well as patches, bug fixes and upgrades to newer releases

  • Also includes product warranty, infringement indemnity, additional enterprise and developer support

  • Subscription pricing will be announced at the time of general release of BlazeDS under the LGPL v3, currently scheduled for early 2020.

What is LiveCycle Data Services ES?

LiveCycle Data Services ES is the commercial version of the product for enterprise-class applications that require data synchronization, offline support for Adobe AIR, portal integration, RIA integration with LiveCycle Enterprise Suite business processes and document services, as well as more advanced deployment options for maximum salability.

A good example of the capabilities added with LiveCycle Data Services ES is the recently announced win with NATO for its new Mission Support System.

NATO crew members will be able to put together mission briefs aggregated from over 80 different data sources, including information such as flight numbers, details about the region and routes to take refuge in case of an emergency. Mission briefs are highly visual electronic maps that show all the information they need to analyze, develop and deliver in preparation for a mission.

Pricing for LiveCycle Data Services ES starts at $6,000 per CPU.

Open is Good!

This announcement builds on Adobe’s commitment to open technology initiatives and its support for a vibrant developer community.

Examples include open source Flex (announced in April 2007), contribution of source code for the ActionScript Virtual Machine to the Mozilla Foundation under the Tamarin project, the use of the open source WebKit engine in Adobe AIR, and the release of the full PDF 1.7 specification for ISO standardization.

BlazeDS source code, builds and licensing will be hosted by Adobe, along with an open planning process that includes the publication of specifications for review and comment by the community. Contributions to the BlazeDS technologies will be encouraged initially through the public bug database, including feature requests and a community voting system. Over time, Adobe plans to promote external contributors to “committer” status, allowing them to contribute code to the source tree.

What is Remoting?

BlazeDS remoting provides a call and response model for accessing server-side Java objects and ColdFusion components from Flex or Ajax applications as if they were local objects. BlazeDS integrates with the existing Java security policies on the server and provides transparent data transfer between ActionScript and Java data types, including data structures that use Java 5 enumerations.

By freeing developers from writing tedious marshalling code, remoting saves developers valuable time, and the use AMF, a binary data transfer protocol natively supported by the Adobe Flash Player, can improve data transfer performance an order of magnitude compared to XML/SOAP.

What is Web Messaging?

The web messaging service in BlazeDS provides support for publish and subscribe messaging over HTTP using standard protocols, concepts and terminology.

  • Adobe Flex and Ajax clients receive pushed messages from the server by subscribing to one or more topics.

  • When client or server code publishes a message to one of these topics, it is received by all clients who have subscribed to that topic.

  • >The management of subscriptions and publishing of messages is performed by a messaging adapter.

Adapters are provided for routing messages between Flex/Ajax clients and between Flex/Ajax clients and the Java Message Service (JMS) and ColdFusion. -Developers also can write their own message adapter by writing Java code to perform custom message processing or subscription management.

With BlazeDS web messaging, developers will be able to create real-time collaboration and data push applications for better decision-making and more engaging user experiences, such as guided self-service, live help, performance monitoring, and incident tracking.

BlazeDS introduces a new HTTP streaming channel that establishes a persistent connection between client and server for true data push

What is AMF?

"AMF" stands for "Action Message Format", and is a compact binary format for data serialization/deserialization and remote method invocation.

A key feature of this format is that it preserves the entire graph of data without duplicating identical objects. Object encoding controls how objects are represented in AMF. Flash Player uses AMF to enable efficient communication between Flash Player and a remote server. AMF encodes remote procedure calls into a compact binary representation that can be transferred over HTTP/HTTPS. ActionScript objects and data values are serialized into this binary format, which is generally more compact than other representations, such as XML.

Data delivery performance when using AMF is up to 10 times faster than applications delivering data payloads using plain XML over HTTP or web services. As data size increases the performance benefits of using BlazeDS increase exponentially. AMF improves performance by dramatically compressing the size of data transferred and parsing binary data into objects in memory far more efficiently than parsing XML data.

How does BlazeDS relate to Adobe’s RIA technologies?

BlazeDS is an integral part of Adobe’s RIA technologies, including best-in-class tools, servers, services and runtime environments, that allow designers and developers to create engaging application experiences that run on more platforms and devices than any other technology.

The combination of open source Flex and BlazeDS dramatically reduces the time it takes for developers to build responsive RIAs.

Damon