Guys,

I am considering using remoting instead of webservices for a distributed app. How many of u use remoting and on what kind/size of project? Number of clients connecting to server etc... I havent used to many apps that use remoting that i know of.

I suppose i could also make a webservice facade for non .NET clients?

Non .NET Clients should use web services. Remoting should be used when your writing .NET to .NET Apps and the clients are on the same network as the services otherwise you will run into some challenges.

COM+ relies on DCOM / COM technology so even if you write managed objects, you must still conform to COM specifications. The ServicesComponent class actually derives from MarshalByRefObject so when leveraging enterprise services in .NET you will actually be using remoting. Using COM+ has its pros and cons as well, i.e. just in time activation, object pooling, and distributed transaction processing just to name a few. However, if your application doesnt need to leverage these features, web services or remoting might be a better choice.

There really isnt a good way to answer your question. The choice in technology really depends on you operational requirements.

Thanks for your response DevilDog!

I am creating basically an inventory management application. This app will be used internally for a while but as it progress i may wish to sell it commercially. If it works good then there is a real good chance i will sell it to other businesses. I plan on making use of plugins so i can adapt the app to different scenarios as each business is a bit different.

I want it to be client/server with the server being some type of layer that talk to the DB. I do not want my clients talking directly to the DB. I also which to do some processing on the server. So now i enter the world of Distributed computing which i have little or no experience. COM is out, i do not want to use it. So its either Remoting or Webservices.

Now, MS recommends to use webservices over remoting unless a few circumstances. which i really dont fit into ( i don't think anyway ). Obvisouly LLBLGen will cut down on my time dramatically over using datasets. Hence i am torn on using llblgen, which at this moment appears i must use remoting (At least until Whidbey beta 2 comes out?) or using datasets in which case i would go either way. I could also use custom objects, but i dont see much need to if using webservices, i think dataset would be better and its lots less work.

So i am getting somewhat conflicting advice. Could you elaborate on what problems i might encounter with webservices. Becuase from my LIMITED experience they seem the way to go. They scale well and i can use IIS and all of its services. Remoting seems cool cuase i can make a service frontend for the app running on the server.

Drawbacks to web services are that they are typically slower than remoting & COM+ communication due to serialization and what not. Also, web services will not raise an event back to the client. There are some considerations that you will need to account for when using llblgen entities over web services that have to do with how llblgen objects are serialized over web services. Frans can elaborate more, but basically you have to work with xml strings in the web method and then turn the xml string into a llblgen object (I think)

By the time you are ready to make your product available commercially (if that event even comes to pass) we'll have Indigo and you'll be reevaluating your technology choices anyway.

Good point Jim

It appears that in Whidbey Beta 2 (or any beta actually) we should be able to use webservice with LLBLGen entities as they now implement IXmlSerializable. But its untested and i havent tried it yet as beta 2 still hasnt come out

Devildog74 wrote:

Drawbacks to web services are that they are typically slower than remoting & COM+ communication due to serialization and what not.

Remoting also uses serialization. The XmlWebservices can be faster if you use solely simple types, in that case the XmlSerializer generates code which hardcoded writes Xml for a given type, which is faster than the dynamic soap serializer code.

Though it doesn't beat DCOM in a COM+ scenario which is so much faster, you'd wonder why on earth you'd even consider .NET.

Also, web services will not raise an event back to the client. There are some considerations that you will need to account for when using llblgen entities over web services that have to do with how llblgen objects are serialized over web services. Frans can elaborate more, but basically you have to work with xml strings in the web method and then turn the xml string into a llblgen object (I think)

That's indeed correct. In 1.0.2004.2, I've made the routine produce less verbose XML which is wrapped in an implementation of IXmlSerializable, so the developer doesn't have to use XmlNode's anymore. It's wise to return an XmlNode btw, which is faster than a string (according to MS).