Classes in webservice have the same name

[yads12]

We have a webservice that is a passthrough to a third party webservice.
The third party webservice uses the classes that are named the same for
both the submission and result message. We have separated these out to
different namespaces in our webservice. Eg.

SubmissionMessage.WebServiceMessage
ResultMessage.WebServiceMessage

When we import this webservice as a web reference into our web
application. These different namespaces aren't preserved. Instead we
get the following classes

OurWebservice.WebServiceMessage
OurWebservice.WebServiceMessage1

I would like to have these classes split out into different namespaces
on the consumer side instead of these classes with the 1 postfix. I can
manually change the Reference.cs file, but since these files are
generated any updates will cause my changes to be overwritten. Does
anyone have a good solution to this problem?

[q]

Per the requirements of webservices, they can't have the same name.
They can't be overloaded and they can't differ only by case. If these
rules are violated they are no longer webservices, but are just
"services". They have to follow the specs...

ya****@gmail.com wrote:

We have a webservice that is a passthrough to a third party webservice.
The third party webservice uses the classes that are named the same for
both the submission and result message. We have separated these out to
different namespaces in our webservice. Eg.

SubmissionMessage.WebServiceMessage
ResultMessage.WebServiceMessage

When we import this webservice as a web reference into our web
application. These different namespaces aren't preserved. Instead we
get the following classes

OurWebservice.WebServiceMessage
OurWebservice.WebServiceMessage1

I would like to have these classes split out into different namespaces
on the consumer side instead of these classes with the 1 postfix. I can
manually change the Reference.cs file, but since these files are
generated any updates will cause my changes to be overwritten. Does
anyone have a good solution to this problem?

[yads12]

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?

[John Saunders]

<ya****@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

We have a webservice that is a passthrough to a third party webservice.
The third party webservice uses the classes that are named the same for
both the submission and result message.

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?

>We have separated these out to
different namespaces in our webservice. Eg.

SubmissionMessage.WebServiceMessage
ResultMessage.WebServiceMessage

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

[yads12]

John Saunders wrote:

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?

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.

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.

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

[John Saunders]

<ya****@gmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...

>
John Saunders wrote:

>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?

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.

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.

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.

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.

>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.

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

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