RE: [WEB400] iSeries web service error from .Net application

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

>(assuming from your response that you are challenging my method)

Challenge is such a strong word... <G>

>You are still hard coding just as much as I am.   

Not so sure. I'm simply changing the .config file as I move from
environment to environment. Unless I grossly misunderstand what .NET is
doing with the WSDL .NET doesn't look at the WSDL once the stub is
generated. So changing the location is the WSDL doesn't buy me anything.
And even if the WSDL is reevaluated each time, how do you tell the
application where to look for the WSDL? 

I'm drawing a line between the WSDL which I consider part of the
development side of the world and the URL for the implementation of the
web service which I consider part of the runtime side of the world. I
shouldn't have to re-examine the WSDL to call the web service each time.


If I understand what your saying, you change the location in the WSDL as
you move from environment to environment. However, how do you tell the
application where to look for the WSDL?

-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 13:05
To: Web Enabling the AS400 / iSeries
Subject: RE: [WEB400] 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

_______________________________________________
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.