RE: iSeries web service error from .Net application

I have the exact same scenario as you oddly enough.  I think my comments
against your method can be addressed by knowing whether or not all your
.NET applications have access to the same config file even though they
may be in completely different applications/namespaces.

For instance, let's say you have an AR package that you store in
SourceSafe as com.company.ar and an Order Entry package that you store
as com.company.orderentry.  Let's say both packages need to make use of
web service GetCustInfo which is http://prodsvr1/GetCustInfo for
production, http://testsvr1/GetCustInfo for testing, and
http://mylocalmachine/GetCustInfo for your development.

In the above scenario where do you store the configs to know which URL
should be used?  Is it in a place like com.mycompany.webserviceconfig
where it can be accessed by any .NET program?  Or is it in
com.mycompany.ar.webserviceconfig AND
com.mycompany.orderentry.webserviceconfig and now you have to maintain
it in two places?  If it is stored in a generic place like
com.mycompany.webserviceconfig then in my mind that would be the best
situation given the limitations.  If you store the configs in a context
that is specific to an application then the promotion of code to
production will cause a lot of maintenance of the different
webserviceconfig files.

I guess my point comes down to there should be a central entity
providing that information, similar to JNDI, so each application base
doesn't have to support it.  The bad part is that there doesn't seem to
be a language independent solution for this (that I have seen).

Just curious, do you have Java developers also?

Aaron Bartell



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] 
Sent: Wednesday, October 20, 2004 3:56 PM
To: Web Enabling the AS400 / iSeries
Subject: RE: [WEB400] iSeries web service error from .Net application

>What happens when a different language or application needs to consume 
>the web service and then wouldn't have access to your config file
(which
>you are storing in CVS or SourceSafe I am assuming)? 

Re: Change Control: Of course! -- Seriously.

If a different language or application has to access the web service,
won't they have their own reference to the service? I'm not saying my
solution is great, in fact I think it sucks, but I don't think there are
better ones. Let's look at an example and we can discuss details.

We have an application call APP1. It consumes 4 web services. First is
DistanceBetweenZips, which, oddly enough, returns the distance between
two zip codes. The second is GetItemPrice, which returns the price for
an item given the item number. The third is AllocateInventory, which
allocates a given quantity of a given item, and the forth is ChargeCC,
which charges a credit card.

Now, for the sake of argument in production there are 3 web servers
involved here. The first belongs to a partner and it is providing the
DistanceBetweenZips function. The second is inhouse, and handles the
pricing and inventory, the third, also in house, handles the credit card
clearing.

In production I'll use
http://www.partner.com/WS/DistanceBetweenZips.asmx for the first
service, http://prodsvr1/GetItemPrice.asmx for the second service,
http://prodsvr1/AllocateInventory.asmx for the third and
http://prodCC/ChargeCC.asmx for the last service.

However, in test I want to use
http://www.partner.com/WS/DistanceBetweenZips.asmx for the first, same
as before. But I want to use http://testsvr/GetItemPrice.asmx,
http://testsvr/AllocateInventory.asmx and http://testsvr/ChargeCC.asmx
for the last three. Note, that in test we consolidate all the inhouse
services onto one machine.

Finally, in development the partner site will be the same as before, but
I'm working on a new version of ChargeCC so I need to use http://devsvr
for ItemPrice and AllocateInventory from our development server, but I
want to use http://pc-waldenl/ChargeCC.asmx for the credit card
functions since I want to call the service on my machine to test it. 

How do I set this up? I don't mean this as an in-your-face challenge,
but as an attempt to see how others are handling a complex and
troublesome issue.

Thanks,
-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 15:13
To: Web Enabling the AS400 / iSeries
Subject: RE: [WEB400] iSeries web service error from .Net application

What happens when a different language or application needs to consume
the web service and then wouldn't have access to your config file (which
you are storing in CVS or SourceSafe I am assuming)?  You could have
each language/application carry the URL's with them through the
development cycle, but that will put you into maintenance mode to make
sure you have all of the consumers updated with the latest URL, won't
it?

>I shouldn't have to re-examine the WSDL to call the web service each
time.
I agree with you here.  That would be a waste of CPU cycles, bandwidth
and time.

I think we are just choosing between the lesser of two evils.  I will
have to look into Ant like Matt Haas suggested.  JNDI might also be the
solution given that a company will most likely have different server
instances for development, testing, and production.  You can read about
JNDI here:
http://java.sun.com/products/jndi/tutorial/getStarted/concepts/naming.ht
ml

I am guessing .NET also has a similar technology to JNDI.

Aaron Bartell

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
Sent: Wednesday, October 20, 2004 12:31 PM
To: Web Enabling the AS400 / iSeries
Subject: RE: [WEB400] iSeries web service error from .Net application

>(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 


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