Thanks James for slicing out the FeatureEnabled thing for now, I appreciate it.
While we're on the topic, I'll squirt out this very brief version of how I envision this stuff working. A full understanding / explanation of this entails grokking the SOAP 1.2 extensibility model, including URI-named Features/Properties/Bindings/Modules. ===== Bindings and Modules are the concrete things which can implement Features. A Binding is the equivalent of an Axis Transport, but named with a URI instead of a generic string. There are server side and client side Bindings. A Module is a registered component, also named with a URI, which implements some functionality using SOAP headers. A Module is typically distributed as a jar containing a Module class, some metadata, and zero or more Handlers. There is a registry of available Bindings There is a registry of available Modules (perhaps discoverable jars sitting in a /modules directory) Modules: * know how to deploy Handlers into global or service flows in order to satisfy their needs * expose an optional "friendly" API to control the functionality in a clean way So a couple of brief scenarios here: 1) WSDL processing - We see something like <soap:module uri="http://foo/securityModule"; required="true"/> in WSDL - We go look in our Module registry to see if we have the desired Module. If so, we hook it into the generated stub/server-impl. This means Handlers automatically get deployed, and APIs are set up appropriately to control the Module. - If there are property values indicated in the WSDL, we simply map those directly to properties on the Stub or the SOAPService so they're available to the runtime. - Same thing for bindings 2) Using / tweaking a Module Call call = getCallFromSomewhere(); MyCustomModule module = (MyCustomModule)ModuleRegistry.getModule(uri); module.setSpecialThingy(5); // These are custom APIs to make using module.setSecurityLevel(3); // this particular Module more intuitive. call.activateModule(module); ===== There's more, but them's the basics. We do need something very much like James' FeatureEnabled interface, which Binding and Module would both implement. I'm not sure that disable/enable functionality is appropriate there, and I'd call it something like FeatureProvider or FeatureSource. There's a lot of further discussion to be had here. --Glen
