Web Service client that dynamically changes posting server

[Daniel Bass]

Hello,

Visual Studio .Net really does well in creating the client side proxy for a
web service that needs referencing. The one drawback of this approach is
that the host can't be change on the fly. Once you've built a application,
you're stuck with it singing only to the web services you designated at
design time.

I need to manually configure an application (c#.net) to do the serialisation
of a SOAP message, and posting via HTTP to the web service of my choice
manually, but haven't a clue as to where to start. Do I need to create a
project that doesn't "reference" my web service at all and do it all
manually, or do i use the bits that VS. Net generates?

I'm using an initialisation string on load up that tells the app the HTTP
location of the web service, and have a fixed WSDL for each web service
(apart from the <service / port / soap:address > tag...).

Any ideas on an implementation approach to this?

Thanks for your time.
Daniel.

 

[Jan Tielens]

You should check out Christian Weyer's example:
http://tinyurl.com/yvqtp
Did you ever think about invoking your XML Web Services dynamically without
having to generate a client side proxy class at design/compile time? No need
to know the exact Web Service description and endpoint at compile/design
time. Just get your WSDL from whereever you want, specify the type to
instantiate and the methods to call ... voila! Glance of features: - No need
to add WSDL descriptions during design time - Point-and-run Web Services
invocation functionality (generates in-memory assemblies) - Also resolves
imports of external schemas - Works with complex types - Provides a better
means to completely hide the Web Services bound functionality from client
apps -> think Grid computing - Caching mechanism to improve performance of
already 'well known' Web Services (pre-compiled and cahced assemblies) -
Access the raw SOAP messages for request and response - Sample client
application for testing purposes Please check out the included DynWSLib
README.txt file!

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

 

[Daniel Bass]

Excellent, just the sort of thing I needed. Cheers!

Dan

 

[Kristoffer Arfvidson]

Could somebody please give the same information to me?

I would also be interested in how this is done...
(vb.net)


Yours: Kristoffer

 

[Daniel Bass]

as Jan said,

"You should check out Christian Weyer's example:
http://tinyurl.com/yvqtp"

Dan.


Could somebody please give the same information to me?

I would also be interested in how this is done...
(vb.net)


Yours: Kristoffer

 

[Ken Onweller \(.NET MCSD\)]

The way I took care of this was to generate the client proxy in a tester
program and to then move that
file into the webservice project, itself, changing it's namespace to
something like WebService.Client.Service ...

Then I created a new constructor for the proxy wherein you supply the
hostname of the box hosting the
service. The constructor would then generate it's own URL based on that,
i.e.

public myProxy( string ServerName )
{
this.URL = "http://" + ServerName + "/WebService/Service1.asmx";
this.Credentials = System.Net.CredentialCache.Default;
}

The second line in the constructor was added to propogating the identity of
the webservice user.

To use this proxy you just add a reference to the WebService assembly,
itself and reference JUST the client,
i.e.

WebService.ClientService.Service myProxy = new
WebService.ClientService.Service( "HOSTMACHINE" );

.... and there you go ...

 

[Ken Onweller \(.NET MCSD\)]

Let me also add that each client using this proxy has the burden of knowing
which host machine to
specify in the constructor. My technique for this was to put the HostName
as a property in the
config file, using the AppSettingsReader to retrieve it at startup.