Re: Update Web Reference - at run time
From: Dino Chiesa [Microsoft] (dinoch_at_online.microsoft.com)
Date: 09/01/04
- Previous message: Jesse Elve: "Re: System.Xml.XmlValidatingReader.set_ValidationType raised InvalidOperationException"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 1 Sep 2004 14:58:12 -0400
John, I know of no example that does what you describe.
In general it is not a solvable problem. If the interface designer "breaks"
the interface, there is no guarantee that "Update Web Ref" will actually
work - in other words, no guarantee that existing apps will just work when
re-compiled. The breakage could be in the wire format (eg, the XML element
names or namespaces) or in the programming model (the method names or param
orders) or both. If the breakage is in the wire format, no problem,
re-compile will take care of it. If the breakage is in the programming
model or programming interface, then recompile will not work.
A related point: When the creator of your web service adds function, this
should not affect existing webmethods. There is nothing explicitly in the
web services model (or wsdl) that says that a client app must know about ALL
of the webmethods offered in order to invoke ONE of them. Just adding a new
method shouldn't (won't) break existing clients. It will change neither the
wire format, nor the existing programming interface. (It is a dangerous
thing to do anyway, because new clients might not work with old servers.
But that apparently does not apply in your case.)
I am guessing then, that the provider of your service is doing something
beyond "adding functions to the existing service".
Sorry I do not have a magic bullet for this. It seems to me that the
provider of your service is not practicing proper webservice hygeine.
There are a couple of things you can try, if you think the changes are only
in the wire format. If it were me, I would not go down this road, because
the ratio of effort to results is too high. But I will offer some ideas
anyway.
- webservicestudio, a project on gotdotnet.com, shows how an app can
swallow a WSDL and dynamically invoke methods on that WSDL. You could use
this as a starting point, slurp in a WSDL, compare the resulting client=side
proxy with the original proxy, and if you find a good match (no programming
model changes), then use the new proxy. I haven't done this, it's only an
idea.
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=65A1D4EA-0F7A-41BD-8494-E916EBC4159C
(I just looked now and it seems the source for WebServiceStudio may no
longer be available? I don't know the status though. . .)
- you could do something similar by doing a StartProcess on wsdl.exe, and
slurping in the resulting assembly.
---- In the end though, it would be simpler and more reliable to get and use a stable interface from the provider. -Dino "John K" <JohnK@discussions.microsoft.com> wrote in message news:33C76921-3535-4FFE-9E04-F6646959C621@microsoft.com... > Dino, > > I have a more specific question. Is there a Visual Basic example that shows > how to dynamically "bind" to a web service function? In my case, as I > mentioned before, the creator of the web service keeps adding functions to > the service and this breaks the compatibility even though the paramters to > the specific function I am using haven't changed. Thus I am looking for a > working example that calls a web service but does the same work as doing > "Update Web Reference' in VS.NET environment. Thus the example can assume a > the parameters to/from a function don't change. > > Thanks! > > "Dino Chiesa [Microsoft]" wrote: > > > There is no definitive answer to your problem. > > > > A rule of distributed computing is that interfaces live forever. > > If the provider of the webservice modified the app and changed the > > interface, s/he committed an error. > > > > A better approach is to ADD a new interface rather than REPLACE an old > > interface with a new one. > > > > Here are some examples of changes that would break existing clients, but > > would be "transparent" to the application layer - in other words, > > programmers will say "the function did not change": > > - modify the name or namespace of the XML element for the method request, > > or the method response > > - modify the SOAPAction setting for the request > > - modify any of the Xml serialization attributes on any of the passed > > datatypes (inputs or outputs) > > - and others > > > > In these cases, a "Update Web Ref" with no other code changes will allow the > > client app to just work. You would be correct in saying "the function > > didn't change" because the programming interface is exactly the same; but > > the on-the-wire XML is different, and different enough for it to just not > > work. > > > > Moral of the story: don't break published interfaces. It forces clients to > > be recompiled and makes people grumpy. > > > > -Dino > > > > > > "John K" <JohnK@discussions.microsoft.com> wrote in message > > news:3F4615DA-E1E6-4905-9636-E0AE61B312BE@microsoft.com... > > > How do you update a web reference at run time? My program that calls a > > > function in a web service worked, but quit working when the progammer of > > the > > > web service service released a new version. The function I was calling did > > > not change but his update of the web service "broke" the connection. If I > > go > > > into my source code and simply right-click the web reference and choose > > > "Update Web Reference" and then recompile my program then everything > > works. > > > How can I do this programmatically so I don't need to recompile and > > > redistribute my program every time the web service is updated? > > > > > > I program in VB.NET and all of the examples I found are either in VC# or > > > have errors in them (e.g. Using UDDI at Run Time, Part I/II). > > > > > > > > > > > >
- Previous message: Jesse Elve: "Re: System.Xml.XmlValidatingReader.set_ValidationType raised InvalidOperationException"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|