Sending and returning objects to/from web service

R

Raj

I have written a web service that receive an object and return an object.
Though the object is serialized, data sent to the service is always null and
hence object with null values returned . Any help would be appreciated.

I have serialized the object using [Serializable] attribute

Thank you

Regards
Raj
 
J

Jeroen Mostert

I have written a web service that receive an object and return an object.
Though the object is serialized, data sent to the service is always null and
hence object with null values returned . Any help would be appreciated.

I have serialized the object using [Serializable] attribute
[Serializable] affects binary serialization only (remoting) and has no
effect at all on XML or DataContract serialization.

Without seeing more detailed code with what you're doing it's hard to tell
what's going wrong. If you're using XML serialization (old-style Web
services) make sure you're using public fields and properties. If you're
using DataContract serialization (WCF) make sure the class is marked
[DataContract] and the members you want to serialize are marked [DataMember].
 
R

Raj

1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization

This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}

public string Writer
{
set{data=value;}
}
}
}

Web Service:
using WebServiceData;

namespace WebService1
{
[WebService(Namespace = "http://localhost/KRA/ASPDOTNET/WebService1")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service1 : System.Web.Services.WebService
{
public UserCredentials Consumer;

[SoapHeader("Consumer")]
[WebMethod]

public WebServiceData.Result PutData(WebServiceData.Result res)
{
string result = string.Empty;
WebServiceData.Result wr = new WebServiceData.Result();
try
{

wr.Writer = "Data received: " + res.Reader;
return wr;
}
catch (Exception e)
{
wr.Writer = e.Message;
return wr;
}
}

}
}

Web Service Consumer:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web.Services;
using WebServiceData;

namespace WebServiceConsumer
{
class Program
{
static void Main(string[] args)
{


Service1 s = new Service1();

WebServiceData.Result r = new WebServiceData.Result();

try
{

r.Writer = "test";
Console.WriteLine(r.Reader);
WebServiceData.Result newr=s.PutData(r);
Console.WriteLine("result: " + newr.Reader);
Console.Read();

}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
}
}
}


Jeroen Mostert said:
I have written a web service that receive an object and return an object.
Though the object is serialized, data sent to the service is always null and
hence object with null values returned . Any help would be appreciated.

I have serialized the object using [Serializable] attribute
[Serializable] affects binary serialization only (remoting) and has no
effect at all on XML or DataContract serialization.

Without seeing more detailed code with what you're doing it's hard to tell
what's going wrong. If you're using XML serialization (old-style Web
services) make sure you're using public fields and properties. If you're
using DataContract serialization (WCF) make sure the class is marked
[DataContract] and the members you want to serialize are marked [DataMember].
 
F

Family Tree Mike

Raj said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization


I'm pretty sure that nothing shown below changes your service from xml to
binary serialization.

This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}

public string Writer
{
set{data=value;}
}

When your object is serialized and deserialized, Reader has no _set_ method
and Writer has no _get_ method. They will not serialize, to the best of my
knowledge, and therefor the private field data will never be restored.

Mike
 
J

Jeroen Mostert

1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization
You cannot use binary serialization in a web service. A web service always
uses XML serialization. The attributes do not choose the mechanism used;
they only provide information to whatever mechanism serializes. If what
you're doing is not compatible with XML serialization, it won't work.
This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}
From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
not convert methods, indexers, private fields, or read-only properties
(except read-only collections)."
public string Writer
{
set{data=value;}
}

And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.
 
R

Raj

I shall make appropriate changes as per your suggestions

Thanks indeed for your time and patience

Regards
Raj

Family Tree Mike said:
Raj said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization


I'm pretty sure that nothing shown below changes your service from xml to
binary serialization.

This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}

public string Writer
{
set{data=value;}
}

When your object is serialized and deserialized, Reader has no _set_ method
and Writer has no _get_ method. They will not serialize, to the best of my
knowledge, and therefor the private field data will never be restored.

Mike
 
R

Raj

I shall make appropriate changes as per your suggestions

Thanks indeed for your time and patience

Regards
Raj


Jeroen Mostert said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization
You cannot use binary serialization in a web service. A web service always
uses XML serialization. The attributes do not choose the mechanism used;
they only provide information to whatever mechanism serializes. If what
you're doing is not compatible with XML serialization, it won't work.
This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}
From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
not convert methods, indexers, private fields, or read-only properties
(except read-only collections)."
public string Writer
{
set{data=value;}
}

And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.
 
R

Raj

Could you please let me know, How do I XMLSerialize the object which needs to
be sent and return?

Thank you

Regards
Raj

Family Tree Mike said:
Raj said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization


I'm pretty sure that nothing shown below changes your service from xml to
binary serialization.

This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}

public string Writer
{
set{data=value;}
}

When your object is serialized and deserialized, Reader has no _set_ method
and Writer has no _get_ method. They will not serialize, to the best of my
knowledge, and therefor the private field data will never be restored.

Mike
 
R

