Advantes of using Remoting with HTTP and SOAP with IIS?

[Guest]

Hi,
I unerstand that if you choose IIS to host your .Net Remotingcomponents with HTTP channel and SOAP formatter, you get thebuilt-in security and configuraion features of IIS. Also we canexpose it to use for the web services clients. But using HTTPwith SOAP has got the least performance amoung all others (exTCP with Binary etc).

The question is what are the advantages of using http with SOAPover http with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)

 

[Miha Markic [MVP C#]]

No firewall hassle?

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

Hi,
I unerstand that if you choose IIS to host your .Net Remoting components
with HTTP channel and SOAP formatter, you get the built-in security and
configuraion features of IIS. Also we can expose it to use for the web
services clients. But using HTTP with SOAP has got the least performance
amoung all others (ex TCP with Binary etc).

The question is what are the advantages of using http with SOAP over http
with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)

 

[Richard Blewett [DevelopMentor]]

The only thing the SOAP formatter is useful for is to be able to look at the message structure on the wire when debugging.

Personally I think they shoiuld delete it from the framework - I have never, in production, used the SOAP formatter its slower and adds no benefit

HTTP/Binary is just as firewall friendly as HTTP/SOAP unless the firewall is using content based filtering (which very few do in my experience).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

No firewall hassle?

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

Hi,
I unerstand that if you choose IIS to host your .Net Remoting components
with HTTP channel and SOAP formatter, you get the built-in security and
configuraion features of IIS. Also we can expose it to use for the web
services clients. But using HTTP with SOAP has got the least performance
amoung all others (ex TCP with Binary etc).

The question is what are the advantages of using http with SOAP over http
with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)





--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]

 

[Miha Markic [MVP C#]]

Ah, right - I though he was comparing http with tcp.

 

[Nick Malik [Microsoft]]

Hello Richard,

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

The SOAP formatter, while less speedy than the binary formatter, is
necessary for SOA implementations. It is, in fact, essential.
One of the problems with HTTP/Binary formats is that we have optimized for
speed to the detriment of maintainability.

However, in the wild majority of apps that expose an EXTERNAL interface,
speed is not a driving factor, while maintenance costs will far far outweigh
the benefit of speed *on that interface* over its lifetime.

One of the advantages of SOA-based applications is that you can create a
discoverable external interface as part of a previously internal one simply
by adding a proxy. In other words, if you have a web layer in a farm that
is accessing a business layer over HTTP/Binary, then a well-executed
architecture would also provide a SOAP proxy to call the Binary objects,
thus allowing ANY application that needs the services of the business layer
to call it, without it being created at the same time by the same team.

The elements of discoverability and the ability to see and debug information
flowing over the network, is important in that case, even though the
interface was not originally developed for those needs. Clearly the proxy
can be developed on an as-needed basis. However, the cost of developing a
small integration object of this kind is low compared to the cost of
developing integration code that has to cross binary boundaries, especially
if the calling environment is not .Net or Windows.

HTH,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

The only thing the SOAP formatter is useful for is to be able to look at

the message structure on the wire when debugging.

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

HTTP/Binary is just as firewall friendly as HTTP/SOAP unless the firewall

is using content based filtering (which very few do in my experience).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

No firewall hassle?

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

Hi,
I unerstand that if you choose IIS to host your .Net Remoting components
with HTTP channel and SOAP formatter, you get the built-in security and
configuraion features of IIS. Also we can expose it to use for the web
services clients. But using HTTP with SOAP has got the least performance
amoung all others (ex TCP with Binary etc).

The question is what are the advantages of using http with SOAP over http
with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)





--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]

 

[Richard Blewett [DevelopMentor]]

OK Nick, I've held off for a few days to check various fact before I replied to this message - mostly because its unusual that I find myslf heavily disagreeing with someone from Microsoft.

The SOAP adapter generates RPC/Encoded SOAP which has been deprecated from the SOAP spec - therefore I doubt the utility of using it to expose an interface to the world outside of .NET today. It also uses extensions to allow the encoding of obj refs into the message to allow callbacks. This is completely against the spirit of SOA and means the SOAP formatter could leak non-service implementation into the Service Orientated world. Finally the team responsible for the SOAP formatter is proposing to obsolete it for .NET 2.0 [1] which makes it an unusual choice for ongoing development.

Creating a web service facade using either .asmx or WSE would, to me, be the way to bring a remoting app into the SOA world (or writing a custom BizTalk adapter). The SOAP formatter was an idea at a time to allow remoting apps to integrate into the web service world - unfortunately that world moved on and the SOAP formatter is now an oddity with no real role (other than its human readable serialization format) IMO.

[1] http://weblogs.asp.net/mattavis/archive/2004/08/23/219200.aspx

Regards

Richard Blewettt - DevelopMentor
http://www.dotmetconsult.co.uk/weblog
http://www.dotmetconsult.co.uk

Hello Richard,

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

The SOAP formatter, while less speedy than the binary formatter, is
necessary for SOA implementations. It is, in fact, essential.
One of the problems with HTTP/Binary formats is that we have optimized for
speed to the detriment of maintainability.

