While I absolutely acknowledge the cleverness of this solution, it's not one I would personally employ. Making a server application dependent on another server for startup configuration strikes me as quite a hack (albeit a clever one!)
> It in fact does make sense to assume that a web service installed on > a network will be reachable from an external network. Careful! Here at work we are using Web Services quite a bit, but so far, very few of them go outside our network. We expose a lot of shared components and systems as services, but they are only available to other internal applications. I don't think that changes your basic premise though... Chances are, if you are using this two-server initialization scheme, your clearly going to make sure they can talk to each other, regardless of network topology. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, January 28, 2005 11:21 am, Dakota Jack said: > <snip> > On Fri, 28 Jan 2005 08:02:46 -0600, David Suarez > <[EMAIL PROTECTED]> wrote: >> I think the answer here would be configuration is the only way in the >> scenario above. The question is, do you really need the call backs for >> what you're really doing? In the licensing example above, you likely >> only need to send the request to the public server. The public server >> can check and respond if the license is valid. There's no need for it >> to send you a request later. > </snip> > > I am not sure at this point David S. what you have tried, but I can > assure you that your conclusion that "configuration is the only way in > this scenario above" is incorrect, because I do this all the time with > no difficulties whatsoever. > > <snip> > It doesn't make sense to assume that > the web service installed on the client inside some network will be > reachable from the external network. If this is what you're doing, > configuration (having the client app user set the URL) is the only way > to set it up because they (the client) will likely need to open up some > incoming requests that they normally would not allow through their > firewalls anyway. > </snip> > > The firewall issue is different. It is true that if you have the > correct URL or IP address that a caller cannot get through if there is > a firewall blocking the port. But that is a totally separate concern. > It in fact does make sense to assume that a web service installed on > a network will be reachable from an external network. There would > otherwise be no sense at all to having the web service. If you toss > in these firewall issues, you will only be muddying the waters with > irrelevant concerns that are unrelated to this problem. > > I hope that did not sound too preachy. I guess I am just pretty sure > in this area and hope that you all will see I am only trying to help. > I am sure because I have gone through all the problems in one way or > another related to this many times. > > Wasn't Martin the originator of this thread? Maybe you are talking > about a sub-thread issue? > > Jack > > -- > ------------------------------ > > "You can lead a horse to water but you cannot make it float on its back." > > ~Dakota Jack~ > > "You can't wake a person who is pretending to be asleep." > > ~Native Proverb~ > > "Each man is good in His sight. It is not necessary for eagles to be > crows." > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > > ----------------------------------------------- > > "This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based > on this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation." > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
