Thats not all I need though - I suppose its quite complicated to explain. My goal is to have a windows-service which exposes endpoints over net-pipe, which can be accessed by any process on the local machine to utilise centralized services. The service instance returned by the windows-service will depend on the user-account of the caller. A user who terminates their application process (which is a client of the windows-service) will NOT have his worker objects destroyed because they are keyed (lifestyle) against their user account, not the process-id. BUT if they log out of the computer, then castle will destroy all their component instances.
I can see that this functionality has many tendrils that need to hook into various different areas of responsibility with the castle infrastructure. I would LIKE to be able to implement this using Castle paradigms so that it is not implementation specific, but could be re-used easily in other, unrelated projects. Does that better explain where I am, and the depth of my proposition? Thanks Krzysztof Adam Langley Please consider the environment before printing this email! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Krzysztof Kozmic Sent: Sunday, 17 April 2011 9:24 p.m. To: [email protected] Subject: Re: New WCF Facility Lifestyle Sorry about the delay. If all you need is authentication information isn't this available from Thread.CurrentPrincipal or from OperationContext.Current ? Krzysztof On 14/04/2011 10:24 AM, Adam Langley wrote: > Absolutely, that would be analogous to my goals - except that nothing in the > WCF infrastructure will identify the windows session of the caller. > > I was thinking that to achieve 'session identification' I would need to > extend windsor further - but perhaps I dont. > > I expect the minimum I require, is that if my 'handler selector' is applied, > then the WCF endpoint must use Windows authentication. Then when a call comes > in, I can identify the windows account of the caller and use that to locate > the correct instance. > Does this sound like the right approach? > > I still need some 'facility' running within castle to listen to log-off > events so that I can dispose of all instances associated with that > user-session. > > I just thought that because my 'extension' required so many different > functional facets, I would need to implement them in several different ways > (IHandlerSelector + Facility + Lifestyle, for example) > > Adam Langley > Please consider the environment before printing this email! > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Krzysztof Kozmic > Sent: Thursday, 14 April 2011 9:38 a.m. > To: [email protected] > Subject: Re: New WCF Facility Lifestyle > > Adam, > > the way I saw it done usually, in multitenant applications is to have > the component registered for each tenant and use IHandlerSelector to > manage returning the right one. > > Say you're using NHibernate and you have different databases for each > tenant and each database has it's own Session component which you pick > based on some information about what tenant is currently making the request. > > Would that be fair to say you're in a similar situation? > > On 13/04/2011 2:01 PM, Adam Langley wrote: >> Dear group, >> >> I have a requirement where-by I will have a Windows Service (running as >> System) that publishes a component on net.pipe (for use by the local >> machine only), but it must service multiple users logged on to the same >> machine simultaneously. >> It must create a 'singleton' instance per Windows User connected... so >> the WCF layer will use integrated windows authentication. >> When a user logs on to the machine, they will receive the same component >> instance no matter how many times they connect/disconnect from the WCF >> service - and no two users will ever share the same instance. >> >> I was thinking that the best way to approach this would be a custom >> lifestyle which creates a release policy per distinct windows user - the >> component could even capture the global 'user logoff' event and dispose >> that user's component at that time (I would really love this!). >> >> What do you think of the concept, and what Castle extensibility points >> would I rely on to implement this? >> >> Adam Langley >> -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en.
