Resending msg again. Didn't see it on the list for some reason... -----Original Message----- From: Sedukhin, Igor Sent: Wednesday, February 06, 2002 10:23 AM To: '[EMAIL PROTECTED]' Subject: RE: Subsystem responsibilities: WSDD
Glyn, >Handlers (including Chains) would then have to cope with being >instantiated >or modified during the processing of a request. For example, a Handler would >have to cope with being driven for onFault() when it has not been driven for >the corresponding invoke(). Handlers (et al) deal with MessageContext mostly. Both 'invoke' and 'onFault' receive msg context nomatter what sequence they're called in. They also don't call the Engine directly (in most cases), and rather use something like Handler service = msgContext.getServiceHandler(); This way MessageContext can handle versioning call to engine.getService(myContextVersionStamp). It provides a sufficient insulation for Handlers not to care about versioning explicitly. Chains are mostly constructed form the outside with public void addHandler(Handler handler) or with public SimpleTargetedChain(Handler reqHandler, Handler pivHandler, Handler respHandler) And so the versioning is not concerning chains this way. As long as one has got a Handler instance, the config versioning is already resolved. I agree that chains and handlers/providers should not be concerned with the versioning. I guess MessageContext and Handler abstraction would take care of that. -- 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 9:25 AM To: [EMAIL PROTECTED] Subject: RE: Subsystem responsibilities: WSDD Igor, You wrote: >I agree that Engine does not have to make any choices. For the Engine >it is always the config interfaces that we define. They will always >assume versioning. Like >EngineConfigurationProvider.getConfig(versionStamp) and >.getCurrentVersionStamp(). It's just that some simple >EngineConfigurationProviders may choose to not care about the >versionStamp parameter and return a blank string as a current version >stamp. So the engine always assumes versioning is taking place but some engine configurations simply return the latest version regardless of which version the engine is asking for. Handlers (including Chains) would then have to cope with being instantiated or modified during the processing of a request. For example, a Handler would have to cope with being driven for onFault() when it has not been driven for the corresponding invoke(). I don't like this as Handler represents one of the most common contracts in Axis and, IMO, it needs to be as simple as possible. By comparison, EngineConfiguration is more limited in its use and it would be reasonable to force implementations to support versioning. Glyn
