Explaining the MX vision part 2
Tim Anderson talks to Jeremy Allaire, Macromedia's chief technology officer.
runtime in the history of computing"
Why not a Java client?
Tim: Did you consider developing a rich Java client as opposed to using Flash?
Jeremy: We tried that a few years ago and it didn't work. Java has a large footprint that's very difficult for users to get. It is slow, its not been effective for the types of intensive interfaces that people build with things like Flash. It not actually truly cross-platform, there's a lot of inconsistencies in how it runs.
One thing to remember about Flash as the rich client is that we've got 98.3% ubiquity on the Internet. It's the most widely distributed runtime in the history of computing. The reason for that is that it's focussed, and it has a very small footprint. The entire runtime is 350K. And we can do 2.3 million downloads of that runtime per day. We can get 80% ubiquity in 12 months. That's because it's focussed.
If we took on a much broader infrastructure that we had to have our customers use and require, it would be a very different situation. For example, Flash MX introduces a video runtime, a very efficient video runtime that lets you get quite reasonable quality video at low bandwidth. The entire video runtime is 50K, and that's just not imaginable if we were doing it on another platform. We are able to customize it and optimize it at a very fine level.
Tim: What is your policy concerning the Flash format? Is it a published specification?
Jeremy: It is. We publish it after every release. There are about 200 companies that have licensed the format and who use it for all kinds of things, authoring tools, servers, applications, embedded devices. It is an open technology.
Why ColdFusion MX?
Tim: Why generate Java servlets from a proprietary tag language, when you could just write Java?
Jeremy: What we've seen is that the vast majority of people building web applications are scripting level developers. They're not system programmers. Of course there is a large population of system programmers and Enterprise developers, and they're pretty well served. What we've found though is that roughly 75% of web applications are built by scripting level developers. It is very important for that community of people, both traditional application developers who prefer to use scripting languages, also emerging developers, people coming over from other aspects of the Web, client-side developers, or rich media developers, or others, that they have an approachable way to do that. At the same time, they want all of the standardisation benefits and scalability benefits of Enterprise Java. And that's really what we're focussing on doing here. We think it's actually going to be quite appealing for corporations. They've invested a lot of money in quite a bit of infrastructure, many of them in major platforms like WebSphere and iPlanet and so on, and a lot of that infrastructure is going unused because there aren't enough skilled people who can build applications on it. So we're extending the value of that.
When you compile it with the rich client model that we have, and the authoring and development tools that we're building around it, we think it's going to be quite accessible and affordable and easy to adopt.
ColdFusion MX and Microsoft .Net
Tim: ColdFusion can access server-side Java, and on Windows COM components. Is it possible to access native .Net components?
Jeremy: There are two ways. One is as a web service. That's very easy to do. You can just import a .Net web service, and script against it in ColdFusion. It's the easiest way to use web services. There's authoring support in Dreamweaver MX for doing that. That's the model we're pushing.
The second way is to use .Net's COM interoperability technology. You can import and use the COM API's with COM objects, and when you do that ColdFusion can access them. We are looking at other types of integration using things like .Net Remoting, which are possible, but it's still very early. There aren't .Net objects out there yet. We're going to see what customer patterns look like, whether they prefer to keep their systems loosely coupled with web services, or whether they want to have tighter binary level integration.
Tim: Do you think Microsoft will succeed in migrating developers to ASP.Net, or will Java take increasing market share?
Jeremy: I see it differently. .Net is very attractive to system programmers. When you look at .Net it's a big jump for Microsoft in terms of capability. It largely is Java, with a couple of different languages that support it, but fundamentally those languages are actually Java. VB.Net and C# are nearly identical, and they're almost identical to Java. They've got quite a nice set of facilities in there, and I think Java programmers will find it compelling.
At the same time, it is a much more complex model for scripting level developers. It is quite a big intellectual leap. We actually think there's an opportunity to attract many of those customers, who may have been traditional ASP developers, and who in some respects are intimidated by that model. The other thing is that the tools that we're doing around .Net, in Dreamweaver MX, encapsulate a lot of that complexity. There are server controls that abstract underlying .Net classes and allow traditional web application developers to use it without having to be C# or VB.Net programmers.
Tim: So ASP.Net is too difficult?
Jeremy: I think it is too difficult for a large number of web professionals and scripting level developers. I think it is attractive to Java programmers.
Soap and WDDX
Tim: Going back to web services, has Soap replaced WDDX or is there a role for both?
Jeremy: It has pretty much replaced it. ColdFusion MX has a web services engine built into it. It is also built into JRun. That engine we coded along with IBM and the Apache group, it's called the Axis web services engine. We are the first commercial platform to ship that.
Tim: Isn't Axis still in beta?
Jeremy: That's right. We've forked at a certain point to get ours to a commercial level of readiness. But that's our web services engine. It's got a few nice features, it does client proxy generation and WSDL generation for Java, but we've also tightly integrated it with the ColdFusion component framework so that a scripting level developer can very easily create and consume web services. For doing inter-application communication that is definitely the way we're going.
However, what Soap doesn't do is to provide a very simple, generic object serialization model. That's what WDDX still does. So we still support WDDX in the product, it's included as an API, and we still have APIs available for Java and COM. It you want to take an object or some data and write it out to disk as XML, it's a very simple way to do it. It's a utility.
Tim: What's your take on the Soap interoperability issues?
Jeremy: It's a big concern. We are doing a lot of testing ourselves and it's still pretty bad out there. We've done private interoperability work with IBM and Microsoft, we're also one of the founding members of WSI. It will take a year before there's real interoperability that people feel comfortable with. So it's an industry-wide issue.
I'm a bit afraid. I think we'll continue to see people layering their own things on top of it, making it more difficult to work. One of our engineers was at one of these interoperability get-togethers, and meeting with the Microsoft folk, and the Microsoft folk said that they have enormous interoperability challenges internally. They have 12 different Soap stacks that have been implemented in Microsoft. Just getting interoperability amongst those is quite a challenge. So yes, it is an issue, but people understand that it's critical and are focussed on it.
Homesite and what happened to Kawa
Tim: What happening with Homesite?
Jeremy: A few things have happened. Dreamweaver MX combines the next release of the foundation of Dreamweaver with the next generation of what was Ultradev, and also with Homesite and ColdFusion studio. We've taken about 70% of the featurs of Homesite and ColdFusion studio and re-implemented them in the Dreamweaver codebase, in cross-platform C++. In fact the Dreamweaver MX workspace very much resembles the Homesite workspace. Almost all of the core programming features, for ColdFusion development as well as generic web programming, are native in Dreamweaver MX. We're also bundling with Dreamweaver MX a free copy of what we call Homesite Plus. This is ColdFusion Studio 5, renamed Homesite 5 - it was always a superset of Homesite anyway. That comes for free with Dreamweaver MX.
Tim: What happened to Kawa?
Jeremy: We stopped developing Kawa about a year ago. It was a nice tool, and the real issue is that to compete successfully in that space was going to be an uphill battle. We did involve the team in some of the other development work that we did. We built a set of extensions to all the other Java authoring tools for building JRun applications. But it didn't become any kind of major product investment for us.
Tin Can communications
Tim: Any last thoughts on how you see web applications evolving?
Jeremy: That's actually another piece that I haven't talked about. We're introducing a new technology for communications applications. The concept of these rich Internet applications is one that combines content and application and communications into a single environment. There's a client piece to that and a server piece to that.
The Flash player that was recently released includes within it all the client capabilities needed for these communications applications. It allows you to deliver real-time, peer-to-peer or one-to-many or many-to-many real-time communications applications, with shared data, audio and video. All that is built into the client today.
We'll be introducing a new communications server later this year. It's codenamed Tin Can, and it allows you to build these communications applications.
Overall, we see people wanting to build richer applications that run in browsers, on desktops and on devices. We have a client for that. We think that the development model is one that combines the synergy of content and application programming. We think that's really how we're going to get to better user experiences and more effective interfaces. Our IDE strategy is reflective of that.
The other piece is that the server side is moving to a very different role. It is moving to providing services to these clients, which is a different kind of model. While we could just repurpose Enterprise middleware applications and wrap them up in Soap, we think that we need to make classic component development for servers acceptable to a much broader range of people. Scripting developers who build ASP or JSP or PHP applications are going to be building on these back-end services. We need to have a component model that's acceptable to those types of developers, and not force them into having to be Java programmers or EJB or COM developers.
That's one of the big focuses for us. How do we make classic middleware approachable for scripting developers?
The communications piece is the most experimental of all this, but we think application development will start to integrate communications more, as people want to augment and extend their Internet applications with human interaction. Today there are standalone solutions to do some of this, but because they are not generally available in ubiquitous clients, or because the server programming models are difficult, they haven't taken off. We are taking a focussed approach there as well.
Tim: Can you say more about the communications piece?
Jeremy: You can do real-time shared audio and video. You can do real-time shared text. But more importantly you can do what's called shared objects. Shared objects allow you take any object in a client in your application, a data object, or a user-interface object, and share that across a connected client. So I could have a collaborative application where multiple users are interacting with the data and the user interface. They may also be doing communications, they may also be speaking to one another and so on, but they may just be collaboratively interacting with a user interface and the data in it.
Check back soon for more interviews, reviews and comment.
Go back to part one of Explaining the MX vision.
Copyright Tim Anderson 29th April 2002. All rights reserved.
Sign up to be notified of future articles
Macromedia Studio MX best buy: upgrade from 2 or more Macromedia products
Details here for (US) Studio
MX Windows and Studio
MX Mac
Details here for (UK) Studio
MX Windows and Studio
MX Mac
Latest books
On Flash MX and
Other Web development topics