Raj

Could you please let me know, How do I XMLSerialize the object which needs to
be sent and return?

Thank you

Regards
Raj

Jeroen Mostert said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization
You cannot use binary serialization in a web service. A web service always
uses XML serialization. The attributes do not choose the mechanism used;
they only provide information to whatever mechanism serializes. If what
you're doing is not compatible with XML serialization, it won't work.
This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}
From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
not convert methods, indexers, private fields, or read-only properties
(except read-only collections)."
public string Writer
{
set{data=value;}
}

And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.
 
P

Peter Duniho

Jeroen said:
[...]
And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.

I would not go so far as the code analysis rule given. Just as one
common use for read-only properties are when they are synthetic and it
doesn't make sense to write the value, so too can it sometimes make
sense to have a synthetic write-only property, where it doesn't make
sense to read the value (because it's setting some state that doesn't
actually correspond to one single thing, or even some stable combination
of things).

I would certainly agree that it's something to use carefully and only
when it clearly makes sense. The situations when a write-only property
is good design are very rare.

In the class being shown here, I think the read-only _and_ write-only
property is just plain absurd. The whole point of a property is to have
a single class member that encapsulates a value, and when that value can
be both read and written, to split that value between two different
properties seems ridiculous to me.

I suspect that the OP will have much more success with the serialization
if the class is changed so that it just looks like this:

[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Data
{
get{return data;}
set{data=value;}
}
}

Of course, there still remains the question why the OP has a whole class
just to wrap a string value. Why doesn't he just serialize the string
value instead of messing around with the class?

But having a simple read/write property should make serialization go a
lot better, I would think.

Pete
 
R

Raj

It working fine

Thanks indeed

Regards
Raj

Peter Duniho said:
Jeroen said:
[...]
And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.

I would not go so far as the code analysis rule given. Just as one
common use for read-only properties are when they are synthetic and it
doesn't make sense to write the value, so too can it sometimes make
sense to have a synthetic write-only property, where it doesn't make
sense to read the value (because it's setting some state that doesn't
actually correspond to one single thing, or even some stable combination
of things).

I would certainly agree that it's something to use carefully and only
when it clearly makes sense. The situations when a write-only property
is good design are very rare.

In the class being shown here, I think the read-only _and_ write-only
property is just plain absurd. The whole point of a property is to have
a single class member that encapsulates a value, and when that value can
be both read and written, to split that value between two different
properties seems ridiculous to me.

I suspect that the OP will have much more success with the serialization
if the class is changed so that it just looks like this:

[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Data
{
get{return data;}
set{data=value;}
}
}

Of course, there still remains the question why the OP has a whole class
just to wrap a string value. Why doesn't he just serialize the string
value instead of messing around with the class?

But having a simple read/write property should make serialization go a
lot better, I would think.

Pete
.
 
M

Mr. Arnold

Raj said:
I shall make appropriate changes as per your suggestions

Thanks indeed for your time and patience

Regards
Raj


Jeroen Mostert said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization
You cannot use binary serialization in a web service. A web service always
uses XML serialization. The attributes do not choose the mechanism used;
they only provide information to whatever mechanism serializes. If what
you're doing is not compatible with XML serialization, it won't work.
This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}
From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
not convert methods, indexers, private fields, or read-only properties
(except read-only collections)."
public string Writer
{
set{data=value;}
}
And that note should also include write-only properties, but it doesn't,
because write-only properties are a bad idea to begin with. See
http://msdn.microsoft.com/library/ms182165.

Why don't you just send back string data? You have one property in the
object and it's string data. You should just have the method return the
string data.
 
F

Family Tree Mike

Could you please let me know, How do I XMLSerialize the object which needs to
be sent and return?

Thank you

Regards
Raj

Family Tree Mike said:
Raj said:
1. The object has public properties
2. I am not using WCF
3. I am not using XML serialization using only binary serialization


I'm pretty sure that nothing shown below changes your service from xml to
binary serialization.

This is the object sent/returned:

namespace WebServiceData
{
[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Reader
{
get{return data;}
}

public string Writer
{
set{data=value;}
}

When your object is serialized and deserialized, Reader has no _set_ method
and Writer has no _get_ method. They will not serialize, to the best of my
knowledge, and therefor the private field data will never be restored.

Mike

I would make a single property with both the get and sets. Something
along the lines:

private string _data;
public string Data
{
get {return _data;}
set {_data = value;}
}
 
A

Adam Clauss

Peter said:
Of course, there still remains the question why the OP has a whole
class just to wrap a string value. Why doesn't he just serialize the
string value instead of messing around with the class?
Just for the record, had he posted some object with 15 different
properties, you would have told him to reduce it to a simple example :)

-Adam
 
P

Peter Duniho

Adam said:
Just for the record, had he posted some object with 15 different
properties, you would have told him to reduce it to a simple example :)

That's true. But since he never once has posted an actual
concise-but-complete code example, I'm not sure how relevant it is. :p
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top