Re: ByRef/Ref passing in Web Services
- From: "Sahil Malik [MVP]" <contactmethrumyblog@xxxxxxxxxx>
- Date: Tue, 3 May 2005 09:52:06 -0400
Brock -
You are shooting the messenger boy here.
I completely agree with what you're saying. Like you, I give out training to
people who might still be caught in object thinking/single program stack
thinking/,NET only non-interoperable thinking, to them and what you say
below is exactly what I'd say too.
But as you will I am sure relate to this - one important aspect of being a
good trainer is to live and understand the mistakes, so you can clearly
explain and put the pain in words, and not only explain "WHAT" is wrong to
do, but "WHY" you shouldn't do it.
Anyway, I am not yelling at you, I'm yelling with you. :-) .. but hey,
thanks for giving words to my thoughts .. I really appreciate all the time
you put into it :-)
- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
"Brock Allen" <ballen@xxxxxxxxxxxxxxxxx> wrote in message
news:625392632507094095196560@xxxxxxxxxxxxxxxxxxxxxxx
> Where is this in the SOAP spec -- and don't say Section 5 encoding rules,
> since that's long outdated. If it is in the modern version of the SOAP
> spec, then I'd be suprised (I can't be bothered to go look). If it's not,
> then I'd rephrase "WebServices can indeed pass ByRef/ref parameters" to
> say "The .NET framework will map a ref param onto WebServices semantics".
> Just a subtle, yet important distinction.
>
>> So my question is - If I mark an int as "ref" in a WebMethod, it seems
>> to work. But if I am exposing a dumb schema (non-intelligent business
>> object), then it doesn't work. (Dumb Schema Non Intelligent Business
>> object example - a class customer, with private string FirstName,
>> encapsulated as a property - that's it !! (Default public constructor
>> present))
>
> I'm not sure what a "Dumb Schema" means, but my sense is that your
> approach to web services is from an object mindset which is fatal. My
> sense is that you also already know this, but at the sake of being
> redundant, I'll mention it again. Web Services are about XML message
> passing. Objects and [WebMethods] are simply a convenience afforided to
> you by the framework you choose to use to implement WebServices. That
> framework is very good at hiding the details of the underlying messaging
> framework (SOAP, WSDL, XSD, etc). And in fact it's too good at times. My
> point is that the framework is so good at hiding the real thing we're
> working with (XML) such that it lets you do dumb things that you really
> shouldn't be doing. Sure those dumb things work if you have .NET on both
> sides, but they don't make sense in a true introp scenario. The reason is
> that XML Schema is how we represent the structure of the XML we're sending
> across the wire, and the [WebMethods] framework infers an XSD from your
> parameters' type definitions. But there are so many things you can do with
> classes in .NET that don't map correctly to XSD. This is part of the
> debate over contract first.
>
>> Why should this work for only Intrinsic data types? :-/ .. or is there
>> a trick to making it work with serialized object graphs?
>
> So, this is a flawed way to think about web services. They're not objects,
> the'yre XML messages.
>
> Now, of course, the point of the framework is to make it easier to develop
> web services, so you can pass objects as long as you know that the
> inferred XSD is correct. [And finally, the answer I know you're looking
> for] The .NET WebService framework uses the XmlSerializer to do this
> mapping (for the actual object instances passed back and forth, at least).
> XmlSerializer is a XSD friendly object serilization/deserilization
> implementation. One part of that is that it only will access what's public
> because the private keyword is a sementic specific to a .NET class (and
> web services aren't about passing classes/objects). This is in contrast to
> the .NET remoting serilization implementation (SoapFormatter, and
> BinaryFormatter). The purpose of those is to faithfully pass objects
> across the network because we have .NET on both sides. This will dig into
> private fields to correctly serialize all of the state so that the object
> can be fully (and correctly) deserialized on the other side.
>
> In my web service implementations I never take .NET classes meant to be
> used by other .NET code and pass those pas paremeters or return values
> from my webservice. I instead create "shell" classes that only hold public
> fields and perhaps references to other "shell" classes. I create them in
> such a way that I know they'll be serialized out correctly according to
> the XSD rules. This way I'm able to utilize the .NET framework
> implementation of web services that wants to map XML messages onto classes
> and [WebMethods].
>
> Sorry for the long rant and aploogies if you already know all of this. I
> feel like this is such a poorly understood distinction, so if this isn't
> for you then perhaps for others reading it.
>
> -Brock
> DevelopMentor
> http://staff.develop.com/ballen
>
>
>
>
>
.
- References:
- Re: ByRef/Ref passing in Web Services
- From: Brock Allen
- Re: ByRef/Ref passing in Web Services
- Prev by Date: .NET Remoting?
- Next by Date: Re: Problem with Publisher Policy File (Can't install)
- Previous by thread: Re: ByRef/Ref passing in Web Services
- Next by thread: Re: ByRef/Ref passing in Web Services
- Index(es):
Relevant Pages
|
