Sorry to beat a dying horse, but in the absence of a high performance,
x-copy queue for both ends of the wire (sounds like there might be one
in development a-la Berkeley DB, but I couldn't find it on Google or
Los Techies or anything) would this work from a scalability and
performance perspective?:
Have an interface along the lines of IDurableMessageCache that can be
injected into an instance of INonDurableTransport:ITransport, and on
the smart-client side of the wire, where presumably durable message
volume will be relatively moderate, you could provide an
implementation IDurableMessageCache using either a local database,
like Sql Mobile, or whatever the smart client is using for its own
persistence, to keep a copy of all messages until they are sent. If
the smart client has no local database, then you could use the file
system, but the idea is that the message store has the same deployment
requirements as the app itself. Then on the server side where you
could potentially be talking to thousands or more such clients via a
non-durable transport and you could void wheel reinventing and use
your enterprise queue similar to how it is used in the Subscription
Storage - as a transactional, high performance disk queue, but instead
of using the transport built into or used by the queuing technology,
you just use it as storage, removing messages manually from the queue
only once a message has been successfully transmitted by the
non-durable transport. I'm sure it sounds like overkill to you guys,
but we are really nervous about dealing with supporting MSMQ at remote
locations on customer computers we have no IT control over, yet at the
same time durable messaging enables the simplification of many
disconnected-client scenarios by orders of magnitude and it would too
bad to have to give it up. Anyway, does such an approach have any
hidden gotchas?

--- In nservicebus@yahoogroups.com, "Nathan Stults" <hereiam@...> wrote:
>
> Sorry about the "you guys" - didn't see the Evan Hoff bit, I
thought maybe
> it was part of MT - in any case, is that project available, or in its
> infancy?
>
> I get the point about re-creating a queue, but what existing queue
for .net
> can be one-click deployed, for instance. It really doesn't sound like it
> should be that big of a deal to throw some messages into a local
database or
> onto a disk and pull them out and send them when and if an endpoint
restarts
> with unsent messages. We're only talking about communication with
endpoints
> outside the firewall anyway using a non-durable transport, and even then
> only about the subset of messages that need to be durable - the
scalability
> and performance requirements aren't the same as they are for the primary
> transport processing back end transactions. Really, you only need this
> "feature" on some client endpoints where it might be cumbersome to
install
> and manage a more heavyweight queue. Easy deployment and durable
messaging
> remote nodes ought to be an eatable, keepable cake.
>
>
>
> From: nservicebus@yahoogroups.com
[mailto:nservicebus@yahoogroups.com] On
> Behalf Of Chris Patterson
> Sent: Monday, June 30, 2008 2:06 PM
> To: nservicebus@yahoogroups.com
> Subject: Re: [nservicebus] Re: Best transport for internet?
>
>
>
> Yep, using Berkeley DB for the backend storage, making it remain
> xcopy-deployable.
>
>
>
> On Mon, Jun 30, 2008 at 4:03 PM, Ayende Rahien <Ayende@...> wrote:
>
> Evan Hoff is doing it
>
>
>
> On Tue, Jul 1, 2008 at 12:00 AM, Udi Dahan <thesoftwaresimplist@...>
> wrote:
>
> > My point is that at this point, you are writing a queuing service, no?
>
>
>
> Yeah, yeah.
>
> How hard could it be? <wink />
>
>
>
> --
>
> Udi Dahan - The Software Simplist
>
>
>
> From: nservicebus@yahoogroups.com
[mailto:nservicebus@yahoogroups.com] On
> Behalf Of Ayende Rahien
> Sent: 30 June 2008 23:55
>
>
> To: nservicebus@yahoogroups.com
> Subject: Re: [nservicebus] Re: Best transport for internet?
>
>
>
> My point is that at this point, you are writing a queuing service, no?
>
> On Mon, Jun 30, 2008 at 11:45 PM, Udi Dahan <thesoftwaresimplist@...>
> wrote:
>
> Hmm, let's see - supporting ACID transactions, what existing proven
> technology does that?
>
>
>
> --
>
> Udi Dahan - The Software Simplist
>
>
>
> From: nservicebus@yahoogroups.com
[mailto:nservicebus@yahoogroups.com] On
> Behalf Of Ayende Rahien
> Sent: 30 June 2008 23:37
> To: nservicebus@yahoogroups.com
> Subject: Re: [nservicebus] Re: Best transport for internet?
>
>
>
> At that point, you are likely to want to have transactions there as
well,
> no?
> Aren't you recreating a queue service then?
>
> On Mon, Jun 30, 2008 at 11:23 PM, Nathan Stults <hereiam@...> wrote:
>
> Yes, but the queue is in memory. Any reason not to have (as a pluggable
> service) a simple but persistent message storage that doesn't
require any
> special installation, is transport independent and can be switched
on for
> any non-durable transport, HTTP, UDP, named pipes, WCF, whatever. I
don't
> suppose the actual wire protocol makes much difference. Such a feature
> wouldn't require most of the stuff in a real queue because the wire
> transport isn't part of the equation, just simple, transactional (or
not)
> persistent storage for transient messages. (I realize this is
essentially
> the BizTalk "message box" concept, but much less involved, and you would
> only use it for endpoints that need to emphasize deployment
flexibility).
>
>
>
> No virus found in this incoming message.
>
>
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date:
30/06/2008
> 08:43
>
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date:
30/06/2008
> 08:43
>