Event Topics and Wildcards

Apr 20, 2008 at 11:36 AM
Edited Apr 20, 2008 at 11:38 AM
Glenn, to continue our discussion from the Directions thread.

Here is a quick example that stays within the RI direction.

Add a service that connects to an external stock price feed. For every price change it gets it publishes a message with a topic of priceupdate/stock/”specific stock symbol”. The message is a price update message base class with a stock price derivation.

Your concrete instances of a stock in the watchlist listens for priceupdate/stock/”mystocksymbol”. When is gets a message it updates the “last” price it shows. It never worries with the other stock messages because it only is listening for a single message type. And it does not have to check the message to see if it is for the stock it is showing.

Now management comes to you and tells you they want a watchlist stock ticker. One way to implement that would be for the ticker class to know about each stock that is in the watch list and subscribe to each priceupdate/stock/”mystocksymbol” message. A simpler way would be for the ticker to subscribe to priceupdate/”wildcard”. Then it gets all price updates that the stock price service publishes. It doesn’t care about the watchlist, or what is in it.

Now add a graph of the current price of all of the stocks in your watch list. It subscribes to priceupdate/stock/wildcard. It the reacts to any stock price change by updating its graph.

Now management says that we need to also show commodities, and then bonds instead of stocks. So you add a service that connects to an external bonds price feed, and you broadcast a priceupdate/bond/specificBondSymbol. The message is a derivitive of the original price update message but for bonds or commodities. The ticker continues to work, without ever having to change. You create a graph that subscribes to priceupdate/bond/wildcard, and it gets those messages. You also create a new bond watchlist object that subscribes to priceupdate/bond/specificBondSymbol messages. The existing stock watchlist classes never have to change, or know about the new messages.

Hopefully I have conveyed the idea. I tried to show various objects that would want different aggregates of messages. One that wants them all, a ticker, several that want all of the second level, the graphs, and some that want the specific message.
Apr 22, 2008 at 12:58 PM


pmont wrote:
Glenn, to continue our discussion from the Directions thread.

Here is a quick example that stays within the RI direction.

Add a service that connects to an external stock price feed. For every price change it gets it publishes a message with a topic of priceupdate/stock/”specific stock symbol”. The message is a price update message base class with a stock price derivation.

Your concrete instances of a stock in the watchlist listens for priceupdate/stock/”mystocksymbol”. When is gets a message it updates the “last” price it shows. It never worries with the other stock messages because it only is listening for a single message type. And it does not have to check the message to see if it is for the stock it is showing.

Now management comes to you and tells you they want a watchlist stock ticker. One way to implement that would be for the ticker class to know about each stock that is in the watch list and subscribe to each priceupdate/stock/”mystocksymbol” message. A simpler way would be for the ticker to subscribe to priceupdate/”wildcard”. Then it gets all price updates that the stock price service publishes. It doesn’t care about the watchlist, or what is in it.

Now add a graph of the current price of all of the stocks in your watch list. It subscribes to priceupdate/stock/wildcard. It the reacts to any stock price change by updating its graph.

Now management says that we need to also show commodities, and then bonds instead of stocks. So you add a service that connects to an external bonds price feed, and you broadcast a priceupdate/bond/specificBondSymbol. The message is a derivitive of the original price update message but for bonds or commodities. The ticker continues to work, without ever having to change. You create a graph that subscribes to priceupdate/bond/wildcard, and it gets those messages. You also create a new bond watchlist object that subscribes to priceupdate/bond/specificBondSymbol messages. The existing stock watchlist classes never have to change, or know about the new messages.

Hopefully I have conveyed the idea. I tried to show various objects that would want different aggregates of messages. One that wants them all, a ticker, several that want all of the second level, the graphs, and some that want the specific message.



A message monitor would also be a simple thing to implement. All it has to do is listen for a subject of "wildcard" and it will then get all published messages. Now it being able to read all of them would be dependant on the message content.

Apr 23, 2008 at 2:56 AM
Apologies if im butting in..

While this eventing ( * and hierarchical topics) is core to share/commodity prices its rare in other business applications and adds a lot of complexity unless you are very carefull. In most cases you can just add a few events for the all categories ( or worst case use a higher level to indicate all sub topics , * is not really needed. )

