Macromedia Announces ColdFusion MX For Top J2EE Servers

Discussions

News: Macromedia Announces ColdFusion MX For Top J2EE Servers

  1. Macromedia made several announcements, stating that their Coldfusion MX platform was ready to roll on app servers such as BEA, IBM, and Sun ONE (as well as its own JRun of course).

    They are also tauting MacOS X as an enterprise OS platform.

    Read: Macromedia Debuts ColdFusion MX For Competing App Servers

    Read: Macromedia ColdFusion MX for BEA Weblogic Now Available

    Read: Macromedia ColdFusion MX Updated to Support Sun ONE Platform

    Read: Macworld: Macromedia touts Java server for Mac OS X
  2. why sun one and not oracle :s
  3. Good news... that is if they don't get bought by Microsoft.
  4. ...or go directly to the source.

    JRun, WebLogic, Websphere and SunONE are officially supported. Apparently, Tomcat is unofficially supported as well.

    Dunno why 9iAS isn't supported, but it shouldn't be too hard to shoehorn it in there...
  5. Well, Weblogic, Websphere and Sun ONE are the market leaders. Makes sense to support them first, and the also-rans later.

    </dons flame-retardent suit>
  6. So if CFMX is built-upon J2EE, can anyone explain the architecture of CFMX. In the same way that a JSP is
    compiled into a Servlet, a JSP Tag is compiled into a
    Java Class that is called by the Servlet, business logic
    can be written natively and called by servlet...what is
    going on in a CF application ? I presume CFML pages
    are compiled into Servlets ? And CFC (Cold Fusion
    Components) are they translated into Java classes
    that are then compiled ? Is this all done at deploy
    time ? Do databases accesses use connection pooling,
    etc ?

    Basically - is CF essentially a 'framework' in the same
    way that Struts is, that just operates at a higher level
    of abstraction (allowing you to develop a limited range
    of J2EE applications without requiring Java development
    experience).

    I'm not interested in flamewars as to why J2EE is better
    than CFMX and vice-versa - there is a time and a place for
    both solutions I'm sure, not to mention "the devil you know". But I'm keen to know what the "overheads" and "benefits" of using CF are, from an architectural/performance/scalability point of view.
  7. Read the part 3 in their PDF whitepaper.
     
    http://www.macromedia.com/go/cfmx_j2ee_architecture/
     
    It seems that CF templates are like JSP, and CF components should be used like servlets. Is it right ?
  8. Cold Fusion predates J2EE by some years. As it happens, it bears a close resemblence to many aspects of J2EE, and no doubt Macromedia has been trying to bring that convergence closer.
  9. First, the reason Macromedia developed CFMX is that it no longer has to develop and maintain an application server and deal with its poor performance, lack of scalability, etc. Macromedia has left those nasty issues to J2EE app server vendors to solve, which gives them time to "flash-ify" everything.

    What is CFMX? Well, the short answer is a very complicated JSP custom tag library sitting atop a java serverside framework. So, CFML templates are converted to JSPs prior to compliation, instantiation and execution. The CFML language has been implemented in CFMX as JSP custom tags. CFML is translated to JSP/java with a servlet filter. CF Components are nothing more than hashmaps that hold property state with hooks to "CF script handlers" to execute serverside scripts. Like JSP, all this translation from CFML to JSP is done at request time and as long as your CFML source doesn't change, the resulting servlet stays resident in memory.

    CFMX is a framework, but not like Struts. It should be thought of as JSP, with all the same application architecture problems. It's even easier with CFMX to place database access code in the presentation layer. Partitioned applications can be developed but requires discipline.

    CFMX leverges much of the services provided by the J2EE platform, such as JNDI, JMX, JDBC, etc. Much of this functionality is accessible using CFML and script. As far as DB connection pooling is concerned, if the database supports it and a JDBC driver supports it, than CFMX supports it.

    So, what are the benefits of CFMX to a developer? Ease of development, primarily. A sophisticated, data driven web site can be developed very quickly with CFMX. All the strengths of the J2EE platform are there, with the CFML language providing a shield to much of it. CFMX can use conventional JSP custom tag libraries, interact with existing JSPs and share session variables with them, but it remains to be seen how real world applications interact.

    From an architectural point of view, I think CFMX muddies the water. The main beneficiary of CFMX are existing CFML shops that gain the stability of the J2EE platform without much of the complexity. For existing J2EE shops, I see little benefit save for deploying any existing CFML applications onto a common server platform.

    BTW, there's also a third-party CFML for java implementation available called Blue Dragon from New Atlanta. I don't have any personal experience with it so I can't comment on it with any authority.

    Disclaimer: I have no connection to Macromedia or New Atlanta.
  10. I am not so sure if this is good news. I used (and liked) coldfusion quite a bit, but placing it on top of a J2EE server seems a bit pointless to me. True - it eases server side development to some extent by providing true RAD and quick development cycles in the frontend. But then again it is another language in the envireonment complicating things. I am sure that there are some benefits, but this seems like rip the J2EE server of its presentation layer and put CF in (valid approach). However what I like about J2EE and the tools available is that you can do pretty much in one place. I'm curious to see where this is heading to..