RE: iSeries web service error from .Net application

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.