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



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



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.