Ayende @ Rahien

kamil commented on Rhino Service Bus

Sun, 18 Jan 2009 10:26:46 GMT

Hi Ayende I thing that you should read XmlIgnoreAttribiute on porperties, becouse in packet i have same read only properties:) Regards

Ayende Rahien commented on Rhino Service Bus

Mon, 12 Jan 2009 16:29:57 GMT

There is a patch to make it run on MSMQ 3.0 It was applied, so now it will automatically choose the appropriate version to use.

lars kolsaker commented on Rhino Service Bus

Mon, 12 Jan 2009 16:28:28 GMT

Hi Ayende You answered Steve that it is possible to run on Windows 2003, but MSMQ 4.0 requires Vista or Win2008, doesn't it ?

Ayende Rahien commented on Rhino Service Bus

Tue, 30 Dec 2008 14:50:49 GMT

1) you can host it with any app, Window Service is the preferred mode, though. The is no WCF involved. 2) Yes

Steve commented on Rhino Service Bus

Tue, 30 Dec 2008 13:54:04 GMT

Thanks Ayende, I have gone through the tests, the sample app - I like it. Some questions: 1. How do I host this? ie. On the server, would I (as one option), create a windows services that listens to the queue ? A WCF service that listens to a queue, etc... ? What are your recommendations on hosting this message bus ? 2. Can it be run on Windows 2003 ?

Ayende Rahien commented on Rhino Service Bus

Sat, 27 Dec 2008 12:02:50 GMT

The mailing list for that is rhino tools dev. The problem is that NH register the session for the DTC transaction, but it is not defering disposal properly the way it should

Hadi commented on Rhino Service Bus

Sat, 27 Dec 2008 11:51:26 GMT

Ayende, Sorry to post in here. I didn't know of any existing mailing list for Rhino Bus. any reason NHibernate transactions failing in a consumer class? the following snippet should show the failure : public class ShipmentSaga : ConsumerOf = PackageLimit; } } } guess it has something to do with ambient transactions. here's the exception message : Disconnect cannot be called while a transaction is in progress. at NHibernate.AdoNet.ConnectionManager.Disconnect() in c:\code\NHibernate\nhibernate\src\NHibernate\AdoNet\ConnectionManager.cs:line 156 at NHibernate.AdoNet.ConnectionManager.Close() in c:\code\NHibernate\nhibernate\src\NHibernate\AdoNet\ConnectionManager.cs:line 122 at NHibernate.Impl.SessionImpl.Close() in c:\code\NHibernate\nhibernate\src\NHibernate\Impl\SessionImpl.cs:line 314 at NHibernate.Impl.SessionImpl.Dispose(Boolean isDisposing) in c:\code\NHibernate\nhibernate\src\NHibernate\Impl\SessionImpl.cs:line 1373 at NHibernate.Impl.SessionImpl.Dispose() in c:\code\NHibernate\nhibernate\src\NHibernate\Impl\SessionImpl.cs:line 1349 at ESB.Services.Saga.ShipmentSaga.HasEnoughOrders() in E:\projects\NET\ESBTests\ESB.Services\Saga\ShipmentSaga.cs:line 53 at ESB.Services.Saga.ShipmentSaga.Consume(NewOrder orderMessage) in E:\projects\NET\ESBTests\ESB.Services\Saga\ShipmentSaga.cs:line 31 Regards >

Ayende Rahien commented on Rhino Service Bus

Tue, 23 Dec 2008 15:57:32 GMT

Jan, The starbucks example isn't done yet.

Jan Stenberg commented on Rhino Service Bus

Tue, 23 Dec 2008 11:23:49 GMT

Ayende, I have some problem running the Starbuck Sample, I get an Exception in DefaultServiceBus.PersistSagaInstance when it tries to resolve the persister type. Should I add something in Program.Main or in the two config files? Regards, Jan

Nathan commented on Rhino Service Bus

Sat, 20 Dec 2008 05:39:32 GMT

