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) --
begin:vcard n:Chappell;Dave tel;cell:617-510-6566 tel;work:781-999-7099 x-mozilla-html:FALSE url:www.sonicsoftware.com org:Sonic Software Corp. <BR><BR><A HREF="http://www.sonicsoftware.com/products/sonicxq.htm";>Read about SonicXQ</A> - the first product to deliver <br>on the promise of the enterprise service bus.<BR><BR><A HREF="http://www.sonicsoftware.com";><IMG BORDER="0" SRC="http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif";></A> adr:;;14 Oak Park;Bedford;MA;01730;USA version:2.1 email;internet:[EMAIL PROTECTED] title:vice president & chief technology evangelist<a href="http://www.oreillynet.com/weblogs/author/207";>[weblog]</a> fn:Dave Chappell end:vcard
![http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif"](http://www.sonicsoftware.com/media/email_signatures/schulte_quote_logo2.gif"){kind=link}