Hi Goldwind,

So, you've identified the main difference between the partner and enterprise wsdls.  They both have equal capabilities to interact with salesforce.com.  Neither is "junior" to the other.

What makes them different is the way you reference the objects in salesforce.com.  This difference is in the definition of the SObject.  For the enterprise wsdl, the SObject contains 2 fields, an ID field and a fieldsToNull field.  If you look at the definition of the other objects, they extend, or derive from the sObject.  This means you cannot create an sobject directly in code generated from the enterprise wsdl, but all the objects can be cast into an sobject type. 

The partner definition for an SObject on the other hand, not only contains the ID and fieldsToNull fields, but also contains a type field and a special field called any.  The type indicates explicitly what type of object the fields in the any field are a part of.  The any field contains the field values for the object of interest.   These values are indicated as key/value pairs and are loosely typed.

What needs to be understood is that you can create a valid soap message using notepad if so desired.  As long as the object defined in the soap request matches what is in salesforce.com, there is no difference between a partner request and an enterprise request.

Where it becomes important is when you have a development environment where code has been generated based on the wsdls.  Each time you obtain the enterprise wsdl, it is a snapshot of the salesforce.com schema at a point in time.  That means that if the schema changes after you have downloaded the wsdl, then your generated code is out of synch with the schema.  It also means that the results of your describeSObject call may possibly be out of synch as well.

The partner wsdll on the other hand, does not attempt to model the salesforce.com schema and is therefore more resillient.  There is a cost to this resilience.  The cost comes in that at design time, you don't have any explicit information about what objects you can access and which fields on those objects you can access.  This means that you must either make assumptions about the objects and fields you are accessing, or better yet, put logic in your code to determine the fields and objects at runtime (use the describeSObject call). 

So, assuming that you have a decent grasp on the likelyhood of how often the schema may change as it relates to the objects and fields you are using, if you have generated your code using the enterprise wsdl and you attempt to access a field that was created after your code genertion, you will always get an error.  The reason for this is that you have requested a field that does not exist in the generated object and the soap deserializer will want to deserialize the entire object into the generated object.  When a field is encountered that it can't dispatch and exception is thrown. 

On the otherhand, if you are using the partner wsdl generated code, the object fields are put into the any object which is that simple key/value pair field mentioned earlier.  No error.  Now, your code may not know what to do with it, but you won't get a run time error.

Now, this gets to the root of the question.  If I need to regenerate and recompile my code when using the enterprise wsdl and the schema changes, why would I not use the partner wsdl?  The reason is if you have a new field you need to deal with, you will likely need to reference that field in your code, which is a change that will require you to recompile it anyway.

There are a few types of applications that can by entirely dynamic.  Consider a data bound application that generates form fields based on the results of a query (a databound grid is a good example).  In this case, you can "can" your query or at least your select statement in a config file or some similar mechanism.  Other applications may have base functionality that is based on standard fields or requirements that state which fields must be available, and additional functionality that based on the existence of optional fields.  Or, maybe the fields are user specified. 

The bottom line is understanding what maintenance may be required for the application based on the wsdl type, what the likelyhood is of the underlying dependent schema changing and balancing that against the convenience of environment value adds such as intellisense and self documentation.

There is no single answer as to which to use.  Depends on the app and the user using the web service.  Personnally, I do most of the stuff I need to do using the partner wsdl.