Web Svc VS remote component hosted in IIS

[JJ]

A current requirement I am facing is the all business objects be stateless
remote components hosted in IIS. I am partial to web services myself.
However, it is insisted that IIS hosted remoting be used. They insist that
it is much, much faster. I don’t necessarily disagree with that point. But
under the circumstances, a web service that is load balanced (as are the
remote objects), though technically slower, would still have a lot of “head
room�.

With the knowledge that IIS hosted web services have to use an HttpChannel,
and that we're publishing them with a *.soap extension, I thought I would see
if I could pull up a WSDL file by entering
http://[server]/[vdir]/remoteObject.soap?wsdl...and it worked to my pleasant
surprise!

I then went an extra step and opened VS.NET and tried to create a Web
Reference to the remote object in question. The Web reference Dialog found
the WSDL and as usual listed the available methods. However, I couldn't
actually create the reference in VS.NET. I don't remember exactly but is
seemed like a problem with the xmlns or some type of xml-namespace issue.

With that said, my above "research" seems to indicate to me that under the
hood of .NET, an ASP.NET web service and a remote object hosted in IIS aren't
really all that different. I suspect that the performance between the two
probably isn’t all that dissimilar either.

I am curious if there is a way that a client could successfully create a
"web reference" in VS.NET to an object that is hosted as remote object, not a
web service. It seems that if the namespace issue could be resolved, then
the object could double as a web service and remote object: non-.NET
platforms could invoke the remote object as a web service, and .NET apps
could remote into it...

Which leads me to this question: Is there a noticeable performance
difference between an IIS hosted remote object and a web service? I know
that remote object hosted in an exe or WinSvc using TcpChannels and binary
formatter will be faster than web services. My question is strictly
comparing Web Services to IIS hosted remote objects using Soap formatting.

Thanks in advance!

[DalePres]

Policies being what they are, it may not help you to know that web services
in an asmx file beat all versions of IIS hosted remoting in most of
Microsoft's performance comparisons. The one area where standard web
services fell short was in handling large return values and in returning
datasets. Using soap extensions in those two cases overcame all of the
performance degredation and put asmx based web services on a par with
TCP/Binary remoting! ASP.Net and the .Net framework are optimised with asmx
based web services in mind.

And if you don't pass datasets over the wire (and no high performance or
otherwise performance bound applicatoin should) then asmx based web services
still out perform any version of IIS based remoting.

Here's the full report:

http://msdn.microsoft.com/library/de...tnetarch14.asp

HTH

DalePres
MCAD, MCDBA, MCSE
"JJ" <[e-mail]> wrote in message
news:7F**********************************@microsof t.com...

A current requirement I am facing is the all business objects be stateless
remote components hosted in IIS. I am partial to web services myself.
However, it is insisted that IIS hosted remoting be used. They insist
that
it is much, much faster. I don't necessarily disagree with that point.
But
under the circumstances, a web service that is load balanced (as are the
remote objects), though technically slower, would still have a lot of
"head
room".

With the knowledge that IIS hosted web services have to use an
HttpChannel,
and that we're publishing them with a *.soap extension, I thought I would
see
if I could pull up a WSDL file by entering
http://[server]/[vdir]/remoteObject.soap?wsdl...and it worked to my
pleasant
surprise!

I then went an extra step and opened VS.NET and tried to create a Web
Reference to the remote object in question. The Web reference Dialog
found
the WSDL and as usual listed the available methods. However, I couldn't
actually create the reference in VS.NET. I don't remember exactly but is
seemed like a problem with the xmlns or some type of xml-namespace issue.

With that said, my above "research" seems to indicate to me that under the
hood of .NET, an ASP.NET web service and a remote object hosted in IIS
aren't
really all that different. I suspect that the performance between the two
probably isn't all that dissimilar either.

I am curious if there is a way that a client could successfully create a
"web reference" in VS.NET to an object that is hosted as remote object,
not a
web service. It seems that if the namespace issue could be resolved, then
the object could double as a web service and remote object: non-.NET
platforms could invoke the remote object as a web service, and .NET apps
could remote into it...

Which leads me to this question: Is there a noticeable performance
difference between an IIS hosted remote object and a web service? I know
that remote object hosted in an exe or WinSvc using TcpChannels and binary
formatter will be faster than web services. My question is strictly
comparing Web Services to IIS hosted remote objects using Soap formatting.

