But if only the first message in a batch is determining what subscriptions are gathered for Publishing, what prevents the _second_ message in the batch failing to receive a message if it doesn't happen to be the endpoint determined by the _first_ message? The logic where messages[0] is solely used to gather subscriptions will not support this.
On Thu, Aug 5, 2010 at 1:22 PM, Ayende Rahien <aye...@ayende.com> wrote: > Nope > Batching is a completely different concept. It is used for: > * minor perf boosting > * ensuring transactional boundaries > > It is a way to bring together discrete operations into a single unit. > This allows you to avoid the issue of granular API and chatty interfaces. > > Subscription is another matter, > > On Thu, Aug 5, 2010 at 10:17 PM, Mike Nichols <nichols.mik...@gmail.com>wrote: > >> @Ayende >> Do you assume only one endpoint subscribing to a batch of messages then? >> >> On Thu, Aug 5, 2010 at 12:51 PM, Ayende Rahien <aye...@ayende.com> wrote: >> >>> Yes & no. I follow your logic, but can you check my Alexandria sample app >>> for their use there? >>> I don't see another way to implement the same thing and getting the same >>> benefits. >>> >>> >>> On Thu, Aug 5, 2010 at 9:49 PM, Udi Dahan < >>> thesoftwaresimpl...@udidahan.com> wrote: >>> >>>> I've said multiple times before that messaging is not suitable for >>>> queries. >>>> >>>> When messages represent user-tasks, each should be its own transactional >>>> boundary, ergo no batches. >>>> >>>> When users are doing classical grid-style data management, the work is >>>> usually non-collaborative, in which case messaging again isn't needed and a >>>> simpler synchronous DTO in-out approach (dare I say datasets) is more >>>> appropriate. >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> -- Udi Dahan >>>> >>>> >>>> >>>> *From:* rhino-tools-dev@googlegroups.com [mailto: >>>> rhino-tools-...@googlegroups.com] *On Behalf Of *Ayende Rahien >>>> *Sent:* Thursday, August 05, 2010 10:20 PM >>>> >>>> *To:* rhino-tools-dev@googlegroups.com >>>> *Subject:* Re: [rhino-tools-dev] Re: rhino rsb subscription harvesting >>>> >>>> >>>> >>>> Udi, >>>> >>>> I am not sure that I agree here. >>>> >>>> I use batches as a way to submit work as a single unit to a remote >>>> endpoint. >>>> >>>> In addition to that, there is a nice perf boost when you are talking >>>> about doing remote queries (see the Alexandria) example and you can compose >>>> those queries to run in a single connection/transaction for the specific >>>> scenario you need. >>>> >>>> >>>> >>>> On Thu, Aug 5, 2010 at 6:37 PM, Udi Dahan < >>>> thesoftwaresimpl...@udidahan.com> wrote: >>>> >>>> Batches are primarily relevant for multiple instances of the same >>>> logical >>>> message - saves you from having to create messages which are nothing but >>>> containers for multiple message instances. >>>> >>>> >>>> -- Udi Dahan >>>> >>>> >>>> -----Original Message----- >>>> From: rhino-tools-dev@googlegroups.com >>>> [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols >>>> >>>> Sent: Thursday, August 05, 2010 7:33 PM >>>> To: Rhino Tools Dev >>>> Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting >>>> >>>> I don't believe I am making my concerns very clear...sorry all. My >>>> argument had nothing to do with events, aggregate roots, cqrs, or >>>> commands. Only with the unexpected behavior that some endpoints will >>>> not receive messages when you send a batch via Notify(...) if they do >>>> not happen to be subscribed to the first message in that batch. This >>>> would be true in a transaction script world as well as a ddd world. I >>>> can easily iterate over the messages one at a time, but then I wonder >>>> why accept a batch at all. >>>> >>>> >>>> >>>> On Aug 5, 8:57 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: >>>> > Should an implementation detail of your command side cause such issues >>>> at >>>> > the interface level? >>>> > >>>> > I would think not - in which case, maybe the implementation needs to >>>> be >>>> > re-evaluated. Don't assume what the structure of your aggregates is >>>> supposed >>>> > to be, nor the events they expose. Let it evolve from the needs of the >>>> > interface. >>>> > >>>> > Regards, >>>> > >>>> > -- Udi Dahan >>>> > >>>> > From: rhino-tools-dev@googlegroups.com >>>> > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols >>>> > Sent: Thursday, August 05, 2010 6:38 PM >>>> > To: rhino-tools-dev@googlegroups.com >>>> > Subject: Re: [rhino-tools-dev] Re: rhino rsb subscription harvesting >>>> > >>>> > @Jason, Thanks for jumping in :) >>>> > I am not using Udi's implementation of DomainEvents.Raise<TEvent>(..). >>>> I >>>> am >>>> > familiar with that approach, but am instead doing event sourcing. What >>>> this >>>> > means is during the course of an operation one or more events are >>>> applied >>>> to >>>> > the Aggregate Root. Upon the commit of a UnitOfWork those events are >>>> > serialized to an event store after which they are published on a bus. >>>> Not >>>> > all usages of Domain Events are synchronous operations on the query >>>> store. >>>> > They can be but I have pulled those out of process. >>>> > In a separate process lives a series of Denormalizers which subscribe >>>> to >>>> > these events. But the domain itself may also subscribe to these events >>>> for >>>> > purpose of communicating across Bounded Contexts or perhaps >>>> contributing >>>> to >>>> > a saga. >>>> > My posting didn't have to do with any of this, though :). >>>> > >>>> > Instead, it was related to the faulty assumption that calling Publish >>>> on >>>> > more than one message should assume that every endpoint in that batch >>>> of >>>> > messages can be derived from the first message in the batch. That >>>> works >>>> for >>>> > Send, but not Publish. When I am calling Send, I am safely making >>>> > assumptions about the endpoint to which I am Sending those >>>> > messages...namely, that they will go to the same place. When I call >>>> Publish, >>>> > that assumption should not be made. >>>> > >>>> > On Thu, Aug 5, 2010 at 7:31 AM, Jason Meckley <jasonmeck...@gmail.com >>>> > >>>> > wrote: >>>> > >>>> > Mike, if I'm following the discussion correctly the problem has become >>>> > confusion between messages on RSB and handlers for domain events. >>>> > >>>> > messaging (RSB) is an asynchronous action. you can batch messages >>>> > together and all the messages in the batch are send to the endpoint >>>> > defined by the 1st message in the batch. that is by design to keep >>>> > transactional boundaries. if you need to send multiple messages to >>>> > various endpoints you need to send them separately, each it's own >>>> > transaction. >>>> > >>>> > domain events are synchronous operations that would occur within the >>>> > same transaction as the message(s) being processed. for example here >>>> > is a consumer to process an order >>>> > void Consume(ProcessOrder message) >>>> > { >>>> > session.Get<Order>(message.OrderNumber).Process(); >>>> > >>>> > } >>>> > >>>> > the Process() method on order might look like this >>>> > void Process() >>>> > { >>>> > //validate order is ready for processing >>>> > //change the state of order and/or order lines >>>> > >>>> > DomainEvents.Raise<OrderProcessed>(this); >>>> > >>>> > } >>>> > >>>> > where DomainEvents.Raise is a static facade to instantiate and execute >>>> > the various OrderProcessed. for example you may have the following >>>> > handlers for order processing >>>> > SendInvoiceToCustomer : IHandler<OrderProcessed> >>>> > ShipProductsToCustomer : IHandler<OrderProcessed> >>>> > DecreaseInventoryOfItemsOnTheOrder : IHandler<OrderProcessed> >>>> > UpdateATableUsedForReporting : IHandler<OrderProcessed> >>>> > >>>> > all of these handlers would execute immediately, within the same >>>> > transaction, when the order is processed. and if any of these >>>> > operations would fail the entire transaction would rollback as well. >>>> > Some of these handlers may call the service bus to send another >>>> > message but each of those messages is yet another transaction >>>> > independent of actually processing the order. >>>> > >>>> > I hope this helps rather than adds confusion or another tangent. From >>>> > what I have read, understanding this distinction may help explain why >>>> > RSB works the way it does, where domain events fit into the >>>> > architecture and how the 2 are used to solve different problems. And >>>> > why atomic transactions to various endpoints doesn't work (or is a bad >>>> > idea). >>>> > >>>> > On Aug 5, 9:03 am, Mike Nichols <nichols.mik...@gmail.com> wrote: >>>> > >>>> > > @Udi >>>> > > I am not sure I understand. I am using event sourcing, so I persist >>>> events >>>> > > on the domain side for rehydration of Aggregates, etc (domain-side). >>>> The >>>> > bus >>>> > > publishes these events, which are subscribed to by interested >>>> query-side >>>> > > denormalizers. >>>> > >>>> > > On Thu, Aug 5, 2010 at 12:40 AM, Udi Dahan >>>> > >>>> > <thesoftwaresimpl...@udidahan.com >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > > > wrote: >>>> > > > I think that the reason you're running into difficulty is that >>>> your >>>> > > > persisting data on the command side that should have only been >>>> persisted >>>> > on >>>> > > > the query side. >>>> > >>>> > > > Cheers, >>>> > >>>> > > > -- Udi Dahan >>>> > >>>> > > > -----Original Message----- >>>> > > > From: rhino-tools-dev@googlegroups.com >>>> > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike >>>> Nichols >>>> > > > Sent: Thursday, August 05, 2010 1:09 AM >>>> > > > To: Rhino Tools Dev >>>> > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting >>>> > >>>> > > > @Udi >>>> > > > I am persisting the events. After the events have been persisted >>>> they >>>> > > > are put on the bus for publication. >>>> > > > My initial concern here though was about the assumption that the >>>> first >>>> > > > message in a batch is the sole provider of subscription details >>>> for an >>>> > > > entire batch of messages. It seems like a user should just Publish >>>> a >>>> > > > batch of messages on a bus and not be concerned about who is >>>> > > > subscribed to them. >>>> > >>>> > > > To be clear this code from the PublishInternal method in the >>>> > > > defaultservicebus is what I am discussing.What this code is saying >>>> is >>>> > > > that if you have two messages in a batch being Published, and each >>>> one >>>> > > > is subscribed to by different endpoints, then the second message >>>> in >>>> > > > the batch will not get published. That seems unpredictable to me: >>>> > > > private bool PublishInternal(object[] messages) >>>> > > > { >>>> > > > if (messages == null) >>>> > > > throw new ArgumentNullException("messages"); >>>> > >>>> > > > bool sentMsg = false; >>>> > > > if (messages.Length == 0) >>>> > > > throw new MessagePublicationException("Cannot >>>> publish >>>> > > > an empty message batch"); >>>> > > > object msg = messages[0]; >>>> > > > IEnumerable<Uri> subscriptions = >>>> > > > subscriptionStorage.GetSubscriptionsFor(msg.GetType()); >>>> > > > foreach (Uri subscription in subscriptions) >>>> > > > { >>>> > >>>> > > > transport.Send(endpointRouter.GetRoutedEndpoint(subscription), >>>> > > > messages); >>>> > > > sentMsg = true; >>>> > > > } >>>> > > > return sentMsg; >>>> > > > } >>>> > >>>> > > > m >>>> > >>>> > > > On Aug 4, 9:51 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> >>>> wrote: >>>> > > > > Mike, >>>> > >>>> > > > > The case of CQRS usually has the service layer publishing the >>>> events >>>> > in >>>> > > > > response to commands, domain events has nothing to do with it. >>>> If >>>> > you're >>>> > > > > talking about event-based persistence on the command-side, >>>> again, >>>> > domain >>>> > > > > events have nothing to do with the bus. >>>> > >>>> > > > > Cheers, >>>> > >>>> > > > > -- Udi Dahan >>>> > >>>> > > > > -----Original Message----- >>>> > > > > From: rhino-tools-dev@googlegroups.com >>>> > >>>> > > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike >>>> Nichols >>>> > > > > Sent: Wednesday, August 04, 2010 4:46 PM >>>> > > > > To: Rhino Tools Dev >>>> > > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting >>>> > >>>> > > > > If I have 5 events that took place on my aggregate root during >>>> the >>>> > > > > course of a unit of work. My understanding is that the root >>>> represents >>>> > > > > a transactional boundary. So I publish the events on the bus as >>>> a >>>> > > > > batch. The subscriber (in this case, denormalizers for events >>>> that >>>> > > > > write to a database) will go through each event and update the >>>> > > > > database, ideally in a single transaction so that if one of the >>>> > > > > handlers fails, then they all fail. >>>> > > > > As I think about it, I am not sure why that is so important >>>> other >>>> than >>>> > > > > the convenience of having NHib in a single session and cut down >>>> on >>>> the >>>> > > > > number of roundtrips. But I realize this is an impl detail that >>>> > > > > shouldn't be the driver. >>>> > >>>> > > > > @Udi - I actually went back and forth on whether to publish >>>> these >>>> > > > > individually or not, so it is helpful to hear from you on this. >>>> Can >>>> > > > > you see why I would consider the batch a single unit though? If >>>> you >>>> > > > > are using a denormalizer you always only send one event at a >>>> time to >>>> > > > > that endpoint? >>>> > >>>> > > > > On Aug 4, 6:35 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> >>>> wrote: >>>> > > > > > Then I'm afraid it sounds like you're not using DomainEvents >>>> the >>>> > right >>>> > > > way >>>> > > > > - >>>> > > > > > each event from the domain should be a discrete domain >>>> occurrence. >>>> > >>>> > > > > > -- Udi Dahan >>>> > >>>> > > > > > -----Original Message----- >>>> > > > > > From: rhino-tools-dev@googlegroups.com >>>> > >>>> > > > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike >>>> Nichols >>>> > > > > > Sent: Wednesday, August 04, 2010 3:45 PM >>>> > > > > > To: Rhino Tools Dev >>>> > > > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription >>>> harvesting >>>> > >>>> > > > > > I am publishing the DomainEvents from my domain. These events >>>> are >>>> > > > > > subscribed to by 1 (or more report) services that update the >>>> db >>>> > state >>>> > > > > > from those events. >>>> > > > > > @Udi - I could publish them one at a time, yes, but I'd rather >>>> the >>>> > > > > > whole batch fail since they represent a unit of work from my >>>> > > > > > domain...I don't want some messages to succeed and others to >>>> fail >>>> > > > > > leaving the db in an odd state. >>>> > >>>> > > > > > On Aug 4, 5:39 am, Ayende Rahien <aye...@ayende.com> wrote: >>>> > > > > > > What is the scenario in which you would want to publish a >>>> message >>>> > > > batch? >>>> > > > > > > And publishing doesn't use the owners, it uses the >>>> subscriptions >>>> > > > list. >>>> > > > > > > I think that I had the wrong idea in mind about what we are >>>> > talking >>>> > > > > about, >>>> > > > > > > yes, for publish, that would make sense, but I still want to >>>> know >>>> > > > what >>>> > > > > > your >>>> > > > > > > scenario is. >>>> > >>>> > > > > > > On Wed, Aug 4, 2010 at 3:33 PM, Mike Nichols >>>> > > > > > <nichols.mik...@gmail.com>wrote: >>>> > >>>> > > > > > > > Isn't that the difference between Publish and Send though? >>>> > > > > > > > 'Publishing' an event in my mind doesn't carry any >>>> assumption >>>> > >>>> > about ... >>>> > >>>> > read more » >>>> >>>> -- >>>> 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-...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>>> -- >>>> 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-...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>>> >>>> >>>> -- >>>> 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-...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>>> -- >>>> 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-...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>> >>> -- >>> 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-...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>> >> >> -- >> 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-...@googlegroups.com. >> To unsubscribe from this group, send email to >> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> > > -- > 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-...@googlegroups.com. > To unsubscribe from this group, send email to > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > -- 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-...@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.
