Take a look at the way IMessageAction is behaving, the conditional logic has shrunk.
On Mon, Jan 19, 2009 at 2:06 AM, Mike Nichols <nichols.mik...@gmail.com>wrote: > > Hm...yeah I could see that approach too. My only concern would be the > amount of conditional logic this would require in the implementations > (like in a Transport_MessageArrived handler) that needs to get > subscriptions, but that could be circumvented too. It just seemed > simpler to treat instance subscriptions as just another type of > subscription and participate in the same lifestyle as any other > handling. > > Thinking about this, I guess since a ServiceBus has a single endpoint > the notion of composing ISubscriptionStorage implementations is > spurious anyways, huh? > > I am going to get my environment going on windows server 2008 this > week...I finally renewed my MSDN stuff to do that...I'll work on this. > I am limited since I can't run the 2008 tests. > > On Jan 18, 11:12 pm, Ayende Rahien <aye...@ayende.com> wrote: > > I am with you on separating the responsibilities, but I think that as > long > > as we are doing that, we might as well do it right and make it fully > > explicit.This means that we don't even have a shared interface between > the > > two > > > > On Mon, Jan 19, 2009 at 12:30 AM, Mike Nichols <nichols.mik...@gmail.com > >wrote: > > > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