Thanks in advance!

[Alexander Shirshov]

Why would anyone use SOAP formatter with Remoting? To fool firewall which
block binary traffic on 80? Rare case I think. If you're using Remoting
chances are it's an internal app and you're more or less in control of
firewalls.

What I see on that crappy low-res graphics (and why there're no tables with
numbers?) is:

Fig. 2 graph 1: IIS_HTTP_Binary outperforms ASMX slightly up to 50 users,
then neck-to-neck.
Fig. 2 graph 2: IIS_HTTP_Binary outperforms ASMX very slightly

Fig. 3 graph 1: IIS_HTTP_Binary outperforms ASMX slightly up to 50 users,
then neck-to-neck.
Fig. 3 graph 2: neck-to-neck

Fig. 4: IIS_HTTP_Binary wins clearly in both cases

Fig. 5: IIS_HTTP_Binary wins clearly in both cases

Fig. 6: IIS_HTTP_Binary wins clearly in both cases

Remoting (with binary formatting) hosted in IIS wins! IMO the text
surrounding the graphics is trying to hide it... Windows Service host with
TCP is the clear winner of course, but I wouldn't even consider it because
it's inherently insecure.

Remoting with BinaryFormatter hosted in IIS is the way to go. If you don't
need interoperability with different applications/platforms, that is.

Alexander
"DalePres" <[e-mail]> wrote in message
news:uS**************@tk2msftngp13.phx.gbl...

Policies being what they are, it may not help you to know that web
services in an asmx file beat all versions of IIS hosted remoting in most
of Microsoft's performance comparisons. .... http://msdn.microsoft.com/library/de...tnetarch14.asp

[DalePres]

There is nothing that says SOAP is used only over port 80. IIS listens on
port 80 but SOAP can be used on any port, on IIS, on Remoting, or over your
PC's serial port if you wish. You can encode messages with SOAP formatting,
put them on a floppy disk a transport them with SneakerNet if you wish.

DalePres

"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:u2**************@TK2MSFTNGP12.phx.gbl...

Why would anyone use SOAP formatter with Remoting? To fool firewall which
block binary traffic on 80? Rare case I think. If you're using Remoting
chances are it's an internal app and you're more or less in control of
firewalls.

What I see on that crappy low-res graphics (and why there're no tables
with numbers?) is:

Fig. 2 graph 1: IIS_HTTP_Binary outperforms ASMX slightly up to 50 users,
then neck-to-neck.
Fig. 2 graph 2: IIS_HTTP_Binary outperforms ASMX very slightly

Fig. 3 graph 1: IIS_HTTP_Binary outperforms ASMX slightly up to 50 users,
then neck-to-neck.
Fig. 3 graph 2: neck-to-neck

Fig. 4: IIS_HTTP_Binary wins clearly in both cases

Fig. 5: IIS_HTTP_Binary wins clearly in both cases

Fig. 6: IIS_HTTP_Binary wins clearly in both cases

Remoting (with binary formatting) hosted in IIS wins! IMO the text
surrounding the graphics is trying to hide it... Windows Service host with
TCP is the clear winner of course, but I wouldn't even consider it because
it's inherently insecure.

Remoting with BinaryFormatter hosted in IIS is the way to go. If you don't
need interoperability with different applications/platforms, that is.

Alexander
"DalePres" <[e-mail]> wrote in message
news:uS**************@tk2msftngp13.phx.gbl...

Policies being what they are, it may not help you to know that web
services in an asmx file beat all versions of IIS hosted remoting in most
of Microsoft's performance comparisons.

...

http://msdn.microsoft.com/library/de...tnetarch14.asp

[Alexander Shirshov]

Again, why would you use SOAP formatter with Remoting components hosted in
IIS on HTTP channel? Why not BinaryFormatter?

The article you pointed to demonstrates that Remoting *wins* over ASMX *if*
used with BinaryFormatter. Exactly opposite of your conclusion. I assumed
you compared SOAP-serialized Remoting components? Then the question remains:
why SOAP?

"DalePres" <[e-mail]> wrote in message
news:uc**************@TK2MSFTNGP12.phx.gbl...

