Application Designer: copying endpoints vs. creating them from WSDL
There are two ways you can copy the specification of a Web service endpoint using Application Designer, which vary in subtle ways that you can leverage. You can simply use copy/paste - see my earlier post, or, if the source application has been implemented, you can use Create Web Service Endpoint from WSDL (right click on the target application and then reference the URL of the source application's endpoint). In both cases you get what we think of as a shallow copy - that is, no implementation code is copied. The differences are in how each approach handles complex types referenced by the operations. In the case of copy/paste, the operation signatures only are copied and no new types are created in the target application. If you create the endpoint from the WSDL, then the WSDL and any referenced XSDs are processed and new CLR types are generated for any complex types referenced in the message definitions. If the target application is unimplemented, you cannot see or reference these new types until code is generated, but rest assured they are there!
Copy/paste of an endpoint takes the view that the implementer of the target application will provide the definition of the parameter and return types out of band. You can define the types from scratch, copy the type definitions from the source or more interestingly, reference the actual type definitions used in the source application. This is likely not a good idea if the types are defined in the source Web service project itself, but may be very useful if you define the types in a separate project/assembly, which is arguably best practice.
The other approach, creating the endpoint from WSDL works rather differently. This works the same way as WSDL.exe /server and will create a 'fresh set' of types in the target application based on the types in the WSDL and imported XSDs. This approach echoes the SOA tenet of sharing schema and not types - although obviously that is directed primarily at avoiding implementation dependencies between consumers and providers of a service - not between providers.
It can be argued that we could have gone further with copy/paste and created references in the target application to the projects/assemblies that contain the referenced types. There proved to be several technical obstacles to doing this, not least that the referencing mechanisms in Visual Studio were only designed for creating references from projects and were not accessible to us - in many cases the target application will not have been implemented and there is no project. Given that the workaround is to simply add the reference yourself to the project once implemented we thought this was a reasonable course. And this approach recognizes that you may not want to create the tie between the service implementations anyway.
In any case, with the two techniques available you have a choice. And choice is a good thing :-)
One other point to note is that you can create endpoints from the WSDL of External Web Service endpoints, which don't otherwise support copy/paste.