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



Nathan

I guess when you are the consumer you have no choice but to use whatever the web service provider using. You cannot dictate to the provider the transport mechanism they should use for their web service, so whether SOAP is 100%, 60% or 1% you still may have to cater for it. The web services we have to call are all based around the industry we provide solutions for - browser based front-ends to subscriber management and billing systems. These may be IBMi based or they may not. We have to call web services that handle document management, letter writing, talking to addressable interfaces for set-top boxes, creating/retrieving customers, creating/retrieving orders...all sorts really.

If you have the tooling to handle WSDLs and SOAP then consuming and providing web services is like falling off a log. That is the trouble - we are an RPG shop so we don't have the tooling (or at least not to the level you have for other languages). We tried the IBMi XML Toolkit once (which generates C++ proxy classes from a WSDL) and called them from RPG. It was too buggy so we had to go with our own RPG solution. WSDL2RPG may help but I haven't tested it yet.

When we are providing web services we tend to stick to the simple XML POST approach because SOAP does nothing but provide us with an overhead we can do without. However, in doing so, we make life harder for our consumers - and we have to spend more time documenting how the service is supposed to work. We invariably get the question - where is your WSDL? I think Scott touched on this in his response earlier.

- Kevin


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 27 January 2012 23:56
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Web Services War Stories

From: Kevin Turner
of the several disparate systems we have to interface with,
only about 60% of them use the WSDL/SOAP approach.


That's the kind of feedback I was hoping to get. 60% is quite significant. That makes WSDL/SOAP a factor to consider. Can you share a little about the types of requests you're getting for Web Services, or what you're using as a consumer?

There was some talk about using JSON rather than XML for data exchange. We see JSON all the time in web applications. But has it made the leap to Web Services?

-Nathan

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


NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



--------------------------------------------------------------------------------


CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.