WS-I Basic Profile Testing Tools
  Posted August 13, 2003    PermaLink    Comments (0)  

For anyone that's been reading the technical news lately WS-I relased the 1.0 WS-I Basic Profile (WBP). Basically it's a document that takes several of the published documents relating to web services and removes as much of the ambiguity that it can. Clearly there was some policiticing in the process in some of the rules but most of the "don't do that" rules fall under the realm of vauge and ill-defined.

One of the nice things is that they also have a set of testing tools. They current;y in beta but cover the bulk of the big "gotchas" from the spec. Implmentations are available in Java (based predominantly on Xerces and Axis) and C# (based on .NET). Source is not available. I spent most of today running these against the WSDL definitions I am developing and glean some suprising details.

  • Axis 1.1's WSDL2Java accepts a lot of WSDL that lies outside of the WBP. That's possiblbly because it generates a lot from Java2WSDL that lies outside of WBP. I consider that a good thing for WSDL2Java becuase it accepts what is within the basic profile (it's a tool, not a WSB conformance cop). I consider this a bad thing for Java2WSDL since some users are just going to blindly use the tool and say "Look! Web Services! Oohh. Aahh." Highlights (all WBP restrictions from the original WSDL spec) are the name element missing from the wsdl:fault element in the bindings, creating types instead of elements for the parts that are fault responses, and using wsdl:import to point to schema files.
  • SOAP Arrays are gonners. This is one piece of conformance I won't be conforming to for a while. Why? For structures themselves I can use other structures to get WSDL2Java to create arrays. The problem lies in the port definitions. If I use the tricks the WBP recommends to construct arrays WSDL2Java generates java classes that consist of a single indexed JavaBean property, and the methods consist of parameters of those classes and not parameters that are arrays. If I use the SOAP Array extensions I get a method call that has arrays instead of that bogus class. This seems to be a tough problem for Axis to address in a non-specialized form. Perhaps there could be a processor rule that checks to see if a type for a message part consists of a single unbound element, and if so then the method part becomes an array with the name of the element child of the element's type. I'de hate to be an IBM programmer working on WebSphere right now. As for .NET programmers? They'll never know since the C# version of the test tool doesn't flag this error.
  • No method overloading. There can be only one bound port and operation corresponding to a name. Differing these operations by message parts is not allowed, the names must be distinct. The reasons make sense. Using overloading makes your WSDL a leadky abstraction, showing too much of the underlying languages features. That, and some client langugages don't allow method overloading and that would break stuff. We want to be sure that those COBOL programmers can use your web service too!
  • Goodbye RPC/encoded and hello RPC/literal. This is potrayed as one of the biggest political force feeds in the spec, but for clear definiton of your web services XML struvture it has some merit. The use attribute on all of the bindings must be literal and can never be encoded. From an Axis viewpoint it means very little. You will only see a difference if you snoop the wire and see that all of those multi-ref elemetns are missing. What's really funny is that WSDL.exe (from Micsosoft's .NET SDK) dosen't accept RPC/literal and demands RPC/encoded or document/literal, accepting nothing else. It whines like a mule and refuses to create oerpations when you try and feed it RPC/literal. This is another poriton of the WBP I won't be conformant to for a while, becuase I use C# to prove some base level of interoperability. So when Microsoft gets their rear in gear I'll get mine. Did I mention I'm going on a vacation soon?

And one last tidbit: don't use circular schema imports. The Java version of the testing tool will start in an infinite recursive loop that no number of StackOverflowErrors will ever be able to stop. You probobly shouldn't do it anyway, but the testing tool won't tell you it's a problem (since it won't tell you anthing).

Trackback URL
  TrackBack URL for this entry:
Post Comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Remember me?

Email Address: