[SalesForce] Avoid hardcoding endpoints in external applications which call custom apex webservice

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! :-)

As the error states, you didn't reset the destination URL. This is accomplished by the following line (after logging in):

pc.endpoint_x = res.serverUrl;