Macromedia has published three versions of the PetStore Blueprint application, including Sun's J2EE version running without modification on JRun 4 with a Flash front-end. I gotta say, the Flash Petsore is breath-taking! Even more interesting is the J2EE integration.
The Flash front end accesses the EJB's in the pet store directly, and Value Objects can be transferred from the EJB's into Flash (where they become ActionScript objects). In this case the Flash piece represents a replacement for the JSP-based front end of the Sun app, although a perfectly valid alternate design would have been to create a hybrid JSP/Flash client instead of replacing the JSP altogether. The Flash client shares the HTTP session available to JSP's, and can invoke simple Java classes and JMX MBeans remotely in addition to EJB's.
There's also a Flash front end for the .NET version of the pet store, illustrating Flash's interoperability with that platform, and of course there's the expected version running on ColdFusion MX, using Cold Fusion Components to implement the business logic.
Test drive the Flash front end for the J2EE Pet Store
Check out info about Macromedia's Petstore blueprints
Info about The Flash Front-end on top of J2EE
Now we have real competition for .NET web forms...
hi,flashmx not only support j2ee but also dot net too!
In fact, the main question I have to ask is: is it compatible with any J2EE server, or just JRUN?
Flash petstore looks really nice. I have only two issues:
FlashRemoting is a closed technology and as such organizations should be wary of it. Its a key integration technology and if it remains closed then there is a danger of a vendor lockin regardless of whether macromedia ends up supporting other J2EE vendors.
Nevertheless I do feel that with Flash we might be seeing the beginings of something application devlopers can fall in love with.
my .2 eurocent
Hey, that was only one issue :-)
The other issue is I wish Flash would become SVG compliant at some point .. having a tool like FlashMX to do SVG would be heaven
Nice looking user interface.
As with all Flash applications the key will be the number of internet users that are unable to access the site due to config/platform/browser issues and the size of the files that need to be downloaded.
The Site is really well-done but I can't see it replacing HTML in the near future.
(I just hope I don't look back at this posting in 12 months and feel as silly as the record-company who turned down the Beatles because guitar bands are passe ;) )
The photo of the rattlesnake looks remarkably like a tortoise :)
... and the poodle looks more like Elton John
try www.nexaweb.com. They use SVG and released a rich Petstore as well.
There are some Open Source projects on sourceforge.net like (JGenerator)
and some other - just search on "Flash". Maybe some of them will support this feature.
Does not work with Netscape 6.2/Mozilla 1.0 even with Flash 6.0. I stuck on "Loading Localized Text... :(
Looks great with M$-IE.
But when I ran Sun version from Macromedia it didn't let me "Add to Cart" - every time I got "Your Shopping Cart is Empty".
Something is broken there...
When (IF) Makromedia will fix problems with Flash player then it will be absolutely great UI.
i think this is a good idea, to integrate the rich client and J2EE side.
but for me this only supports IE is so bad:(
hope Macromedia to fix the bug:)
wow, works fine and looks great for me.
Obviously there is a _crucial_ question on cross platform capabilities, however:
according to the buzz statements:
-this talks to the ejb layer, but using the same http connection that accesses the jsps
Is this the solution for:
-rapid web gui development ? (anyone done much flash.. is it quick to develop with ?)
-good separation of presentation development versus middle tier ?
-a web based front end that is actually _good_ for heavy data entry end users ?
Hugh Madden said:
> Is this the solution for:
> -rapid web gui development ? (anyone done much flash.. is it quick to develop with ?)
> -good separation of presentation development versus middle tier ?
> -a web based front end that is actually _good_ for heavy data entry end users ?
You should download the app and take a look at the source to the Flash movie that implements the client part of the app. There's definitely a strong separation between the tiers. For example, the same Flash movie front-ends all three store implementations. The client uses a MVC pattern to separate out the different parts of the UI implementation.
For data entry, you can do a lot with the new Flash Components that are included in the new release.
We did test Pet Market on Netscape as well as IE. In fact, when I demo it I usually use Mozilla.
During the development of Pet Market, it turned out that we discovered an incompatibility between the Flash 6 player and Netscape 6.x. There'll be a player update out shortly to address it.
The bug with Netscape 6.x and Mozilla 0.9.6 has been reported and a fix will be out shortly. It works in Netscape 7 and should work in Mozilla 1.0 but Macromedia is also supplying a fix in the player.
More info posted here: http://webforums.macromedia.com/jrun/messageview.cfm?catid=252&threadid=363050
I don't know what is so nice about this? A non usable nice looking interface WOW!
I wasn't able to run it since I am running linux, I later checked it from my friend's computer. Flash is terrible. I personally wouldn't use it on any serious web site for anything other than a short animation.
It does not work for Netscape 7.0 Preview release 1.0 either.
Eeeuhm noticed something strange
I first ran the sample (http://blueprints.macromedia.com/PetMarket/flashstore.html
) in IE 5.5. About 5 minutes later, I've checked my email via Netscape 7, and decided to take a look at the pet shop in Netscape. I've added a 'snake' to my shopping cart, and... hey... suddenly all my (not submitted) purchases I've made through IE appeared in my shopping cart! Can somebody explain me how the session management is done? Is this a 'bug' or a 'feature'?
I have been looking really closely at Flash for an enterprise level application that currently uses ColdFusion and an HTML interface.
I can't see too many cons, other than reliance on Macromedia for the client, connectivity and development environment (as far as I know there is only one Flash IDE - the Macromedia one). In fact, Flash is marketed as a developer tool, not a user solution.
Flash offers a brillian replacement, provided it continues to be multi-platform and reasonable cost. Sure it's proprietary, but only from the UI. All your back-end can be written in Java, .NET or ColdFusion.
Wow. I was hoping something like this would happen. Macromedia is ingenious in having the mindset to do this sort of thing. We need a richer front end. Flash is available on something like 95% of browsers. That way it doesn't matter whether Microsoft is gonna support the JVM in their browsers.
I wrote this before, replying to the original JRun 4 announcement: Flash integration is *the* killer feature of JRun. I'm thrilled to see Macromedia put some wood behind this, and show everyone what's possible.
This gives developers a good back-end solution in JRun, and a fabulous client-side development and deployment suite, in Flash and associated tools.
This is a great addition to the J2EE ecosystem, it's a great offering for client-side developers who might have chosen VisualBasic (along with the obvious server pairing) instead.
So, I read on groups.google that the
remoting feature used to acess J2EE
will work with any J2EE server.
So my question now is, what's needed
on the server side, and will it run on
Linux? Will I be able to deploy EJB's
to JBoss on my Linux machine and have a
Flash MX front end?
My guess is that the server side components
are some sort of server or EJB that uses
xml to act as a proxy between your EJB's
and the Flash MX app.
According to the Macromedia web site(http://www.macromedia.com/software/flash/flashremoting/
), Macromedia Flash Remoting "is a native feature of both ColdFusion MX and JRun 4, and will be available for purchase separately at a later date."
The JRun 4 Programmer's Guide has a section about using Flash:
According to the Macromedia web
> flashremoting/), Macromedia Flash Remoting "is
> a native feature of both ColdFusion MX and JRun
> 4, and will be available for purchase separately
> at a later date."
JBoss has FlashMX support today; it's in the 3.1 cvs code. From what I understand the only hard part was that Macromedia uses slightly non-complient SOAP so they has to write an extended AXIS servlet.
As soon i read this headline i was very excited & curious to see the demo.. Hardly few folks give a web demo.Generally they ask to download & install one fine day we see our whole harddisk full !!!
I tried with IE 6 & some reason it went on "downloading.. ".It never stopped & two refreshes it didn't work.. As usual I killed the browser & reopened with a new one. This time i got the main screen with all the "Loading messages".. I was getting more & more excited to see the cool UI..But now something new occured..
"A communication error occured. This might happen due to:
A network communication problem between your computer and the Pet Market server.An older version of the Flash 6 Player on your machine. To verify you have the current version, visit the Macromedia Flash Player Download Center. Click here if you'd like to try again "
The i decided let me dump IE & go back to favourite browser. Guess what ??. Yes it is Mozilla 1.0. I clicked the URL & it asked for me "Click here to get the plugin". With great enthuthiasm.. i clicked it.. but it said "Error page requested doesn't exist" :-(.
Then i searched in the macromedia website to download the plugin for Mozilla1.0 but it said me "We are unable to locate a single Web player that best matches your platform and operating system"..
By this time it striked me "Hey search for netscape" & i did and got the one.Installed it & finally i was about to get,set,go..
I typed the URL with my Mozilla & it threw the main screen.. wow..He said "Loading .. Localizing Text" .. thats it .. it never got back to me..
I waited for 10 mins.. lot my patience.
Now i didn't know what to do ?
Then it striked to me.. Hey i got another laptop let me try in that. but i was almost tired.. let me do it some time later....
I was wondering what will happen if we ought to deliver some critical functionality using such plugin based front-end . Recently read a article about "Promises of Curl" ..
Answer is simple : Please keep couple of PCs & laptops with different configurations as back up to view them ;)
Some one in this thread was commenting "Wow we got a competitor for Windows Web Forms".. Yes i think so but only when it works,just like that.. without any extra pain on a 56 Kbps modem with user not having any knowledge other than how to "Open a browser & type in the URL".
Waiting for those days to come .....
if you go back, after error, you can use the demo with mozilla 1.0!
try to take a look at some other vendors. Nexaweb published A rich Pestore at their website as well (www.nexaweb.com).
Goodbye HTML ;-)
I've spent the majority of the past year or so working in an architect role on JRun 4 and the Flash Remoting product for J2EE and .NET, and would like to offer some strictly unofficial remarks on the topic, pulled from an earlier note I contributed to TSS community. By the way, I also have to say that the Mozilla folks were terrific in helping us track down the Netscape Flash Player bug mentioned elsewhere in this thread, those folks really deserve a tip of the hat.
The Flash Remoting mechanism I'm about to describe will expose obvious opportunities for improvement in the future -- random dreams might include XML Schema and SOAP support in the Flash player itself, support for XML-based UI and event definitions (XUL, XUP, XForms, SVG), support for JavaServer Faces through a Flash RenderKit, etc. -- and there's a great deal of potential for client-server connectivity in Flash MX itself even without Flash Remoting. But it seems to me that the current MX launch is a smart first step toward achieving those dreams, and it does enrich J2EE apps today with extremely powerful and bandwidth-conserving clients that are a generation beyond HTML forms. This isn't to say that Flash would replace JSP or HTML in anything other than a minority of cases; in fact, since Flash can share HTTP session sate with JSP's, there's no reason we shouldn't expect to see a hybrid approach. And there's no reason frameworks such as Struts and WebWork can't incorporate these sorts of client hybrids as well.
Flash Remoting -- a product distinct from the low-level network I/O and XMLSocket, XML loading, and LoadVars functionality available in Flash out of the box -- provides an asynchronous messaging model that allows Flash to invoke methods RPC-style directly on web services, EJBs, JavaBeans, JMX MBeans, POJOs, ColdFusion pages, ASP pages, to perform ADO.NET data binding operations, and also to create links to a number of other resources in the ColdFusion and .NET worlds that are probably less important to TSS than the Java cases. The product 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 typically faster than 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, though the data typing is not currently based on XML Schema. Passing ValueObjects through existing EJB-based apps to Flash clients is certainly possible, and EJBObjects themselves are passed by reference to Flash as a result of create and finder operations.
There are two parts of the Flash Remoting product: client ActionScript extensions that leverage some player internals, and a server gateway. Both parts are bundled in the same install. The J2EE version of the server gateway is implemented as a J2EE application that currently ships in JRun 4 and ColdFusion, so if you download either of those you'll have Flash Remoting; the product should soon be available elsewhere for further vendor's products through partnerships with folks like IBM and Sun.
The 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 a bit differently; it also includes an ASP.NET control to simplify Flash.NET development in both DreamWeaver and VS.NET environments.
Note that implementing basic SOAP support in a Flash client without such a gateway is also possible, and some of our Flash customers have done so. And again, Flash itself has strong XML support and the ability to retrieve URL query strings over HTTP. Flash Remoting adds a simpler development model, a debugger, additional security, a data binding API, better performance, automatic serialization, and a few other things to the mix, but Flash MX by itself certainly has client-server strengths that folks can leverage directly even without Flash Remoting.
The Flash Remoting 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, and it would do 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.
How slow can we go...
>Flash Remoting -- a product distinct from the low-level >network I/O and XMLSocket, XML loading, and LoadVars >functionality available in Flash out of the box -- >provides an asynchronous messaging model that allows Flash >to invoke methods RPC-style directly on web services, >EJBs, JavaBeans, JMX MBeans, POJOs, ColdFusion pages, ASP >pages, to perform ADO.NET data binding operations, and >also to create links to a number of other resources in the >ColdFusion and .NET worlds that are probably less >important to TSS than the Java cases. The product 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 typically faster than >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, though the data typing is not currently based on >XML Schema. Passing ValueObjects through existing EJB->based apps to Flash clients is certainly possible, and >EJBObjects themselves >are passed by reference to Flash as >a result of create and >finder operations.
Thanks for the long message from Macromedia - it was very interesting. I'm curious about the relationship between Flash Remoting and J2EE environments.
From the JRUN4 trial, we've taken the Flash Remoting pieces and gotten them to install under Tomcat - but we're prompted for a license key. Is it possible to use Flash Remoting without JRUN? And most importantly, how will this be available? (And when will it be available? For how much?)
I was hoping to make it before you guys... I'm working on a similar project.
Instead of a proprietary message format, I'm using XML loading over HTTP. It's still asynchronous and event-driven and allows for RPC-style method invocation through its counterpart on the server side. It can also be used standalone with XML documents from the local file system - substantially reducing development time.
There is no need for client-side (action)scripting. The UI is defined using a superset of XUL. The XUL engine embedded in the compiled flash client takes care of the View(partially) and the Controller components, the developer being responsible for providing UI definitions in XUL format and obviously the Model.
Currently the data is submitted through HTTP GET but I'm working to support the XUP event model. Since the messages - in XML format - are delivered over HTTP, my approach is completely language / platform independent.
The GUI components used are the ones shipped with Flash MX, although external SWF files can be used to substitute the default components allowing for a "theme" based approach. The same technique, using the additional, non-XUL <COMPONENT> tag provides for extension, so new components like tables, calendars, etc. can be added to the UI without recompiling the flash client.
Perhaps someone from FlashMX team can explain how to develop large FlashMX application in a team environment.
I have minimal experience with Flash (partly picked up from the creative team at my old employer, partly by playing with Flash 5 for a few days) ... please correct me if I'm wrong about any of this.
Unless FlashMX is very different, the flash movies are monolithic binary files. This is quite different from ordinary code development, where different developers can work on individual files largely without interfering with each other.
In addition, source code, which has a simple syntax, works well with source code comparisons and even automatic merging, such as in CVS.
Unless FlashMX breaks with this in some way, then its complexity is limited to what a single developer is capable of producing. Further, that single developer will need to understand Flash, ActionScript and J2EE ... an extremely rare breed.
You don't understand the myrid of ways Flash can be used. Think of Flash like a .gif or a .jpg.
I haven't written too many JPEGs that interact with an EJB server using HTTP tunneling.
What I'm saying is that a Flash movie is complex; it has all those tracks and layers. All those things for sliding, fading, animating, plus some kind of input and output components and ActionScript to deal with communication back to the server.
If it is still monolithic, then you end up with a smorgasborg of Flash and UI and now clean way to split it between developers, especially developers with different skills sets (such as a Flash guru and a Java developer).
By comparison, using a (watch the plug) framework like (here it comes) Tapestry (http://tapestry.sf.net
) you split the work up into little pieces, some for HTML producers, some for Java developers, and cleanly join them together when the application is built.
If the UI and presentation logic is all bundled into a single file, a single monolithic binary file, then you can't do merges or even perform comparisons ... goodbye team development ... the file can only be editted by a single user at a time. Even on small teams, that kind of situation is very detrimental to productivity -- been there, done that, hated it.
Well I am getting an Internal Server Error at 12:55 EDT must say something about Jrun right there.
Re: server being down, this is a reflection of bad sharing of dmz boxes and not of JRun. We're sorting out the mess out right now and the server should be back up shortly.
And if you don't believe me here, feel free to do your own load testing. :) In our internal load tests, we haven't had any problems with the petstore and JRun.
But despite the include possibility, your general point is still quite valid: there's a lot more we can and will do to make Flash more palatable to Java developers, and we hope to do so without alienating our current designer community. Maybe support for XUL, XForms, SVG, XUP or some similar technology is a good bridge (don't take that as any sort of feature promise, I'm merely conversing here).
Meanwhile the WebWork folks have contacted us with questions regarding Flash UI support in their framework, and given the caliber of engineers in projects like Struts and Tapestry perhaps similar support can be added there. Heck, the SWF format itself -- while admittedly binary at the moment -- is open, and anyone is free to create a SWF renderer without using any of our software (http://www.openswf.org
is one site that springs to mind).
On another issue, reiterating a response to a question that's popped up again: the Flash Remoting product will become available for J2EE servers other than JRun 4, and there's a .NET version as well.
When are you guys going to understand that the internet is supposed to be open for everyone and the technology you use should be open standards that are accessible to all browsers/OS.
If flash want to accomplish that, they should at least maintain decent players on other platforms that work as well as their windows counterpart.
SVG is so much more existing to me and I can't wait for better tools to come out.
SVG?SVG supports VIDEO?
This demo looks kind of nice but it's merely a tiny application with a very simplistic UI. What if you have a very complicated one, with a mix of complex inputtable tables and fields for instance ? I cannot find any table in the standard FlashMX components, only one made by some guy in Russia. With the 5 or 6 components that come with Flash how can you seriously make any professional application ? Compare that with Swing for instance, and have a good laugh.
hi,we do not need "table" in flash even if "form" .
we just need textfields.the components in flashmx just to speed up building your application up.by the way,if more components provided would be perfect!
Flash has a mechanism called shared libraries (or something like that) that allows you to encapsulate functionality into components that can be shared across Flash applications/Movies. This would provide the modular work flow people are looking for.
But, Flash development is traditionally slow. Flash MX may improve things, but based on peeking at code it still looks to be slow to create apps in Flash. One of the 'big' features of MX is the UI components that Macromedia likes to hype. Yes , these UI components help a lot but lets face the facts that these components are just simple reproductions of HTML form elements!
Html has problems but once you get it HTML works great for me. It is only when you try to force HTML to be something it is not that people run into problems.
Just my two cents
It is only when you try to force HTML to be something it >is not that people run into problems.
Which is what most Web [business] Applications do.
Indeed. Applications force HTML to do things it's not meant to do because HTML is hopelessly inadequate for the job.
Howard, you should download one of the distributions and look at how the ActionScript code is factored out of the .FLA file.
The Pet Market project was organized with just one person working in the Flash .FLA file, and the coding work done in external files that the .FLA referenced. I don't think that access to the .FLA file is the bottleneck that it used to be.
<comment> Unless FlashMX breaks with this in some way, then its complexity is limited to what a single developer is capable of producing. Further, that single developer will need to understand Flash, ActionScript and J2EE ... an extremely rare breed.</comment>
This is an excellent point - I think the general ubiquity of the Flash player is what makes the offering interesting (despite the issues people are having here loading the thing ;-> ).
Another platform to look at that has interested me is Altio's platform (www.altio.com). IT provides most of the standard rich UI elements while marshalling web services. Note: I don't work for Altio - I just think their stuff is kinda cool.
I'm a little confused as to how tightly integrated FlashMX is with JRun; any idea if FlashMX will run with another application server?
Is anyone else having trouble accessing this Pet Market demo?
I am getting a 'Page not Found' error.
Hi Rob, please see my previous message. Things should be fine now.
I know people have talked about bugs and stuff in other browsers. I'm curious what the official standing is. My boss and I are looking into using Flash for our front end for some of our webapps because we're tired of our stuff looking like crap just so we can support the lowest common denominator. Problem is, I can't access the pet market using Netscape 4.7 or 6.2 I upgraded to the Flash 6 player but it complains about needing a newer version. I know bits and pieces of the answer to this question are strewn about. I'm looking for a complete answer to this. When will there be a patch issued so I can tell my boss that FlashMX will let us make one interface that works across IE 5&6, Netscape 4,6 & 7, and Mozilla?
Also, I'm on a T1, but the interface is a bit slow. Any ideas on why? I can't imagine it's my connection, I was busy downloading a file at work at 300k per second earlier ;)
I want to get a little advice. After looking at the petstore demo I have to say I'm pretty impressed. I've been working on a Java / Swing app for a while now and have to say I'm not at all happy with Swing (to say the least) I think that Swing is weak looking and way too hard and slow to get anything done. Secondly the phase II of my project will to create an internet enabled version of the application which mean I will have to re-write a lot of it from Swing to JSPs etc. Here was what I was thinking and I'd love to hear some of your opinions on if you think it's feasable, if so how I could pull it off or if you think it's just a plain stupid idea. Flash really has the look that I'd like my app to have. I don't swing will ever get it there.
Here was what I was thinking, write the app as a web app and run it locally on the client machine using Flash as the front end. So I'd need to run a single use webserver/app server, tiny database etc. Is this feasable? If so what do I do for an application server that I could embed on the client machine? Has anyone done anything like this before?
I'd love to hear your opionions and advice.
Secondly the phase II of my project will to create an >internet enabled version of the application which mean I >will have to re-write a lot of it from Swing to JSPs etc
Not necessarily. But you would have to use your app as an Applet or use WebStart (or a version of it) or find some other way to distribute the client. You may have to re-write your client to server communication.
>Here was what I was thinking, write the app as a web app >and run it locally on the client machine using Flash as >the front end. So I'd need to run a single use >webserver/app server, tiny database etc. Is this feasable? >If so what do I do for an application server that I could >embed on the client machine? Has anyone done anything like >this before?
I wouldn't. Write your app using OO principles. Then when you need to deploy it use the right tools and techniques for the environment. You may need to use and AOP tool to help you. And it might require having a small database on the client.
Using Flash MX for the frontend is cool but if it only runs in the browser then it is a little limiting. This is not too bad if one must always be connected to the server to work.
Use an EJB tier for your business logic accessed from Swing. This way your app can be accessed from Swing/JSPs/Flash(if you need). If I am wrong on this one, please do correct me.
Doesn't have to be an EJB tier. I do the same thing with plain Java Classes.
Heathan! Thou goest against the Worde from Sun - "Thou Shalst Use the EJB from the Sun Shoppe!"
I shall not worship the Sun god. One will go blind staring at the Sun. Not the way I want' that to happen.
Actually beforet Macromedia, Nexaweb has released a rich client Java petstore that runs on the web. No Java classes was recompiled. It is at