We have to talk to various disparate systems via web services. They are all slightly different - some use the WSDL/SOAP approach, some are RESTful and some are just simple XML over an HTTP post. We can talk to them all from an RPG perspective but it always comes with a certain amount of pain to start with.

When we have to talk to a WSDL/SOAP web service we can do it in about 5 minutes flat using SOAPUI or Visual Studio - but when we want to do it from RPG that is when it gets to be a pain. It seems there are tools to import WSDL and generate the proxy code you need to use the web service for most languages except RPG - so you have to knife and fork it together. Cumbersome and error prone. We have downloaded a tool called WSDL2RPG however, but haven't had a chance to play with it yet. WSDL and SOAP are oriented towards object oriented languages, which leaves RPG a square peg in a round hole.

One other observation - of the several disparate systems we have to interface with, only about 60% of them use the WSDL/SOAP approach.

- Kevin

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

Friday late afternoon is probably not the best time to start a discussion like this. But some of my thoughts are extensions of the XMLSERVICE discussion that has been going strong on the RPG list this week. This discussion is for Web Service producers and consumers.

One problem I'd like to address is the cost and complexity of "recommended" Web Services architectures based on WSDL and SOAP. If you go to study the WSDL & SOAP interface specifications there's a good chance that you'll be asked to first get a good understanding on XML, XML Name Spaces, XML Schema Definitions, & XML Paths as prerequisites. Then WSDL. Then SOAP. Then how they all come together in Web Services architecture.

I guess it's not a requirement to study the underlying interfaces and specifications. You could just license the appropriate middleware, frameworks, toolkits, and runtime environments from Microsoft and IBM. I haven't done that.

Web services appear to be the vehicle du jour for getting otherwise disparate systems to inter-operate. I'm facing a problem right now concerning that, which I'd like to share if this discussion catches on. But first I'd like to ask if you have general thoughts or opinions or stories or travails about integrating disparate systems through Web Services? What do you think of WSDL and SOAP and associated frameworks?

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