Sounds about right. IMO, Bindings should be black boxes that handle all of the details of actually sending/receiving the messages on the wire. A Binding may specify zero or more Modules that it either supports or requires. Required Modules are used by default, the only thing the developer/deployer can do is manipulate the behavior of the Module and Binding via properties/options. Supported optional Modules may be configured by the developer/deployer but may/may not be used by default by the binding.
Services, Providers and the Axis Engine can operate the same way. Required
or optional supported Modules can be configured.
Anyway, lots of stuff to consider, but I'd highly recommend not digging in
further until after we get the basic async functionality working :-)
- 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
David Chappell <[EMAIL PROTECTED]>
12/04/2002 04:01 PM
Please respond to axis-dev
To
[EMAIL PROTECTED]
cc
bcc
Subject
Re: Features and Modules and Bindings, oh my!
I think this approach may solve an issue that I was struggling with
earlier today with regard to variations in different transport's
interpretation of things like "reliable delivery". (It was a private
struggle...don't look for it in any mail archives :) The feature
represents a more encompassing capability such as JMS, ebXML MS,
davesReliableMEP, etc. The semantic meaning of whether a binding
supports things like persistent connections or acknowledgement receipts
would be in accordance with whatever agreed-upon behavior that feature
conforms to. Am I getting this right?
Dave
James M Snell wrote:
>
> 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
--
Sonic Software - Backbone of the Extended Enterprise
--
David Chappell <[EMAIL PROTECTED]> Office: (781)999-7099
Mobile: (617)510-6566
Vice President and Chief Technology Evangelist, Sonic Software
co-author,"Java Web Services", (O'Reilly 2002)
"The Java Message Service", (O'Reilly 2000)
"Professional ebXML Foundations", (Wrox 2001)
--
chappell.vcf
Description: Binary data
