Udi,

I hope my explanations didn't come off as negative in regards to NSB.  It's
a great tool and you are personally extremely helpful.  I have very few
complaints about NSB itself; I'm just comparing features and performance
between all of the .NET ESB tools and trying to learn as much as I can about
each.

-tyler

On Fri, Jul 31, 2009 at 2:11 AM, Udi Dahan <[email protected]>wrote:

>
> I think it's great you're exploring all options - I myself learned a
> lot from Rhino Service Bus and Mass Transit. For example, the
> exceptions which are thrown when a subscription message arrives at an
> endpoint without a subscription storage were inspired by RSB and the
> new saga finding API is inspired by MassTransit:
>
>        public override void ConfigureHowToFindSaga()
>        {
>            ConfigureMapping<OrderMessage>(s => s.PurchaseOrderNumber,
> m => m.PurchaseOrderNumber);
>            ConfigureMapping<CancelOrderMessage>(s =>
> s.PurchaseOrderNumber, m => m.PurchaseOrderNumber);
>        }
>
> Personally, I've found only good things coming out of this cross-
> pollination.
>
> The pain points you've described are things we've been feeling too and
> have taken concrete steps on the trunk to address them which should be
> coming out in a formal release in the next month or two. They're
> currently stable on the trunk and available to download from the
> continuous integration server via the download page:
> http://www.nservicebus.com/Downloads.aspx
>
> In terms of xcopy deployment, what we've done is include code which
> automatically at startup installs MSMQ if it's not there, configures
> it correctly, starts the windows service if its not running, and the
> same is true of the DTC (which RSB depends on as well, as far as I can
> tell).
>
> We're also being a lot more cognizant about internalizing any 3rd
> party components we merge so that there won't be any versioning
> conflicts. For this reason, the castle container adapter will not be
> merged in NServiceBus.dll.
>
> Let me just end with a little apology to others on the list for
> barging in - just wanted to make sure all the facts were out on the
> table.
>
> With thanks,
> Udi Dahan
>
>
> On Jul 31, 5:29 am, Tyler Burd <[email protected]> wrote:
> > That's what I'm looking at now, but I am working around it by subclassing
> > the consumer at runtime for each class that implements the message
> interface
> > and adding that subclass to the container.  I haven't really dug deep,
> but
> > it seems like that will work.
> >
> > My reasons for switching:
> >
> >    1. Exploring all options.
> >    2. I really like the xcopy deployment and easy configuration of rhino
> >    queues.
> >    3. Upgrading to the latest version of NSB is a bit painful (I'm
> compiling
> >    Castle, NH, rhino, and NSB from the trunks), and since I already use
> rhino
> >    there is an opportunity to cut down on that work.
> >    4. The single-assembly, ilmerged NSB is a headache when we already
> have
> >    projects that reference castle, NH, and other libraries explicitly.
> >
> > Thanks, Ayende!
> >
> > On Thu, Jul 30, 2009 at 8:09 PM, Ayende Rahien <[email protected]>
> wrote:
> > > Oh,And what are your reasons to move from NSB to RSB?
> >
> > > On Fri, Jul 31, 2009 at 5:09 AM, Ayende Rahien <[email protected]>
> wrote:
> >
> > >> Tyler,No, RSB doesn't support this right now.
> > >> It should be pretty easy to patch, though. Take a look at
> > >> DefaultServiceBus.GatherConsumers()
> >
> > >> On Fri, Jul 31, 2009 at 1:44 AM, tyler.burd <[email protected]>
> wrote:
> >
> > >>> Hi there.  I'm converting an application from NServiceBus to Rhino
> > >>> Service Bus, and I'm hung up on one thing.  In NSB you can create a
> > >>> MessageHandler that handles an interface.  Something like this:
> >
> > >>> public class MySpecialMessageHandler :
> > >>> IMessageHandler<IAmASpecialMessage>
> >
> > >>> NSB then calls this handler whenever it receives a message that
> > >>> implements the "IAmASpecialMessage" interface.  I can't recreate this
> > >>> behavior in RSB.  I tried the following:
> >
> > >>> public class SpecialMessageConsumer : ConsumerOf<ISpecialMessage>
> > >>> {
> > >>>        public void Consume(ISpecialMessage message)
> > >>>        {
> > >>>                Console.WriteLine(string.Format("Consumed message of
> type
> > >>> : {0}",
> > >>> message.GetType().Name));
> > >>>        }
> > >>> }
> >
> > >>> public class MySpecialMessage1 : ISpecialMessage {}
> > >>> public class MySpecialMessage2 : ISpecialMessage {}
> >
> > >>> //code to initialize RSB and a windsor container
> > >>> container.AddComponent<SpecialMessageConsumer>();
> > >>> bus.Start();
> > >>> bus.Send(bus.Endpoint, new MySpecialMessage1());
> > >>> bus.Send(bus.Endpoint, new MySpecialMessage2());
> >
> > >>> This never results in a message being consumed, and the log shows
> > >>> "ERROR - Got message RsbTest.MySpecialMessage2, but had no consumers
> > >>> for it"
> >
> > >>> Is this possible?  Is there another way to handle this?
> >
> > >>> Thanks!
> > >>> -tyler burd
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to