axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Features and Modules and Bindings, oh my!
Date Wed, 04 Dec 2002 21:45:23 GMT

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


* 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"/>

- 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.


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.


View raw message