ByRef/Ref passing in Web Services

  • Thread starter Thread starter Sahil Malik [MVP]
  • Start date Start date
S

Sahil Malik [MVP]

Okay so now I understand (surprised though) - that WebServices can indeed
pass ByRef/ref parameters. All I have to do is mark an integer parameter of
a WebMethod as "ref". Funnily enough, this is also supported per the SOAP
Spec, and from what I understand, .NET's implementation of WebServices,
donot follow the standard, but instead shimmy this behavior by working with
a strict request/response WSDL.

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))

Why should this work for only Intrinsic data types? :-/ .. or is there a
trick to making it work with serialized object graphs?

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
 
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))
Click to expand...

You have now defined a property, not a parameter. The difference is that you cannot define a property as "ref". If, in fact, the
property Type is of a class that inherits from MarshalByRefObject, then it will be marshalled by reference.
 
Okay there have been two misunderstandings -

1. I am passing in the customer object as a PARAMETER to a WebMethod. A dumb
schema will have properties - XmlSerialization does not worry about type
info/methods.
2. Okay if I did Customer:MarshalByRefObject - that effectively should not
and will not have any difference. This is XmlSerialization/WebService, not
Remoting. And yes I know WebService is a specialized case of remoting, but
there is a big difference - XmlSerialization vs. Binary/SoapFormatter.
XmlSerialization will try and extract MarshalByRef like any other business
object - no behavior, just soapsuds like dumb metadata - anyway write up a
quick sample to find out what I'm tryin' to say.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
 
Yes, there must be some misunderstandings.

I tested it using MarshalByRefObject just to verify that I was correct.

Create a web serivce with a web method and a custom class:

public void MyClass : MarshalByRefObject
{
public string Field = "Initial Value";
}

[WebMethod]
public void ChangeValueByRef(MyClass cls)
{
cls.Field = "New Value";
}

Consume the method:

Service1 service = new Service1();
MyClass cls = new MyClass();
service.ChangeValueByRef(cls);

// outputs "New Value"
Console.WriteLine(cls.Field);
 
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))
Click to expand...

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?
Click to expand...

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
 
Type is of a class that inherits from MarshalByRefObject, then it will
be marshalled by reference.
Click to expand...

In .NET remoting, yes. But in WebServices? How do I load a proxy in a java
or a perl script web service client that when methods are invoked on that
proxy come back and call into the .NET MBRO object? It doesn't work this
way, as they are two different frameworks for doing two different things.

-Brock
DevelopMentor
http://staff.develop.com/ballen
 
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 said:
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))
Click to expand...

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?
Click to expand...

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
Click to expand...
 
Okay here is a more detailed answer - but don't rant at me, I am just trying
to discuss with you.

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383533

<--- 7.1, bullet #5 - says .."... method response is viewed as a single
struct containing an accessor for the return value and each [out] or
[in/out] parameter. "

Okay what I meant by a dumb schema was - here is an example -

public class Customer {
public Customer() {}
public string FirstName { get {..} set {...} }
}

Basically, XmlSerializer in it's serialization and deserialization - will
not loose any nature of the object - because the object itself contains no
logic inside, just a dead - data object map.

No I am not thinking in Object terms, if I were, I'd make this guy inherit
from a Person, and Person would have a constraint that a person can have
only two legs and no more. That would not be extractable via
soapsuds/XmlSerialization - thus doesn't fall into the WebService
philosophy.

Finally ---
So, this is a flawed way to think about web services. They're not objects,
the'yre XML messages.
Click to expand...

Agreed. but the above object is serialized to Xml, sent over, and
deserialized back to yourproject.webreferencename.object - which has no
logic inside, but a dumb object !! So true it is about message passing, but
I could pass in a schema. Yes sir, this is still schema headed thinking, and
not object headed thinking. I mean, a webservice isn't limited to passing in
only Ints/doubles and other scalar types. Even the Customer object I
specified is readable through a non .NET web service because (magic words
follow) - "The proxy object is created via. the information in the WSDL".

So ... in short, I agree with your arguments,

Now back to the question - How do I make ref type work with non scalar data
types? (Not that I'd ever want to, but for academic reasons .. How?)

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/



Brock Allen said:
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))
Click to expand...

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?
Click to expand...

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
Click to expand...
 
Now back to the question - How do I make ref type work with non scalar
data types? (Not that I'd ever want to, but for academic reasons ..
How?)
Click to expand...

This works for me:

public class Foo
{
public int xoxo;
}

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1, EmitConformanceClaims
= true)]
public class WebService : System.Web.Services.WebService
{
[WebMethod]
public void HelloWorld(ref Foo param)
{
}
}

-Brock
DevelopMentor
http://staff.develop.com/ballen
 
Y'know this is what another gentleman just recommended. I guess it must work
then. I swear I wrote an example last night which didn't, the only
difference was I didn't have a public int, I had a private string with a
get/set property.

Anyway, thanks for your help - I'll try this out tonight when I have my
hands on a 1.1 machine.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/



Brock Allen said:
Now back to the question - How do I make ref type work with non scalar
data types? (Not that I'd ever want to, but for academic reasons ..
How?)
Click to expand...

This works for me:

public class Foo
{
public int xoxo;
}

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1, EmitConformanceClaims
= true)]
public class WebService : System.Web.Services.WebService
{
[WebMethod]
public void HelloWorld(ref Foo param)
{
}
}

-Brock
DevelopMentor
http://staff.develop.com/ballen
Click to expand...
 
Okay if you put only ByRef - it still works. :-)

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/


Dave said:
Yes, there must be some misunderstandings.

I tested it using MarshalByRefObject just to verify that I was correct.

Create a web serivce with a web method and a custom class:

public void MyClass : MarshalByRefObject
{
public string Field = "Initial Value";
}

[WebMethod]
public void ChangeValueByRef(MyClass cls)
{
cls.Field = "New Value";
}

Consume the method:

Service1 service = new Service1();
MyClass cls = new MyClass();
service.ChangeValueByRef(cls);

// outputs "New Value"
Console.WriteLine(cls.Field);

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------
Sahil Malik said:
Okay there have been two misunderstandings -

1. I am passing in the customer object as a PARAMETER to a WebMethod. A
dumb schema will have properties - XmlSerialization does not worry about
type info/methods.
2. Okay if I did Customer:MarshalByRefObject - that effectively should
not and will not have any difference. This is
XmlSerialization/WebService, not Remoting. And yes I know WebService is a
specialized case of remoting, but there is a big difference -
XmlSerialization vs. Binary/SoapFormatter. XmlSerialization will try and
extract MarshalByRef like any other business object - no behavior, just
soapsuds like dumb metadata - anyway write up a quick sample to find out
what I'm tryin' to say.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
Click to expand...
Click to expand...
 
Back
Top