While researching Observer pattern I have noticed, that the connection between the Subject and the Observer is usually one to many. Why so? Is there any particular reason why many-to-many relationship could cause any problems?
The system being designed using an Observer design pattern is done to provide the facility to a subject to have multiple observers and notify them whenever the subject's state changes. That is the textbook definition.
Lets take a real world use case - Newspaper and subscribers. A newspaper company sends out newspapers to people subscribed to it. It publishes newspapers and people subscribe to it.
As per your query, those subscribers can subscribe to many newspapers. So, it should be many-to-many. It appears so if you consider the system being designed and developed catering to all subscribers and all newspapers. Then this subscriber-newspaper universe is many-to-many. And you are right. As was discussed in the comment above - Twitter handles have multiple subscribers who subscribe to multiple twitter handles. Many-to-many it is.
But then there is a catch.
Actually to answer your question - we need to break down this many-to-many relation between publisher-subscriber into two parts-
1. One-To-Many from publisher to subscriber
2. One-To-Many from subscriber to publisher
One-To-Many from publisher to subscriber is used all the time - newspaper publisher distributes newspapers to its subscribers, tweets appear in followers feed etc.
But then do you really have any use for the one-to-many relationship back from the subscriber to publisher. I mean take the case of multiple folks and twitter handles they subscribe to. Suppose one subscriber tweets something. Does this information flow in the reverse direction to the twitter handles he/she follows? No. Do the twitter handles know that their followers have tweeted something?No.
Information does not flow in the reverse direction from subscriber to publisher ,or, observer to subject. Then if there is no information flowing from observer to subject - why design for it! That is your answer.
Although there are usually multiple observers of the observable (sometimes called the subject), I don't think there have to be more than one.
Agreed, there could be observers observing a data model and presenting the data as a pie chart, a graph and a table.
I have a case where I have three Android Fragments changing my DataModel (the Observable) but only one Observer (my Main Activity) that summarizes the current state.
Related
All:
I am pretty new to deepstream, on its website, it described in core concepts section as:
data-sync Interactive JSON documents that can be edited and observed.
Changes are persisted and synced across clients.
and
publish-subscribe Many clients can subscribe to topics and receive
data whenever other clients publish it to the same topic
I wonder what is the diff between its data-sync and pub-sub in terms of their purpose, in anther way, what task can one do while the other can not?
Thanks
PubSub is a way for clients and servers to send messages to each other. These messages can contain all sorts of data, but once the message is delivered its gone - there's no storage or statefulness. If you're familiar with EventEmitters in e.g. JavaScript you're already familiar with the pattern.
Data-Sync on the other hand is stateful, persistent data. Clients can request JSON documents called records, update them and subscribe to changes made by other records. Records can be arranged in lists and lists can be referenced by records, allowing for data-sync to become the realtime backbone for all the data that drives your app.
We are currently starting to broadcast events from one central applications to other possibly interested consumer applications, and we have different options among members of our team about how much we should put in our published messages.
The general idea/architecture is the following :
In the producer application :
the user interacts with some entities (Aggregate Roots in the DDD sense) that can be created/modified/deleted
Based on what is happening, Domain Events are raised (ex : EntityXCreated, EntityYDeleted, EntityZTransferred etc ... i.e. not only CRUD, but mostly )
Raised events are translated/converted into messages that we send to a RabbitMQ Exchange
in RabbitMQ (we are using RabbitMQ but I believe the question is actually technology-independent):
we define a queue for each consuming application
bindings connect the exchange to the consumer queues (possibly with message filtering)
In the consuming application(s)
application consumes and process messages from its queue
Based on Enterprise Integration Patterns we are trying to define the Canonical format for our published messages, and are hesitating between 2 approaches :
Minimalist messages / event-store-ish : for each event published by the Domain Model, generate a message that contains only the parts of the Aggregate Root that are relevant (for instance, when an update is done, only publish information about the updated section of the aggregate root, more or less matching the process the end-user goes through when using our application)
Pros
small message size
very specialized message types
close to the "Domain Events"
Cons
problematic if delivery order is not guaranteed (i.e. what if Update message is received before Create message ? )
consumers need to know which message types to subscribe to (possibly a big list / domain knowledge is needed)
what if consumer state and producer state get out of sync ?
how to handle new consumer that registers in the future, but does not have knowledge of all the past events
Fully-contained idempotent-ish messages : for each event published by the Domain Model, generate a message that contains a full snapshot of the Aggregate Root at that point in time, hence handling in reality only 2 kind of messages "Create or Update" and "Delete" (+metadata with more specific info if necessary)
Pros
idempotent (declarative messages stating "this is what the truth is like, synchronize yourself however you can")
lower number of message formats to maintain/handle
allow to progressively correct synchronization errors of consumers
consumer automagically handle new Domain Events as long as the resulting message follows canonical data model
Cons
bigger message payload
less pure
Would you recommend an approach over the other ?
Is there another approach we should consider ?
Is there another approach we should consider ?
You might also consider not leaking information out of the service acting as the technical authority for that part of the business
Which roughly means that your events carry identifiers, so that interested parties can know that an entity of interest has changed, and can query the authority for updates to the state.
for each event published by the Domain Model, generate a message that contains a full snapshot of the Aggregate Root at that point in time
This also has the additional Con that any change to the representation of the aggregate also implies a change to the message schema, which is part of the API. So internal changes to aggregates start rippling out across your service boundaries. If the aggregates you are implementing represent a competitive advantage to your business, you are likely to want to be able to adapt quickly; the ripples add friction that will slow your ability to change.
what if consumer state and producer state get out of sync ?
As best I can tell, this problem indicates a design error. If a consumer needs state, which is to say a view built from the history of an aggregate, then it should be fetching that view from the producer, rather than trying to assemble it from a collection of observed messages.
That is to say, if you need state, you need history (complete, ordered). All a single event really tells you is that the history has changed, and you can evict your previously cached history.
Again, responsiveness to change: if you change the implementation of the producer, and consumers are also trying to cobble together their own copy of the history, then your changes are rippling across the service boundaries.
I apologize for such a non-specific question, but I'm in the research stage of a project and had one question about the Windows Enterprise Service Bus that I can't seem to get a clear answer to.
The project entails users sending different types of "jobs" as messages to the ESB, which should then hand off the message to one of several available severs for background processing.
Considering we will have multiple different "jobs", I thought it would be best to create a subscription per background server and have each message be filtered by it's type, this way we wouldn't have to build in a dequeuer ourselves. However, my concern is that I will not be able to lock a message to one subscription in time and the message will be processed by each subscription that handles the particular type of "job".
I've been hard-pressed to find good research material on this subject and it seems that a Queue and a Subscription are mostly handled the same with the Service Bus, but the only part I can't find is when you lock a message on a topic, can it be locked only to one subscriber.
Thanks for any help or guidance towards the answer.
A message sent to a topic is essentially duplicated/copied to all subscribers. So there is no way for one subscriber to "lock" the message. The approach for this is to have a single subscriber by type, then have multiple receivers associated with that subscriber.
Unlike subscribers, receivers are competitive, giving you the "only one get its" behavior you appear to be after.
We've got a CQRS project and are thinking about a way to implement a "catchup", e.g. a new event handler is started and tells the eventstore to replay all events for him.
We're not sure if we should do the replay over the NServiceBus, as there is a real 1:1 connection and no publish/subscribe situation. Also we think that our new consumer is not able to keep up with the publish-speed and its input queue would get stuck.
What's the best practice here?
I've heard of people doing the following:
Have a system of replaying/rebroadcasting the events. Event handlers that have produced projections that have already seen these events ignore the events.
Allow events to be queried directly by the Event Handler when resetting it or when starting a new projection from scratch. This can be done in some systems by reading directly from the event store and in other actor based system an actor abstraction around the source of events may be queried.
From my understanding, option 2 allows for better performance as events can be queried in batches as opposed to being replayed to all listeners individually. These are just my observations without any practical experience to draw on yet.
We are using NServicebus to design a system that has to solve an auction scenario: we want to send out a message to a set of companies that can bid on an item. After we've received all the bids we want to send the item to the highest bidder.
We initially thought this kind of scenario was perfectly suited for NServicebus: Pub/sub for sending out a message (e.g. BidOnItem or ItemAvailable), message handlers that subscribe to that message for each interested company and a saga for storing the different bids we receive and we're done.
In a normal auction we could set a timeout at say 5 minutes and then decide who gets the item based on the highest price we've received. We don't have that luxury. The problem that we've run in to is that our specific scenario has a tricky, non-negotiable business requirement: the auction is very time-sensitive. Seconds matter. What we'd like to do is decide who gets the item as soon as all companies have responded. Usually this will happen in a matter of seconds. We want to decide the second all subscribers have responded. Obviously we'll also still implement a timeout but that will be the exception rather than the rule. If we want to determine if everyone has replied we'd need something like a list of all the handlers at all the endpoints that are subscribed to the BidOnItem message. It appears the NServicebus API doesn't provide this information.
There are some future requirements we have to implement as well centered around data enrichment and approval/rejection decisions that would benefit greatly from knowing whether all handlers on a pub/sub channel have responded. I know this reeks of request/reply which is something NServicebus discourages because of the coupling it causes but this requirement feels like something that's fundamental for a lot of processes that is very hard to implement outside of the core bus infrastructure. In that sense it feels a lot like Saga.ReplyToOriginator which NServicebus does provide.
What would be the "NServicebus Way" to solve this problem?
Pub/Sub is usually not the way to go in these auction scenarios. What if your saga would do reguest/response with your bidders?
S: OnAuctionCreated (carries the list of bidders, or you could fetch them somewhere)
foreach bidder in event.Bidders
-bus.Send(RequestBidFrom(bidder))
SetTimeout(X)
S: OnBidResponse
bids.Add(response.Bidder,response.Bid)
if(bids.Count()== Data.TotalBidders)
CompleteAuction();
S:OnTimeout
CompleteAuction()