Here is a proof of concept if you want to see what it looks like. https://github.com/CoreyKaylor/fubutransportation-spike
On Fri, Feb 10, 2012 at 2:27 PM, Corey Kaylor <[email protected]> wrote: > A bit of an update on the status of my v3 ideas. > > I have successfully made a spike that leverages FubuMVC directly for > handling messages in RSB and all the boostrapping needs of consumers. > > What does this buy us? > > 1. All the behavior chain goodness and conventions that Fubu has to offer. > 2. Modularity via bottles also handled by Fubu boostrapping. > 3. Leverages subcontainer for lifecycle of a message consumer (no more > IMessageModule ugliness) > 4. We can introduce new conventions, if action has a return type, next > behavior after action would issue a bus.Reply for example > 5. Possibly reduce or eliminate the requirement for DTC by intercepting > Send, Publish, etc until all behavior chains have been executed > successfully then perform the send operations. > 6. With a little bit of work we would get the Fubu Diagnostics and > potentially a simple mechanism to expose an admin UI through Fubu running > on top of Kayak. > > What do we lose? > > 1. Currently Fubu only has StructureMap support, although it is built > agnostic > 2. Likely will have to think through a Fubu + RSB saga story, however the > existing RSB saga will work and continue to work fine. > > Where I plan to focus my efforts... > > I want this effort to be more of an adapter rather than a rewrite of RSB > internals etc. You can opt in if you want to use the adapter, but don't > have to. > I want to focus on the separation of ITransport(s) and build a one or two > more with primary focus on rabbitmq. > > Any more thoughts or opinions? > > > On Fri, Jan 6, 2012 at 1:37 PM, Corey Kaylor <[email protected]> wrote: > >> I'll keep that in consideration. >> >> >> On Fri, Jan 6, 2012 at 10:33 AM, Jason Meckley <[email protected]>wrote: >> >>> that's what I thought :) >>> >>> How difficult would this be to implement within RSB itself? I ask >>> because it seems the more dependencies infrastructure requires, the more >>> difficult it is to upgrade a system. If the logic is not too complex, the >>> behavior chain could be built within RSB and no dependency on FUBU would be >>> required. >>> >>> Or would you take advantage of the other FubuCore features as well? In >>> which case you are already dependent on Fubu. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Rhino Tools Dev" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/rhino-tools-dev/-/_7DbSGG5slEJ. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