There is nothing that says SOAP is used only over port 80. IIS listens on
port 80 but SOAP can be used on any port, on IIS, on Remoting, or over
your PC's serial port if you wish. You can encode messages with SOAP
formatting, put them on a floppy disk a transport them with SneakerNet if
you wish.

[DalePres]

You've taken the topic completely off the topic of the OP's question. I
didn't suggest SOAP over HTTP or IIS. I only showed Microsoft's own report
that web services using asmx is faster than remoting over IIS. I didn't do
the test and can't validate the results.

If you have done your own testing, please feel free to post the test
scenario and results here. I'd love to see your work on the subject.

DalePres

"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:eb*************@TK2MSFTNGP10.phx.gbl...

Again, why would you use SOAP formatter with Remoting components hosted in
IIS on HTTP channel? Why not BinaryFormatter?

The article you pointed to demonstrates that Remoting *wins* over ASMX
*if* used with BinaryFormatter. Exactly opposite of your conclusion. I
assumed you compared SOAP-serialized Remoting components? Then the
question remains: why SOAP?

"DalePres" <[e-mail]> wrote in message
news:uc**************@TK2MSFTNGP12.phx.gbl...

There is nothing that says SOAP is used only over port 80. IIS listens
on port 80 but SOAP can be used on any port, on IIS, on Remoting, or over
your PC's serial port if you wish. You can encode messages with SOAP
formatting, put them on a floppy disk a transport them with SneakerNet if
you wish.

[Alexander Shirshov]

You've made the misleading comment that according to Microsoft's benchmarks
ASMX outperforms Remoting+IIS. This is NOT true! Please carefully read the
article you yourself pointed to! Remoting is FASTER.

ASMX outperforms Remoting+IIS with SOAP formatter and falls behind
Remoting+IIS with BinaryFormatter.

Again, I'm not talking about my benchmarks or someone else's. I'm talking
about data presented in the article.

The only reason to use SOAP with Remoting I could think of is to bypass
firewalls which block the binary traffic on 80.

"DalePres" <[e-mail]> wrote in message
news:uY**************@TK2MSFTNGP14.phx.gbl...

You've taken the topic completely off the topic of the OP's question. I
didn't suggest SOAP over HTTP or IIS. I only showed Microsoft's own
report that web services using asmx is faster than remoting over IIS. I
didn't do the test and can't validate the results.

If you have done your own testing, please feel free to post the test
scenario and results here. I'd love to see your work on the subject.

DalePres

"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:eb*************@TK2MSFTNGP10.phx.gbl...

Again, why would you use SOAP formatter with Remoting components hosted
in IIS on HTTP channel? Why not BinaryFormatter?

The article you pointed to demonstrates that Remoting *wins* over ASMX
*if* used with BinaryFormatter. Exactly opposite of your conclusion. I
assumed you compared SOAP-serialized Remoting components? Then the
question remains: why SOAP?

"DalePres" <[e-mail]> wrote in message
news:uc**************@TK2MSFTNGP12.phx.gbl...

There is nothing that says SOAP is used only over port 80. IIS listens
on port 80 but SOAP can be used on any port, on IIS, on Remoting, or
over your PC's serial port if you wish. You can encode messages with
SOAP formatting, put them on a floppy disk a transport them with
SneakerNet if you wish.

[DalePres]

Can you provide any documentation to back up your statement that SOAP with
remoting bypasses firewalls or uses port 80? There's no association between
the formatter and the port.

And as far as my interpretation of the article, I posted the link to the
article so the OP, and you if you like, can draw your own conclusions. I'm
glad you have done so. If you want to continue to argue about the matter,
you'll have to find a different telephone pole; this one is done with it.

DalePres
"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:u5**************@tk2msftngp13.phx.gbl...

You've made the misleading comment that according to Microsoft's
benchmarks ASMX outperforms Remoting+IIS. This is NOT true! Please
carefully read the article you yourself pointed to! Remoting is FASTER.

ASMX outperforms Remoting+IIS with SOAP formatter and falls behind
Remoting+IIS with BinaryFormatter.

Again, I'm not talking about my benchmarks or someone else's. I'm talking
about data presented in the article.

The only reason to use SOAP with Remoting I could think of is to bypass
firewalls which block the binary traffic on 80.

