By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,206 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,206 IT Pros & Developers. It's quick & easy.

Web Service Extensions

P: n/a
Hi all,

I'm playing around with an idea for an app that uses WSE (2.0) to
communicate between client and server. Here's the deal - first I'm not
using IIS or ASP.NET at all; just C# and WSE. The client and server will be
Windows Forms apps. (It's hard finding info on Web Services that isn't
IIS/ASP.NET specific!) Next, I'm running into an issue - I want my client
to locate the server app automatically on start-up (the end-user may not
know which machine the server app is located on). Does anyone know of a way
to use XML/SOAP to automatically locate a server app on the local network
without using DISCO or UDDI?

Thanks,
Michael C., MCDBA
Jul 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
may be you should try .net remoting. have you considered the app.config to
store values of the server app?

"Michael C" wrote:
Hi all,

I'm playing around with an idea for an app that uses WSE (2.0) to
communicate between client and server. Here's the deal - first I'm not
using IIS or ASP.NET at all; just C# and WSE. The client and server will be
Windows Forms apps. (It's hard finding info on Web Services that isn't
IIS/ASP.NET specific!) Next, I'm running into an issue - I want my client
to locate the server app automatically on start-up (the end-user may not
know which machine the server app is located on). Does anyone know of a way
to use XML/SOAP to automatically locate a server app on the local network
without using DISCO or UDDI?

Thanks,
Michael C., MCDBA

Jul 21 '05 #2

P: n/a

Thanks for the start. I'm looking at the possibility of .NET remoting
also... The main problem I have either way though, is that I need to
dynamically locate the server application on the network regardless of
which implementation I use. Do you know of a way to do this with .NET
remoting?

Thanks,
Michael C., MCDBA
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 21 '05 #3

P: n/a
well, for one is you can provide some sort of a discovery program. on the app
server, you can write a tcp listener or another object which would provide
info that it offers the service. on your client, you need to scout all
possible ip addresses on your network to check which ip is running that tcp
listener. there may be a better solution but that's what i can come up with
at this time.. and maybe you can just limit the local ip to a certain range
where you would want the tcp listener running.. say assign 192.168.5.100 -
192.168.5.150 exclusively for use by your app servers. so the discovery
process would be swift and fast...

"Michael C" wrote:

Thanks for the start. I'm looking at the possibility of .NET remoting
also... The main problem I have either way though, is that I need to
dynamically locate the server application on the network regardless of
which implementation I use. Do you know of a way to do this with .NET
remoting?

Thanks,
Michael C., MCDBA
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Jul 21 '05 #4

P: n/a
That's well and good, but if I'm going to go through all the trouble to
implement a TCP listener that waits for an IP broadcast to tell the
clients where the server is, there's not much point in creating a
separate listener for the actual client commands...

It seems like the solution is to create a bunch of proprietary messages
and a proprietary message format for the whole thing... I was trying to
do it using standardized protocols (i.e., SOAP), but it looks like that
idea's out the Window©.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.