|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Is data always serialized when passing through a WCF service?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 Dent, M.Sc. Juan Dent wrote:
> Yes, I understand that in most cases the data will need to be serialized Well sure but then WCF itself is absolutely pointless in such a > (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? 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 Please let me know if you advance on this topic, it sounds like an > 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. alternative. > worth asking whether you actually have a performance problem or if Sorry, don't follow you. What do you mean by someone being anal and what do > 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. you mean by just easier to go with the IPC Channel? -- Show quoteThanks in advance, Juan Dent, M.Sc. "James Crosswell" wrote: > Juan Dent wrote: > > 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? > > 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 > Juan Dent wrote:
>> worth asking whether you actually have a performance problem or if I meant dispensing with the serialization in the interest of improving >> 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. > 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? 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 I think remoting did that. Not sure if wcf does this or not.
-- Show quoteWilliam Stacey [C# MVP] PCR concurrency library: www.codeplex.com/pcr PSH Scripts Project www.codeplex.com/psobject "Juan Dent" <juanjr@nospam.nospam> wrote in message news:07385DBF-59CC-425D-9D59-3B1980B48951@microsoft.com... | 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, | | Hi,
Can anyone think of a way to test if serialization is actually done when Inproc service hosting? -- Show quoteThanks 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 > > > "Juan Dent" <juanjr@nospam.nospam> wrote in message > news:07385DBF-59CC-425D-9D59-3B1980B48951@microsoft.com... > | 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, > | > | > > > 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. -- Show quoteWilliam Stacey [C# MVP] PCR concurrency library: www.codeplex.com/pcr PSH Scripts Project www.codeplex.com/psobject "Juan Dent" <juanjr@nospam.nospam> wrote in message news:32F47FDD-DD21-4A25-BB85-39E2D5B6B989@microsoft.com... | 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 | > | > | > "Juan Dent" <juanjr@nospam.nospam> wrote in message | > news:07385DBF-59CC-425D-9D59-3B1980B48951@microsoft.com... | > | 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, | > | | > | | > | > | >  |
|||||||||||||||||||||||
Other interesting topics