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



Agreed about SOAPUI being useful. Using SOAPUI you can get a sample
request and response of the exact XML that will be going across the wire
without actually having to call the web service. It builds the sample XML
based on the WSDL/XSD specs.

Aaron Bartell
www.MowYourLawn.com/blog
www.OpenRPGUI.com
www.SoftwareSavesLives.com



On Mon, Jan 30, 2012 at 8:20 AM, <TAllen@xxxxxxxxxxxxxxxxx> wrote:

There have been many informative responses on this thread. The point was
made in one post but I will also add that it is very valuable to have a
WSDL if you are the web service producer. Nearly all our customers use
the WSDL to generate their web service consumer skeleton code (read .NET).
The soapUI tool is a must-have when testing web services and creates
sample requests for you given a WSDL. Without the WSDL template you'd
likely need to provide a good amount of documentation about how the
service works. The WSDL handles most of that documentation for you.

Thanks,
Todd Allen
Estes Express Lines
tallen@xxxxxxxxxxxxxxxxx




Nathan Andelin <nandelin@xxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
01/27/2012 06:11 PM
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>


To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc

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





For 80 Years — Delivering Solutions that Exceed Expectations.



This communication and any transmitted documents are intended to be
confidential. If there is a problem with this transmission, please contact
the sender. If the reader of this message is not the intended recipient,
or the employee or agent responsible to deliver it to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.


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