Pub/Sub Filtering

[mantzas]

Hi,

All of the clients want some OrderProcessed event.
Each order has a customer. Each customer belongs to a "ProfitCenter".
Each client has the right to see one or more Profit Centers.

This means that each client has the right to see the event for a
customer
that belongs to a Profit Center to which he has access to.

I could simply filter the order out on the client side and process
only
those messages for which the client has access to. This would mean
that
i would flood the network with messages to clients that have no access
to
the customer.

My question was if there was a way to filter the messages on the
server's side. Just before the Publish method is called for each
subscription to
check if the client of the subscription has access to.

This is a sort of dynamic filtering!
Is this doable?

[Dru Sellers]

What is the network layout of this application as it relates to clients?

-d

> --
> You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
> To post to this group, send email to masstrans...@googlegroups.com.
> To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/masstransit-discuss?hl=en.
>

[Travis Smith]

You could, in theory, use the distributor to do that filtering. It's
about the only place we allow content based routing. Otherwise, just
build an endpoint that does that work and republishes it for you. I'm
against content based routing on principal but I would have to admit
I've done it before.

-Travis

[mantzas]

Many windows clients that will place orders (20 clients and counting).
One, for the start, OMS (Order management server) Server handling the
clients order.
Various 3rd party systems that execute other related stuff.

All that on a 1gb LAN, on many switches on different floors. (Other
network intensive apps are working too, that why i want to keep
traffic to a minimum).
About 7 of the client are working on remote location (branches) via
dedicated vpn's.

Anything more?

On Jun 28, 8:33 pm, Dru Sellers <d...@drusellers.com> wrote:
> What is the network layout of this application as it relates to clients?
>
> -d
>

[Chris Patterson]

Yeah, I'm with Travis here. It's not something that I would typically do by choice, but the Distributor has a worker selection strategy that you could use to route the messages to specific workers based on some customer type. It really sounds like something that should be more explicitly modeled in the application domain however, since it appears to be a part of the business.

[Dru Sellers]

on the theme of don't do content based routing (which I agree with) http://www.udidahan.com/2011/03/20/careful-with-content-based-routing/

you have N rich client applications (operated by employees?), and one backend server that processes them?

-d

[mantzas]

Yes i have n rich clients operated by employees and one backend server
that processes them!

Chris,

if the filtering where of a static nature and did not alter then i
would agree with you.

The situation is this:

Client A sends an order for Customer x in ProfitCenter Z.
Client B has access to this Customer x in ProfitCenter Z.
Client C has no Access to ProfitCenter Z and hence no access to
Customer x.

All clients subscribe to the OrderComplete message.

Without filtering all client would get the OrderComplete message even
Client C who has no access. (Here i must do client side filtering in
order to prohibit showing the message)
Creating for every ProfitCenter a OrderComplete message is not an
option (obviously, they are create, updated, deleted daily).

My though is this (since i am using the same just with WCF and
Callbacks).

Before publishing the message (foreach client), check if the client
has access to the customer and send it.

In WCF i have the control of what will i send to each client (throug
callbacks).
Every time a fat-client connects to the service, he is added in the
callback list along with all ProfitCenters he is allowed to access.
On every callback i check if the order profitcenter and the user
profitcenter is matching. If it is a match then it is send else it
goes to the next fat-client callback.

My question is if it is possible to do something like that with
masstransit!
I am searching for an alternative to WCF and Callbacks because it is
not reliable and elegant.

Regards,

On Jun 28, 9:44 pm, Chris Patterson <ch...@phatboyg.com> wrote:
> Yeah, I'm with Travis here. It's not something that I would typically do by
> choice, but the Distributor has a worker selection strategy that you could
> use to route the messages to specific workers based on some customer type.
> It really sounds like something that should be more explicitly modeled in
> the application domain however, since it appears to be a part of the
> business.
>
>
>
>
>
>
>
> On Tue, Jun 28, 2011 at 1:07 PM, Travis Smith <tra...@legomaster.net> wrote:
> > You could, in theory, use the distributor to do that filtering. It's
> > about the only place we allow content based routing. Otherwise, just
> > build an endpoint that does that work and republishes it for you. I'm
> > against content based routing on principal but I would have to admit
> > I've done it before.
>
> > -Travis
>
> > On Tue, Jun 28, 2011 at 1:33 PM, Dru Sellers <d...@drusellers.com> wrote:
> > > What is the network layout of this application as it relates to clients?
>
> > > -d
>

[Dru Sellers]

@Chris, what about instead of publishing the results of the order, a direct send was used.

Publish sounds like the wrong pattern. Thoughts?

-d

[Chris Patterson]

Yeah, it sounds like you are defining the behavior for an application service that sits on top of MT and responds to the command messages that are sent (OrderComplete) which would then break it down and notify the profit centers.

[mantzas]

It seems that such behavior is not supported on MassTransit.

The OMS should handle the client messaging in it's own way (With Send)
and inform only the appropriate client about the OrderComplete.

My thought is that something like this could be useful in order to
support such behavior.
Not all Events are meant for everyone. And creating for each event a
message is not possible because of the constant changes to some
parameter (new profitcenters, customer changing profitcenter).

It would be nice if (in a generic way):

When a client subscribes, the developer can hook into this point and
create his custom logic to support this (like create a list of clients
with a list of allowed profitcenter per client).
The same goes to the unsubscribe. When the server publishes, the
developer could hook into this point and control if a client meets the
developed criteria in order to send or not the message (do a foreach
loop for the list of clients, and send only to the clients that meet
the profitcenter criteria).

This would be a "decision based" publishing (filtering).

