Ayende @ Rahien

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Thu, 08 Dec 2011 08:18:08 GMT

Cocowalla, You need to look at the Protocol directory, this is where most of the transport stuff is happening. Basically, you need to change that from a push model to a pull model

cocowalla commented on Setting up a Rhino Service Bus Application: Part I

Wed, 07 Dec 2011 18:34:52 GMT

@Ayende I'm not that familiar with the RSB or RQ code bases, so it seems a bit of a daunting task - any pointers on where to start?

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Sun, 04 Dec 2011 12:42:44 GMT

Cocowalla, It shouldn't be very hard, but it isn't something that RQ is doing right now.

cocowalla commented on Setting up a Rhino Service Bus Application: Part I

Sat, 03 Dec 2011 12:52:35 GMT

@Ayende I'd rather not have an open port listening on the clients if it can be avoided. Is there no facility to have the client receive subscription notifications over the same channel (in callback fashion), so the client doesn't have to listen on a port? So the client would establish an outbound connection to the server and that connection would be kept open and used for callbacks from the server?

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Thu, 01 Dec 2011 10:47:24 GMT

cocowalla, No, those are two independent channels

cocowalla commented on Setting up a Rhino Service Bus Application: Part I

Thu, 01 Dec 2011 10:45:38 GMT

Let's say I'm using Rhino Service Bus with Rhino Queues, and I have a server application on one side of a firewall, and a client application on the other. Would I be correct in assuming that, when using Rhino Queues, I only need to open an outgoing firewall port from the client to the server (that is, any responses would use an existing connection)?

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Thu, 01 Dec 2011 07:15:00 GMT

Jean, That is pretty much the same as far as this config is. The IT guys have to enable the connection, but that is pure IT work (enabling MSMQ over HTTP)

jean-philippe commented on Setting up a Rhino Service Bus Application: Part I

Thu, 01 Dec 2011 06:15:55 GMT

What is the configuration story when you have a heavily firewalled endpoints living in the DMZ and backoffice networks and all you have is port 80/443 for communication?

Please commented on Setting up a Rhino Service Bus Application: Part I

Thu, 01 Dec 2011 05:17:23 GMT

@Nick, please..

JV commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 15:59:27 GMT

Just want to take the opportunity to say we have been using RSB in production for several years. It is rock solid. Thank you, Ayende.

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 13:30:01 GMT

Daniel, Thanks :-) Fixed

Ayende Rahien commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 13:29:18 GMT

Krzysztof, I don't think that this is really that bad, honestly. I think that once you get the idea about consumers, it is pretty simple from a tech standpoint. But the major hurdle is with architectual view of the thing

Corey commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 12:37:55 GMT

There are plans for v3 for you to be able to define your own conventions and do auto-wiring. Even the ConsumerOf is a bit ceremonial and I hope to introduce conventions for as wel.

Nick commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 12:31:07 GMT

this made me laugh "Oh, yeah, that would be me. Maybe I ought to fix that."

Daniel Lang commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 11:22:04 GMT

There is a typo - the nuget-package ist "Rhino.ServiceBus.Castle" instead of "Raven.ServiceBus.Castle". Yeah! Ravens vs. Rhinos!

Krzysztof Kozmic commented on Setting up a Rhino Service Bus Application: Part I

Wed, 30 Nov 2011 10:12:38 GMT

The ... part is IMO confusing, NServiceBus suffers from the same problem - there's nothing intuitive about it, and unless you know that name is actually a name of an assembly holding your messages there's no way you can figure it out on your own.