Big-Picture Question (Web Services, RegNow)

[Laurent Bugnion]

Hi,

Hi Laurent,

Thanks for following up on this. It took me a few days before I could get to
this.


I still think we're talking about different things here.

OK, I finally understand what you mean. You mean you created the web
service, and then you navigated with your browser to the ASMX page.

This "feature" is only there to help you check that your code is
working, without having to create any client. It is however very
primitive, and the reason why it doesn't work with "complex" types is
simply that it is not able to create a test UI for anything else than
simple types.

However, it doesn't say anything about the ability of the server to deal
with classes as parameters. The testing abilities are so primitive that
I almost never use it. Note that another way to test if your service is
running OK is to get the WSDL file and inspect it. You can do that from
the web browser by using the ASMX URL with a query string:

mywebservice.asmx?WSDL

I wouldn't worry about that if I were you. Create a simple UI to test
your web services and you'll see that it works fine.

Sorry for the misunderstanding,
Greetings,
Laurent

 

[Jonathan Wood]

Hi Laurent,

OK, I finally understand what you mean. You mean you created the web
service, and then you navigated with your browser to the ASMX page.

I set the ASMX page as the start-up page so no navigation was necessary. If
you do this, VS has some ready-made pages for testing the service.

This "feature" is only there to help you check that your code is working,
without having to create any client. It is however very primitive, and the
reason why it doesn't work with "complex" types is simply that it is not
able to create a test UI for anything else than simple types.

However, it doesn't say anything about the ability of the server to deal
with classes as parameters.

I fear we are talking past each other here. Again, my concern is not that
..NET can handle this. My concern is that some consumers of my service may
not be able to do. Those consumers may be written in .NET, but they could
just as easily be written by some other and maybe older platform.

If I were writing the code to use the service, I'd simply try it as you have
and there'd be no problem if it did not work. But since the VS Web service
testing does not support it, I'm going to use that as a signal that maybe
that approach is less compatible with other consumers of my Web service as
well.

For me, this is currently enough of a reason to avoid this approach. And I
can simply define the separate arguments so there isn't that much reason not
to do it that way, which appears to be more basic and perhaps more
compatible with some platforms/approaches.

The testing abilities are so primitive that I almost never use it. Note
that another way to test if your service is running OK is to get the WSDL
file and inspect it. You can do that from the web browser by using the
ASMX URL with a query string:

mywebservice.asmx?WSDL

Interesting. I'll have to try that sometime.

Thanks.

 

[Laurent Bugnion]

Hi,

I fear we are talking past each other here. Again, my concern is not that
.NET can handle this. My concern is that some consumers of my service may
not be able to do. Those consumers may be written in .NET, but they could
just as easily be written by some other and maybe older platform.

No, no, I understand exactly what you are talking about. Look, a few
years ago, I wrote the whole web service API for our web application in
JavaScript (there was no other solution back then), including SOAP
serialization and deserialization. So really, I can tell you that
packing or unpacking classes or arrays is no big deal for a client as
long as the attributes are simple types, because SOAP is XML, and XML is
hierarchical by nature, so it's really easy. On the other hand, if you
use complex types, it's more difficult.

If I was able to do it, I think that many other client platforms will be
able to offer the same kind of service, so I don't think that using
arrays or "container classes" will prevent clients from using your web
service.

If I were writing the code to use the service, I'd simply try it as you have
and there'd be no problem if it did not work. But since the VS Web service
testing does not support it, I'm going to use that as a signal that maybe
that approach is less compatible with other consumers of my Web service as
well.

That's your freedom of course ;-) You could use a CSV (comma value
separated) string.

HTH,
Laurent

 

[Jonathan Wood]

Laurent,

That's your freedom of course ;-) You could use a CSV (comma value
separated) string.

Yes, that might also be something to consider.

Thanks!