|
OK, I see where you're coming from. Personally, I've found UDDI to be more trouble than it's worth and tend to ignore the location specified in the WSDL. The problem I have with UDDI is it's granularity -- or lack thereof. Ideally you'd have one UDDI registry with all the web services in it (external or internal UDDI, I don't care). But the problem with that is I may want to call the web service on the development machine when I'm in development and the production machine when I'm in production. So... I could have two UDDI registries, one for development and one for production. I would then have one .config entry that contained the name of the UDDI server the application should talk to. In development I would talk to the development UDDI server, in production I would talk to the production UDDI server. The Development UDDI server would return references to the development web services, the production UDDI server would return referenced to the production web services. However, I now have to maintain 2 UDDI servers, yuck. Plus, what if I have a test environment too, or what about a training environment, now I have 4 UDDI servers? Oy! And then what if I want to call some development web services and some production web services from the same environment? How do I manage that? So we've just ignored UDDI. .NET is nice enough to give us an easy way to specify the location of web services at run time via the URL Behavior property and .config entries. So I can specify which web services use which servers. Sure, at deployment it means that I have to change several .config entries to use production URLs instead of development URLs, but at least I can do this one web service at a time if I want/need to. And actually, I could play some games with DNS and avoid changing the .config most of the time. -Walden ------------ Walden H Leverich III President & CEO Tech Software (516) 627-3800 x11 WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bartell, Aaron L. (TC) Sent: Wednesday, 20 October, 2004 11:20 To: Web Enabling the AS400 / iSeries Subject: RE: [WEB400] iSeries web service error from .Net application The way I look at it, a WSDL file doesn't have to reside on the server that is also offering up the service. For instance, you may not have your UDDI server running on the same iSeries that is taking in web service requests. So in that case what is the 'location' attribute suppose to contain? In my mind it either has to contain a domain or ip address. If you leave it as localhost then the web service consumer has to be smart enough to replace localhost with the ip address of the server it found the WSDL on. This is just my perception of how WSDL and UDDI interoperate with each other. It may be that I am making wrong assumptions. How are you approaching deployment of WSDL files? Aaron Bartell -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] Sent: Wednesday, October 20, 2004 10:03 AM To: Web Enabling the AS400 / iSeries Subject: RE: [WEB400] iSeries web service error from .Net application Aaron, Your WSDL file contains the IP (or name) of the machine it's installed on? Why? Doesn't that make deployment difficult since it requires you to change the WDSL between the test and production deployments? Rick, Also have your developers check that the URL Behavior in the properties page for the Web Reference is set to Dynamic. If they grabbed the WSDL from the same machine they're testing against it won't cause a problem now, but it will when you go to production. You need a way to tell .NET where to look for the WebService. By default it hard codes the URL you grabbed the WSDL from, but if you change the URL Behavior to dynamic it will use the URL you specify in the .config file so you can change it to use production vs. test. As for why it's blowing up, has the developer run it in debug to see where that exception is being thrown and why? -Walden ------------ Walden H Leverich III President & CEO Tech Software (516) 627-3800 x11 WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bartell, Aaron L. (TC) Sent: Wednesday, 20 October, 2004 09:32 To: Web Enabling the AS400 / iSeries Subject: RE: [WEB400] iSeries web service error from .Net application What type of web service is it? Are you using SOAP? Is the .NET program consuming a WSDL file? One thing that got me when one of our .NET programmers tried to consume a web service from my local box was the URL specified in the WSDL. It had 'localhost' specified and it should have been my IP address. Here is the line of code you need to change in your WDSL file: <wsdlsoap:address location="http://192.99.99.155:9080/CustomerWeb/services/Doorway"/> HTH, Aaron Bartell -----Original Message----- From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] Sent: Wednesday, October 20, 2004 8:23 AM To: web400@xxxxxxxxxxxx Subject: [WEB400] iSeries web service error from .Net application We are trying our first iSeries web service. It's been slow going but we've finally got it. Almost. When the .Net application tries to use the service it gets an error. The developer can access the service using IE so we know the connection is good and the service will work. The service hasn't been published to the iSeries yet. It is currently running on a WDSc WAS test server on my PC. I can provide source code if necessary. The .Net error information is shown below. Any help would be greatly appreciated. "System.Net.WebException: The underlying connection was closed: Unable to connect to the remote server.\r\n at System.Net.HttpWebRequest.CheckFinalStatus()\r\n at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)\r\n at System.Net.HttpWebRequest.GetRequestStream()\r\n at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)\r\n at TestI5Service.WebReference.ARSWebSvcService.getFormattedField(String fieldName) in C:\\Documents and Settings\\mhill2\\My Documents\\Visual Studio Projects\\TestI5Service\\Web References\\WebReference\\Reference.cs:line 38\r\n at TestI5Service.Form1.button1_Click(Object sender, EventArgs e) in c:\\documents and settings\\mhill2\\my documents\\visual studio projects\\testi5service\\form1.cs:line 93" Rick _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/web400 or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/web400. _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/web400 or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/web400. _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/web400 or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/web400. _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/web400 or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
