Consuming multiple web services with a .disco file

I've got two web services that use the same data types and that
clients will have to consume. I read the msdn article on sharing types
(http://msdn.microsoft.com/library/de...ce07162002.asp)
but I don't want clients to have to add two web references and then
manually have to edit the proxy classes. After doing some searching I
found that putting references to multiple web services in a .disco
file and then having the clients point to the .disco file when adding
a web reference will enable them to use multiple web services under
one namespace without any additional editing. When I tried this the
generated proxy class contains code only for the first web service in
the disco file. I do see that both wsdl files are imported under the
web reference though. Is it possbile to get VS.NET to generate proxy
class code for both services and put it in the same proxy file
(reference.cs)? Below is the .disco file I created. Thanks for any
help.

<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef
ref="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebservice.asmx?wsdl"
docRef="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebservice.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap
address="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebservice.asmx"
xmlns:q1="http://reservationsmiddletier.uhaul.com/webservice"
binding="q1:CustomerWebServiceSoap"
xmlns="http://schemas.xmlsoap.org/disco/soap/" />
<contractRef
ref="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebservice.asmx?wsdl"
docRef="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebservice.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap
address="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebservice.asmx"
xmlns:q1="http://reservationsmiddletier.uhaul.com/webservice"
binding="q1:LocationWebServiceSoap"
xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>

re: Consuming multiple web services with a .disco file

Hi,

This is a classic partitioning problem. The real issue is that the proxy
class is an assembly, and not an XML data structure. As an assembly, it
has a .NET namespace. What the article you read is trying to accomplish is
to put both of your sets of service methods in the same namespace. There
are a few ways to do this - and the best way I know of is to not use the
automatically generated proxy, but instead to provide a set of custom
proxies for your .NET clients to use. You can create these by copying the
generated proxy code into two class files - give them a namepace of your
choosing. For the shared types, factor them out of your server application
into a separate assembly, and reference that assembly from not only your
server side code, but also from your custom proxies.

What you are encountering in the auto-generated proxies is .NET strong
naming. Even though the two class shadows that are generated are identical
(presumably), the difference in the name assigned to your proxies is
causing the cast of either one to fail when trying to copy/pass/cast the
data.

You could try naming your proxies the same thing as your server side
namespace. Since you are separately adding two, this could cause a name
collision in the project artifacts. But there is no issue in having both
proxies in the same namespace.

Finallly, have you considered that you may have actually improperly
partitioned your web service design? Since you intend for both services to
live together and be used together, have you considered combining them into
a single service implementation? This would make them share a WSDL file -
and this would solve the issues that relying on the "free for nothing"
generated proxy is providing.

I like to think of the generated proxy as a favor. It isn't required to
call a service, and any number of equivalent proxies can exist that are all
correct for a given service. The fact that the behavior of the proxy that
is generated doesn't meet your needs drives some to say "hey, it's just
code, I own that". Others for some reason treat it as if it were sacred -
as if it was ever safe to regenerate it (hint, if you have to refresh the
proxy ever, you haven't created a stable service contract, so you're still
early on in development anyway). After you've shipped it is NOT OK to
expect proxies to be refreshed - not from a service level management
perspective anyhow.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------
NNTP-Posting-Date: Wed, 22 Dec 2004 16:45:54 -0600
From: Matt D <mdd9024-news@yahoo.com>
Newsgroups: microsoft.public.dotnet.framework.webservices
Subject: Consuming multiple web services with a .disco file
Date: Wed, 22 Dec 2004 15:45:54 -0700
Message-ID: <pusjs0hugkj63cbe190in0umn61p2sl47m@4ax.com>
X-Newsreader: Forte Agent 2.0/32.652
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 39
X-Trace:
sv3-VGgayvZ8JsqDpwtKvdaOFHVFYPGT+MO+hdu0IKRn4dCAR4aQ9K JtemSFwWdFXHwwQULaP07L
YnOVnII!X78l0Wg07TrQqLR2AoEa4V85zafGdYAdzkCjksbhrK oN3U0vQnoBvFaNMh14Il/U/HB/
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your
complaint properly
X-Postfilter: 1.3.22
Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!news-out.cwi
x.com!newsfeed.cwix.com!border1.nntp.dca.giganews. com!nntp.giganews.com!loca
l1.nntp.dca.giganews.com!news.giganews.com.POSTED! not-for-mail
Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.webservices:8274
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

I've got two web services that use the same data types and that
clients will have to consume. I read the msdn article on sharing types
(http://msdn.microsoft.com/library/de...-us/dnservice/
html/service07162002.asp)
but I don't want clients to have to add two web references and then
manually have to edit the proxy classes. After doing some searching I
found that putting references to multiple web services in a .disco
file and then having the clients point to the .disco file when adding
a web reference will enable them to use multiple web services under
one namespace without any additional editing. When I tried this the
generated proxy class contains code only for the first web service in
the disco file. I do see that both wsdl files are imported under the
web reference though. Is it possbile to get VS.NET to generate proxy
class code for both services and put it in the same proxy file
(reference.cs)? Below is the .disco file I created. Thanks for any
help.

<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef
ref="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebservice
.asmx?wsdl"
docRef="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebserv
ice.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap
address="http://localhost/ReservationsMiddleTierWebServiceAPI/customerwebser
vice.asmx"
xmlns:q1="http://reservationsmiddletier.uhaul.com/webservice"
binding="q1:CustomerWebServiceSoap"
xmlns="http://schemas.xmlsoap.org/disco/soap/" />
<contractRef
ref="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebservice
.asmx?wsdl"
docRef="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebserv
ice.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />
<soap
address="http://localhost/ReservationsMiddleTierWebServiceAPI/locationwebser
vice.asmx"
xmlns:q1="http://reservationsmiddletier.uhaul.com/webservice"
binding="q1:LocationWebServiceSoap"
xmlns="http://schemas.xmlsoap.org/disco/soap/" />
</discovery>

re: Consuming multiple web services with a .disco file

Hi Dan. Thanks for the help. I think I was unclear by mentioning the
"types" article and kind of got off track. I've spent quite a bit of
time designing the web services and data types that will be used so
I'm pretty satisfied with the design. I am definitely aware of the
fact that the web service interface should never change and that
creating a custom proxy that is given to the clients is a good option.
But it would be nice if I could get the auto generated proxy to work
right. The question that I really wanted to know is why isn't the
proxy file correctly generated when multiple web services are added to
a .disco file. It seems to only generate a proxy class for the first
web service that is in the .disco file. The reason I want to combine
web services in a .disco file is because I have a total of six web
services that can be used totally independently and they all use the
same custom types. Some clients will only use one of the web services.
But some will use all six. So I wanted to create .disco files that
have all of the possible combinations of web services that a client
could use. I got the idea about using .disco files from the following
posts:

http://groups-beta.google.com/group/...9056c71cd83830
http://groups-beta.google.com/group/...a642c500262e17

From these posts I would assume that VS.NET should be able to generate
the correct proxy and that I'm doing something wrong. Thanks for any
help.

On Wed, 22 Dec 2004 23:05:19 GMT, danro@microsoft.com (Dan Rogers)
wrote:
[color=blue]
>Hi,
>
>This is a classic partitioning problem. The real issue is that the proxy
>class is an assembly, and not an XML data structure. As an assembly, it
>has a .NET namespace. What the article you read is trying to accomplish is
>to put both of your sets of service methods in the same namespace. There
>are a few ways to do this - and the best way I know of is to not use the
>automatically generated proxy, but instead to provide a set of custom
>proxies for your .NET clients to use. You can create these by copying the
>generated proxy code into two class files - give them a namepace of your
>choosing. For the shared types, factor them out of your server application
>into a separate assembly, and reference that assembly from not only your
>server side code, but also from your custom proxies.
>
>What you are encountering in the auto-generated proxies is .NET strong
>naming. Even though the two class shadows that are generated are identical
>(presumably), the difference in the name assigned to your proxies is
>causing the cast of either one to fail when trying to copy/pass/cast the
>data.
>
>You could try naming your proxies the same thing as your server side
>namespace. Since you are separately adding two, this could cause a name
>collision in the project artifacts. But there is no issue in having both
>proxies in the same namespace.
>
>Finallly, have you considered that you may have actually improperly
>partitioned your web service design? Since you intend for both services to
>live together and be used together, have you considered combining them into
>a single service implementation? This would make them share a WSDL file -
>and this would solve the issues that relying on the "free for nothing"
>generated proxy is providing.
>
>I like to think of the generated proxy as a favor. It isn't required to
>call a service, and any number of equivalent proxies can exist that are all
>correct for a given service. The fact that the behavior of the proxy that
>is generated doesn't meet your needs drives some to say "hey, it's just
>code, I own that". Others for some reason treat it as if it were sacred -
>as if it was ever safe to regenerate it (hint, if you have to refresh the
>proxy ever, you haven't created a stable service contract, so you're still
>early on in development anyway). After you've shipped it is NOT OK to
>expect proxies to be refreshed - not from a service level management
>perspective anyhow.
>
>I hope this helps
>
>Dan Rogers
>Microsoft Corporation[/color]

re: Consuming multiple web services with a .disco file

Hi.

I'm from the 70's, and Disco is dead... ;)

