Hi folks
I am in the process of developing a .net distributed app that will have a SQL Server back end.
I have a basic knowledge of building Web Services but virtually nothing on using Remoting. The app will eventually be deployed to a intranet & will be accessed from various offices around Australia.
I have heard that there are certain advantages in using Remoting rather than Web Services under certain circumstances, although (I am told) that Web Services are better if interoperability with other apps (such as Java) is important.
I was rather hoping that somebody could explain in fairly simple terms the pros & cons of each approach.
Kind regards
Ross
Web Services vs Remoting in .netPro's & Con's of Web Services & Remoting
Page 1 of 1
1 Replies - 2152 Views - Last Post: 08 February 2006 - 04:57 PM
Replies To: Web Services vs Remoting in .net
#2
Re: Web Services vs Remoting in .net
Posted 08 February 2006 - 04:57 PM
Well, I'm not sure to what level you'd like to go into...varying people have their own opinion on whether to go with remoting versus services.
I suppose the biggest determing factor is state management. Web Services are stateless by design...if you need to maintain a state, or correlate object calls from the same client, Web Services are a little tricky...you can maintain the state with Services, but you'd have to use the Session or Application properties to do so...with Remoting, you have a variety of options for State Management. A good example would be something like an IM client...both client machines have to be running the app, and therefore you need to maintain a state, and coordinate between the two. Remoting is a better answer here.
The old knock against Services was that they are far slower than remoting, but with .NET 2.0 coming out, they are about the same, at least on the HTTP side of things (Remoting is still faster with regards to TCP transmission).
There are a lot of reasons to go with one over the other...two good articles on the subject can be found here and here. In the end, the choice is yours...it depends on the application. If you need greater functionality, like running a lot of object methods on the server, many prefer remoting, but Web Services provides a much greater interoperability with other OSs...
Decisions decisions!
I suppose the biggest determing factor is state management. Web Services are stateless by design...if you need to maintain a state, or correlate object calls from the same client, Web Services are a little tricky...you can maintain the state with Services, but you'd have to use the Session or Application properties to do so...with Remoting, you have a variety of options for State Management. A good example would be something like an IM client...both client machines have to be running the app, and therefore you need to maintain a state, and coordinate between the two. Remoting is a better answer here.
The old knock against Services was that they are far slower than remoting, but with .NET 2.0 coming out, they are about the same, at least on the HTTP side of things (Remoting is still faster with regards to TCP transmission).
There are a lot of reasons to go with one over the other...two good articles on the subject can be found here and here. In the end, the choice is yours...it depends on the application. If you need greater functionality, like running a lot of object methods on the server, many prefer remoting, but Web Services provides a much greater interoperability with other OSs...
Decisions decisions!
Page 1 of 1
|
|

New Topic/Question
Reply



MultiQuote



|