Very cool. Looking forward to digging deeper into this. You and Udi seem to have such a good relationship full of deep mutual respect - I'm surprised that there wasn't some sort of collaboration possible. Maybe someday. To me, combining Udi's depth of understanding of all things SOA / EDA and message oriented with your grasp of framework design would yield something really beautiful. Not to say this effort won't reach that on its own, it's just that I'd also love to see NSB taken to the next level as well, saving us one more service bus to evaluate :) One possibly stupid suggestion, but I'll make it anyway: I wonder if a common messaging API couldn't be negotiated, in the same way that was done for the IoC's - so that as the future begins to demand that all of our components become capable of participating in asynchronous messaging, we can easily delay final framework selection until the very end, or have the capability to build messaging aware components that can defer the decision to end users.

Ayende Rahien commented on Rhino Service Bus

Fri, 19 Dec 2008 15:17:41 GMT

Rewrite history? I don't think that I understand. I don't think that you should make a choice without having context to apply it in. In this case, I had a very specific idea in mind of what I wanted, and I was not able to modify the existing service bus projects to meet what I wanted. Trust me, I tried them both, and I run into differences from what I considered ideal to the context I was in. As it is a limited scope and size, I decided that I can take the time to produce something that would fit the bill, instead of having to do with something that was merely close. I made the comment in DNR that you should choose the infrastructure that you want to fit what you need, not the other way around, and that it is REALLY easy to create infrastructure in a way that allow you to match a single scenario. It is taking this from single scenario to full blown implementation that can cover all scenario where the problem arise. One day or three months, there isn't anything in between. And if you know someone who will pay for doing those things, I am all for rebuilding them, properly. You can check a series of posts that I did early this year and toward the end of the last one, talking about "a vision of enterprise platform". I have seen, first hand, the amount of money, time and effort that went into trying to repurpose crappy tools to do things that they weren't suitable to do (often the very thing that they were sold as being able to do!) I am not willing to accept a state of painful neglect when I am capable and willing to FIX the bloody thing. (the last statement refer to MS CRM, SharePoint and NAvision, not to NSB or MT).

Bil Simser commented on Rhino Service Bus

Fri, 19 Dec 2008 15:06:36 GMT

Dude, don't me wrong, you're aces in my books and I think this effort rocks but seriously, you seem to always rewrite history in 1000 lines of code or less. I think the comment we made before (during drinks at DevTeach or something) was that given enough time, Oren could rewrite every MSFT POS using 10% the codebase and 100% code coverage. So what's the message you're sending out here for some of these projects? nServiceBus and Mass Transit are nice but use Rhino bus because it's lean and simple. I'm all for simplicity, but should we just sit around until you feel some pain on an app and rewrite it in 4 days? Can we unleash you on OreNavision or RhinoPoint and get some real code going. Sorry if I seem sarcastic this morning, it's that time of the month. We'll hook up some day on the phone and all will be well in the universe.

Ayende Rahien commented on Rhino Service Bus

Thu, 18 Dec 2008 22:39:02 GMT

I am making the assertion that web request don't wait for external resources, yes. If we need to contact external system, they will have to retry the request.

Chris Ortman commented on Rhino Service Bus

Thu, 18 Dec 2008 20:50:14 GMT

Udi's article is here in case someone needs it [www.infoq.com/.../async-high-perf-login-web-farms](http://www.infoq.com/articles/async-high-perf-login-web-farms) Are you assuming then that any POST to the webserver that would actually need to wait for the reply is going to have to use ajax?

Ayende Rahien commented on Rhino Service Bus

Thu, 18 Dec 2008 20:11:54 GMT

No, take a look at the way Udi describe async login process. It publish a message and tell the UI to call back to it in a bit, at which point it will have the answer

Chris Ortman commented on Rhino Service Bus

Thu, 18 Dec 2008 20:09:14 GMT

Does using pub / sub automatically imply you are asynchronous? How would you implement something ValidateAddress in an external system if you were building a webapp... something like Browser sends POST to web app to create new account WebApp PUBLISH ValidateAddressMessage WebApp blocks until message comes back?

Ed McPadden commented on Rhino Service Bus

Thu, 18 Dec 2008 05:05:08 GMT

