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!

[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******** ******@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.

[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******** ******@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.

[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******** ******@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.

[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?
Interoperabilit y?

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*******@omni talented.com> wrote in message
news:Of******** ********@TK2MSF TNGP10.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?
Interoperabilit y?

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. Interoperabilit y 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?
Interoperabilit y?

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