2. And recently several products were released by Adobe. Can you tell us more about those?
Sure. So about two weeks ago we released Flex 3, Flex Builder 3, the AIR runtime and then BlazeDS. So that was two weeks ago. There are a lot of new features. At the high level, what is really exciting about it is that Flex 3 is open source, so the framework goes open source. So I think that's really exciting. We have set up the infrastructure -- so you have an SVN repository you have a JIRA bug base; so there is really an environment there for the community to participate. So that is really exciting. The AIR runtime is also extremely exciting. So, for people who don't know, AIR is really just a runtime and what it does, it allows you to take Flex applications, or even applications that you build with HTML, and actually run them on the desktop, And that has a number of advantages. I think that when we say that, people automatically think "
Ok, so I will be able to work offline" which is obviously one of the benefits; so you can start your application offline. If you work offline you probably need to access your data as well, so in the AIR runtime there is actually an embedded relational database. And we have technology also to synchronize your central database with the local database that's embedded in the runtime, so that's something that is really important. Store the application offline, to access data, and store, capture data while offline. But we also have additional features, like native drag and drop, so you can drag and drop between an AIR application and other desktop applications, Excel or Word or whatever. We have a file I/O API -- so you basically run in a different sandbox, you are not constrained by the browser sandbox, so you can access your file system. You have obviously a database API to access that database, and so we think that that's really going to be extremely exciting.
3. With Flex 3, there seem to be several changes with it. Can you describe those in more detail?
Sure. In the framework itself there are a lot of new things that we did. First of all we added components; we tried to make the environment as productive as possible so we had a lot of extremely sophisticated components like data grids, tree views, charting components; but people are always asking for more and obviously because it's a full framework and a full programming model you can build your own components either from scratch or by extending existing components that we provide in the framework. But for some components, so many developers actually asked for the same ones, like for instance the most requested component I think was a kind of a tree grid, so a hybrid between a tree view and a data grid.
And so because the demand was so high we decided to build that into the framework. That's an example; we have an OLAP data grid as well. So that's a first area of new features if you want, new components. We also did things to improve the overall performance of the platform. People start building really sophisticated applications with Flex and sometimes really big applications. And so the default model when you build a Flex application is that we will take your source code and compile that into bytecode. And the default model is that you have that one binary file that we will then send to the client and it will be executed by the Virtual Machine. So that works pretty well for widgets or small apps, but at some point if you build a really big application that file can get pretty big, so we have things like runtime shared libraries or modules, where you can actually download a small piece of the application, the core of the application and then as needed you can start loading additional modules.
One thing that was... we had that actually in Flex 2... but one thing that we added was, if you build a "Hello World" application for instance, the size of the SWF will be around 200K which is pretty big for "Hello World". And the reason for that is that we always bake the framework or most of the framework classes into the binary file, into the SWF file. And then you run that "Hello World" application and then you go on another website and you download another Flex application, maybe a very small one as well and so you will again download 200K, most of that is going to be the framework again. So what we decided to do in Flex 3 was to allow you to load the framework as a runtime shared library, and then cache it inside the player. And so we signed that so that it is a secure environment, but if I visit your website and I run your Flex application, initially I didn't have the Flex framework so I will get it from you, I will cache it in the player and then I visit another website, download the Flex application, the player is going to check, "Oh, do I have the framework already?" -- if yes you don't need to download the framework again. That is significant in terms of making the size of applications to download a lot smaller.
And then obviously in the framework what we did, we added support for AIR. Because again I think one of the big benefits of AIR and what makes the story so nice is that it is one programming model. Oftentimes people have to decide... I mean it happened to me in my developer life, people come to me with requirements and I look at the requirements and I say: "Well, should I build this as a web application or as a desktop application?", and very often you have to make that decision upfront. And based on the answer that you provide, the technology, the language that you will use is going to be completely different and then you are stuck with that path that you took and oftentimes people end up building two versions of the same application, but two completely different codebases with a different set of technologies. So what's so nice about the Flex and AIR story, is that it's one programming model, so there is no such thing as an AIR programming model, AIR is just a runtime, and you build your application with Flex, or with HTML as I mentioned before. However there is a kind of a superset of APIs that you can use with AIR, if you want to take advantage of all these new features that you get only when you are on the desktop outside the browser sandbox like, as I mentioned before, a file I/O API, a database API, native drag and drop, so we had to provide that as a kind of a superset of the framework to support that. So these are some of the new features in Flex 3.
4. You have also mentioned Blaze DS. Can you tell us a little more about that?
Yes. BlazeDS is kind of a server-side technology, so specifically for Java developers, so if you have a Java back-end. To give you a little bit of background, you don't need anything Flex-related at the server side to run Flex applications. There is often a misconception that, if you want to use Flex you need some kind of a server-side piece of Flex, or some Flex components have to run at the server side. That's not true. You can build Flex applications without anything Flex on the server side, and so if that's the case you have a few ways to access your backend, we have an HTTP service that basically allows you to do XML over HTTP or JSON or whatever over HTTP to get to your data, so that's one data connectivity approach.
Another one is web service, so at the client side you can directly point to a WSDL and then consume a web service and you still don't need anything Flex on the server side to do that. So these are basically, if you don't want to use a Flex-related server component, these are the two options that you have to connect to your backend. Some people want a little more: like for instance if you are a Java developer, some people would like to be able to implement a kind of a remoting approach. So in other words, I am at the client side, I have a bunch of Java components deployed in my application server, I would like to be able to directly invoke methods in these Java objects deployed in the application server. So with BlazeDS you can do that. That's kind of the first component of BlazeDS remoting - it can directly invoke methods of Java objects deployed in the middle tier.
The second key component of BlazeDS is actually messaging, and that I think is going to be extremely important as well. It used to be that the only kind of data connectivity approach that you had for web applications was the traditional request-response model: if you need data you ask the server. Now sometimes you don't know if you need data and the typical example of that is a chat application. If that's really the model you have to constantly ask the server "Did that other person talk to me?", because you have no other way to know. The other example is a more traditional data push-type of use case, where I stream real-time market data updates. As the client I don't know if your stock just had an update so I constantly have to ask the server. With the messaging component of BlazeDS we have a pub/sub messaging infrastructure. So your Flex client can subscribe to a messaging topic and automatically the messaging service in BlazeDS is going to push the information to you when that information becomes available.
So again I think it enables two types of new applications: collaboration-type application and then traditional data push. Now what's really exciting about BlazeDS is that we decided to make that technology open source as well. And again, we have the same infrastructure, so the location for that is opensource.adobe.com, for people who want to access that technology.
Sure. And you are right. We strongly believe in open source. Iin the Flex world we started with Tamarin which is basically the Flash Virtual Machine which today is really an ECMAScript 4 Virtual Machine that we donated I think about a year ago to the Mozilla Foundation. And of course we continue to develop that and to be active developers in that project. And now with the Flex 3 SDK and BlazeDS, I think it really makes sense. I think that's how the industry works these days, what we want to do is make this technology available to a very very large number of developers and then I think it's a win-win situation because you create a very big ecosystem, partners can pitch in and benefit from that ecosystem, build components, some of these components are open source as well, and some people have a commercial model around that, but if the ecosystem is bigger there are just more opportunities for people to work with that ecosystem.
And we do the same thing, so a large part of the Flex family of products if you want is open source today. But then we still sell tools. Flex Builder 3 is not open source today, it's a plugin on top of Eclipse that we sell... and I've realized that I didn't mention all the new good features in Flex Builder 3, I can speak about that in a moment. So the model is really, make the technology available to a large number of developers, create an ecosystem and then there are some pieces of the technology that we continue to sell like Flex Builder and then there is the big brother, if you want, of BlazeDS which we call LiveCycle Data Services, which is basically a superset of BlazeDS. It includes additional realtime channels.
If you want to do realtime, there are different strategies and network protocols that can be used. BlazeDS offers a large number of options like traditional polling, long polling, HTTP streaming, so these are really good options. In addition to that, in LCDS - LiveCycle Data Services - we offer a socket-based protocol, RTMP, which is more scalable. We offer channels based on Java NIO, so more scalable in terms of thread management options that we have on the server side to make the system scale better. But many people won't need that, because that's really for very mission-critical applications, but that technology is available as a commercial product as well. So that's really the strategy.
6. So you mentioned Flex Builder 3. Can you describe some of the changes in more detail?
Flex Builder 3, as I said before. is a plugin on top of Eclipse. Version 2 was actually pretty good. You have a design view so you can build the UI in a WYSIWYG type of environment. We had a debugger, we still have it, but I am describing Flex Builder 2; so it was a pretty good tool. Then we got a lot of feedback from developers, and what is interesting about Flex is that we have a wide range of developers. We have people coming from more of the HTML world, if you want, and then we have people coming, you know, hardcore Java developers, and the type of features that these people want is very different. If you speak to an HTML developer, maybe they come from Dreamweaver, and they like to do things in the WYSIWYG environment, so these people are going to ask for more features in the design view. And some hardcore Java developers, they will say "We don't even use the design view, we are coders, so please improve the coding environment".
And it's true that in Flex Builder 2 we had to please these two different audiences, and I think we did a very good job, but certainly there was room for improvement in terms of code editing and even in the design view. So to give you a few examples, people -- especially from the developer side of that spectrum -- asked for refactoring capabilities. So that is now in Flex Builder 3. Or they asked for a profiler because they wanted from the tool to be able to identify the performance bottlenecks of the application, identify potential memory leaks and things like that. So these are all tools that developers wanted, so we added all that. And then at the other side of the spectrum, people said: "Hey, you guys support CSS styling of Flex applications. That's great! But really I don't want to edit in code that CSS, that's kind of... I type stuff but I can't see the result immediately. So you gave us a nice design view for Flex code, can you give us a nice design view for CSS editing?" So we have now a design view to edit your style sheets. That's an example, and we made some improvements in the design view for Flex code as well, so there are a lot of improvements both at the developer features side and then more designer features side.
That's really a good question because that's what we face all the time, and I think it's a testimony to how mature the industry has become because we are really able to plug in to existing architectures. And certainly for people who have been respectful of good design patterns, then the way we position ourselves is really as another view to an existing architecture. So basically Flex is all about the experience and we don't ask people, the message is certainly not "If you want to use Flex, then you need to change your backend", that's definitely not the message and it's exactly the opposite -- you need a better view, you understand that because the bar has been raised and the industry forces you in that direction. People focus on the user experience these days.
We can help, and the good news is that you won't have to change your backend, so it's another view to an existing architecture. The way that's being done has a lot to do with the data connectivity options that I mentioned before. Some people have standardized around a SOAP-based web services API to expose their business logic and persistence logic, so we say "Hey, if that's what you decided to do we'll support you, and in fact from your client you will be able to directly invoke these web services". Some other people have put together an XML over HTTP API, to get to their business logic. Well, we can support that as well. Some other people said: "Well we basically go through a web tier and then from there we start invoking methods in Java objects". Well in that case we said "If you think about it, that web tier, and that web framework that you have, the main goal, or one of the important goals of that web tier framework was to recreate the client state at the server side because the environment is stateful, but now that you have real application at the client side maybe you don't need to recreate the state, because there is a state there at the client side, so maybe you can skip that part and start invoking directly your service layer".
And we can do that with remoting, so skip the web tier framework and start invoking directly services deployed in the application server. And then we have a deeper level of integration, we have specific adaptors to connect with Spring and with Hibernate for people who want to do that. So that is really the message. We don't want you to change the backend, you have spent a lot of time and a lot of energy building that so we will integrate with it, and we are a really good client technology to support whatever you have standardized on at the server side. So that's the message.
That's a really good question and let me start by saying that sometimes people mention that as strictly Flex or Flash problems. And the point is these are problems of Rich Internet Applications, where the content is not static, but at the client side you assemble and create the content on the fly. So these are problems that exist whether you do Flex, Flash or AJAX. So the first one, searchability, we have some techniques and best practices that we publish to make your content searchable, even if the search engine doesn't want to introspect these SWFs, the binary format that we use. Basically at the high level the technique is to expose metadata. You know that Flex application is always hosted obviously in an HTML file, and so you can surround the object, the Flash application, by metadata, that the search engine will be able to understand.
And we have some automated ways of doing that and we published some best practices, so that's one option. The other option obviously is that we start working -- and we started that a long time ago -- but I think the vendors, the search engine vendors are a lot more listening these days. So we work with them, so that they start introspecting the Flash, the SWF content. And it is not rocket science and they know how to do that. And as more of them actually start using the technology, in fact if you visit Google, if you visit Yahoo, they start using Flex and Flash content. And they start to see that content proliferating on the web, so I think the incentive is bigger for them to start supporting that. So we expect to see in the near future better support for SWF content introspection if you want. That's kind of the searchability aspect of your question.
So the second part of your question related to browser integration, the back button, bookmarking, what we call deep linking, while you are working with a Flex application, you see -- let's say it's an e-commerce application -- at some point you see a product that you like, you want to grab the URL and email it to your friend and say "Look at that". Of course if it's a dynamically created application that is not obvious. But there are well known techniques to do that and one technique has been URL manipulation, after the anchor you can add something at the end of the URL to go back to the specific state that you are on. Now that's a well known technique and that's probably today the best way of doing it. But it's kind of a hack, which is fine, because these days people work with hacks, it seems to be a way of life these days.
But however you really don't want to have to write that code yourself because it's pretty cumbersome to write. So what we did in fact, in Flex 3 we added support for that, in the tool actually. We released as an open source project as well, the Flex-AJAX bridge some time ago. And now it's actually part of the tool. And what that tool does, it allows your Flex application to really easily integrate with the container, the HTML page and some JavaScript hosted in that page. And then we also support, in the framework, history management -- managing the back button of the browser, so that it actually doesn't go to the previous page but it goes to the previous state of your Flex application. So we capture the click on the back button and we handle it. But all these are very feasible and very well-documented techniques, the point is you don't want to write that code, you want us to support that and that's what we do. So we have support for history management and support for deep linking provided as part of the solution.