axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sedukhin, Igor" <>
Subject RE: Subsystem responsibilities: WSDD
Date Wed, 06 Feb 2002 18:37:13 GMT

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 .. (
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Glyn Normington [] 
Sent: Wednesday, February 06, 2002 11:31 AM
Subject: RE: Subsystem responsibilities: WSDD


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

public EngineConfiguration getSnapshot();


View raw message