Passing xml vs. passing a class

[Stan]

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these two
methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml is
used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[Manohar Kamath]

Stan,

I don't think there is any whitepaper on the above. The classes you use in
WebServices are nothing but state objects -- with Get/Set properties. Hence,
they can be represented as XML (for the structured data). Passing objects
instead of XMl makes it easier to play with the data on the either side --
else you will have to use XML parsers to get values; I would almost always
prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these two methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml is
used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[marc.derider]

I prefer using classes also. The only comment and if somebody has
actually tested this and found this to be true or not to be true feel
free to comment, would make that for speed create your own
serialization/deserialization methods. since implementing the
ISerialization interface and implementing the constructor allows .net
to not use reflection when serializaing data to xml or any other format?

[Stan]

There are two benefits of xml I can think of:

1. Predictable xml format. Not relying on xml serialization
2. Easy to test

I don't think it is hard to change or get anything:

XmlDocument doc = new XmlDocument();
doc.LoadXml (xml);
string OrderId = doc.SelectSingleNode ("//OrderId").Value:

It is longer than

string OrderId = Order.OrderId;

but not a huge deal..

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl...

Stan,

I don't think there is any whitepaper on the above. The classes you use in
WebServices are nothing but state objects -- with Get/Set properties. Hence, they can be represented as XML (for the structured data). Passing objects
instead of XMl makes it easier to play with the data on the either side --
else you will have to use XML parsers to get values; I would almost always
prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these

two

methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml is
used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[Manohar Kamath]

Stan,

Totally agree... however, now consider:

string myName = Order.Orders[5].Customer.CustomerName;

It makes it not only shorter, but also logical instead of say
"//orders[@id=5]/Customer/@CustomerName"

However, putting my consulting hat on, the solution does not fit all cases.
Given some performance hit during serialization/de-serialization, and given
the ability to scale well, I could choose the XML approach.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

There are two benefits of xml I can think of:

1. Predictable xml format. Not relying on xml serialization
2. Easy to test

I don't think it is hard to change or get anything:

XmlDocument doc = new XmlDocument();
doc.LoadXml (xml);
string OrderId = doc.SelectSingleNode ("//OrderId").Value:

It is longer than

string OrderId = Order.OrderId;

but not a huge deal..

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl...

Stan,

I don't think there is any whitepaper on the above. The classes you use in WebServices are nothing but state objects -- with Get/Set properties.

Hence,

they can be represented as XML (for the structured data). Passing objects instead of XMl makes it easier to play with the data on the either side -- else you will have to use XML parsers to get values; I would almost always prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these

two

methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml

is used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[Stan]

Here is one important benefit of xml - inteface is stable. In other words if
I have

SendOrder (string xml)

I can pass anything (which is good and bad at the same time), and it is
easier to change withought regenerating proxy classes for all clients...

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...

Stan,

Totally agree... however, now consider:

string myName = Order.Orders[5].Customer.CustomerName;

It makes it not only shorter, but also logical instead of say
"//orders[@id=5]/Customer/@CustomerName"

However, putting my consulting hat on, the solution does not fit all cases. Given some performance hit during serialization/de-serialization, and given the ability to scale well, I could choose the XML approach.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

There are two benefits of xml I can think of:

1. Predictable xml format. Not relying on xml serialization
2. Easy to test

I don't think it is hard to change or get anything:

XmlDocument doc = new XmlDocument();
doc.LoadXml (xml);
string OrderId = doc.SelectSingleNode ("//OrderId").Value:

It is longer than

string OrderId = Order.OrderId;

but not a huge deal..

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl...

Stan,

I don't think there is any whitepaper on the above. The classes you

use

in WebServices are nothing but state objects -- with Get/Set properties. Hence,

they can be represented as XML (for the structured data). Passing objects instead of XMl makes it easier to play with the data on the either side -- else you will have to use XML parsers to get values; I would almost always prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...
> There are two ways to pass structured data to a web service:
>
> xml
> ===
>
> <Order OrderId="123" OrderAmount="234" />
>
> or class
> =====
>
> public class Order
> {
> public string OrderId;
> public deciaml OrderAmount;
> }
>
> Class will be serialized to xml and on soap level there will be no
> difference.
>
> Are there any white paper or any guideline document which compares these two
> methods? In which cases should I use one or another?
>
> For example, test page is not available when passing a class, but

xml is > used, I can make it Notepad and paste it into the test page.
>
>
> Thanks,
>
> -Stan
>
>

[recoil]

I fail to see how that example pertains to the question however.
AbridgedTicketInfo[] MyWebMethod()
{ return GetListOfTickets(); }

This web service method returns XML regardless of how it was created.
I thought what Stan was originally asking was how to constfuct it.
e.g.
XmlNode TmpNode = RootDocument.CreateElement("order");
XmlAttribute TmpAttr = RootDocument.CreateAttribute("orderid");
TmpAttr.Value = OrderID.ToString();
RootDocument.Append(TmpNode);
TmpNode.Append(TmpAttr);

