I like the approach. Specific comments inline.
- James Snell
IBM Emerging Technologies
[EMAIL PROTECTED]
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
Glen Daniels <[EMAIL PROTECTED]> wrote on 12/04/2002 01:45:23 PM:
> Thanks James for slicing out the FeatureEnabled thing for now, I
> appreciate it.
Notta problem
> 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.
Interesting. I can see us revamping the current Transport/Sender
mechanism so that Binding jar files are dropped into a directory (e.g.
/bindings/httpBinding.jar) and automatically discovered. Sounds like a
great feature for Axis 2.0 that once we get through the Async stuff, I'll
gladly explore helping out with.
> 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.
Very good, but we're going to also need a way of connecting modules
(allowing them to work together) which would be a much more difficult
task.
> 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.
At this point, I think I agree. At a minimum, the FeatureEnabled
interface needs to have a getSupportedFeatures() method that returns an
array of URI's identifying the features supported by a given component.
disable/enable can probably be removed for now.
> --Glen
