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: Wednesday, February 06, 2002 11:31 AM To: [EMAIL PROTECTED] Subject: RE: Subsystem responsibilities: WSDD 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