Seriously... the purpose of a disco file is to allow a visual studio tool's
add-web-reference proxy to find what services are on a given server.
You're supposed to select one of the services from the list of available
services, and then generate the proxy.

As far as I know, once you've made the selection, it'll generate a proxy
for the one you selected. From my own experience, you may be
encountering a usability gotcha - the list is displayed, and the first one
is selected for you. If you don't change the selection (double click it)
you will always get the proxy for the default one.

I hope this helps

Dan
--------------------
NNTP-Posting-Date: Tue, 28 Dec 2004 11:35:31 -0600
From: Matt D <mdd9024-news@yahoo.com>
Newsgroups: microsoft.public.dotnet.framework.webservices
Subject: Re: Consuming multiple web services with a .disco file
Date: Tue, 28 Dec 2004 10:35:31 -0700
Message-ID: <eg43t0hec9l5gb00gab4n6lkhgd5k5dfs9@4ax.com>
References: <pusjs0hugkj63cbe190in0umn61p2sl47m@4ax.com>
<zniI3qH6EHA.3984@cpmsftngxa10.phx.gbl>
X-Newsreader: Forte Agent 2.0/32.652
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 76
X-Trace:
sv3-yxazzPDhaX9ZDhUUWguChn9PyY3yobV75z8r++a+UoXf/spnyZST87XPrQU5tngrlqKWrUJ/
zFX5RcT!uc8CXUu5aop56tgzjYuo6BKqYWbibCHty9cs7ePqOW i3Ie8kKruAocKlgLS/GmUH2qgI
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your
complaint properly
X-Postfilter: 1.3.22
Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!newsfeed00.s
ul.t-online.de!t-online.de!border2.nntp.dca.giganews.com!border1.nn tp.dca.gi
ganews.com!nntp.giganews.com!local1.nntp.dca.gigan ews.com!news.giganews.com.
POSTED!not-for-mail
Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.webservices:8327
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Hi Dan. Thanks for the help. I think I was unclear by mentioning the
"types" article and kind of got off track. I've spent quite a bit of
time designing the web services and data types that will be used so
I'm pretty satisfied with the design. I am definitely aware of the
fact that the web service interface should never change and that
creating a custom proxy that is given to the clients is a good option.
But it would be nice if I could get the auto generated proxy to work
right. The question that I really wanted to know is why isn't the
proxy file correctly generated when multiple web services are added to
a .disco file. It seems to only generate a proxy class for the first
web service that is in the .disco file. The reason I want to combine
web services in a .disco file is because I have a total of six web
services that can be used totally independently and they all use the
same custom types. Some clients will only use one of the web services.
But some will use all six. So I wanted to create .disco files that
have all of the possible combinations of web services that a client
could use. I got the idea about using .disco files from the following
posts:

http://groups-beta.google.com/group/...amework/msg/d2
9056c71cd83830
http://groups-beta.google.com/group/...amework.aspnet
.webservices/msg/14a642c500262e17

From these posts I would assume that VS.NET should be able to generate
the correct proxy and that I'm doing something wrong. Thanks for any
help.

On Wed, 22 Dec 2004 23:05:19 GMT, danro@microsoft.com (Dan Rogers)
wrote:
[color=blue]
>Hi,
>
>This is a classic partitioning problem. The real issue is that the proxy
>class is an assembly, and not an XML data structure. As an assembly, it
>has a .NET namespace. What the article you read is trying to accomplish[/color]
is[color=blue]
>to put both of your sets of service methods in the same namespace. There
>are a few ways to do this - and the best way I know of is to not use the
>automatically generated proxy, but instead to provide a set of custom
>proxies for your .NET clients to use. You can create these by copying the
>generated proxy code into two class files - give them a namepace of your
>choosing. For the shared types, factor them out of your server[/color]
application[color=blue]
>into a separate assembly, and reference that assembly from not only your
>server side code, but also from your custom proxies.
>
>What you are encountering in the auto-generated proxies is .NET strong
>naming. Even though the two class shadows that are generated are[/color]
identical[color=blue]
>(presumably), the difference in the name assigned to your proxies is
>causing the cast of either one to fail when trying to copy/pass/cast the
>data.
>
>You could try naming your proxies the same thing as your server side
>namespace. Since you are separately adding two, this could cause a name
>collision in the project artifacts. But there is no issue in having both
>proxies in the same namespace.
>
>Finallly, have you considered that you may have actually improperly
>partitioned your web service design? Since you intend for both services[/color]
to[color=blue]
>live together and be used together, have you considered combining them[/color]
into[color=blue]
>a single service implementation? This would make them share a WSDL file -
>and this would solve the issues that relying on the "free for nothing"
>generated proxy is providing.
>
>I like to think of the generated proxy as a favor. It isn't required to
>call a service, and any number of equivalent proxies can exist that are[/color]
all[color=blue]
>correct for a given service. The fact that the behavior of the proxy that
>is generated doesn't meet your needs drives some to say "hey, it's just
>code, I own that". Others for some reason treat it as if it were sacred -
>as if it was ever safe to regenerate it (hint, if you have to refresh the
>proxy ever, you haven't created a stable service contract, so you're still
>early on in development anyway). After you've shipped it is NOT OK to
>expect proxies to be refreshed - not from a service level management
>perspective anyhow.
>
>I hope this helps
>
>Dan Rogers
>Microsoft Corporation[/color]