Macromedia today announced Macromedia MX, a new integrated family of client, tool, and server technologies for creating rich client applications. In particular, FlashMX fully integrates with server side EJBs, Java beans, jmx beans, and Web Services. The new J2EE-based Coldfusion MX includes a new server side Component Model, allowing business components to be developed and hot-deployed as Web Services.

Read the press release on Macromedia MX Suite Launch.

When Jeremy Allaire gave me a briefing on this last week I couldn't help but think about the new implications that this could have on the way we design web-apps. Although Flash is proprietary, it is deployed on 98% of browsers, essentially making it a universal standard. Now that Flash MX has such strong out of the box integration with server side technologies like EJB and .NET, it is possible that we will begin to see many large and familiar websites move off of the clumsier request/response web model and begin implementing new online *business* applications with Flash front-ends to their server side business logic. What are your thoughts on this?

The new Flash Component Model offered part of Coldfusion MX also seems to provide a simple model and language (scripting) and IDE base upon which to quickly launch Web Services. This combination of a simplified model, language and IDE is only currently rivalled by Weblogic Workshop and Visual Studio .NET. Could Coldfusion MX, itself a J2EE-app deployed on J2EE servers make Macromedia a player in the Web Services market?

-Floyd

I was trying to do something like that in java!

http://reservations.broadmoor.com built using MX is really something!

Just wanted to note that the iHotelier's Broadmoor (as well as a couple of other hotels') application has been around since before FlashMX and works perfectly with Flash 5.

Jesse

I have been waiting for this release for a while, and think it offers some really exiting possibilities.

The trouble with Flash has always been on the usability front. Flash has in the past required developers to create their own interface 'widgets', and because of the skill set involved this really requires dedicated flash designers to achieve. Compare this to a technology like Swing or .Net forms, where the interface components are standardised and fairly generic and developers can create them themselves. Go to HTML and forms and the interface process is even easier, albeit clumsy, although with DHTML things can be a little bit more useful, but then cross-browser issues come into play and Flash looks more and more appealing. (I also think that .Net applications on the client have some potential - with a download of the runtime, you gain capabilties not unlike the Java applets of yesteryear ... depends what the uptake is like, but count on MS to push the technology to everyone ASAP).

Also, when information is put into Flash, it is no longer indexable and searchable. As an aside, the statistics for Flash uptake have always seemed a little bit high to me.

ColdFusion has for a long time been my favourite server-side development technology, and it was always sad that it lost out to ASP, PHP and JSP, it would be great to have a revival. ColdFusion was tag libraries years before JSP had even been invented, and it remains one of the best designed frameworks in any environemtn that I have encoutnered.

Disclaimer:
In a past life I was a 'Multimedia' developer so I actually have a lot of experience in Flash, Director and ColdFusion.

Flash is a usability nightmare.
The support on Linux is very buggy and behind the other platforms.
Flash is not an open standard.
When SVG tools mature, SVG is a better solution.

java applets of yesteryear? Java applets are still alive and well. And they don't cut off any clients who choose not to use microsoft. And I can't wait to see the .net clients that simply don't work becuase you are not running a 4 GHz with Windows XP++ version 4.3567 dll version 3a with IE version 7.6. Just force your clients to upgrade.. You know they want to.

Why develop for a single platform when you can develop for any at no extra cost. Why spend shedloads of money on the tools for developing when you can do it all for free... on a proven platform.

Just because .net is new and shiny and has a huge marketing budget does not mean we should believe it is actually a step in the right direction. Or that it will actually work, might do, might not.

Sorry to go off thread.

Jonathan

I don't think Flash MX has something to do with .NET or says that applets are not state-of-the-art. MX is just nicer than programming a lot Javascript functions for every browser and getting a "rich" client with DHTML. MX is nice and if it integrates with J2EE and .NET it's even nicer...with 98% supporting browsers you really reach a mass with it.

Mirko

Come on, admit it. No one uses Java applets any more, not really. When they were first released they were hyped as the new model for the web, I know, I was there. I still have my Java applet book. I haven't coded one in nearly 5 years almost, although in 2000 I did have to use a load calculator in the browser, but I didn't write it.

