× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.