Will something like this violating the whole messaging concept???

On Jun 29, 3:01 am, Chris Patterson <ch...@phatboyg.com> wrote:
> Yeah, it sounds like you are defining the behavior for an application
> service that sits on top of MT and responds to the command messages that are
> sent (OrderComplete) which would then break it down and notify the profit
> centers.
>
>
>
>
>
>
>
> On Tue, Jun 28, 2011 at 2:57 PM, Dru Sellers <d...@drusellers.com> wrote:
> > @Chris, what about instead of publishing the results of the order, a direct
> > send was used.
>
> > Publish sounds like the wrong pattern. Thoughts?
>
> > -d
>

[Scott Barnes]

Hmm,

For me this sounds kind of like a Ping/Pong? equation. You have a ProfitCenter and n-Clients. ProfitCenter in theory shouldn't be the guy that holds all the logic / decisions around who see's what and why. It should be held outside the ProfitCenter facade, meaning say you had ProfitCenter who had a direct line (via Application scope) to a business layer which makes those decisions. All the ProfitCenter does in theory is triage inbound messages (headers) onbehalf of the business layer (ensuring you have domain separation).

If this is the case, then you can setup a timer driven solution where the clients can either poll the ProfitCenter for requests like "AnyOrdersForMe(MyId)" which it then hands off to your business layer for decision(s). That or you could make the ProfitCenter ask the BL "Do you have anything for clientX<WhateverUniqueID> as i'm about to check its pulse?" logic.

I personally in my own apps make it so that each machine that connects to my network has its own msmq://machinename/pingpongchannel so that the central node it connects to can ask whether or not its still available (the client also asks the central node if its also available and proceeds to use a call tree if its not). In this pingpong it creates a trigger effect which not only says "hey we still can see each other" but it also slips in situations like "do you have any mail for me?" mentality. 

My reasons are that ProfitCenter could drop out for whatever reason and I'll need another machine to take over its workload should that occur. 

I deal with mines who's networks/machines aren't known for their uptime, so i need to keep everyone aware of each other as at any given point its a game of last machine standing could be the entire grid's message queue.  Meaning ProfitCenter, AuditCenter, SecurityHub etc typically are spread around n-Machines. Should AuditCenter drop off the face of the earth, then i need to automate the routing of inbound messaging to either ProfitCenter or SecurityHub so these guys take on the role of message triage machine when the AuditCenter comes back online. They also need to inform the clients onbehalf of the AuditCenter that its down and isn't contactable...so the clients can make a decision of whether or not messages are required for immediate delivery or they can leave a data equivelant of "voicemail" through other Center/Hubs. I do this as often the clients are also occasionally connected/disconnected (Geologists come online to sync data and then leave, they aren't seen again for days, so they haven't the time to wait to keep messages queued locally for when AuditCenter comes back).

Doing this kind of has this natural way of redundancy in place. I also really only keep my hub/centers spread over machines simply because they all have snapshots of the business layer  installed but only use % of it all. Each time they are asked to take on their cousins role that % of usage of the snapshot gets increased and then behind the scenes we reconcile the databases in separated threads to ensure integrity is kept consistent 

Anyway, point is the filtering occurs within the business layer and the endpoints on both client/server relationships are just relaying onbehalf of both business logic ends (clientside and serverside). I prefer that each message that gets sent or pushed is specific in purpose vs blind broadcasts ..as they are kind of like "put your fingers in your ears and wait for an explosion" loosey goosey way of doing things?

I could be doing it wrong though :)

---
Regards,
Scott Barnes
http://www.riagenic.com

[mantzas]

@Scott

In order to clarify one thing:

The concept of Profit Center is just a Customer Grouping for provision
calculation. There is no physical presence of it, its purely virtual.
This means that a customer belongs to a profit center.
A profit center contains from one to many customers.

If an order is executed for a customer the profit center gets a
provision i.e. 1% of the Order Amount.

Now each fat-client user has access to one or more profit centers.
This means that in the end of a month the user get a cut from each
profit center provision he participates in.
i.e.
User A has access to Profit Center X and Y.
User B has access to Profit Center X.

This means that User B cannot see orders from Profit Center Y and gets
no provision from it. He only gets provision from Profit Center X.
User A on the other hand can see orders from Profit Center X and Y and
gets provision from both.

A customer can change at any time the profit center even in the middle
of the working day.
User can change profit centers at any time even int he middle of the
working day.

Hopefully this is clear now.

> Scott Barneshttp://www.riagenic.com

> ...
>
> read more »

[Dru Sellers]

mantzas - the bottom line is that content based routing is not going to be implemented by Chris or I. So with that said, I think you can achieve what you want, but you may have to approach your problem a little bit differently. You may want to have the clients talk to a profit center via request/response (command/response) messaging patterns, then have the profit centers talk to the OMS using the same type of patterns.

You can find a list of conversation patterns by Gregor Hophe here: http://www.google.com/url?sa=t&source=web&cd=8&sqi=2&ved=0CFAQFjAH&url=http%3A%2F%2Fhillside.net%2Feuroplop%2Feuroplop2008%2Fsubmission%2Fshepherd.cgi%3Ftoken%3Dddb3e5acccc162303656b24adea5a0f8bd0cc350%26action%3Ddownload%26label%3D1203322025_15&rct=j&q=conversation%20patterns%20gregor&ei=vTALTruyN_SpsAKizoi5AQ&usg=AFQjCNEPtB4LuIBt6uuyidoGWmvS0E9SrA&cad=rja

but you may need to introduce more actors to help with the authentication issues you have. feel free to send up a drawing of what's going on. :)

-d

To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.