include ("/var/www/itwriting/itwritinginc/itwritinginc.php"); ?>
next for ColdFusion
"Hypothetically, at some point we
may decide to run on something
other than a JVM"
|include ("google.txt"); ?>||
Edwin Smith is a key software architect at Macromedia. As his bio modestly declares, ďHis contributions to rearchitecting CFML for the J2EE and .NET platforms led to the ColdFusion MX productĒ. I was fortunate to get an interview with Edwin at Macromedia Devcon 2002 in Orlando.
Authorís note: References to Neo, coloured pills and the like make more sense if youíve seen the cool movie, The Matrix.
How ColdFusion MX began
Tim: ColdFusion MX is a radical revision of the product. How did it come about?
Edwin: It started at Live Software. We were working on JRun and in 1998, 1999 we started this project called CF_Anywhere. We announced it, and Allaire gave us a call; and a couple of months later we moved to Boston and joined Allaire. We initially spent all our time putting out JRun 3.0. After we were done with that, in summer 2000, we looked at what our options were, and decided to resurrect the CF_Anywhere project.
Tim: Was there any debate about that being the right direction?
Edwin. Yes, total debate. We called it the red pill and the blue pill. The red pill was continuing to evolve the ColdFusion 4, 5, 6 codebase, and then to take the Neo project and make that a new product that didnít necessarily have backwards compatibility, faster, with new capabilities, more powerful scripting, and squarely intended to sit on top of J2EE. All the J2EE servers are having trouble differentiating from each other. So this would be a new thing.
The blue pill was to have one product line, backwards compatible, with new features but also a major focus on compatibility. We took the blue pill.
Tim: The main issue with the migration from ColdFusion 5.0 to MX is compatibility with server-side COM components. Were you aware that would be a big issue?
Edwin: We had a rough idea of who was using COM and how much they were using COM. We knew that anyone using COM might run into issues. But we had tested it fairly well. There were issues that we found in testing but we werenít sure what the severity would be. But the reaction from people was much bigger than we expected. We immediately retooled and our first updater fixed a lot of those COM problems.
We knew that COM would be hard. From an engineering standpoint, going from Java to COM is not trivial. Weíre using a technology called J-Integra, which if properly implemented does a nice smooth bridge, but integrating that into ColdFusion is a challenge.
Tim: Were the problems to do with your interface to J-Integra, or J-Integra itself?
Edwin: It was to do with our interface. Essentially - and I donít remember the exact specific details - it boiled down to instantiating new COM objects more often than necessary.
Tim: I didnít realise until I attended your ColdFusion Under the Hood session [at Devcon] that you could do thinks like calling Java methods on ColdFusion variables. Is there any reason why you canít just embed Java code into ColdFusion, the same way you can with JSP?
Edwin: Actually, an early version of NEO did do that. We decided not. What it boiled down to is that when you have Java in a JSP page you have two languages on the server, the JSP on the server, and the Java on the server. Then theyíre layered together into one running program. If you want to give the user good error messages, good context and good optimization, then dealing with two languages interleaved like that is not very nice. We didnít want to write the equivalent of a Java compiler as part of the product. We did want to have this really great reporting, and good internal model. Thatís the engineering answer.
From the customerís point of view, it was a story that didnít make sense. You have CFScript and you have the tags, and those are easy to learn. Thatís one language. And you have JSP. We integrate with JSP. The two worlds connect, and JSP can do what JSP does very well, and we do what we do very well, and itís a much cleaner picture.
Java, ColdFusion and .NET
Tim: Does your compiler emit byte code directly from ColdFusion CFML, or do you convert it to Java and then pass to the compiler?
Edwin: The current version produces Java source code, compiles it, and we load the byte code back.
Tim: So aside from the debugging it would technically be easy to embed Java code in the CFML?
Edwin: Well, it would just parse right through. But it would be difficult to provide good error reporting. We would have some things you could do that would break the embedded Java code. We could have code that happened to generate the same variable name as something you wrote. So suddenly you use the variable and bam, you get some error message that we canít explain.
The other thing is that in future versions we most likely wonít be generating Java source at all.
Tim: So you will go directly to byte code?
Edwin: Hypothetically, at some point we may decide to run on something other than a JVM. Again, it doesnít make much sense to have Java source in there and then take it out again later. So we took the purist route.
Tim: Are you hinting at the possibility of compiling to MSIL as an option?
Edwin: Iím not hinting that weíre going to do it, but ... we had a design decision to make. We said, well, we canít say weíre not going to do it. So we want to leave our options open.
Tim: That would fix peopleís COM problems.
Edwin: Yes, COM would definitely work better.
Tools for JRun and ColdFusion
Tim: Thereís quite a lot of debate here at Devcon about the right tools for JRun. Macromedia had a nice Java tool called Kawa, which could have been adapted to handle CFML as well. Why was it dropped, when competing app servers mostly have a close association with a particular tool that has good integration features?
Edwin: We had to focus. Kawa was a Java IDE that needed to compete in the Java IDE market. We didnít have the resources to compete seriously. It would have been too hard. Today, Iím looking at Eclipse and IntelliJ IDEA thinking, ďThose are amazing IDEs.Ē If I was using Java every day in my job, or even JSP, one of those two tools would be the one I would pick.
On the other hand, if I were doing web design most of the time, even with Sun JSP, I would pick Dreamweaver. The databinding and the database integration in Dreamweaver is much better than anything we had in Kawa or anything we had in Studio. We pushed the Dreamweaver schedule back by six months to get a lot of the Homesite features in.
Tim: Admittedly Dreamweaver MX is a massive improvement from a developer perspective.
Edwin: Right. Further, some of the gripes I agree with. It should be faster and I would like it to be faster. But as the development team iterates, they will get it faster.
Tim: You mentioned Eclipse, and Macromedia is on the Eclipse board. Will Macromedia produce an Eclipse plug-in for JRun integration?
Edwin: We donít have any plans that weíve announced.
JRun and J2EE
Tim: You mentioned the difficulty in differentiating J2EE application servers. What does differentiate JRun?
Edwin: Weíve tried to keep it small, fast and easy to manage. So compared to the big three [IBM, BEA, Oracle] itís smaller, faster and easier to manage. Thatís just my anecdotal version of ďfasterĒ, rather than specific benchmarks. Then compared to the others, weíve done really good integration with Flash, and we have some unique cluster management features. We use Jini for clustering, which is a very simple way to get a cluster up and running. Any node will come up and discover its peer nodes. Even the cluster management server itself is clustered, so thereís no single point of failure. Using Jini for that makes it easy.
So the differentiation is that we focus on making the management side easy. But as far as the APIs go, theyíre all standard, just like everyone else.
Tim: I was impressed with the JMX support.
Edwin: Credit there goes to Sean Neville. We hired him at the beginning of the 4.0 cycle, and heís done a fantastic job with the clustering, the JMX and the EJB implementation.
Tim: Is there a discontinuity here - supporting the full EJB spec must be a huge amount of effort, but in terms of usage, from what I gather from users at this Devcon, very few people are using EJB at the moment.
Edwin: Part of that is whoís here, which is the traditional Dreamweaver, ColdFusion, Flash web developer. They donít use EJB much. If you go to Java One, for example, a lot more of those people are using EJB.
But yes, youíre exactly right. Even in most applications itís not necessary. In some applications it is, and thatís where all the energy goes. This is for the higher complexity, more mission-critical applications. Thatís what drives the J2EE market, the need for those use cases. Thatís why most vendors spend less time focusing on ease of use, scripting, and easy management, and more time focused on high transaction rates and all of those things. The buying public has obviously said thatís what is most important.
Tim: I find EJB something of a nightmare, because itís so hard to architect your application to take advantage of what is on offer. Is the solution in tools that can simplify the process, or does it need a revision or simplification of the EJB spec itself?
Edwin: Itís both. All the container services that EJB adds, in my opinion they push the envelope of the Java language. The reason you have so much complexity with Beans, the Bean instance, the Home instance, all these generated classes, deployment descriptors, is partly due to the fact that Java itself doesnít express that kind of stuff. It has to be added in as patterns, either manually or with a tool.
In the end, it gets into model-driven design. If you can lay out your design just in terms of its patterns, then the implementation can be derived from that, either in the form of EJBs or Web Services or whatever. Thatís what you want as a designer, as a modelling person. The tools chains just get much bigger and heavier.
Tim: Can you give me any clues as to where youíd like to take JRun in its next iteration?
Edwin: Itís pretty early. Weíre looking at the next version of the J2EE spec, and looking very hard at whatís needed for rich clients. As you know, we released Flash Remoting as part of JRun, ColdFusion, and standalone. Weíre looking at what we can do there, what the problems are, what problems people have putting the presentation layer on their J2EE applications. So JRun itself is focussed on being a good server.
Being a good server is something we can do, but so can everyone else. Itís a pretty well understood problem. But well-designed user interfaces? Thatís uncharted territory. So every product team in the company is looking at problems like that. What people are doing to improve the user experience, to put better front-ends on things.
Tim: Personally I hope that JRun does well, because IBM shouldnít run everything
Edwin: The market wonít let that happen. The market will always make sure thereís some competition, even when thereís a dominant vendor. Weíre still running Apples. But implementing the J2EE spec is a commodity at this point. So you compete on service, support, performance, reliability, but itís tough. So what weíre doing is saying, Macromedia is all about user experience, working out what means for JRun, and moving it in that direction.
Flash and ColdFusion futures
Tim: Iím interested in the use of Flash as a rich client. Of course Flash is horrible if you want to code any client-side logic into your application, better than it was, but still horrible. Have you thought of miniaturising JRun as say a J2ME engine that you could embed into Flash?
Edwin: That would be pretty interesting. One of the things that has enabled Flash to succeed is relentless focus on graphics and on small download. Right now itís a 350K download. No instance of J2ME is that small. So there would be huge challenges on the distribution side. But itís an interesting concept. Itís the client-server pendulum swinging. More logic on the client means more container services on the client, and itís definitely an interesting concept.
Tim: An interesting aspect of ColdFusion is that itís an example of declarative programming, which of course DreamWeaver also uses, not only with ColdFusion, but even with ASP.Net. Is that a deliberate strategy?
Edwin: Totally. Thatís been ColdFusionís approach from day one. Actually, to me declarative programming is like the way a makefile works, or the way an XSL stylesheet works, where thereís no implied control flow. What youíre doing is just declaring relationships. ColdFusion is only partially like that. But that is a great way to program. When you do it that way, the system can derive much better code for you. Youíre working with more domain-specific terms for the problems you solve, instead of just generic code loops and assignments and things like that.
With ColdFusion, when new tags are necessary we add them in. For example we added a stylesheet tag. CFCs [ColdFusion Components] are new, and weíre definitely looking at what more we can do with CFCs. To me thereís a vast range of things we could do there, now that there is an object model built into the language.
ColdFusion vs JSP
Tim: Why would someone choose ColdFusion rather than just do JSP?
Edwin: ColdFusion is not as strongly typed as Java. Itís picked up by people who are interested in doing something other than programming. Itís a programming language but itís basically trying to not be in your face and not require a lot of conceptual understanding of whatís going on. Even in jumping between JSP and ColdFusion, the extra use of colons, strict use of quotes on attributes, and the fact that youíre using Java instead of a scripting language, means you tend to have to think harder using Java.
If Iím picking between two environments, and I donít mind thinking harder, and Iím thinking about power and standards, then JSP is a way to go. But if youíd really rather be running your business, or doing something other than coding, then ColdFusion is always appealing.
Copyright Tim Anderson 17th November 2002. All rights
|include ("mxlist.php"); ?>|
|include ("mxlist.php"); ?>|