Web Services vs. Remoting Hosted In IIS - Pros/Cons Whats the difference?

[Lucas Tam]

Does anyone have a good articles that describes the pros and cons of Web
Services vs. Remoting Hosted in IIS?

Is there a reason to use either or?

With Remoting Hosting in IIS, is it possible to maintain a constant thread
(i.e. thread that polls the database and sends messages back to client when
a certain record is found?).

Thanks.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Reza Alirezaei]

The First question which come to my mind is that,what type of Clients are
you addressing? Are they pure DotNet sort of clients or a combination of
different platform would be served by your service layer?

The second question is that Is speed an issue or not? How about the
security? Web services are still in evloving peroid,but they are
platform-nuatral where remoting is more bound to DotNet.

HTH,
Reza
http://blogs.devhorizon.com

"Lucas Tam" <RE********@rogers.com> wrote in message
news:Xn***************************@127.0.0.1...

Does anyone have a good articles that describes the pros and cons of Web
Services vs. Remoting Hosted in IIS?

Is there a reason to use either or?

With Remoting Hosting in IIS, is it possible to maintain a constant thread
(i.e. thread that polls the database and sends messages back to client
when
a certain record is found?).

Thanks.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Lucas Tam]

"Reza Alirezaei" <ra********@nospam.com> wrote in
news:O1**************@TK2MSFTNGP14.phx.gbl:

The First question which come to my mind is that,what type of Clients
are you addressing? Are they pure DotNet sort of clients or a
combination of different platform would be served by your service
layer?
Primarily .NET clients. However, it *would* be nice for the interface to
be totally generic... but I don't see that happening.

I could abstract a lot of the features into a DLL, then build both a Web
Service and a Remoting interface.

The second question is that Is speed an issue or not? How about the
security? Web services are still in evloving peroid,but they are
platform-nuatral where remoting is more bound to DotNet.

Yes, speed is important, I'll be transferring live information back and
forth between the client/server. Security too - come to think of it,
hosting in IIS would be nice since I can secure it via SSL + password
authentication.

Does remoting in IIS support two way communications? I've built regular
remoting apps (standalone) but never in IIS.
--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Reza Alirezaei]

Lucas,

Primarily .NET clients. However, it *would* be nice for the interface to
be totally generic... but I don't see that happening.
As you mentioned ,a combination of a webserice and a remoting interface in
client side will do.Even if later you need to make newer versions of your
assembly ,then no problem ,you can use a technique called assembly binding
redirect
(http://msdn.microsoft.com/library/de...edirection.asp)
to make sure that your clients are always pointing to the newest version of
your remoting objects.
Yes, speed is important, I'll be transferring live information back and
forth between the client/server. Security too - come to think of it,
hosting in IIS would be nice since I can secure it via SSL + password
authentication.
You can always use the BinaryFormatter with HttpChannel to serialize your
objects into binary format (I think it is an alternative to using TCP ports
in *pure* Remoting apps(Not hosted in IIS)). This might gives you a heads up
to choose your path
better:http://msdn.microsoft.com/library/de...stingInIIS.asp
Does remoting in IIS support two way communications? I've built regular
remoting apps (standalone) but never in IIS.
I guess for any remoting app ,the first thing you need to choose is a
channel.The choice is HttpChannel or TcpChannel or probably your own
channel.AFAIK both of these channels implement IChannelReceiver and
IChannelSender which means that there is a two way communication in both.The
only thing you got to do is to hook up your objects appropriately to the
channels and everything should be fine.

Have you had the chance to look at WSE 2.0?

Hope this helps,
Reza
http://blogs.devhorizon.com


"Lucas Tam" <RE********@rogers.com> wrote in message
news:Xn***************************@127.0.0.1... "Reza Alirezaei" <ra********@nospam.com> wrote in
news:O1**************@TK2MSFTNGP14.phx.gbl:

The First question which come to my mind is that,what type of Clients
are you addressing? Are they pure DotNet sort of clients or a
combination of different platform would be served by your service
layer?

Primarily .NET clients. However, it *would* be nice for the interface to
be totally generic... but I don't see that happening.

I could abstract a lot of the features into a DLL, then build both a Web
Service and a Remoting interface.

The second question is that Is speed an issue or not? How about the
security? Web services are still in evloving peroid,but they are
platform-nuatral where remoting is more bound to DotNet.

Yes, speed is important, I'll be transferring live information back and
forth between the client/server. Security too - come to think of it,
hosting in IIS would be nice since I can secure it via SSL + password
authentication.

Does remoting in IIS support two way communications? I've built regular
remoting apps (standalone) but never in IIS.
--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/