Actually, in a delicous irony, developing applets is probably now the way to cut off people who choose to use Microsoft, given that the Java runtime is not pre-installed and is a fairly large download (no idea how much it is, but at least the Flash plugin can be measured in KB).

Anyway, I wasn't trying to start a flame war, I don't care about .Net any more than I care about Java (although I am probably one of the few people who can say they are fairly conversant in both, which is the (dubious, I admit) advantage of not actually having a life). My point was really that perhaps the time of the rich-web-client has come. Now we have at least 3 models (Java, .Net, Flash) so users may become more amenable to the idea...

Many sites do. MSDW does. Tools like Robocode generate HTML code that uses them. I know of a major communications company that uses them - I developed one for them.

I don't do any that use the MS JVM. But when I have to do a complicated HTML interface - I don't. I use an applet. Many times my backend isn't Java (unfortunately) so I can't do something like Tapestry. The way I write my applets they can be quickly transformed to standard application frontends and can be deployed via Java Webstart.

As for Java not being installed on PCs, it will affect any client-side Java application.

I hate developing and using complicated HTML user interfaces. The rich user interface has been here for awhile. I wish I could sell more customers on the idea.

Mark

I went to their site and read the FAQ and some marketing stuff.

What is the architecture of this thing?

Is it ColdFusion tags implemented as JSP Tag Libs? How does this relate to the JSTL?

They mention IBM WebSphere, but I assume this will run on any app server?

Does this rely on their XML format (WDDX)?

It's confusing isn't it. The technology here looks really impressive from the 'demo' hotel booking application. However, the MacroMedia website seems to only be giving out examples about ColdFusion.

OK, I know that is your baby MacroMedia, but some of us would like to know how to use the client part from simple JavaBeans/EJBs using Tomcat (for example) without using ColdFusion at all.

MacroMedia can you please clarify?

Couple of items:

Flash is a usability nightmare : This is something that is not specific to flash, but to bad design. Furthermore, Flash MX adds a lot of new features specifically to make it easier to design usable sites (i.e. common ui components, ability to book mark sections of a flash movie).

Support of Flash on other platforms : We have spent a lot of time ensuring that flash is available on a wide variety of platforms, these currently include:

windows
mac
linux
solaris
hp-ux
pocket pc
QNX
BeOS

In addition, we have players for a ton of devices (too numerous to mention).

as far as the linux player lagging behind, true, traditionally we have developed the win / mac players first, and then released the linux players, but does anyone think that this is the wrong strategy? (not a rhetorical question)

Flash is not an open standard : no, but we do make the file format available.

as far as Flash Remoting and Java, we haven't made any specific announcements on this yet, but check out these interviews with jeremy allaire:

http://www.itwriting.com/mxinterview1.php

http://www.itwriting.com/mxinterview2.php

he gives some information on our plans with Flash Remoting vis a vis java.

specifically:

---
Tim: Is Flash Remoting only a feature of ColdFusion MX?

Jeremy: Flash Remoting supports ColdFusion, .Net and Java. The capabilities come with ColdFusion MX, but you can also buy the Flash remoting service standalone.

We have adaptors for ASP.Net and for Java, so you can use Flash as a client with any backend.
---

As far as lack of resources on Flash Remoting and Java, check out:

http://radio.weblogs.com/0106797/

