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