"DalePres" <[e-mail]> wrote in message
news:uY**************@TK2MSFTNGP14.phx.gbl...

You've taken the topic completely off the topic of the OP's question. I
didn't suggest SOAP over HTTP or IIS. I only showed Microsoft's own
report that web services using asmx is faster than remoting over IIS. I
didn't do the test and can't validate the results.

If you have done your own testing, please feel free to post the test
scenario and results here. I'd love to see your work on the subject.

DalePres

"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:eb*************@TK2MSFTNGP10.phx.gbl...

Again, why would you use SOAP formatter with Remoting components hosted
in IIS on HTTP channel? Why not BinaryFormatter?

The article you pointed to demonstrates that Remoting *wins* over ASMX
*if* used with BinaryFormatter. Exactly opposite of your conclusion. I
assumed you compared SOAP-serialized Remoting components? Then the
question remains: why SOAP?

"DalePres" <[e-mail]> wrote in message
news:uc**************@TK2MSFTNGP12.phx.gbl...
There is nothing that says SOAP is used only over port 80. IIS listens
on port 80 but SOAP can be used on any port, on IIS, on Remoting, or
over your PC's serial port if you wish. You can encode messages with
SOAP formatting, put them on a floppy disk a transport them with
SneakerNet if you wish.

[Alexander Shirshov]

"DalePres" <[e-mail]> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl...

Can you provide any documentation to back up your statement that SOAP with
remoting bypasses firewalls or uses port 80? There's no association
between the formatter and the port.

Remoting components hosted in IIS use HTTP and (most likely but not always)
port 80. BinaryFormatter could be a problem in this configuration because I
heard (but never came across) that some overzealous firewalls block binary
traffic on port 80. In this case SoapFormatter is the only solution.

The article demonstrated that Remoting + IIS + BinaryFormatter *outperforms*
ASMX. Sad you can't see it. Bad you're trying to inflict your
misunderstandings on others in such an authoritative voice.

[DalePres]

Re-read the entire thread. I have not argued about any point you raised
about the relative performance of the various remoting/web service options
since your original post. I am not sure with whom you think you have been
arguing with but it hasn't been me.

The only point I have persisted with is to question your assertion that
using SOAP inherently implies the use of port 80 and provides a method for
bypassing firewalls - a point that you did not elaborate upon, or respond
to, until finally in your last post.

As far as your statement about "an authoritative voice", I offered the OP an
authoritative response: the link from Microsoft on the subject. I would not
expect him to take my assessment or my opinion over that authoritative
response. You, on the other hand, have been making authoritative statements
about a topic that, in the end, you admit your only knowledge is base upon
"because I heard (but never came across)".

So, to get this all back to how it started; from the OP's original question:

"Is there a noticeable performance difference between an IIS hosted remote
object and a web service? I know that remote object hosted in an exe or
WinSvc using TcpChannels and binary formatter will be faster than web
services. My question is strictly comparing Web Services to IIS hosted
remote objects using Soap formatting."

In particular, take note of the last sentence of the original post.

Do you have something you'd like to say in response to the OP's original
question or do you just want to argue?

DalePres
"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"DalePres" <[e-mail]> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl...

Can you provide any documentation to back up your statement that SOAP
with remoting bypasses firewalls or uses port 80? There's no association
between the formatter and the port.

Remoting components hosted in IIS use HTTP and (most likely but not
always) port 80. BinaryFormatter could be a problem in this configuration
because I heard (but never came across) that some overzealous firewalls
block binary traffic on port 80. In this case SoapFormatter is the only
solution.

The article demonstrated that Remoting + IIS + BinaryFormatter
*outperforms* ASMX. Sad you can't see it. Bad you're trying to inflict
your misunderstandings on others in such an authoritative voice.

[Das Bose]

Guys, my question was strictly related to performance differences between web
services (asmx) and IIS hosted remote objects using SOAP formatting.
Alexander, I am well aware that binary formatting is much more performant -
but in my particular case, policies and pre-existing architecture (based on
what I would call mis-conceptions about the .NET remoting framework in
general) demand that SOAP formatting be used. That is the reason in my
original question I specified that I am only talking about the above
mentioned mechanisms. I don't believe the other perrson replying to my
original post was implying anything otherwise. The other poster was
answering my question within the context I specified. Binary formatting is
understood to be faster and is not relevant to the original question I
presented.

