Yea, I'm afraid it starts looking like that. I'm investigating this and coming up with prototypes because it's for my internship (last year in college, application design) So yea, boss is convinced it should be somehow possible to put the whole thing together like I explained but meh, it's getting confusing in the long run lol.
However, I did just come up with a new prototype that *could* behave like the way we want it to. Please, take a look at the following diagram: http://bit.ly/euGnCY This prototype *hopefully* works as follows: Per message type, we have an agent that always fetches that type of message and "stores" it in its queue. (MT1A, MT2A, ...) Now, whenever a new agent comes online, that agent will know from it's config to which MTA it has to subscribe. So whenever the agent subscribes to that MTA, it will automaticly get messages that are in its queue. The agent does whatever it needs to and simply .Reply() a new, or the same type of message back. Altho it'll be placed in some sort of general container. The MTA that sent the agent the message will receive the container and check the following: * If the message type contained in the general message it the same message type that the MTA handles, publish / notify again * If the message type contained in the general message is from another type, directly .Send() that message to the approperiate MTA So when another MTA receives a new message from another MTA, it will again Publish or notify so that agents subscribed to his message type can deal with it. And so the cycle continues. This way, only the MTA's know about eachothers existance through their app.config files, and the agents themselves don't know how many other agents there are. They only know to which message type (read message type agent) they have to subscribe. There will be a limited, predefined number of message types, thus also a limited number of MTA's, but there can be an unlimited amount of agents working with those message types. Kind regards, Dirk On 10 mrt, 17:14, Corey Kaylor <co...@kaylors.net> wrote: > Most, if not all of the .NET OSS service bus implementations discourage a > central broker model. If trying to go down this road you'll be tweaking a > system that was designed specifically not to be a broker and will feel a lot > of friction along the way. If you truly need a broker I would use a system > that was designed to be a broker. Not that I would say write off a service > bus, but rather see what advantages it might bring over a broker. -- 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.
