Calling Web Services Dynamically - 06-12-2006 , 07:15 AM
I would like to know how can I do the following.:
Write a software that will call web services dynamically
depends upon settings save upon database.
So the webservice call is not hard-coded but for example
I have a user interface that let a user pick and choose
which web service to use on a set of data.
Save the settings and then when user clicks on a button
the code in the button will read the "action'" that must be
taken upon the data from database and then the name of
web service and url and parms will be read from dynamically and
populated dynamically. So no web service is hard coded.
In such a way one can have a user interface displaying data
and when user clicks a button it will execute the webservice
'action'" that is linked to the button.
The code in the button will just read from database table which
to execute and this string as a generic procdure that will execute the
This way limitless webservices can be executed instead of hard coded
references and proxies that need to be recompiled
Francois du Toit
Re: Calling Web Services Dynamically - 06-13-2006 , 04:29 PM
You could use the Web Service Studio from gotdotnet.com that does
pretty much everything you ask, it's available here:
Re: Calling Web Services Dynamically - 07-13-2006 , 01:06 PM
This sample also has what you want
It works like the sample Josh posted but also has source code.
Please note that both samples rely on creating an assembly for the web
service proxy at runtime, then loading and running it. .NET assemblies
cannot be loaded unless the AppDomain is unloaded. This may be OK for a
console application or a desktop application that is not running for a long
time, or an application that is not processing too many web services. But
for a Windows service or a web application your application will suffer from
loading too many assemblies.
You have to evaluate how loading too many assemblies will affect your
Another approach is create the assembly in a separate AppDomain and using
marshaling to pass data from and to that AppDomain, then unloading the
AppDomain. This is not a very attractive solution, but will solve the
assembly unloading problem.
"francoisdt" <francois.a.dutoit (AT) jpmorgan (DOT) com> wrote
|Thread Tools||Search this Thread|