Great stuff! In a previous consulting assignment (in 2004) I helped build and design an Xml message bus, it worked with TCP/IP socket connections to a central bus. The bus was in C++ and the clients in C#. I like the MSMQ approach much better. We created our own client-side proxies that essentially looked like web service proxies and allowed developers to code against them like they were local services. Once nice feature we had was that our proxies had events that would get fired when a notification message was sent out that the endpoint subscribed to. In fact, the act of hooking up the event would do the actual subscription for that event (for the first handler that was hooked up) and unsubscribe when the last handler was disconnected. When an endpoint would come up, it would broadcast a message that would tell all other endpoints what messages it could handle, then broadcast a request to ask other endpoints to send to it what messages they could handle. The bus itself would broadcast messages when any endpoint disconnects. That way each endpoint would always have a self maintaining list of the endpoints it cared to talk directly to. It enabled plug and play across a dynamic set of endpoints. Also, multiple endpoints could be set up to handle the same message which had nice fail over ability. The thing we would get criticized for was the whole single point of failure of the bus itself. Not sure that we ever were able to overcome that. Its difficult to have failover on the bus itself without having serious performance problems. I think that what you have here is very compelling and gets at the heart of what you want a bus to do. Thanks for this very enlightening post!

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 17:15:54 GMT

1) part of the transport, you can encrypt / sign messages 2) [ayende.com/.../...s-conversation-saga-message.aspx](http://ayende.com/Blog/archive/2008/11/06/messaging-concepts-conversation-saga-message.aspx)

Corey commented on Rhino Service Bus

Wed, 17 Dec 2008 17:11:20 GMT

1. How does security fit in? 2. Do you know of a good resource to understand Sagas better? I tried google and unfortunately didn't yield very applicable results. Your unit tests got me close, but I feel like I'm missing parts of the overall picture.

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 17:03:41 GMT

You are missing the difference between an existing subscription and a live handler. If the handler is down, we don't care. It will go up at some point. The important part is that we know that we need to send a messga to it

Mark Nijhof commented on Rhino Service Bus

Wed, 17 Dec 2008 17:01:17 GMT

But how about the scenario that there is a new order and the order handler is down, I would have liked to be able to put the message in the queue and have the order handler handle it when it comes back up? So how would I deal with this I also would not like my order creator to have to deal with the fact the order handler is not available? Or am I thinking wrongly about this scenario? -Mark

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 16:34:26 GMT

Because there is a distinction about it. If I publish a message about new order, I _really_ want to know it is not going into the void.

Mark Nijhof commented on Rhino Service Bus

Wed, 17 Dec 2008 16:23:54 GMT

This is very cool! Incredible time to market :) I have a question: What is the main reason why you would want to make a distinction between Publish or Notify? I mean why do you want to make publisher care / aware to the fact that nobody is reacting on their publishes? And is there a way that the code can check if there are subscribers before using Publish? -Mark

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 15:28:55 GMT

No, send means just that, put that message in the associated message queue. There is no reply going on. The return of this is void.

Pawel Pabich commented on Rhino Service Bus

Wed, 17 Dec 2008 15:24:17 GMT

"Send == send to the owner of this message", isn't it Request/Replay? I see you associate a queue with a group of messages which lets you have multiple input queues.

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 15:06:48 GMT

Because you often want to send, not to publish. Send == send to the owner of this message. The url is to let the bus know what the end point is, so it can start listening to it.

Ayende Rahien commented on Rhino Service Bus

Wed, 17 Dec 2008 15:04:24 GMT

ason, Tell me how you find it after taking this to a test drive

Jason Motylinski commented on Rhino Service Bus

Wed, 17 Dec 2008 14:42:32 GMT

We were just evaluating NServiceBus and Mass Transit as well but were struggling with the over-complexity of those frameworks. This appears much more straight forward and simple. I hope it will meet our need. Thanks for the code.

Pawel Pabich commented on Rhino Service Bus

Wed, 17 Dec 2008 14:31:09 GMT

If I understand correctly you are saying that you want encourage people to use publish/subscribe type of messaging. If so then why do you need Send method? It's not clear to me why do you need "msmq://localhost/test_queue" queue.

Colin Jack commented on Rhino Service Bus

Wed, 17 Dec 2008 13:31:38 GMT

@Ayende OK ta, we're thinking of using either your solution or MT/NSB and then wrapping whichever we do use in a project specific API anyway. Whether this works, who knows...