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.so ap?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" <JJ@discussions .microsoft.com> wrote in message
news:7F******** *************** ***********@mic rosoft.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.so ap?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 interoperabilit y with different applications/platforms, that is.

Alexander
"DalePres" <[e-mail]> wrote in message
news:uS******** ******@tk2msftn gp13.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*******@omni talented.com> wrote in message
news:u2******** ******@TK2MSFTN GP12.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 interoperabilit y with different applications/platforms, that is.

Alexander
"DalePres" <[e-mail]> wrote in message
news:uS******** ******@tk2msftn gp13.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******** ******@TK2MSFTN GP12.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*******@omni talented.com> wrote in message
news:eb******** *****@TK2MSFTNG P10.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******** ******@TK2MSFTN GP12.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******** ******@TK2MSFTN GP14.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*******@omni talented.com> wrote in message
news:eb******** *****@TK2MSFTNG P10.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******** ******@TK2MSFTN GP12.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*******@omni talented.com> wrote in message
news:u5******** ******@tk2msftn gp13.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******** ******@TK2MSFTN GP14.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*******@omni talented.com> wrote in message
news:eb******** *****@TK2MSFTNG P10.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******** ******@TK2MSFTN GP12.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******** ******@TK2MSFTN GP12.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
misunderstandin gs 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*******@omni talented.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

"DalePres" <[e-mail]> wrote in message
news:Oa******** ******@TK2MSFTN GP12.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 misunderstandin gs on others in such an authoritative voice.