However, in the wild majority of apps that expose an EXTERNAL interface,
speed is not a driving factor, while maintenance costs will far far outweigh
the benefit of speed *on that interface* over its lifetime.

One of the advantages of SOA-based applications is that you can create a
discoverable external interface as part of a previously internal one simply
by adding a proxy. In other words, if you have a web layer in a farm that
is accessing a business layer over HTTP/Binary, then a well-executed
architecture would also provide a SOAP proxy to call the Binary objects,
thus allowing ANY application that needs the services of the business layer
to call it, without it being created at the same time by the same team.

The elements of discoverability and the ability to see and debug information
flowing over the network, is important in that case, even though the
interface was not originally developed for those needs. Clearly the proxy
can be developed on an as-needed basis. However, the cost of developing a
small integration object of this kind is low compared to the cost of
developing integration code that has to cross binary boundaries, especially
if the calling environment is not .Net or Windows.

HTH,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

The only thing the SOAP formatter is useful for is to be able to look at

the message structure on the wire when debugging.

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

HTTP/Binary is just as firewall friendly as HTTP/SOAP unless the firewall

is using content based filtering (which very few do in my experience).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

No firewall hassle?

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

Hi,
I unerstand that if you choose IIS to host your .Net Remoting components
with HTTP channel and SOAP formatter, you get the built-in security and
configuraion features of IIS. Also we can expose it to use for the web
services clients. But using HTTP with SOAP has got the least performance
amoung all others (ex TCP with Binary etc).

The question is what are the advantages of using http with SOAP over http
with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)





--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]

 

[Nick Malik [Microsoft]]

I find myself at a loss, Richard. I haven't disagreed with you on anything
in the past. I will research your message and think about it before
responding.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

OK Nick, I've held off for a few days to check various fact before I

replied to this message - mostly because its unusual that I find myslf
heavily disagreeing with someone from Microsoft.

The SOAP adapter generates RPC/Encoded SOAP which has been deprecated

from the SOAP spec - therefore I doubt the utility of using it to expose an
interface to the world outside of .NET today. It also uses extensions to
allow the encoding of obj refs into the message to allow callbacks. This is
completely against the spirit of SOA and means the SOAP formatter could leak
non-service implementation into the Service Orientated world. Finally the
team responsible for the SOAP formatter is proposing to obsolete it for .NET
2.0 [1] which makes it an unusual choice for ongoing development.

Creating a web service facade using either .asmx or WSE would, to me, be

the way to bring a remoting app into the SOA world (or writing a custom
BizTalk adapter). The SOAP formatter was an idea at a time to allow remoting
apps to integrate into the web service world - unfortunately that world
moved on and the SOAP formatter is now an oddity with no real role (other
than its human readable serialization format) IMO.

[1] http://weblogs.asp.net/mattavis/archive/2004/08/23/219200.aspx

Regards

Richard Blewettt - DevelopMentor
http://www.dotmetconsult.co.uk/weblog
http://www.dotmetconsult.co.uk

Hello Richard,

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

The SOAP formatter, while less speedy than the binary formatter, is
necessary for SOA implementations. It is, in fact, essential.
One of the problems with HTTP/Binary formats is that we have optimized for
speed to the detriment of maintainability.

However, in the wild majority of apps that expose an EXTERNAL interface,
speed is not a driving factor, while maintenance costs will far far outweigh
the benefit of speed *on that interface* over its lifetime.

One of the advantages of SOA-based applications is that you can create a
discoverable external interface as part of a previously internal one simply
by adding a proxy. In other words, if you have a web layer in a farm that
is accessing a business layer over HTTP/Binary, then a well-executed
architecture would also provide a SOAP proxy to call the Binary objects,
thus allowing ANY application that needs the services of the business layer
to call it, without it being created at the same time by the same team.

The elements of discoverability and the ability to see and debug information
flowing over the network, is important in that case, even though the
interface was not originally developed for those needs. Clearly the proxy
can be developed on an as-needed basis. However, the cost of developing a
small integration object of this kind is low compared to the cost of
developing integration code that has to cross binary boundaries, especially
if the calling environment is not .Net or Windows.

HTH,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

The only thing the SOAP formatter is useful for is to be able to look

at
the message structure on the wire when debugging.

Personally I think they shoiuld delete it from the framework - I have

never, in production, used the SOAP formatter its slower and adds no benefit

HTTP/Binary is just as firewall friendly as HTTP/SOAP unless the

firewall
is using content based filtering (which very few do in my experience).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

No firewall hassle?

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
SLODUG - Slovene Developer Users Group
www.rthand.com

Hi,
I unerstand that if you choose IIS to host your .Net Remoting components
with HTTP channel and SOAP formatter, you get the built-in security and
configuraion features of IIS. Also we can expose it to use for the web
services clients. But using HTTP with SOAP has got the least performance
amoung all others (ex TCP with Binary etc).

The question is what are the advantages of using http with SOAP over http
with Binary formatter?
What are the other benifits of using IIS with http and SOAP?

Pankaj


User submitted from AEWNET (http://www.aewnet.com/)





--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005



[microsoft.public.dotnet.languages.csharp]