My name is Ryan Slobojan and I'm here with Cristophe Coenraets, Technical Evangelist at Adobe. Cristophe, can you tell us a little bit about how Catalyst works with the developer-designer interaction?

Absolutely. Catalyst is really a key new component and tool, actually, in that developer-designer workflow. It used to be that a designer would produce assets using PhotoShop or Illustrator and then give that to the developer and the developer would try to reproduce that in Flex Builder. The reality is that a lot was lost in translation, because these were just wireframes and the designer didn't really have a tool to represent and to model the transitions between the different states of an application, so it was pretty much described in text.

What Catalyst is, it's really a tool that will allow a designer to take assets produced in PhotoShop, in Flash, in Illustrator and start to create, really, application components from these assets, transform static assets into application components and also model the transitions between states of the application and things like that - essentially, do what a traditional enterprise developer doesn't like to do. Typically, these people don't like to model transitions or animations and things like that. Really, what's interesting here is that the output -- the underlying language -- is actually Flex.

That tool, Catalyst, is actually producing Flex code so that now when I'm done as the designer, when I'm done modeling the interactions, the transitions, I can give that to my developer and the developer can simply open my work in Flash Builder as a Flex project. As a developer then I don't have to focus on the design part of the application and we think that with Catalyst we really fill the gap between designer and developer.

There seem to be a fairly major set of changes coming with Flex/Flash Builder 4.0 and AIR 2.0. Can you tell us a little bit more about this?

Absolutely. First of all, from a product naming point of view, Flex Builder was renamed Flash Builder. We speak now about the Flash Platform, and Flash Builder is the tool to build applications for the Flash platform. But, from a technical point of view, it's really the next version of Flex Builder. I wanted to clarify that because I know that there is a lot of confusion there. So Flash Builder 4.0 is essentially the next release of Flex Builder. In the SDK, in the Flex 4.0 SDK, a lot of work was done around the component model and, in fact, to support Catalyst as we just described it.

We introduced a brand new component model in addition to the HALO component model, which is the set of components that you are used to if you use Flex 3.0 today. The reality is that, to support Catalyst, we really had to decouple the behavior of components from their look and feel and physical appearance, if you want. We had to do that at a very kind of deep level and that's why we introduced that new component model, Spark. That's a lot of the work that went into Flex 4.0. In Flash Builder 4.0, obviously we support the Spark component model. There is also a lot of improvement around data connectivity, back-end connectivity, connection to services.

We added a service browser that essentially allows you to go find and introspect existing services that you may have, whether they are web services, RESTful services, remoting services in Java, simple components deployed in your application server. We'll introspect these service and we'll do what... Typically the type of repetitive work that every developer had to do and was pretty painful, which was generate value objects, for instance, generate service stubs so that you can access these remote services in a kind of a strongly typed way.

When you are in Flash Builder, you type '.' and you indeed see all the methods that are available in the remote service. That's certainly a key aspect of Flash Builder 4.0. In addition to that we also do simple form generation as a starting point. We simply try to make it easier for developers to work with data. I would say, the combination of really good support for the Spark component model and then the new service browser and some code generation - the code that you don't want to write - that's a big part of what we did in Flash Builder 4.0 and in the SDK. In terms of AIR, we listened to the community.

There were a few APIs that people felt were missing, so for instance access to external USB keys, USB devices - that kind of thing - or we have microphone API support. Something that I'm really excited about is the ability to call external native processes from the operating system. I think that in some kind of applications that was really something that a lot of people asked for and that's really exciting to see that in AIR 2.0.

Livecycle Data Services 3.0 is also on the horizon. What new features are going to be coming with that and how do they integrate with the changes to AIR and Flex Builder/Flash Builder?

LCDS 3.0 is a major release, so I would say there are 2 key new features in the product. The first one is model-driven development; the idea that, if you look at a typical application, you spend a lot of time writing the same kind of code again, again and again. I spoke about writing value objects all the time, but you may also end up writing data access objects or some kind of a persistence layer. If you think about it, for many applications that code is always very similar, yet you have to go through that process again and again.

What we did was to build on top of the foundation that we have with data management - the data management service in LCDS 3.0 - and focus on approachability, make this service a lot easier to use. And so the way it works is that, we have a model that becomes the centre of the universe, if you want, of the server-side developer and you create a model that represents your data. You can create it from scratch or you can introspect the database as a starting point, you can introspect a set of existing server-side components as a starting point and you end up with a model. This is supported very deeply in Flash Builder.

There is a new plugin that you add on top of Flash Builder: that is the Model Designer. The process that I just described here is actually done within Flash Builder in a kind of a visual way; so we have a visual model editor. In that model, it's more than what you typically do in a pure data model - you can add constraint and validation rules, you can specify things that typically you would have to specify again and again in view components, like for instance which label you want to use for a text input field, which header you want to use in a data grid, and you can hardcode that in your model or you can use resource bundles to support multilingual applications.

All that you can specify at the model, so that you don't have to repeat yourself, if you want, and write that in code. Additional things that you can specify at the model level is, for instance, a default UI widget that you want to use for a specific field in your data model. Instead of having to respecify the same edit mask, for instance, you define it as a default in your model. Then every single time you create a UI that includes that specific field, will take that widget as a default. Once you create your model, you deploy the model and basically you don't have to write server side code because, based on the model, we have enough to really provide a persistence layer.

Behind the scenes, this is implemented using Hibernate - the persistence layer is provided by Hibernate - and then we also do some code generation on the client side, again the value objects and the service proxies. The key point is that the foundation for that is still the data management service. We think that the productivity gain can be huge. One last thing that I want to mention about that is that, I'm always myself very skeptical when people say "You won't have to write any code and it's just going to work." There are good reasons to be skeptical there. So what we wanted to do was to make sure that we provided hooks to say "Maybe you have some logic to execute before the persistence really happens.

You have that extension layer and at any point in the process you can actually plug in your own filters, if you want, or your own code to execute additional logic. That's one key feature of LCDS 3.0, model-driven development. The second feature is around messaging, and we added some key features specifically for people building very high-traffic applications, like... A typical example would be financial services organization building something like a trader desktop, and there were a couple of features that were missing for them to be able to implement that in an extremely scalable way.

For instance, we added an edge server, we added a "guaranteed delivery of message" feature, we added message throttling, so the ability to automatically identify that a client has a slow connection and react to that so that we don't overwhelm that client with messages that he cannot consume - all that is also part of LCDS 3.0. These are really the key features - model-driven development and high-performance messaging.