I've not seen a WSDL/schemas yet that soapUI could not handle. I don't
know about MS Visual Studio. I've written a couple basic web service
clients in C# and VS worked fine. I'd say the tooling is likely up to the
challenge. As a quick test you could download/install soapUI (soapui.org)
and create a project based on one of these WSDLs.
Regarding the normalization, what I always do is create a common schema
that can be shared across operations in a WSDL. As for the meaning of
elements, there is an <annotation> tag that can be used to document the
element use. Of course, that is only as good as the creator of the WSDL
making use of it.
Thanks,
Todd Allen
Estes Express Lines
tallen@xxxxxxxxxxxxxxxxx
Nathan Andelin <nandelin@xxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
01/30/2012 02:12 PM
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc
Subject
Re: [WEB400] Web Services War Stories
Okay, so web service client tooling may or may not stand up to complex
WSDL files. What about standing up to complex XML response documents? Most
of the examples posted on the Internet are simple interfaces
like Fahrenheit to Celsius conversions. What happens when XML responses
are more hierarchical?
http://www.radile.com/rdweb/temp/xml.html
That's a link to a small sampling of XML documents which are part of the
School Interoperability Framework (SIF). The SIF specification has been
growing like a cancer over a period of years. Now it's up to 178 document
formats.
A couple things concern me about complying with the specification.
First, the data models are not normalized. You find the same XML elements
defined in many different documents. The irony is that these documents are
meant to share data between disparate systems. Why make that more
difficult by duplicating data elements in multiple documents? Why not
normalize your XML documents like you'd normalize your database?
Second, the documents contain hierarchical structures. How well will
client tooling handle them?
Third, what if you find data elements that don't have clear meaning? What
is this field? What does it stand for? How do we use it? And it's not like
a WSDL file is going to clarify the questions, other than perhaps indicate
the data type of the element.
-Nathan
----- Original Message -----
From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx
Cc:
Sent: Monday, January 30, 2012 9:35 AM
Subject: Re: [WEB400] Web Services War Stories
On Jan 30, 2012, at 11:20 AM, web400-request@xxxxxxxxxxxx wrote:
You've got to give someone credit for the amount of code that must have
gone into PHP SoapClient to simplify the interface as they did. I wonder
how well it works with complex WSDL files ... <snip>
I've actually got one it can't handle Nathan. There is an issue when there
are duplicate definitions used. I'm not sure of the exact issue but it
relates to the fact that in the wsdl I have there are two includes
referenced that contain the custom data type definitions. Problem arises
because one of them includes and references element definitions in the
other. SoapUI handles it and ignores the duplicate entries. The PHP parser
craps out and can't handle it. The problem can apparently be cured by
judicious editing of the wsdl - but I'm not savvy enough with wsdls to be
able to sort it out (I have tried but ...). Originally vendor support
staff told me that could could give me instructions on how to make the
change. Now they are refusing and claim that none of their staff would
ever have told me that <sigh>
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
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.
midrange.com