If you do need hierachies and * ( dubious) you almost have an xpath expression/WS-Eventing so why not use that ? I think fine for a stock app but it does not really belong in a sample for a UI framework , the time would be better spend on simpler examples like commands or using WPF with no code behind/presenter ( though possible this could really do with some work to make it simpler but getting wrid of the Poo in MVP with no drop in maintability is a lofty and worthy goal) .

Regards,

Ben
Apr 23, 2008 at 11:33 AM


bklooste wrote:
Apologies if im butting in..

While this eventing ( * and hierarchical topics) is core to share/commodity prices its rare in other business applications and adds a lot of complexity unless you are very carefull. In most cases you can just add a few events for the all categories ( or worst case use a higher level to indicate all sub topics , * is not really needed. )

If you do need hierachies and * ( dubious) you almost have an xpath expression/WS-Eventing so why not use that ? I think fine for a stock app but it does not really belong in a sample for a UI framework , the time would be better spend on simpler examples like commands or using WPF with no code behind/presenter ( though possible this could really do with some work to make it simpler but getting wrid of the Poo in MVP with no drop in maintability is a lofty and worthy goal) .

Regards,

Ben


I tried to target the example to the RI, but in no way believe that the use of hierarchical name spaces with wildcards for topics/subjects is limited to a stock quote app.

If you dont need hierarchies, dont use subjects with them. A simple subject of "A" would still work in a hierarchical naming system. Is it an absolute neccessity? No!, Is it one more tool that can enable designs that arent possible without it? Yes!

They are building a plugabble architecture, with everything dynamic and discoverable at runtime, using hierarchical object models with base classses and interfaces and derived classes, but yet a flat messaging system is good enough? <grin>

Off the top of my head, and with no real thought to other implementations, I can think of several apps that could use it. For Instance A Musical app that is recording from Midi. The main window shows all the notes and instruments, there are individual windows for each instrument. Each instrument window listens for its note message type, while the main window listens for all note messages. A Supply Chain app where a main window listens for any kind of route event, where specialized windows listen for a specific event or route or such. A realtime Customer Service app where the main window shows all open service requests regardless of customer, and individual windows specialize based upon either customer, or type of service request, or what have you.

When you want to build something that can grow, i.e. a pluggable architecture, you want to be able to build components that dont have to change whenever a new component is plugged in, but yet they want to participate in the actions of the new components. How can one introduce new messages without having to change the code in the old components to allow them to subscribe to the new events? And how do you not flood specialized components with messages that they then have to react and filter when they dont care about the message.

Interesting discussion, and I am interested in your points. Thanks for the input.

Paul
Apr 23, 2008 at 12:46 PM


Apologies if im butting in..



Please dont feel as if you are butting in. All input is appreciated.

Just for fun I did a google search on "pub sub hierarchical subject" and came up with lots of discussions on the topic. Most of them are targetted towards inter-process - multiple machine types of pub sub, but I believe they apply to an intra-process pub sub system also.

Some links
http://msdn2.microsoft.com/en-us/library/ms978603.aspx
http://books.google.com/books?id=9CL446IzhuAC&pg=PA196&lpg=PA196&dq=pubsubhierarchical+subject&source=web&ots=qlISOsAwe2&sig=TiSrZNYmRMMKJ4estsnK_muJCUw&hl=en

Thanks, and please, continue the discussion if you feel the need.

Paul
Apr 25, 2008 at 6:55 AM
Edited Apr 25, 2008 at 7:17 AM
Hi Paul ,

I have done a fair bit on it ( even got a book and it can get pretty hairy) ...mainly cross app - this subscription is really better done in the middleTiers/App servers.

For example you can get Roman Kiss's WS-Eventing ( code project) server , the 10 line samples which fire the event and use it are based on weather but you coudl change it for stock quotes in a few hours. The interesting thing about WS-Eventing is the topics are non hierachial ie NASDAQ , NASDAQ.livequotes and NASDAQ.news are distinct. There is no NASDAQ.livequotes.MSFT. However you supply a xpath subscription which is used to match quotes for that topic - this can be hierachial . Note the query is based on the xml data message.