The premise I am trying to validate is: There isn't a practical difference
in performance between an ASMX and IIS hosted remote objects using SOAP
formatting.

"Alexander Shirshov" wrote:

"DalePres" <[e-mail]> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl...

Can you provide any documentation to back up your statement that SOAP with
remoting bypasses firewalls or uses port 80? There's no association
between the formatter and the port.

Remoting components hosted in IIS use HTTP and (most likely but not always)
port 80. BinaryFormatter could be a problem in this configuration because I
heard (but never came across) that some overzealous firewalls block binary
traffic on port 80. In this case SoapFormatter is the only solution.

The article demonstrated that Remoting + IIS + BinaryFormatter *outperforms*
ASMX. Sad you can't see it. Bad you're trying to inflict your
misunderstandings on others in such an authoritative voice.

[Das Bose]

Thanks for the link: I found what I needed to know. My suspisions were
correct:

"...The ASP.NET Web service outperforms IIS_HTTP_SOAP and WS_HTTP_SOAP,
since ASP.NET XML serialization is more efficient than .NET Remoting SOAP
serialization. And as can be seen in Figure 2, the ASP.NET Web service is
very similar to IIS_HTTP_Binary in performance..."

Being that the article was written in Sept 2002, I am pretty sure that the
graphs are charted against the Framework 1.0. I would like to see a similar
article based on 1.1, and perhaps 2.0 beta.

"...Note that the performance of the ASP.NET Web service has dropped so much
so that it performs similar to WS_TCP_SOAP, WS_HTTP_SOAP and IIS_HTTP_SOAP.
This drop in performance is due to two known issues in ASP.NET, which will be
fixed in upcoming versions. One is the buffering issue as discussed earlier;
other is related to DataSet serialization in ASP.NET. With these issues
fixed, the ASP.NET Web service will be nearly comparable to
IIS_HTTP_Binary..."

Taking this into account, assuming they were speaking about the upcoming 1.1
version, an ASMX should be just as performant as IIS_HTTP_BINARY even when
passing along large objects such as DataSets.

Again, I would like to see a updated comparison using the latest version of
the framework, perhaps even 2.0 Beta.

"Alexander Shirshov" wrote:

"DalePres" <[e-mail]> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl...

Can you provide any documentation to back up your statement that SOAP with
remoting bypasses firewalls or uses port 80? There's no association
between the formatter and the port.

Remoting components hosted in IIS use HTTP and (most likely but not always)
port 80. BinaryFormatter could be a problem in this configuration because I
heard (but never came across) that some overzealous firewalls block binary
traffic on port 80. In this case SoapFormatter is the only solution.

The article demonstrated that Remoting + IIS + BinaryFormatter *outperforms*
ASMX. Sad you can't see it. Bad you're trying to inflict your
misunderstandings on others in such an authoritative voice.

[Das Bose]

Just in case, I am "JJ", I changed my ID after making the initial post ;-)

Sorry if I caused any confusion!

"Das Bose" wrote:

Guys, my question was strictly related to performance differences between web
services (asmx) and IIS hosted remote objects using SOAP formatting.
Alexander, I am well aware that binary formatting is much more performant -
but in my particular case, policies and pre-existing architecture (based on
what I would call mis-conceptions about the .NET remoting framework in
general) demand that SOAP formatting be used. That is the reason in my
original question I specified that I am only talking about the above
mentioned mechanisms. I don't believe the other perrson replying to my
original post was implying anything otherwise. The other poster was
answering my question within the context I specified. Binary formatting is
understood to be faster and is not relevant to the original question I
presented.

The premise I am trying to validate is: There isn't a practical difference
in performance between an ASMX and IIS hosted remote objects using SOAP
formatting.

"Alexander Shirshov" wrote:

"DalePres" <[e-mail]> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl...

Can you provide any documentation to back up your statement that SOAP with
remoting bypasses firewalls or uses port 80? There's no association
between the formatter and the port.

Remoting components hosted in IIS use HTTP and (most likely but not always)
port 80. BinaryFormatter could be a problem in this configuration because I
heard (but never came across) that some overzealous firewalls block binary
traffic on port 80. In this case SoapFormatter is the only solution.

