Glyn, Great. I'll start looking deeper into this next week. It should not be very difficult to implement. I'll writeup something for the arch. too.
-----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 11:20 AM To: Sedukhin, Igor Cc: [EMAIL PROTECTED] Subject: RE: Subsystem responsibilities: WSDD Igor, I agree with everything in your last note. Also, the commit I did earlier has completed the group of configuration changes I was planning on making, so the area should be fairly stable now. Would you now like to proceed and let me know if you would like any help? (If you could also write up a few paragraphs for the architecture guide, I'd be delighted!) Glyn "Sedukhin, Igor" To: Glyn Normington/UK/IBM@IBMGB <Igor.Sedukhin cc: [EMAIL PROTECTED] @ca.com> Subject: RE: Subsystem responsibilities: WSDD 07/02/02 14:51 Glyn, Oops, total messup, sorry. Included below is the message that din't make it to the list somehow (I's not the one I have resent :). Please let me know what you think about those points. PS. I'm not sure about 'clone'. It has some implied meaning that is not really what we're trying to achieve. In reality it will never be cloned, unless, of course it is some very simplistic impl that does versioning by replicating the whole config. -----Original Message----- From: Sedukhin, Igor Sent: Wednesday, February 06, 2002 1:37 PM To: '[EMAIL PROTECTED]' Subject: RE: Subsystem responsibilities: WSDD Glyn, I would add 4. There should be only one Engine instance per client/server usage (i.e. NOT one Engine instance per one 'snapshot'). There could be multiple 'snapshots' known to the Engine though. One MessageContext would always refer to one 'snapshot'. I would question 3. The Engine is the guy that knows what to do and also accepts initial requests. I believe it creates chains, etc. Also if at any point, anyone wants to ask the Engine getService, etc. there should be no doubt that providing the config 'snapshot' version is required. I'm afraid otherwise (i.e. allowing it to always implicitly query head version) it may result in an architecture that is not consistent and allows semantic mistakes. Another solution: remove getService et al methods from the Engine. I don't even know why they should belong to the Engine when we have getConfig() and EngineConfiguration interface. I agree with 1 & 2. I was only proposing the config factory to simplify writing a config provider. In other words not to mix two conceptual elements in one interface. For the sake of the amount of changes involved going for one interface seems very reasonable to me. So, I support getSnapshot thingy. I think we're converging on this. A few more iterations and we'll know what the best way to make an efficient, safe dynamic deployment possible without affecting everyone at large. PS. Another thing that worried me for a while is thread safety of the deployment code. We may be able to offload this concern to the config provider implementation with this approcah. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 4:00 AM To: Sedukhin, Igor Subject: RE: Subsystem responsibilities: WSDD Igor, >Resending msg again. Didn't see it on the list for some reason... I saw the original message and here's my reply in case you didn't see it... Also it occurs to me that 'getSnapshot' could actually be spelled 'clone'. I feel we are converging on a good approach - I hope you agree! Regards, Glyn ----- Forwarded by Glyn Normington/UK/IBM on 07/02/02 08:56 ----- Glyn Normington To: [EMAIL PROTECTED] cc: 06/02/02 16:30 From: Glyn Normington/UK/IBM@IBMGB Subject: RE: Subsystem responsibilities: WSDD(Document link: Glyn Normington) Igor, I like the general drift of your proposal, except that I think it need not involve the EngineConfigurationFactory. Let me play it back in abstract form to make sure we are in synch. 1. EngineConfiguration should provide a method which returns a "version stamp" representing the *current* configuration -- logically a snapshot. 2. MessageContext is responsible for hiding the complexities of versioning from handlers. Conversely, handlers should access the engine configuration via the message context so the message context can sort out versioning. 3. The engine should know nothing about versioning. (Not totally convinced of this, but it's a good objective!) May I propose an improvement? Instead of exposing a "version stamp" interface/class, let's use EngineConfiguration! So EngineConfiguration would support a method (which could be called getCurrentVersion if you prefer): public EngineConfiguration getSnapshot(); Glyn