eg
All microsoft queries
topic NASDAQ.livequotes
query MSFT

All microsoft warrants
topic NASDAQ.livequotes
query MSFT/warrants

All microsoft options which expire more than 30 days from now
topic NASDAQ.livequotes
query MSFT/warrants/Expires>30

This is a very powerfull method to desiminate live data ( think courier tracking information , sensors , quotes etc) . To implement this requires no code as its part of WS-Eventing and you can just use Romans services . ( and for real life usage it would not be hard to push a reuters feed into a WS-Eventing service) . I would not recommend using the code just the dlls as you can esily waste a lot of time on it,

For Stockbroking apps why is this needed in the client ?.. The only case i can think of is if you populate the db from the service and then fire the event however most apps would populate the data from the db and use events directly into the UI. ie when the data arives the MSFT data is updated and the UI will change via INotifyProprtyChanged

eg Reuters and DFS( an Australian broking app) both require you to subscribe to the central app server anyway..

My question is why is this functionality ( Hierachial events) needed within a client app.. Its seems heavy and rarely used. ( Though the above example would really make the sample a lot more powerfull and show the basics of a broking system , it will not demonstate Prism) . Would be cool though ( The stocktrader app has some nice ideas as well) .

Regards,

Ben
Apr 25, 2008 at 11:41 AM

I think I see our disconnect.

You agree that the hierarchical subjects with wildcards are a powerfull feature, but dont see the need in a client app.

