Couldn't they have the same name, but be in different namespaces? This
is the case. The VS auto generated code does not create these different
namespaces and instead just lumps them all in the same namespaces. This
requires that they have different names. Is there a workaround to not
have these classes in the same namespace?

[quoted text, click to view]

First of all, what do you mean when you say that the third party web service
uses classes with the same name? Did you mean that it uses two complexType
declarations with the same "name" attribute but in different namespaces?
Could you provide a snippet of the schema illustrating the problem?

[quoted text, click to view]

Is your web service able to consume the 3rd party web service via a web
reference? How do the names of the 3rd party web service translate?

It's possible that, however it works with the 3rd party web service, that's
how it should work with yours.

Also, what do you mean when you talk about being a "passthrough"? Do you
mean that if the 3PWS (3rd party web service - I'm tired of spelling it
out!)...

when the 3PWS changes, you want your clients to see all of the same changes?
Every one?

You might consider being a facade to the 3PWS instead of just a passthrough.
That way, you can name your classes whatever you want, and whatever makes
the most sense to your clients.

John

[quoted text, click to view]

So for example the submission message looks like this:
<RootElement>
<SomeCommonElement>20000</SomeCommonElement>
</RootElement>

and the result message looks like this
<RootElement>
<SomeCommonElement>20000</SomeCommonElement>
<SomeResultElement>40000</SomeResultElement>
</RootElement>

notice how RootElement and SomeCommonElement are shared between the
submission and result message. They also usually have a different
schema. Unfortunately since we just post to an asp page we don't get to
import the references. Also we leave namespaces out when we construct
the xml document. And the result message also has no namespaces.

[quoted text, click to view]

This is impractical since the 3PWS is very complex and we have no idea
how future clients may want to use it.

[quoted text, click to view]

If they use different schemas, then they had better be in different
namespaces, and I don't see your namespace declarations in your examples.

This is likely the cause of your problem.

[quoted text, click to view]

This is a critical mistake. The only time namespaces are truly optional is
when it two elements with the same name always have the same type. In your
case, they do not have the same type, so you need namespaces.

[quoted text, click to view]

I suppose this is ok, assuming that you properly emulate a client of the
3PWS. I expect your solution to break as soon as you look different than a
regular client. For instance, what happens when the 3PWS decides to
implement SOAP 1.2 for some of its operations? What happens if it decides to
use some end-to-end authentication scheme?

Your problem can be solved for today, but tomorrow, you might be in trouble.

John