Web service parameters and WSDL

[Mark]

Is there a way I can be more specific about the attributes of a web service
parameter. For instance, instead of just defining a string, I would also
want to specify the maximum length allowed for that string or valid
characters for that string. Also, when passing an array, I might want to say
that 2 elements are required. The WSDL is effectively an XML schema for the
web service but I don't know how to have any effect on what WSDL is output -
the default WSDL in the Service Description just isn't tight enough.

Can I do this using Attributes?

 

[Brock Allen]

You can always take the WSDL that's generated and then hand-tweak it. This
is really not a bad approach and it prevents VS.NET from doing stupid things
to you (and your contract). If you do this, then make sure you disable the
auto-WSDL generation via web.config.

 

[Dan Rogers]

Hi Mark,

Well, you can, yes, you can. The easiest thing is to not use generic
types, but to instead expose a very detailed contract. For instance, if
you want the parameters to be a document that contains two specific types,
by all means make that the case. The more detail you provide, the more
friendly the client experience will be.

Starting from WSDL, however, can be a difficult path. Just because you
describe it in your WSDL doesn't mean you get that result. The key is to
actually describe the interface you expose. So if your web methods expose
a function that takes a string parameter - don't expect to get your WSDL as
the bridge that makes your callers think you know how to process XML.
Strings are NOT xml - so that's a well worn dead end path.

Instead, create classes that represent the interface you truly want. Stick
to cross platform compatible types - or even better yet, write cross
platform (basic profile 1.0 compliant) schemas, and generate your type
implementations and then use these generated types as your method returns
and parameters. If you use a tool like XSD.exe or XsdObjectGen.exe, and
stay away from scary schema types that don't map cleanly to object oriented
type systems, you'll get beautiful and functional WSDL's automatically.
THEN you can hand tweak the generated WSDL if you are a WSDL bit twiddler -
but there's little to gain there if you're careful.

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

 

[Vern DeHaven]

Mark,

To expound on Brock's submission, there's a great article on schema
validation written by his cohorts, Aaron Skonnard and Dan Sullivan.

http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/

The article's offered code is almost production-ready.

I come from the other side of the fence from Dan, so here's my $.02. All
of my Web services are developed WSDL-first; this has a few advantages
that outweigh the time it takes to learn how to do it.

-- Interoperability: This is nearly a non-issue as long as you work with a
Web services stack that supports the whole W3C XML Schema specification.

-- Security: Using the code that comes along with the article above, you
get data validation by having the ability to assign facets to data types
using XML Schema that would take a tiresome number of lines of code and
would be a pain to maintain. Regular expressions in schema are powerful!
Without any kind of validation, either schema- or code-based, you are
asking for buffer overrun or denial-of-service attacks.

-- Productivity: By agreeing on a WSDL contract before code is written,
both the producer and consumer of the Web service can work simultaneously.

-- Analysis/Design: You get to design the interface before any code is
written, and have a contract that can be presented to business users with
tools such as XMLSpy. (Its visual representation of WSDL and schema
rocks.)

A few companies have made it easier to design your Web services in this
fashion. My personal favorite is Cape Clear's SOA Editor. It's free!

http://www.capescience.com/soa/index.shtml

HTH,
Vern