Is data always serialized when passing through a WCF service?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Yes, I understand that in most cases the data will need to be serialized
(ie, to reach another AppDomain). But what about a service that is self
hosted, ie. called InProc? Seems to me serialization there is absolutely
pointless and hurts performance. Don't you think?
 
Juan said:
Yes, I understand that in most cases the data will need to be serialized
(ie, to reach another AppDomain). But what about a service that is self
hosted, ie. called InProc? Seems to me serialization there is absolutely
pointless and hurts performance. Don't you think?
Click to expand...

Well sure but then WCF itself is absolutely pointless in such a
scenario... so it's hard to find fault with the design of WCF on this
account.

I guess you could want to have a service that COULD be self hosted or
COULD be hosted in a separate process/machine - in which case it would
be nice to dispense with the serializing bit. I guess you could just
instantiate the class that implements your DataContract directly from
the client portion of the code and assign it to the same interface that
would normally point to a proxy class... which would mean you could
effectively leave all your client code the same. This is something I'd
planned on investigating myself at some point but haven't tried yet.

One complication with this is that you probably don't want to add
compile time references in the client app to the assembly containing all
the code for the server (and thus the DataContract) but I figure the
instantiation of the server class could be done on the client using
reflection in the case that the client was self hosting the server.

Another complication is that the DataContract may be reliant to some
extent on various context features of WCF, such as the security
principal and claims established during authentication and
authorization. If that's the case then the design is necessarily going
to get quite complicated if you want to dispense with WCF so it might be
worth asking whether you actually have a performance problem or if
you're just being anal (not you personally, I'm talking about a general
you here) and if it isn't just easier to go with the IPC Channel.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
 
Hi,

would normally point to a proxy class... which would mean you could
effectively leave all your client code the same. This is something I'd
planned on investigating myself at some point but haven't tried yet.
Click to expand...
Please let me know if you advance on this topic, it sounds like an
alternative.

worth asking whether you actually have a performance problem or if
you're just being anal (not you personally, I'm talking about a general
you here) and if it isn't just easier to go with the IPC Channel.
Click to expand...
Sorry, don't follow you. What do you mean by someone being anal and what do
you mean by just easier to go with the IPC Channel?
 
I think remoting did that. Not sure if wcf does this or not.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


| Hi,
|
| Yes, I understand that in most cases the data will need to be serialized
| (ie, to reach another AppDomain). But what about a service that is self
| hosted, ie. called InProc? Seems to me serialization there is absolutely
| pointless and hurts performance. Don't you think?
|
|
| --
| Thanks in advance,
|
|
 
Juan said:
Sorry, don't follow you. What do you mean by someone being anal and what do
you mean by just easier to go with the IPC Channel?
Click to expand...

I meant dispensing with the serialization in the interest of improving
performance might be "anal" if you don't actually have a performance
problem in the first place... Does the overhead involved in
serialization make your app unusable or even noticeably slower to the
user??? Or are you just being a tech-head and tuning up stuff that
doesn't actually need tuning?

If the process that will be consuming the service is on the same machine
then you can use IPC (rather than http or tcp)... This will still
involve serialization but the data will be serialized to memory (not
across any network protocols) so the overhead really is pretty minimal
for all but the most demanding of apps performance wise - and dispenses
with the complications involved in implementing the kinds of workarounds
to issues that I mentioned above.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
 
Hi,

Can anyone think of a way to test if serialization is actually done when
Inproc service hosting?
 
whether it is inproc or out of proc is not the factor. Either way, you
still need a channel and wcf serializes/deserializes on and off the channel.
After all, that is the whole point - to abstract clr types to some general
wire form. Unless there is some hidden feature I have not read about yet.
If you think speed is an issue even with the netpipe channel, then perhaps
wcf is not the right tool for your need.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


| Hi,
|
| Can anyone think of a way to test if serialization is actually done when
| Inproc service hosting?
|
| --
| Thanks in advance,
|
| Juan Dent, M.Sc.
|
|
| "William Stacey [C# MVP]" wrote:
|
| > I think remoting did that. Not sure if wcf does this or not.
| >
| > --
| > William Stacey [C# MVP]
| > PCR concurrency library: www.codeplex.com/pcr
| > PSH Scripts Project www.codeplex.com/psobject
| >
| >
| > | > | Hi,
| > |
| > | Yes, I understand that in most cases the data will need to be
serialized
| > | (ie, to reach another AppDomain). But what about a service that is
self
| > | hosted, ie. called InProc? Seems to me serialization there is
absolutely
| > | pointless and hurts performance. Don't you think?
| > |
| > |
| > | --
| > | Thanks in advance,
| > |
| > |
| >
| >
| >
 
Back
Top