It'll be easy to port the refactoring to the new stuff (I think...I haven't seen your changes yet). Since you asked, here is my (long- winded 'thought process').
Primarily my simple goal for the refactoring was Separation of Concerns...Msmq subscrptions have nothing to do with instance subscriptions, yet all the instance storage is hidden inside the msmq storage code. What if I want to implement something for ActiveMQ? I could pull the instance subscription code out to prevent duplication, but that is just hiding the SoC violation IMO. This inevitably causes upstream interface changes; specifically, the concept of a 'subscription'. Currently, "subscription" is an implicit concept coupled to a string (endpoint) . Instance subscriptions break this since they are not strings. So I can just add overloaded methods to deal with that (like it is now), but I wanted to make Subscription an explicit concept that has different implementations (eg, instance, endpoint on a queue) and make the interfaces (IServiceBus, ITransport, and ISubscriptionStorage) simpler to work with...clients should just be able to use the interface and let the implementations being consumed by the bus handle them. One benefit from all this is the potential for multiple storage/ transport implementations since I implement a CompositeTransport and CompositeSubscriptionStorage to hide the handling of Instance and Msmq stuff. You could theoretically also add an ActiveMQ implementation and simply add it to the Composite implementation during container registration. Whether that is valuable or not I don't know...I seriously don't have the big time experience using ESB solutions to know but it seems like it would be valuable for testing or migration to a new provider. The point is, simplifying the interfaces makes it easier for the developer to implement his own ITransport/ISubscriptionStorage ... ISubscription is pretty much hidden from the client; it is an internal way of letting me just send a message and let the handlers determine how to do deal with it. At first I wondered if I was over-abstracting, but I think if you compare the original ITransport/ISubscriptionStorage/IServiceBus interfaces with the ones I propose, you might think it considerable simpler and clearer. Anyways, that was my goals. On Jan 18, 12:53 am, Ayende Rahien <aye...@ayende.com> wrote: > Okay, just committed a big rafactoring on MsmqTransport. Mostly dealing with > extracting classes and responsibilities out.I think that I absolutely do > want to have separation from actually getting msgs from the queue in a > consistent fashion and the way that we build the transport. > Physical layer - which we are likely to reuse over and over again vs. fit to > purpose. > > I am afraid that the current commit invalidate the patch that you have, but > I would still like to understand more about your thought process when > building this. > > I am not sure that I understand the ned to create this explicit separation > between the transport and teh management system. > > On Sat, Jan 17, 2009 at 11:40 PM, Mike Nichols > <nichols.mik...@gmail.com>wrote: > > > > > I introduced this so that I could simplify the interfaces for > > ITransport and ISubscriptionStorage. This let me tear all instance > > subscription handling out of msmq handling and understand how each > > transport/storage implementation does their work. It also let me > > simplify all interfaces. > > How does this interface limit the sending of messages since it isn't > > really exposed much publicly on the IServiceBus interface? It just > > wraps the subscription implementation (Uri or Instance). > > > On Jan 17, 8:28 pm, Ayende Rahien <aye...@ayende.com> wrote: > > > Okay, here are a few comments from reading the patch. > > > > Why change end point to ISubscription? > > > The idea is that you can send a message whereever you want, not just to > > > people you subscribe to. > > > > On Sat, Jan 17, 2009 at 11:57 AM, Mike Nichols <nichols.mik...@gmail.com > > >wrote: > > > > > It's in the files section on the rhinoTools list: > > > > rsb_instance_sub_refactoring > > > > >http://rhino-tools-dev.googlegroups.com/web/rsb_instance_sub_refactor. > > .. > > > > > On Jan 17, 2:51 am, Ayende Rahien <aye...@ayende.com> wrote: > > > > > Can you resend that patch? I just need to get an idea about the sort > > of > > > > > changes that you made. > > > > > > On Sat, Jan 17, 2009 at 1:41 AM, Mike Nichols < > > nichols.mik...@gmail.com > > > > >wrote: > > > > > > > ah just got this... > > > > > > the last patch I submitted is that patch. i'll pull down all the > > most > > > > > > recent changes you made and redo it then forward the patch. > > > > > > > On Jan 16, 3:51 pm, Ayende Rahien <aye...@ayende.com> wrote: > > > > > > > Mike, > > > > > > > Can you generate a patch for this? > > > > > > > I find it really hard to understand zip files wihtout context > > > > > > > > On Thu, Jan 15, 2009 at 7:52 AM, Mike Nichols < > > > > nichols.mik...@gmail.com > > > > > > >wrote: > > > > > > > > > I just uploaded the zip. I started to get a GoGrid server > > setup so > > > > I > > > > > > > > could test all this on 2008, but I haven't had time to finish > > it. > > > > > > > > Tests were passing (that I could run) since I compose both > > Instance > > > > > > > > and MSMQ implementations. > > > > > > > > I will make the changes on the current copy if you look at it > > and > > > > see > > > > > > > > if its worth it. > > > > > > > > > The changes you made should not affect this except that the > > > > interface > > > > > > > > are much simpler. I just treat InstanceSubscription as its own > > > > > > > > implementation of ITransport and ISubscriptionStorage and > > remove > > > > all > > > > > > > > traces of it from the msmq implementations. Introducing > > > > > > > > "ISubscription" lets me do this. > > > > > > > > > mike > > > > > > > > > On Jan 15, 8:31 am, Ayende Rahien <aye...@ayende.com> wrote: > > > > > > > > > Can you try to see how this works after the changes I made > > > > recently? > > > > > > > > > > On Thu, Jan 15, 2009 at 10:24 AM, Mike Nichols < > > > > > > nichols.mik...@gmail.com > > > > > > > > >wrote: > > > > > > > > > > > In the patch I submitted (and havent had a chance to deal > > with) > > > > I > > > > > > > > > > refactored Transport and SubscriptionSTorage completely so > > that > > > > I > > > > > > > > > > could pull all InstanceSubscrption logic out of the Msmq > > stuff > > > > and > > > > > > > > > > into its own Transport/Storage implementation. Then, I have > > a > > > > > > > > > > CompositeTransport and CompositeStorage that hides the > > > > separation. > > > > > > > > > > I still have a project with the refactoring there...you > > wanna > > > > see > > > > > > it? > > > > > > > > > > > On Jan 15, 6:58 am, Ayende Rahien <aye...@ayende.com> > > wrote: > > > > > > > > > > > Right now MsmqTransport is doing WAY too much.I would > > like to > > > > > > break > > > > > > > > it > > > > > > > > > > apart > > > > > > > > > > > and get it into smaller pieces, each with a single > > > > > > responsability. > > > > > > > > > > > However, I can't really envision how to get there. > > > > > > > > > > > > Any ideas? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-dev@googlegroups.com To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