The article demonstrated that Remoting + IIS + BinaryFormatter *outperforms*
ASMX. Sad you can't see it. Bad you're trying to inflict your
misunderstandings on others in such an authoritative voice.

[Alexander Shirshov]

Allright, my bad. Apologies to DalePres.

but in my particular case, policies and pre-existing architecture (based
on
what I would call mis-conceptions about the .NET remoting framework in
general) demand that SOAP formatting be used.

That's definitely a misconception I was fighting over and over.
BinaryFormatter over HTTP works just fine through firewalls (except for
those rare ones where binary traffic banned; I wonder, how they see pictures
in a browser then?). I missed the original point of compariing SoapFormatter
(as I see no point in using it). BinaryFormatter is default for ref="http"
channel template.

For pure IPC Web Services is extra work for no benefit. Why SoapFormatter?
Interoperability?

FYI, there were talks about deprecating SoapFormatter in .NET 2.0:
http://blogs.msdn.com/mattavis/archi...23/219200.aspx (It isn't
deprecated as per February 2005 CTP).

Alexander

[DalePres]

Not a problem, Alexander.

DalePres

"Alexander Shirshov" <al*******@omnitalented.com> wrote in message
news:Of****************@TK2MSFTNGP10.phx.gbl...

Allright, my bad. Apologies to DalePres.

but in my particular case, policies and pre-existing architecture (based
on
what I would call mis-conceptions about the .NET remoting framework in
general) demand that SOAP formatting be used.

That's definitely a misconception I was fighting over and over.
BinaryFormatter over HTTP works just fine through firewalls (except for
those rare ones where binary traffic banned; I wonder, how they see
pictures in a browser then?). I missed the original point of compariing
SoapFormatter (as I see no point in using it). BinaryFormatter is default
for ref="http" channel template.

For pure IPC Web Services is extra work for no benefit. Why SoapFormatter?
Interoperability?

FYI, there were talks about deprecating SoapFormatter in .NET 2.0:
http://blogs.msdn.com/mattavis/archi...23/219200.aspx (It isn't
deprecated as per February 2005 CTP).

Alexander

[Das Bose]

I'm not sure. Mostly because it is a lack of understanding of .NET in
general. They started this "framework" and have never used .NET before.
Before, everything was ASP & Javascript. Interoperability isn't an issue
since everything is new from the ground up. As far as performance goes
requirements, they aren't realy specified as far as I can tell. But from
what I can see of how the app will be used, ASP.NET would be more than
adequate, with plenty of room to spare. Transactional throughput isn't an
issue. Another issue I have with their design is that no interfaces or
abstract classes are used for the remoteable objects - only pure
implementation. They can't seem to understand that an object's interface
and its implementation can be independant of each other. Implementation is
shared at the client and hosting servers. I don't like this. Sorry.

As far as extra work is concerned using ASMX-based web services, i think it
would simplify the design and yet still meet their design requirements:
remotely hosted, stateless objects communicating via SOAP protocol that can
be load balanced. Nothing in here says it HAS to be IIS hosted remote
objects. As far as coding the web services to do what these remote objects
need to do, implementing Web Services would have been easier, and much more
".NET newbie" friendly. I know this isn't always the case, but in this
specific instance, Web services would have been the easiest to code and
deploy.

"Alexander Shirshov" wrote:

Allright, my bad. Apologies to DalePres.

but in my particular case, policies and pre-existing architecture (based
on
what I would call mis-conceptions about the .NET remoting framework in
general) demand that SOAP formatting be used.

That's definitely a misconception I was fighting over and over.
BinaryFormatter over HTTP works just fine through firewalls (except for
those rare ones where binary traffic banned; I wonder, how they see pictures
in a browser then?). I missed the original point of compariing SoapFormatter
(as I see no point in using it). BinaryFormatter is default for ref="http"
channel template.

For pure IPC Web Services is extra work for no benefit. Why SoapFormatter?
Interoperability?

FYI, there were talks about deprecating SoapFormatter in .NET 2.0:
http://blogs.msdn.com/mattavis/archi...23/219200.aspx (It isn't
deprecated as per February 2005 CTP).

Alexander