(I apologize in advance for the length of this email... After meeting with Jim and Sebastien for the last two days, there are a LOT of thoughts swirling around in my head....)
One of the questions that came up in the discussions was something along the lines of "if a user wants to replace the Axis 2 ws implementation with Celtix, how would they do it?" Or, more generally: "In tuscany, if I want to replace XXXX with YYYY where YYYY is functionally equivalent, how can I do it?" (XXXX being a binding.*, container.*, etc...) The "simple" answer is something along the lines of: delete the XXXX jars, add the YYYY jars, muck with the classpath, done. However, that really sucks. Telling users to muck with things down on that level is usually not a good idea and can generally result in bad things happening. The other problem with this approach is that there is no way that a user could use BOTH XXXX and YYYY in the same system since XXXX is completely deleted. One idea I came up with is a concept of "aliasing". All components would always register with a very specific name. Instead of binding.ws, it would be binding.axis2; instead of container.js, it would be container.rhino, etc... Tuscany would then have some configuration that would "bind" the specific name to the "generic" name. This could come from a config file, a system property, etc.... If the user want to change the underlying implementation of one of the generic One advantage of this that the user then has more control in their assembly. If they want to use a more "portable" form and allow the sca/tuscany runtime to use the default, they can do something like "implementation.js" or "binding.ws" and the tuscany runtime would use the appropriate one that is configured. However, if the user wants the specific version (using some advanced feature of axis or something...), they can specifically use "binding.axis2" or "implementation.rhino". It allows complete coexistence. In a module, you could actually use both "binding.axis2" and "binding.celtix" as well as the default "binding.ws" that may or may not point to one of them. The next "issue" this brings up is how to provide a usable system if the user HASN'T configured anything (zero config) as well as validate that a user that has configured something hasn't shot themself in the foot. On thought with this is that when something registers with the system, it not only registers it's name, but also can return a list of services it can provide. Example: Name: binding.axis2, Provides: binding.ws With that additional bit of information, the runtime could automatically wire stuff up with no configuration as well as validate configuration. (example: I alias "binding.ws" to "binding.jsonrpc". That shouldn't work since jsonrpc doesn't provide that service.) In the case where there are two or more implementations that provide a service, it could be a "first one registered" or "undetermined" or anything. The other thing about this is that a single "thing" could possibly provide multiple services. Example: Name: binding.celtix Provides: binding.ws, binding.corba, binding.blah) Anyway, I just wanted to start a discussion about this. This is going to be important as we start getting Celtix more integrated. Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