versus
[Serializable
public class OrderInfo : ISerializable
{
// implementation of Iserialization GetInfo and Constructor
can goes here for improved performance
}

Both methods return Xml.
One requires lots of extra code to construct every single node and
attribute.
One merely requires implementing a proxy class for the serialization.

How one chooses to use the data upon consuming it is one's own choice.
One could use it as raw xml - because both methods return Xml or one
could choose to deserialize the xml into an array of OrderInfo.

[Manohar Kamath]

It is similar to:

SendOrder (object myClass)

-- not any different (beside the overhead of casting). The compromise
between a stable interface and a concrete one is always the
readability/logical view. Not saying one is better, but I guess your
software has to stabilize at some point, especially if you wish the outside
world can have a contract with it. Besides, you could version your
interfaces so different clients can be served differently.
--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:eZ**************@tk2msftngp13.phx.gbl...

Here is one important benefit of xml - inteface is stable. In other words if I have

SendOrder (string xml)

I can pass anything (which is good and bad at the same time), and it is
easier to change withought regenerating proxy classes for all clients...

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...

Stan,

Totally agree... however, now consider:

string myName = Order.Orders[5].Customer.CustomerName;

It makes it not only shorter, but also logical instead of say
"//orders[@id=5]/Customer/@CustomerName"

However, putting my consulting hat on, the solution does not fit all

cases.

Given some performance hit during serialization/de-serialization, and

given

the ability to scale well, I could choose the XML approach.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

There are two benefits of xml I can think of:

1. Predictable xml format. Not relying on xml serialization
2. Easy to test

I don't think it is hard to change or get anything:

XmlDocument doc = new XmlDocument();
doc.LoadXml (xml);
string OrderId = doc.SelectSingleNode ("//OrderId").Value:

It is longer than

string OrderId = Order.OrderId;

but not a huge deal..

"Manohar Kamath" <mk*****@TAKETHISOUTkamath.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl...
> Stan,
>
> I don't think there is any whitepaper on the above. The classes you

use

in

> WebServices are nothing but state objects -- with Get/Set properties. Hence,
> they can be represented as XML (for the structured data). Passing

objects

> instead of XMl makes it easier to play with the data on the either

side --

> else you will have to use XML parsers to get values; I would almost

always

> prefer a class.
>
> --
> Manohar Kamath
> Editor, .netWire
> www.dotnetwire.com
>
>
> "Stan" <no****@yahoo.com> wrote in message
> news:%2******************@TK2MSFTNGP14.phx.gbl...
> > There are two ways to pass structured data to a web service:
> >
> > xml
> > ===
> >
> > <Order OrderId="123" OrderAmount="234" />
> >
> > or class
> > =====
> >
> > public class Order
> > {
> > public string OrderId;
> > public deciaml OrderAmount;
> > }
> >
> > Class will be serialized to xml and on soap level there will be no
> > difference.
> >
> > Are there any white paper or any guideline document which compares

these

> two
> > methods? In which cases should I use one or another?
> >
> > For example, test page is not available when passing a class, but

xml

is

> > used, I can make it Notepad and paste it into the test page.
> >
> >
> > Thanks,
> >
> > -Stan
> >
> >
>
>

[Dan Marshall]

The class doesn't seem to return readonly properties...Is anybody able to do
this?
Dan

"Manohar Kamath" wrote:

Stan,

I don't think there is any whitepaper on the above. The classes you use in
WebServices are nothing but state objects -- with Get/Set properties. Hence,
they can be represented as XML (for the structured data). Passing objects
instead of XMl makes it easier to play with the data on the either side --
else you will have to use XML parsers to get values; I would almost always
prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these

two

methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml is
used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[Le MasterChief]

You can still use XML messages, and have the classes that you need. This is
more in line with SOA. Look at this great article, specifically, check out
the section on "Building an ASP.NET web service". I started using this
pattern, and it works quite well.

You define xml schemas for what you want to send to the webservice method,
and what you receive back, and then run the XSD tool that comes with VS. It
then creates the serialized classes based on your schemas. You can then use
them in your method as input variables and return values.

Here is the article:
http://msdn.microsoft.com/architectu...soiwithnet.asp

"Dan Marshall" wrote:

The class doesn't seem to return readonly properties...Is anybody able to do
this?
Dan

"Manohar Kamath" wrote:

Stan,

I don't think there is any whitepaper on the above. The classes you use in
WebServices are nothing but state objects -- with Get/Set properties. Hence,
they can be represented as XML (for the structured data). Passing objects
instead of XMl makes it easier to play with the data on the either side --
else you will have to use XML parsers to get values; I would almost always
prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

There are two ways to pass structured data to a web service:

xml
===

<Order OrderId="123" OrderAmount="234" />

or class
=====

public class Order
{
public string OrderId;
public deciaml OrderAmount;
}

Class will be serialized to xml and on soap level there will be no
difference.

Are there any white paper or any guideline document which compares these

two

methods? In which cases should I use one or another?

For example, test page is not available when passing a class, but xml is
used, I can make it Notepad and paste it into the test page.
Thanks,

-Stan

[Stan]

Excellent artcle

"Le MasterChief" <Le***********@discussions.microsoft.com> wrote in message
news:D1**********************************@microsof t.com...

You can still use XML messages, and have the classes that you need. This is more in line with SOA. Look at this great article, specifically, check out the section on "Building an ASP.NET web service". I started using this
pattern, and it works quite well.

You define xml schemas for what you want to send to the webservice method,
and what you receive back, and then run the XSD tool that comes with VS. It then creates the serialized classes based on your schemas. You can then use them in your method as input variables and return values.

Here is the article:
http://msdn.microsoft.com/architectu...soiwithnet.asp
"Dan Marshall" wrote:

The class doesn't seem to return readonly properties...Is anybody able to do this?
Dan

"Manohar Kamath" wrote:

Stan,

I don't think there is any whitepaper on the above. The classes you use in WebServices are nothing but state objects -- with Get/Set properties. Hence, they can be represented as XML (for the structured data). Passing objects instead of XMl makes it easier to play with the data on the either side -- else you will have to use XML parsers to get values; I would almost always prefer a class.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Stan" <no****@yahoo.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...
> There are two ways to pass structured data to a web service:
>
> xml
> ===
>
> <Order OrderId="123" OrderAmount="234" />
>
> or class
> =====
>
> public class Order
> {
> public string OrderId;
> public deciaml OrderAmount;
> }
>
> Class will be serialized to xml and on soap level there will be no
> difference.
>
> Are there any white paper or any guideline document which compares these two
> methods? In which cases should I use one or another?
>
> For example, test page is not available when passing a class, but xml is > used, I can make it Notepad and paste it into the test page.
>
>
> Thanks,
>
> -Stan
>
>