I say why not? If it will delay Prism by 6 months, dont do it. If they are still in the design stage of the event broker ( which I beleive they are ), and they can add hierarchical events with wildcards as a normal part of the process, then do it. There has to be an interesting way to implement it using LINQ ( or CLINQ - see http://dotnetaddict.dotnetdevelopersjournal.com/clinq_continuousvwap.htm ) or xpath, or what have you. They are some smart guys, and can probably wow us with how it is done. <grin>

It has proven very usefull in distributed apps that I have written, and I can see the same opportunities within the client to make life simple, in some cases.

If they dont do it, no problem, I can get by. But if they are asking for use cases for the event broker, I believe that hierarchical subjects with wildcards is one they should scope and consider.

Thanks
Paul
Apr 26, 2008 at 1:49 AM
Hi Paul ,

Exactly .. I dont see the value in the client.

- If you look at a broking client you also need alerts for when things go under and over a price , hence * is not enough ( this is probably more used than *) . Hence an Xpath expression is more usefull( like WS-Eventing).
- I preffer thinner clients with more work done on the server . So i would never use such a featue - not do i think others will use it often within a client , the reason is there is no way to push the initial data. In a 2 tier you have to poll a DB or server ( notifications are of little use here as you still need to see what has changed) and hence it tends to be more display what you have .. This business requirement really comes in when you have live data and hence are talking distributed publish subscribe anyway (courier tracking information , sensors , quotes , news etc)
- Id rather they get Event Broker out there ASAP. As is is fine.
- As there is always an opportunity cost i think the time is better spent on .
- improved MV ( with no code behind ) support ( as well as MVP)
- extended guidance package with creation of MV and MVP views ,auto wiring up the views/controlled and maybe even auto wire up the business objects in Xaml.
- Get it out there now , as is with basic Event Broker and disconnected agent. Spend the rest of the time on v2 based on peoples comments and a really nice gidance package.
- A simple form of making components , eg some of the basics of Acropolis. This is probably needed for auto wire up anyway.

Regards,

Ben
May 8, 2008 at 11:28 AM
Glenn

Any hints on where things are going with this?

Thanks
Paul
May 8, 2008 at 2:29 PM


pmont wrote:

I think I see our disconnect.

You agree that the hierarchical subjects with wildcards are a powerfull feature, but dont see the need in a client app.

I say why not? If it will delay Prism by 6 months, dont do it. If they are still in the design stage of the event broker ( which I beleive they are ), and they can add hierarchical events with wildcards as a normal part of the process, then do it. There has to be an interesting way to implement it using LINQ ( or CLINQ - see http://dotnetaddict.dotnetdevelopersjournal.com/clinq_continuousvwap.htm ) or xpath, or what have you. They are some smart guys, and can probably wow us with how it is done. <grin>

It has proven very usefull in distributed apps that I have written, and I can see the same opportunities within the client to make life simple, in some cases.

If they dont do it, no problem, I can get by. But if they are asking for use cases for the event broker, I believe that hierarchical subjects with wildcards is one they should scope and consider.

Thanks
Paul


I think it all depends on how the end up architecting the EventBroker. If everything is hardwired in then Glenn and his team will have to build this. On the other hand if they build the EventBroker to allow for example a replacable IEventDispatcher then I don't see why this would need to be part of Prism at all because it could be reasonably easily built by an organization/community if the need is present.

Just replace the default IEventDispatcher with an implementation that looks for an event that provides some sort of Hierarchical Topic information and makes its custom decisions on who to send the information to based on that.

I realize that is kind of a bit "hand wavey" but I think the key point is that while there are groups that want Hierarchical topics and those that don't, depending on how EventBroker is built, it might not support them out of the box but still be implemnted to allow them to be supported reasonably easily.

Guess we need more details from the Prism team.
May 8, 2008 at 2:47 PM



Guess we need more details from the Prism team.


yup, :)

I agree, I was just looking for an update on what direction they planned on going. As I understand the "Vision" of prism, everything is going to be pluggable, so I would expect no less of the event broker. As to another group building one, they have done it with Unity why not this? Once the Prism team sets the direction I am sure quite a few derivitives will show up.

Paul
May 9, 2008 at 12:28 AM
Edited May 9, 2008 at 12:29 AM
The current design we have is as follows. We have a new PrismEvent<T> object, where T is the params. You create your own custom events that inherit from PrismEvent. We then have an event aggregator that you can use to register events. You this by doing something like

EA.Register<NewCustomerEvent>();

One the event is registered, you can then subscribe (unsubscribe is also available) to it and fire events. Let's say NewCustomerEvent is PrismEvent<Customer>, then to subscribe I would do

EA.Get<MyEvent>().Subscribe(OnCustomerCreated);

Then to fire, I would do

EA.Get<MyEvent>().Fire(ACustomer);

Subscribe also allows an additional parameter which is a Predicate<T> filter, where T is the parameter type agian. This way for the same event you can have different listeners for different filters. This is true pubsub, where the publisher has no knowledge of who is listening and does not have to worry about doing any specific routing.

The Subscribe also has a parameter for specifying how the thread marshalling will be handled.

Finally we've made the PrismEvent support a WeakDelegate notion. That is you can have the event not keep a strong reference to the listener who is handling it.

You'll see this functionality in a new Quickstart in our next drop.
May 9, 2008 at 11:15 AM


gblock wrote:


So if I understand this right, the register method on the Event agregator takes a type and uses that as the key for the link between the publisher and subscriber. So you are actually subscribing to a message type and not a subject. correct? Not quite sure, because you use two different names in your description above with no subjects shown.


EA.Register<NewCustomerEvent>()

and

EA.Get<MyEvent>().Subscribe()



Also, the CAB eventing model had the ability to specify the thread that the event reception would occur on ( UI THread, etc. ). Is this in your plans too? Or is is up to the user? ( either is fine, we can marshall data to threads too. <grin> )

It seems then that the key to this agregator is the register method. It needs to be called before any pub or sub is done. I assume it can be done by any party in the conversation, right? If the listener gets created first by design, it can register the event, or if the publisher gets created first, it could register the event. Or it could even be done by the module at bootstrap time, and then neither the publisher or subscriber have that responsibility.

Thanks, looking forward to the quickstart.
Paul

May 11, 2008 at 3:24 AM
@Paul

There's a difference between registering and subscribing. Registering is making an event available to be published or subscribed to. When you subscribe, you subscribe to a PrismEvent<T> instance. You have the option at that point, to also specify a filter based on T. This is essentially topic filtering, however it keeps the publisher completely unaware of who is listening, or what they are filtering on.

On the threading, the Subscribe method is overloaded to allow providing the threading info as in CAB. Additionally we are allowing you to specify whether the event is holding a hard reference, or a weak reference to the listener. Essentially if it's weak, we only create the delegate for a moment in time whenever the event is fired, and then we immediately dispose of it.

Hope this helps
Glenn