dotnet remoting: Dear all,

I am building a 3 tiers application under .NET 2.0. This application is
based on different library ore compoenent which ahve there own purposes. At
first this application will run on a local machine but in order to get a
future vision I could imagin that layers can be split anywhere else.

On big issu of my application is that I need to handle asynchronous message
between as OEM application and my own .net libraries. The big question that I
have is how to handle thos asynchrone message:

Fist by having a kind of service which initilise MSMQ's and each application
place it own mesage in the queue ?

Second, use .NET remoting asynchrounous delegates ?

Which one is more appropriate ?

As a result I guess that MSMQ creation should be nade by a different
component, it can be a windows service based on a COM+ served component ?

Thanks to clear up my mind
regards

Hi Calderara

I have just recently posted a related question on MSDN forum you might be
interested in.
(http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1448168&SiteID=1)

In order to qualify an answer to your question however, you have to really
decide your primarily objective. MSMQ is great for messaging; but if you want
your various tiers to use callbacks, events, or any form of RPC (Remote
Procedure Call), then I'd definitely stick to .NET Remoting.

In terms of asynchronous messaging, I believe both technologies are able to
do it; its just their tweaks will be different. With MSMQ, you would have two
queues one for receiving the initial call, and the other for a return value
(or callback).

On the Remoting side of the fence, .NET will take care of the actual
serialization and deserialization of the object for you. Hence it is a lot
easier to handle objects and delegates such as callbacks, events, etc.

So I guess it all boils down to your primarily objective and design. From
experience I would suggest designing your application so that one tier is
telling another tier to "do something", by providing all the data it will
need - rather than "asking" to do something, with the possibilities that
additional data may be required. In this way, each tier can be completely
independant of the other, and subsequent future updates may be made without
worry that each tier won't play nicely together.

Regards,
Kel


[quoted text, click to view]