RE: iSeries web service error from .Net application

I guess I don't see how your method is any less messy. (assuming from
your response that you are challenging my method)  You are still hard
coding just as much as I am.  

I like my method better because the .NET consumer shouldn't have to
provide features/defaults of the WSDL, that the WSDL has the ability to
contain within itself.  In short, I think you are providing the
configuration on the wrong end, or rather you are doing it on both ends
and it should only be on the WSDL end.  Purely my opinion.

I think what we can both agree on though is that it would be nice if
within the Dynamic Web Project Properties there were settings for how to
deploy a WSDL through a development lifecycle.  But then you start
getting into functionality of products like Aldon Lifecycle manager
which has a pre-configured path for deployment and would, I am guessing,
change configurations based on the server being deployed to.  IBM has
more or less made the statement that they are staying out of the Change
Management market because of the nice third party products, so I don't
know if I see us getting that as a feature of WDSc anytime soon if ever.

If anybody has another way of doing this I am all ears.

Aaron Bartell



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] 
Sent: Wednesday, October 20, 2004 11:41 AM
To: Web Enabling the AS400 / iSeries
Subject: RE: [WEB400] 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