Here is a list of the most important differences:
- webMathematica is a server side technology (the Mathematica code runs on the server) while Mathematica code contained in a CDF-Document runs on the client, either in the standalone player or the browser-plugin. This of course has many important consequences, see the sections below for more details.
- The UI part of a webMathematica application can't be programmed in Mathematica but must be HTML plus optionally additonal code running in the browser, e.g. java-script, flash etc. The UI part of a CDF application must be Mathematica
Dynamic
and Manipulate
code.
- A (standard) webMathematica application will run on every client that has a recent HTML-browser. Only when the application makes use of
MSPManipulate
the client will need to additionally have installed a Flash plugin. To view a CDF document you will need to install one flavour of Mathematica, either the "real thing" or the free CDF-Player or PlayerPro -- which all are of course by far not available for as many devices as HTML-browsers.
- Import/Export etc. for a webMathematica application really means upload/download to the server. Also any kind of visualizations of data/results will need to be generated on the server and downloaded to the client browser for display which might result in limitations on how interactive such visualization can be for larger datasets/results.
- Especially for commercial and/or heavily used applications there are important differences concerning security, performance and licensing, see extra sections below for details.
Considering all the differences, it seems that the two technologies are not really competitors but rather complement each other: it can be possible and advantageous to combine both: e.g. a webMathematica-application can as a result return a CDF-document which lets the user interactively investigate a result on the client that was calculated on the server. WRI's own web-applications do use such combinations already.
Server-Side Technology
As it is built with standard Java server side technology (JSP == Java server pages), a webMathematica application can in principle be combined with everything that can be run from a webserver and/or a Java servlet container. This might be especially interesting for corporate applications but usually needs some extra efforts. One example is sending emails, as Rolf Mertig has mentioned in his answer.
The server side technology used in webMathematica in principle makes a plethora of server-side computation / data access technologies available, the standard web technology for the communication with the client makes all kind of client-side and rendering technologies immediately available which include, among others: applets, JavaScript, CoffeeScript, (several other client-side browser scripting languages not mentioned here, there's tons of them), AJAX, GWT, DTHML, XHTML, cgi scripting, perl scripting, python scripting, etc.
It may seem trivial, but it is worth mentioning that with webMathematica you have access to ALL server-side technologies, either from Mathematica itself, or through the JSP, or through the html. Executables, libraries, scripting, databases, ... whatever you choose to make available on your server via the Mathematica kernel, JSP, or HTML. This is from the webMathematica documentation: "These include APIs for database connectivity, XML processing, speech generation, data format I/O, and calling via HTTP to other web services. All of these are readily available to webMathematica." This of course by far outnumbers your technology options in a CDF
In addition, the "JSP world" itself allows to do a lot on the server side: getting/setting JSP variables, using JSP standard tags (such as if/set/when/choose/otherwise), and many more. Let's not forget that JSP technology allows us to "script" any Java program (although that's of course very inefficient for larger code sections and should not be done, but only for performance reasons, not for technology reasons), and JSPs have additional features that are not part of "standard" Java. With webMathematica you can mix and match Mathematica expressions (page variables, session variables), JSP variables, JSP tags, and Java objects (and their methods and fields and constructors, ...). In a CDF you don't have JSP variables or Java objects. It's immensely powerful to have Mathematica expressions and Java objects interact.
The HTML forms part itself has become very powerful in the last few years: it is not just limited to "basic" text input fields anymore, there are pulldown menus, check marks, radio buttons, and sliders (at least for HTML 5 in moderns browsers). This gives you already the most useful input elements needed.
In addition, the HTML part allows you to use style sheets for formatting ... a huge abundance of stylesheets exists already -- oftentimes no need to write your own, or you can take an existing one and modify it to your needs. You can use styles in Mathematica cell expressions and use them in a CDF, but the sheer abundance of existing css that has already been written and the easy modification makes css a powerful tool in the UI design arsenal. You can't take ready-made css from another web page and use on your own in a CDF, you'd have to develop your own cell style to "mimic" the css.
There are additional features that are not necessarily "inherent" to webMathematica, but are features that are provided by the servlet container that webMathematica run in (e.g. tomcat or JBoss): usage tracking, log file analysis, etc. Usually a servlet container is run in combination with a webserver (e.g. apache), which can be configured to do IP address tracking in log files, and if you have Google Analytics, you can track everything GA provides you: demographics, hardware, browser, o/s, landing pages, exit pages, etc. Compared to that, for a CDF-document all one can log is the access to the CDF-document if it is served by a file- or webserver, once on the client there are no possibilities to get any information about who is using it in which ways.
Security
Since the Mathematica code runs on the server for a webMathematica application that code is never leaving the server. It thus is protected against disclosure -- at least as long as your server is secure. When using CDF, the Mathematica code will be delivered to the client. You can encode that code, but that will only be as secure as the encoding you use -- since it must be interpreted on the clients machine such encoding can in principle always be hacked. The standard Encode
that Mathematica provides isn't considered to be very secure, although no recipes to hack it seem to be publicly available and it certainly will suffice for some use cases.
Another security aspect is that there are no restrictions ("sandboxing") necessary for the server side code of a webMathematica application, compared to the code running on the client for a CDF-application which needs such restrictions to protect the user from malicious code which could be contained in a CDF document. All the mentioned powerful serverside technology can be made available in webMathematica as all the code runs in a controlled environment on the server and the client only gets HTML for his/her browser (of course the combination of HTML+browser also has security issues).
Performance
If computational demands are high compared to communication overhead, a webMathematica solution can guarantee a certain performance level by providing corresponding hardware (and number of Kernel licenses) while CDF applications will run on the clients hardware and there is no control over how performant that is and whether your application will run at all (due to e.g. memory requirements).
Of course the webMathematica server needs to run the code for all concurrent users at a time which might become a problem for many users. For long computations webMathematica has kernel queuing system, which might or might not be an important point depending on the nature of the application.
A CDF document can of course be run in parallel on client computers independently without any interaction so the performance of a CDF application is only limited by the client hardware and load but doesn't suffer from heavy load on (or downtimes of) the server.
Licensing
The licensing for the two are very different: a free CDF document can be generated with a regular Mathematica license, with no additional costs. You only have to comply to the license conditions. With an enterprise Mathematica license (which costs more than a regular one) you can create enterprise CDF documents with additional features. I don't think that there are limits on how many of those you can create and how often you can distribute them, but you might need to check the license conditions.
For a webMathematica solution you have to get a webMathematica license. There is an "Amateur Edition" which I think is free for registered premier service clients but you have to request it and it has some restrictions. For the unrestricted "Professional Edition" I think there are no public price lists available, so you have to contact WRI to get a quote.
Another licensing aspect is that limitations of what can be done in a CDF-document compared to what a full Mathematica can do only depend on the combination of Licenses of the generating Mathematica and the Player with which it is shown: A free CDF shown with PlayerPro or Mathematica will not have any such restrictions, and when the CDF document is generated (signed) with an enterprise license many restrictions will not even affect users of the free CDF-Player. You would need to have a look at the licensing conditions when distributing such an "enterprise-signed" CDF-document and maybe contact WRI for details on that.