News: Macromedia ColdFusion MX for J2EE AppServers Released
Macromedia today announced the availability of Macromedia ColdFusion MX for J2EE AppServers. The product allows you to write ColdFusion Components (CFC's) and use the server scripting environment within J2EE appservers. You can also make calls to EJB's or other java-constructs from within the CF application code, in-process.
- Posted by: Floyd Marinescu
- Posted on: September 09 2002 11:55 EDT
Read the Press Release.
Check out Coldfusion MX.
- Macromedia ColdFusion MX for J2EE AppServers Released by sean decor on September 09 2002 13:00 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Jason McKerr on September 09 2002 14:14 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Greg Jones on September 09 2002 17:19 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Jim Arnold on September 10 2002 04:49 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Toby Hede on September 09 2002 21:54 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Rob Smith on September 10 2002 10:51 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Craig Schlegelmilch on September 10 2002 14:50 EDT
Macromedia ColdFusion MX for J2EE AppServers Released by David Grant on September 10 2002 03:39 EDT
Macromedia ColdFusion MX for J2EE AppServers Released by sean decor on September 11 2002 04:31 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by charles arehart on September 11 2002 05:03 EDT
Macromedia ColdFusion MX for J2EE AppServers Released by John Bigboote on September 11 2002 05:14 EDT
Macromedia ColdFusion MX for J2EE AppServers Released by Toby Hede on September 12 2002 12:28 EDT
Macromedia ColdFusion MX for J2EE AppServers Released by John Bigboote on September 12 2002 08:55 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by VIJAY KHANNA on September 12 2002 11:30 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Toby Hede on September 13 2002 12:18 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by John Bigboote on September 12 2002 08:55 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Toby Hede on September 12 2002 12:28 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by sean decor on September 11 2002 04:31 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by David Grant on September 10 2002 03:39 EDT
- Macromedia ColdFusion MX for J2EE AppServers Released by Craig Schlegelmilch on September 10 2002 14:50 EDT
Cold fusion was improved / same as Microsoft ASP stuff. It was simple server side script. Now theses guys have added some thing called components. but still mixing this with java will be more complicated than to just use J2EE or just use Cold fusion. Somehow mix of two totally different technologies is a risky affair.
What do you guys think ?
I think it'll be a great thing. If it is as easy to use as the old Cold Fusion, that's a good thing. Very good for less experienced developers.
And, if it's that easy to use, but can work extensibly with J2EE conventions, that's excellent. The biggest problems with Cold Fusion were extensibility and performance (on scaling). This may fix those problems, while simplifying development.
Of course, everything I just said is kind of a guess, since I haven't downloaded and tried it, and probably won't.
Allaire and Cold Fusion doesn't get the credit it deserves.
The Allaire company has been about ahead of technology since I started using it about 8 years ago.
Take what JSP tag libraries have today and go back in time about 5 years ago. CF was doing the same thing and people where making money on the tags they created back then.
They were creating equivalent JSP Tags in '97. They where displaying dynamic XML content in '99.
The thing to get across is that this is all Java now. The past CF was written in C++ and the Cold fusion controllers where written in C++. Now that it is in Java, this should open the doors for them.
If Macromedia keeps the brains behind the Allaire company they bought, it's going to be a really difficult server to beat for midsize, large, asp sites.
I agree, Cold Fusion was well ahead of its time. I mean, I *hated* using it and just thought it was a novelty, but now I've been using other tag-based models I can see what they were trying to do. You could get a print-out of a database recordset in like 3 lines ISTR.
I hope they can continue to innovate.
I started with ColdFusion way back in 1998 before server-side Java was really invented. It remains one of my all time favourite development environments. You could do stuff in ColdFusion then that only recent Java frameworks are cacthing up with: MVC patyterns, server-side components rendering HTML. We did web services in 1999 with a thing called WDDX, serializing native ColdFusion objects into XML, then streaming across the web into a COM application.
I think that ColdFusion MX offers Java developers some substantial productivity gains and poses a real value proposition for many organisations.
Couple this with a rich Flash MX client and you have an incredibly powerful model for development.
Macromedia seems to have a fairly compelling product set here. I checked out the Flash pet store demo, it's probably the best UI I've seen on the web.
Anyone have experience deploying Flash front-end's that utilize the Flash Remoting software? We're using a portal, and I don't think we can fit in the Flash Remoting and ColdFusion MX software on to the portal server, but could the portal still serve up the .swf file, which would then talk to some other server running Flash Remoting and CF MX? Is that possible - create the .swf file using Flash MX, then deploy it on a web server, and the .swf file is configured to talk to some server running the Macromedia stuff? I know very little about Macromedia software, I'd be eager to hear of suggestions for integrating their software.
I must admit, Flash remoting is very cool. If there is any advantage to bolting CF onto a bigass app server like websphere, its to utilize this. Flash can now accept RecordSets and pull data out as need be. All it needs is a CF Component, Java class or .NET class to call on to get it.
I'm also a diehard CF devotee after spending many an hour with JSP. The CF syntax is so nice and concise. Now that you can integrate CF templates into J2EE contexts, its now possible to replace JSP with CF while not giving up your JavaBeans. All the power of Java, all the elegance of CF at the presentation layer. Very cool... If only it was free...
As for having a Flash swf calling another service -- it seems like it should, but we've never been able to get it to work. I'm pretty sure I read somewhere in the MM documentation you can't, but I may be wrong.
As for the "Hard to integrate two technologies" comment;
Besides being built in Java now, ColdFusion pages actually compile to Servlets like JSP's do. Something that gives CF more performance, instead of being interpreted with each and every request.
we have to agree java technology is by far the most stable as of yet. so why is CF also coming into market with something like components which compile into servlets. I m not saying they should not, but i dont see any advantage and maintainig Cf pages seems easy for smaller sites only. Its a lot lot lot lot more like scripting language at the end. its a pain in the ass to maintain for sites with more than 1000 pages. And howmuch ever people have used it, i have spent 2+ years on cold fusion too and know how it works and what it lacks. so i guess its a question of everyones peception and and what u feel is m\necessary and what the application size is. As per me Cf started to be a scripting language, then saw that java and jsp seems cool, so started to build somehting like that and came up with Cf pages which build into servlets, then came out with flash integration ( flash by the way looks cool on T1 lines only. u add more content and come down to more than 50% of people who use dial up modems still in the US, u will know how flash sucks and heavy on memory.
It has a long long long way to go and it better be fast else it will be way behind the race with j2ee - .net
shs, you're slinging a lot of FUD, I think. You ask why MM is coming out with components, and assert that it's a pain in the ass to support large apps. The whole point of components (CFCs) in CFMX is to relieve the pain of scripting by moving more code and functional responsibility into components, just like beans. That's certainly a good thing.
It's going to take a while for the CF community to fully grasp and leverage the design possibilities that CFCs enable. It's already happening. The bigger challenge, as your comments suggest, will be persuading folks with negative images, whether they've worked with it in the past or only heard about it.
CFMX is a whole new animal on many levels--yet, as others have suggested, it all comes with the same ease of use and approachability that are hallmarks of CF. That may seem an impossible contradiction. Instead, it suggests the elegance of the implementation. Folks can leverage whatever their skills and software engineering maturity will allow.
As for your bashing Flash and asserting that it sucks on anything but a T1, that's just not true. And I'm not arguing on emotion here. I'm connected as I write while traveling via a modem in a hotel room at less than 56k.
I just visited the Macromedia PetMarket app (http://examples.macromedia.com/petmarket/flashstore.html) and am running it from that site. This is surely among the richest flash apps out there (again, I'm referring to using flash not for "movies" but instead for enhanced web application interfaces).
While the app took a few seconds up front to load up its resources, once done, the app is working extremely well. And a Flash app that leverages flash remoting won't even have to download large amounts of data. It can instead gather it on the fly in response to user selections and without the kind of page refresh that would happen in typical HTML-driven web apps.
Sorry to sound too much like a homer, but it just seemed that shs's comments needed to be thoroughly addressed.
The main advantage of CFCs is that rather than developing with a page or template architecture in mind, you can develop true reusable components using CFML and CFSCRIPT. These components can be declared and instantiated, call methods, do some work and destroy the instance. It's very much like object oriented development, but notice that Macromedia is careful not to use 'OO' and has opted to use 'component' instead to describe CFCs.
The big thing with CFCs for Macromedia is the ability to easily deploy web services in a Cold Fusion enviroment.
As far as Flash Remoting is concerned, this has got to be one of the biggest kluges going. I can see why Macromedia would want to leverage a plug-in that's on nearly every desktop, and salvage a technology that makes "Skip Intro" the most frequently clicked link on any site. But, this is a developer's nightmare. If you can think like a graphic artist and somehow shoehorn the concepts of layers and timelines into your software engineering world view, you'll do okay. And, if you want to learn yet another (albeit ecmascript derived) scripting language, fine. But, no matter what Macromedia would like you to believe, it ain't easy to do anything but the most simplistic tasks. Understandably, they want to grab the "rich client" market.
IMNSHO, you'd be better off developing rich client apps in SVG and good ole straight ecmascript. Yeah, there's no SVG plug-in already installed in most browsers, but so what. Stick to open standards and download the plug-in.
"it ain't easy to do anything but the most simplistic tasks. Understandably, they want to grab the "rich client" market"
You can do stuff in flash that you wouldn't dream of doing with other technologies. Ever tried scripting a draggable layer in DHTML? Flash requires 4 lines of code to handle this type of thing.
FlashMX has made huge leaps into a real development environment. It is component-based, so you can drag and drop interface widgets, just like in VisualBasic. The 'Movie' paradigm does take a little getting used to, but for many types of rich-client applications can be largely ignored anyway.
Please note that I didn't say "it ain't AS easy AS..." but rather "it ain't easy", period. Neither is cross browser DHTML as easy as it could/should be. But, I guess I think of draggable layers for an enterprise app as fluff, anyway...The Pet Store never looked better, though...Don't get me wrong, Flash is very cool for what it does: animated vector graphics. My contention is that it's a stretch to consider it anything other than a crude first attempt to repurpose a technology in a "square peg in round hole" fashion. Perhaps this will change, but...
A big concern I have is code maintainability. Code married to graphics in a timeline sounds like a nightmare in the making...
Another technology I would look into is XUL for "not as rich" client apps. There's even an effort to develop a XUL framework for Flash, of all things.
Finally, check out the article in InternetWeek about a recent startup in the rich client arena, Laszlo Systems. Sounds like this would be a more comfortable technology for most developers....
Well..all said and done.
I think we guys need to understand the underlying beauty in both the technologies.I believe thats the reason..they decided on handshaking.Having worked on CF as well as J2EE, I feel this approach is going to help us ..the developers in providing rich content with the incredible power backed by the most stable platform.Having worked on Apache struts..which provides lots of tags...to replace scriplet in JSP's....I feel the integration of CF with Java will prove to be a boon to both the community developers.
Someone said about T1 lines....I think bandwidth will be taken care of in the years to come.After all SUN & MACROMEDIA are not JunkTanks...but indeed ThinkTanks.
Their marriage is going to be a blessing for most of us.
But guys ....don't be complacent....PHP is heading a bigway too.After all, the opensource community has the blessing from the community worldwide.They are heading towards OOP. have a look at http://pear.php.net.The Israelis will not sit quite :)
XUL has me intrigued as well. The possibilities of this are ery promising. The ability to accesss the intrinsic Mozilla components from script with XUl is also a big step. There is a version of Mozzilla with a Web Service client built-in now, so that opens up all sorts of new realms to explore.
I agree that code maintenance in Flash has been really poor. However with Flash MX you can code in external text files, so control code using your normal CVS stratgy. Also, and you can create generic classes of objects in ActionScript. These objects can then be 'extended' by particular components or movie clips at runtime, giving you a way to start bringing a real OO architecture into Flash.
I have been working with Flash MX for some months, so I sound a little evangelical, but I am really really enjoying it.