"Doogie" <dn******@dtgne t.comwrote in message
news:11******** **************@ e65g2000hsc.goo glegroups.com.. .
Hi John, I am still confused. I understand the difference between
client/server namespaces. But take out the fact that we're talking
about a web service altogether here and let's just deal with the fact
that it is a .NET dll.
If I have a windows application in .NET and I reference two dlls and
they both happened to have a class name of Customer, without the
unique namespace attached to them, I could not reference them both and
use them or else I'd have a conflict because .NET would not know which
dll's methods I am referring to (now I understand that you can get
around that with aliases and such but that's not relevant to my
overall question).
If in VS 2005, namespaces are not a part of webservice component, then
if I have a web application that references two web services with a
class name of Customer, aren't I going to run into the same problem?
If not, why not? It seems strange to me that namespaces would just
not be there at all but could be added, because that seems to leave
open the strong possibility that someone is going to do something
wrong.
Am I way off base here or not understanding what you are getting at?
You're not alone in being off-base in this way. In fact, Microsoft seems to
encourage it.
A large proportion of the confusion I hear about from web service newbies
stems from the fact that Microsoft has tried too hard to make Web Services
just magically work. This is good in one sense. On the other hand, it means
that people can get quite far in before understanding the ways in which web
services are different from other development models.
So, if you don't need to look "under the covers", it's perfectly fine to go
ahead and think of Web Services as just another kind of RPC; in fact, to
think of it just like a local procedure call. But occasionally, the
difference will show itself and bite you when you don't know to be looking!
In those situations, please keep the following in mind, even though it
contradicts the "magic" model:
******* The client and the server are totally unrelated *******
One implication of this is that the namespace of some class on the server it
totally irrelevant to any discussion about the client.
In fact, I think the best way to think about web services is to pretend you
don't know what platform the client and server are running on. Just assume
that you've got some Perl script or something running on a web server, and
that you've got, say, a VBScript file running on the client. The VBScript
client sends some "<XML/>" to the server and the server parses it with
regular expressions or something, then sends some "<XML/>" back.
Notice: there are no namespaces in the above example. There are no classes.
There are no methods. There was (implicitly) a WSDL somewhere, but it's all
XML itself!
It's all just XML traveling over the wire. This is not only the underlying
implementation, it is also the source of the limitations. No namespaces, no
classes, no constructors, no nothing except XML.
Now, as to your original question, Visual Studio.NET is clever enough to not
allow you to name two Web References the same thing, and to use the name of
the Web Reference in the namespace of the generated proxy classes. This will
cause them to be in different namespaces. So, even if you have two
references to the exact same service, you'll be ok because the Web
References have different names, hence different namespaces.
I hope that helps more than the lecture hurts! ;-)
John Saunders [MVP]
