Unfortunately the Enterprise WSDL does not aggregate Apex Web Services defined in the org, only custom objects. I've also confirmed this by writing a short Apex Web Service, downloaded the Enterprise WSDL and searched it for my class and it is not present.
Force.com Enterprise WSDL—This API is for most enterprise users who are developing client applications for their organization. The enterprise WSDL file is a strongly typed representation of your organization’s data. It provides information about your schema, data types, and fields to your development environment, allowing for a tighter integration between it and the Force.com Web service. This WSDL changes if custom fields or custom objects are added to, renamed, or removed from, your organization’s Salesforce configuration. If you are downloading an enterprise WSDL and you have managed packages installed in your organization, you need to take an extra step to select the version of each installed package to include in the generated WSDL.
If you have many Apex classes wishing to expose web services, i agree it can be quite cumbersome to manage the multiple WSDL's and not possible to share common types across the resulting WSDL's.
The suggestion I can offer, in order to maintain the code in separate classes is to perform the aggregation via a single Apex Webservice class that purely acts as an endpoint and thus WSDL for Apex Web Services. It contains no code other than to delegate to the others classes you have already. I would consider some kind of naming convention on the methods to help group the operations.
global with sharing class MyUberService
{
global class SharedType
{
webservice String someMember;
}
webservice static void ServiceA_SomeMethod(String parameterA, SharedType sharedInfo)
{
ServiceA.SomeMethod(parameterA, sharedInfo);
}
webservice static void ServiceA_AnotherMethod(Decimal parameterA)
{
ServiceA.AnotherMethod(parameterA);
}
webservice static String ServiceB_DoSomething(SharedType sharedInfo)
{
return ServiceB.DoingSomething(sharedInfo);
}
}
As you can see this would also help you share types between services and thus the generated C# or Java code once the WSDL is consumed by your client.
Thoughts on REST. Regarding REST, I'm a big fan of the simplicity of API's utilising this form of web service convention. Web Service standards have grown very bloated and hard to use without the help of a framework, so REST definitely addresses this, especially for mobile framework clients this is important. However when the client environment allows it, I am also a big fan of strongly typed interactions with API's. So if you have a lot of complex data structures and many operations, sometimes SOAP and WSDL's offers a lower barrier to entry to your callers as they get a locally generated API in their native language to consume as apposed to having to construct JSON structures at runtime. Big fan of both for different reasons! :-)
The Partner WSDL contains XML Schema features that are not supported by the WSDL2Apex tool, specifically in the case of the sObject type, it uses the any attribute.
<complexType name="sObject">
<sequence>
<element name="type" type="xsd:string"/>
<element name="fieldsToNull" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<element name="Id" type="tns:ID" nillable="true" />
<any namespace="##targetNamespace" minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</sequence>
</complexType>
As per the documentation here, any is an element not listed as supported, unfortunately the WSDL2Apex tool does not output an error any warnings, and just skips this fact, hence you get the Apex sObject class that looks like the following and is not very useful.
public class sobjectPartnerSoapSforceCom {
public class sObject_x {
public String type_x;
public String[] fieldsToNull;
public String Id;
private String[] type_x_type_info = new String[]{'type','urn:sobject.partner.soap.sforce.com',null,'1','1','false'};
private String[] fieldsToNull_type_info = new String[]{'fieldsToNull','urn:sobject.partner.soap.sforce.com',null,'0','-1','true'};
private String[] Id_type_info = new String[]{'Id','urn:sobject.partner.soap.sforce.com',null,'1','1','true'};
private String[] apex_schema_type_info = new String[]{'urn:sobject.partner.soap.sforce.com','true','false'};
private String[] field_order_type_info = new String[]{'type_x','fieldsToNull','Id'};
}
}
So there is no class member you can set to define your fields, in theory you could use the Enterprise WSDL to generate explicit types that represent the custom objects in your target org, though i suspect you will also want the same when querying your source org. The WSDL for Enterprise is also very very large so I would not recommend attempting to perform WSDL2Apex on it for this reason alone.
Possible Alternative Route Forward
I would propose you look at using the Salesforce REST API from Apex, there has been a number of posts on this on StackExchange. Here for example is some code that allows you to update the currency objects via the REST API via Apex.
Http h = new Http();
HttpRequest req = new HttpRequest();
req.setEndpoint(URL.getSalesforceBaseUrl().toExternalForm() + '/services/data/v28.0/sobjects/DatedConversionRate/04wb0000000KzHlAAK?_HttpMethod=PATCH');
req.setBody('{ "ConversionRate" : 2.5 }');
req.setHeader('Authorization', 'OAuth ' + sessionId);
req.setHeader('Content-Type', 'application/json');
req.setMethod('POST');
NOTE: A login example from Apex without using Partner WSDL can be found here.
HttpResponse res = h.send(req);
You basically encode the fields you want to set in the JSON string set in the body of the request. Note that this is not a bulk API, so depending on the volumes this may not be ideal. I've never used the Salesforce Bulk API from Apex, but in theory if your determined enough its possible.
Finally you may also be interested in External Data Sources, a feature upcoming in the platform, you can read more here.
Best Answer
As the error states, you didn't reset the destination URL. This is accomplished by the following line (after logging in):