Hi Jeremy, I echo your opinions on bindings, and lets put this discussion into a concrete use case - enabling Celtix binding in Tuscany, and see if we can agree a list of action items as a result.
When spec binding <binding.ws> is used, users do not care and should not care which Web Service binding implementation is used, it is up to the Tuscany runtime to determine which implementation of <binding.ws> to pick up using its own way. In this case, my previous question of how to switch between different implementations would be invalid, as users can not specify which implementation to use for binding.ws. Our current loading mechanism (using DirectoryScanExtender.java) already satisfies the use case above. The only issue needs to address is when multiple implementations of same binding are available under the extension dir. If I understand correctly, it is the last binding getting registered being used. This can be a random pick depending on the OS and environment. To avoid this situation, shall we have a distribution target for each binding, and users should be instructed that they need to put binding distribution under the ext dir and normally they should not put competing binding implementations under the ext dir. If users really need to have multiple competing binding implementations under the ext dir, they should either let the Tuscany runtime pick up one for them or they should load specific binding impl as described in the next paragraph. The mechanism Tuscany used to determine which bindind.ws implementation to use when multiple available should be documented. If users do need to use a specific binding implementation, they can do so by using a non-spec binding, e.g., <binding.celtix>, which is extended from binding element. <binding.celtix> is product type binding that supports various bindings/protocols, such as soap/http and JMS. Users need Celtix specific knowledge in order to know how to configure which binding/protocol is being used. I will create a JIRA task on the support of <binding.celtix>. Does this make sense to everyone? Cheers, Jervis -----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 2006?8?16? 22:14 To: tuscany-dev@ws.apache.org Subject: Re: Create distribution for bindings, or how to switch binding implementations I view Celtix as you said: "as a product that provides implementations to several bindings." The same can be said for Axis with its support for different transports, and I would not be surprised if there are yet more (e.g. ServiceMix). The spec has not "preserved" binding names - it is specifying a vendor-independent way of representing a binding using a common technology. It also expects there to be multiple implementations of that common binding - for example, by different SCA implementations. It fully expects that there will be other bindings defined and simply requires that such bindings have an identifying element from a different namespace (which is simply good XML). The use of "binding" in the name is good form but is not normative - you could have a binding with the name <foo:booBar> if you wanted. IMO if someone uses the spec binding (e.g. <binding.ws>) they are explicitly saying that they do not care which implementation to use - and indeed it should not matter as all implementations should conform to the spec. They may do this for portability between different platforms, or between different configurations of a platform. Alternatively, if they want to us a specific implementation then they must express that intent and the way the spec supports that to be done is through implementation-specific bindings. The spec also allows the user to specify multiple bindings at the same time - for example they could use <binding.ws>, <binding.ejb>, <axis:binding.axis> and <celtix:binding.jms> concurrently. The spec leaves it to the runtime to determine which of those are actually activated. In terms of our implementation, we have a loading mechanism that loads implementations explicitly: the single component that registered with the LoaderRegistry for an element is the one that is used to handle that element. A component can register to handle multiple elements, and the loader can choose what happens when multiple components register for the same element (IIRC at the moment it goes with the last one, it could also ignore duplicate attempts i.e. go with the first one). IMO this is simple, precise and flexible. It allows an administrator to easily configure the runtime using extensions by simply configuring in an implementation. That implementation can support a single element, or it may support multiple ones - it can even support none meaning it can only be used from non-XML based assemblies. The policy for determining what to do when multiple implementations register for the same element is determined by which implementation of LoaderRegistry is used. It uses the spec's method of choosing between implementations: using an implementation specific element. I don't see why we need to change this but if you have a use case in mind please share. -- Jeremy On Aug 16, 2006, at 3:10 AM, Liu, Jervis wrote: > Hi, > > One question has to be answered before we go any further is that we > view Axis and Celtix (and others like Xfire) as different > implementations of Web Service binding or different bindings. > > If we view them as same binding but different implementations, we > should stick to the schema of binding.ws and we have to solve the > problem I raised previously: how to switch different impl for the > same binding under the scene? This problem can be probably tackled > by some kind of loading mechanisms, like the extension dir we are > using at the moment. We may run into some limitations though, for > example, if two implementations of same binding are both available > to the loading mechanism, how to load a specific explicitly? > > If we view Axis and Celtix as different bindings, e.g., we > represent them using the schema of binding.axis and binding.celtix > as described by the extension mode in spec, we can always load axis > or Celtix explicitly, there is no need to invent a loading > mechanism, all bindings can live happily together in the extension > dir. However, I found the meaning of binding.axis or binding.celtix > is confusing and does not following the concept in spec. SCA spec > has preserved binding names for binding.ws, binding.jms, > binding.eis etc, them are all names for different bindings/ > protocols, but Axis or Celtix is really an product other than a > binding or protocol type. Celtix as an ESB, supports various > bindings/protocols besides soap/http, such as JMS and CORBA. > Conceptually, I found its more clear to view Celtix as a product > that provides implementations to several bindings (thus we can have > a Celtix version loader/builder for each bindings, e.g., > org.apache.tuscany.binding.celtix.WebServiceBindingLoader and > org.apache.tuscany.binding.celtix.JMSBindingLoader) other than > having a binding.celtix in Tuscany. > > In summary, viewing axis or celtix as different implementations to > the same binding is more clear in concept, but it needs us to > invent a loading mechanism that can load the specific > implementations explicitly. Not sure about other guys' opinion, any > thoughts or comments? > > Jeremy, I also have a question for you. What do you mean by saying > "allow the extension directory to contain simple SCDL files (xml > files) that define composites and which get their code through > dependencies"? Do you mean adding a SCDL for extension dir to > describe all extensions available under the extension dir? Then we > take this scdl as a single composite that can be deployed into > runtime? But this does not seem to address the loading problem > (when multiple implementations available). > > Thanks, > Jervis > > >> -----Original Message----- >> From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, August 15, 2006 7:48 PM >> To: tuscany-dev@ws.apache.org >> Subject: RE: Create distribution for bindings, or how to >> switch binding >> implementations >> >> >> Jervis, >> >> Few thoughts ... >> >> I think flexibility and ease of use is important in terms of >> switching >> between bindings, not just two implementations of the same transport >> (for example axis and XFire for WS binding), but also between two >> different transports (WS and JMS for example). With one of the ESBs I >> have been using it is as simple as switching the protocol in the >> endpoint URI for the target component. For example, you can switch >> between Axis to XFire, by changing the endpoint URI of the component >> from axis:http://localhost:81/services to >> xfire:http://localhost:81/services, and if you want to switch >> from WS to >> JMS, it is as simple as changing the URI to jms://myQueue. I think >> the >> gist is providing the flexibility to expose the services over >> a variety >> of transports, even more than one if that is deemed >> necessary. According >> to my understanding this issues are all addressed by the SCA spec. >> >> I think the spec mandates support for SCA and web services >> bindings and >> talks about having extensibility mechanisms for other kinds >> of bindings. >> Though it should be possible to expose services across multiple >> bindings, multiple implementations of the same transport >> (XFire and Axis >> for example) wouldn't make much sense, as the implementation >> type itself >> is transparent to the service consumer, unless different >> ports are used >> by the different bindings. I think, may be the issue is the mandatory >> binding binding.ws from the spec perspective. You could look at >> binding.ws as the default WS binding used by the SCA runtime >> implementation (using axis for example) and to use a different WS >> binding one could use the extension model and have a binding like >> binding.ws.xfire. >> >> Ta >> Meeraj >> >> -----Original Message----- >> From: Liu, Jervis [mailto:[EMAIL PROTECTED] >> Sent: 15 August 2006 03:56 >> To: tuscany-dev@ws.apache.org >> Subject: Create distribution for bindings, or how to switch binding >> implementations >> >> Hi, >> >> I can see from yesterday's IRC chat that we had a quick discussion on >> how to create distribution for bindings. I think the main >> problem we are >> facing is how to switch binding implementations. For example, we may >> want to switch the implementation of binding.ws between axis2 >> and celtix >> for helloworldws sample, in an easy and user friendly way. >> The approach >> Jeremy proposed should work: package the binding as an extension and >> somehow install it into the runtime(put it into the extension >> dir?) . So >> this is definitely one option. But I think we should also provide >> alternatives to better address following scenarios: >> >> 1, Tuscany users installed a generic Tuscany distribution, and they >> would like to be able to switch binding implementations without >> moving >> libraries around or changing any directories. I think we can improve >> usability if users only need to change a config file. >> >> 2. Some applications may want to use two binding >> implementations at the >> same time. >> >> It seems to me that we will need a configuration somewhere to specify >> the specific binding implementation. Can we have a >> proprietary entry in >> scdl file sth like <binging.ws.axis2/> or <binding.ws >> bindingImplementation=axis/>? Any comments are welcome. To >> better track >> this thread, I have created jira 621. >> https://issues.apache.org/jira/browse/TUSCANY-621. I also enclosed >> relevant IRC chat log for your info. >> >> Thanks, >> Jervis >> >> (05:27:47) cr22rc: jboynes : I'm ok about taking it out .. >> but what are >> we looking for doing for samples needing axis wsbservice binding >> (05:28:44) jboynes: I want to package the axis binding as an >> extension >> that can be installed in the runtime >> (05:29:46) jboynes: so to run the sample you add the axis >> extension to >> your installation >> (05:30:43) ant: or we may have a distribution that includes >> axis right? >> (05:31:03) jboynes: sure >> (05:32:32) jboynes: I want to make sure that the basic >> concept (core + a >> bunch of extensions) works >> (05:33:19) kgoodson left the room (quit: Read error: 110 (Connection >> timed out)). >> (05:33:23) ant: could we talk about the ServletHost stuff now? >> (05:33:33) jboynes: so we don't end up in a situation where >> an extension >> only works if it is packed into a distro in a special way >> (05:33:40) jboynes: I need a couple more >> (05:33:48) jboynes: I need to eat >> (05:35:32) ant: ok, well ping when you're ready >> (05:48:04) jboynes: ant: hi, better now I've had breakfast :) >> (05:48:30) ant: yum >> (05:48:31) jboynes: sorry for holding things up - I just reached the >> pass out or get cranky phase >> (05:48:48) dkulp left the room (quit: "using sirc version >> 2.211+KSIRC/1.3.12"). >> (05:49:19) ant: ok so there's an interface ServletHost >> (05:50:02) jboynes: yep >> (05:50:10) ant: so the WS binding should use that to register >> a servlet >> for each ws endpoint >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> >> >> ***************************************************** >> >> You can find us at www.voca.com >> >> ***************************************************** >> This communication is confidential and intended for >> the exclusive use of the addressee only. You should >> not disclose its contents to any other person. >> If you are not the intended recipient please notify >> the sender named above immediately. >> >> Registered in England, No 1023742, >> Registered Office: Voca Limited >> Drake House, Three Rivers Court, >> Homestead Road, Rickmansworth, >> Hertfordshire, WD3 1FX >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