i will try to get some simple java example up soon (we will have more on the Des / Dev center http://www.macromedia.com/desdev/ in the future).

mike chambers

mesh at macromedia dot com

Where is the EAR file?

As I understand it, you need the EAR file deployed on the app server. I installed the remote services but did not see an EAR file. Where do we get it?

-Matt

Having spent the majority of the past year working on both JRun 4 and Flash Remoting for J2EE and .NET, the relation between Flash and J2EE (beyond ColdFusion) is of great importance to me and to the other engineers who pulled the products together. Although official announcements and docs will continue to flow through marketing and product management, here are some unofficial notes from engineering on the topic.

Flash Remoting -- distinct from the low-level network I/O and XMLSocket available in Flash -- is an asynchronous RPC model that allows Flash to invoke methods directly on web services, EJBs, JavaBeans, JMX MBeans, POJOs, ColdFusion pages, ASP pages, and a number of other resources in the ColdFusion and .NET worlds that are probably less important to you than the Java cases. This model uses a binary message format (called Action Message Format, or AMF) that is delivered over HTTP and is modeled on SOAP, though it is much smaller and faster that standard SOAP and is purely asynchronous and event-driven in order to meet the Flash player requirements. It allows you to send a variety of data types -- RecordSets, full Java objects, primitives such as integers, Strings, XML Documents, references to EJBObjects, Dates, etc. -- across the wire. Passing ValueObjects through existing EJB-based apps to Flash clients is certainly possible. A gateway on the server handles conversion of these various types from their ActionScript (ActionScript is the ECMA script syntax used in authoring Flash) versions to their Java versions and vice versa (the .NET version of Flash Remoting does the same for CLR/CLS types). This gateway is designed as a front controller to server processes, and contains a number of filters to handle issues such as serialization, logging, security, etc. before handling the actual invocation of the targeted service. The .NET version follows a similar architecture, although it was written from the ground-up in C# instead of Java and is packaged and deployed differently.

The client-side scripting model involves setting a connection to the gateway URL -- and due to security sandbox concerns, a client delivered over HTTP is permitted to access a gateway only on the host that delivered the movie, ala Java Applets -- and invoking the getService(...) method from the gateway connection. A "service" can be any server-side resource mentioned above, and the client assumes it exposes "functions" that can be invoked in the movie. If the remote service is an EJBHome, then the service functions are the EJBHome methods; if the service is a web service, the service's functions are the same as the web service's methods; if the service is a web context, then the service functions are ASP or CF pages available in that directory; etc. Through ActionScript, typically in response to client events such as clicks or data input, a service's functions are invoked and the results are asynchronously (everything in Flash is asynchronous) returned to the movie, typically causing the movie to update in some manner. Regardless of whether the remote gateway is hosted in a J2EE, CF, and/or .NET environment, the client-side API is the same. A single Flash client might connect to both .NET and J2EE resources, but it does so with the same API.

There are other elements -- we included a data binding API so that RecordSets and other relational data can be directly bound to Flash UI components, for example, and added a debugger and service browser to aid in development, and numerous new UI components -- but this summarizes the basic approach.

There are two parts of the Flash Remoting product: client ActionScript extensions and a server gateway. The client extensions are free, but the server gateway is implemented as a J2EE application (packaged as an EAR) that currently ships in JRun 4 and ColdFusion, and will soon be available elsewhere through partnerships with IBM and Sun. If you download JRun 4 or CF, you'll get this EAR as part of the install. I'm not yet sure how it will be productized in other application servers, but if not embedded I imagine it will be available for sale (look for official announcements as they occur).

For more information about Flash Remoting, I'd recommend downloading either JRun or ColdFusion (the default ColdFusion standalone version is now a web app that runs on an embedded version of JRun, essentially JRun with a large taglib and different web admin, though it will be released for other app servers as well) and fiddling with the Flash Remoting samples and bundled documentation there. Alternatively, you can grab Flash Remoting for WebSphere or for .NET in a beta program, if you're working with either of those platforms, and fiddle with the samples and docs we include for those versions. There are certainly opportunities for improvement in the future, but the current MX launch in conjunction with the pending release of JRun 4 is a terrific start toward enriching J2EE development with extremely powerful media-rich clients.

PS Neville

By the way, JRun 4 is not quite final yet -- further evidence that my messages are unofficial, and that while as an engineer I can tell you all about the technology, you're better off receiving product packaging and editioning info through the official announcements -- but for those eager to dive into tinkering with Flash-J2EE today, JRun 4 is accessible through a public beta at the following URL:

http://betaprograms.macromedia.com/nozomi

Flash MX is available with the rest of the MX platform, tutorials, articles, and samples at http://www.macromedia.com

psn

Why would anyone choose Macromedia MX over for example EJB+ struts + SVG + XML + XSLT + JSP + Servlets?

The above are probably harder but you can accompish so much more and they are a much better solution for any enterprise application.

People would choose Flash because to the best of my knowledge there is no development tool for SVG. Flash provides a pretty sophisticated IDE for creating interactive client-side applications.

So the choice becomes:
EJB + struts + SVG + XML + XSLT + JSP + Servlets

Or:
EJB + struts + Flash + Servlets

Flash seems simpler to me ...

As an aside, I wonder what happens to Director now that Flash has gone balistic? Director seems to be slipping slowly out of the Macromedia suite, which is a good thing in my opinion because it was starting to get a bit bloated in its olde age...

Actually, depending on your application, it could be:

EJB + Flash

If you truly build a business logic server with EJB and have flash access your business application through session beans, you can use flash to manage the entire presentation layer. The client is stateful which helps this job a lot.

Modeling your application to work this way is probably a good idea anyway. You can also build the:

struts + jsp

layer as a client to your business application if you need to support non-flash clients. In the real world, this layer will probably also include services for your flash client which will work fine too.

Hi,

How does the Flash MX remoting differ from Generator?

If you use Flash MX and you start talking to Java Beans then the upcoming DreamWeaver IDE is used for what. I would guess at that point it is a question of FLASH MX and the app-server.

Can this remoting capability be added to any JSP/servlet container such as Resin or ORion?

Thanks,

Stef

Flash MX is cute, but not capable of supporting a real distributed enterprise application.

If you want to see a rich-client programming language with:
- full SOAP and HTML support to integrate with any server side architecture
- 2d/3d graphics
- client side events
- desktop style interface
- integrated SAX 2.0 parser

... then take a look at www.curl.com and in particular the demo at http://www.curl.com/html/demos/subtleframe.jsp?embed=1&title=Featured+Curl+Customer:Siemens&url=/demos/solutions/siemens/start.curl

I think you will be impressed.

People won't use SVG or Curl or Applets because the people that *best know how to design UI* know and love Flash; and Macromedia knows this.

Most good server-side Java developers suck (can I say that on the air?) at designing good user interfaces. The same guys that could put together a booking engine with EJB's and JMS couldn't make an easy-to-use UI if they were given a time machine. In my experience, good looks sell, good back-end maintains. That's it! You can have the best back-end in the world, but no one will give a flip if they don't like the interface.

Have you seen any interface libraries in SVG? I haven't and I look daily; even frequent the SVG developers mailing list.

Oh, and in response to Flash's supposed inability to "support a real enterprise application". Hate to tell you but Flash is already very capable of doing this in version 5 with its XML capabilities. The native object bridge is just icing on the cake.

Jesse

I think using Flash as a front end is cool(definitely better than HTML) but how do I keep my business rules in one place? By using Applets and Webstart I can.

Save for view-change logic (zoom in on numbers or details, etc), I'm not sure how I would actually *put* any business logic in my Flash movies. The movies read XML data sent to them by web applications. If you don't support flash, write a JavaSCript application that takes the same XML and dynamically manipulates HTML...badda bing, badda boom.

Either way, everything but the user experience is generated on the back-end (and even some of the Flash charts, thanks to Corda).

Jesse

Any validation logic can be (and should be) considered business logic.

> distributed enterprise application.
[ ...snip...]
> ... then take a look at www.curl.com

I don't think many corporations will develop enterprise
applications using a metered application pricing model.
I can't imagine a CIO going for this because they wouldn't
be able to predict their costs. If an application is
successful and is eagerly adopted and used corporate-wide,
the price goes up? Where's the cost-benefit in that? Can
you imagine where the web would be if Tim Berners-Lee
charged a content toll for the HTML that is transfered
from host to client? There wouldn't be a web, we'd all
still be using gopher and there wouldn't be a browser
cluttering up my OS.

btw..I think Curl is very cool but much lesser supported than Flash. Also MM leverages a very small plugin. If you think what you can do with Flash, and you take a look at the size of the plugin, than my respect for the engineers grows immediately. If you want to download support software for curl, it takes you several minutes to download and install.

In my opionion is Flash MX a good step towards a new movement, but not yet good enough to beat Java applets..f.e take a look at security issues..

btw..
http://www.curl.com/html/demos/subtleframe.jsp?embed=1&title=Featured+Curl+Customer:Siemens&url=/demos/solutions/siemens/start.curl

very cool...usr: test pass: test


T.Thiessens

"I don't think many corporations will develop enterprise
applications using a metered application pricing model."

This is the most common argument against Curl utilization, and one which they have now addressed. They have just changed their pricing model, moving towards a per-seat, per-department or per-site model.