On Tue, Jan 5, 2010 at 12:06 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
It's definitely best to use minOccurs=1 for primitives. nillable=true is
*not* a good choice in general, and I'd recommend you instead go with
minOccurs=0 for object types.
Why is nillable=true bad? 1. It requires the element to still be present
in the message, adding unnecessary bloat (including the xsi namespace
definition and usage) and confusion for human viewers of the message. 2.
If required attributes are defined for the element (not an issue for
POJO deployment, since it doesn't use attributes, but applicable in
terms of the general use of nillable=true) those attributes need to be
present even with xsi:nil=true in the document. minOccurs=0 is a cleaner
representation of optional values.
I know minOccurs="0" is a cleaner representation of optional values, but
I think that if Axis2 would like to be compatible with .NET clients it
should try to use the solution more compatible, rather than that more
"elegant". Or, at least, it should be configurable (and documented) for
that, especially because the .NET world is very important out there...
Even if minOccurs=0 might be a better solution from an XML
Schema/instance point of view, if you have a WSDL that defines a service
input parameter (called "myParam") with minOccurs=0, under certain
cicrumstances (bound to the type of myParam) .NET clients generated by
.NET tools from that WSDL have an awful layout like the following
public string myMethod(int myParam, bool myParamSpecified)
That is: myParam is "doubled", a second boolean parameter is added to
the method signature to specify if the myParam parameter has actually
been specified (i.e.: its value is significant and it's not null) or not
(i.e.: its value has to be ignored, myParam is to be considered "not
specified"/"null").
Even worse, if minOccurs=0 is specified on a service output parameter,
there must be a bug in the .NET generation tools that causes a method to
be generated like:
public void myMethod(...)
that is, with "void" return type!! This is the main reason for which the
issue has been opened.
However, even if the issue regarding minOccurs=0 vs nillable=true for
optional input parameters seems just to be an aesthetic issue (related
to .NET clients generation), from my daily work experience I had to
listen to a lot of complaints from .NET developers when they have to
interface with our services and they go to generate their client code
from our WSDLs. We use a contract-first approach (as of now, Axis2
code-first is not quite usable for serious production-quality web
service development IMHO) so we can choose every time where to use
minOccurs=0 or nillable=true and, because we need to keep .NET 1.1
compatibility, sometimes we are forced to use minOccurs=0 even if we
know about the "double-parameter" generation issue, so we have to
explain to the .NET client developers *why* we chose that strategy. But
because the user of a code-first approach usually does not have such
control (and knowledge...) over the WSDL, I think that Axis2 should try
to do its best to be as smart as possible when taking care of such
interoperability issues.
Also, the aesthetic issue could become an actual issue when you have
services with a lot of input parameters (try to think about an operation
with a request message with 5 optional parameters, you end up with a
client method with at least 10 (!!!) input parameters... And so on.
Because of this, using nillable=true seems to be the safest way to go
here. Actually, if you think of a scenario in which a Java developer is
writing services using code-first approach and a .NET developer is
generating its client code with automatic tools, do they really care if,
for an optional parameter which has not been specified, an XML element
with an xsi:nil=true attribute is passed on the wire rather than no XML
element at all?
You may argue that .NET is just one option among many others in the web
services world, but I think it's a really important one, so I would
appreciate if Axis2 could be at least configurable to behave in a
.NET-friendly way.
Please note that all my trials and researches were carried out on .NET
1.1 and .NET 2.0 interoperability. I don't have details on the
behaviours of 3.x .NET client generation tools. Maybe in the later
versions all the issues have been solved (so that minOccurs=0 could
actually be used with no harm), but there are many .NET 1.1/2.0 users
still out there.
--
Mauro Molinari
Software Designer & Developer
E-mail: mauro.molin...@cardinis.com
