Jesper Joergensen has a good blog post that answers many important questions around VMForce.  To add, Mike @embracingthecloud lists following really good thoughts about VMForce.

The VMForce value proposition:

Download Eclipse and SpringSource

Signup for a Salesforce Development account and define your data model

Write your Java app using objects that serialize to Salesforce

Drag and drop your app onto a VMWare hosted service to Force.com to deploy

The partnership breaks down as:

1. VMWare hosts your app
2. Salesforce hosts your database

The 2 are seamlessly integrated so that Java Developers can effectively manage the persistence layer as a black box in the cloud without worrying about setting up an Oracle or MySql database, writing stored procedures, or managing database performance and I/O. For larger organizations already using Salesforce but developing their custom Java apps, this opens up some new and attractive options.

CIO’s are being bombarded with virtualization as a viable cloud computing solution, so I think Salesforce has wisely taken a step back and taken a position that says

“We do declarative, hosted databases better than anyone else. Go ahead and pursue the virtualization path for your apps and leverage our strength in data management as the back end”

The post ends with two really good questions …

The connection between VMWare and Salesforce is presumably via webservices and not natively hosted in the same datacenter. Does this imply some performance and latency tradeoffs when using VMForce?No. Per the comment from David Schach, the app VM is running in the same datacenter as the Force.com DB.

It strikes me as quite simple to develop Customer/Partner portals or eCommerce solutions in Java that skirt the limitations of some Salesforce license models when supporting large named-user/low authentication audiences. Will Salesforce limit the types and numbers of native objects that can be serialized through VMForce