Re: [DISCUSS] Declaring extensions as being available in the domain
Thanks thats helpful. Let me take this to the extreme so you can point out where it loses the plot to help me understand what you're saying: The idea is eventually there might be standardized interfaces for all the SCA runtime plug points, many of the Tuscany things for the various SCDL and SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have in org.apache.tuscany.sca namespace might one day be standardized interfaces, just like the org.osoa.sca.* interfaces for application Java implementations to use, and there would be a standard way to define new binidng and implementation extensions in the definitions.xml. Anyone could make an SCA contribution that would add a binding or implementation type which once contributed to an SCA domain then other contributions in the domain could use in their SCA assemblies. And this new binding contribution would work in any runtime that supported SCA just like application SCA contributions should. So as a simple example, say a file binding that component service or references could use to read and write to a file system. That could be packaged in a regular jar which has a meta-inf/definitions.xml along the lines of: definitions ... bindingType type=binding.file ... ...elements and attributes defining the binding.file schema and implementation classes ... /bindingType /definitions and all the file binding implementation classes within that file binding contribution jar would implement only standard interfaces, nothing at all Tuscany specific in the contribution. The splitting out all the various Tuscany SCDL classes and SPIs points into interfaces happened when we did the 0.90 rewrite so binding and implementation type extensions can now be written using only interfaces, but the pluggablity mechanism is still quite Tuscany specific. So is whats being suggested with this definitions.xml work starting on the road to coming up with a less Tuscany specific way of doing that, it would still be in a Tuscany namespace for now just as the various Tuscany SPI interfaces are, but in the future all this would be defined in some SCA spec , but it would just be a refactor in Tuscany to move to that spec namespace instead of a complete rewrite? Is that anything like what you had in mind? ...ant On Thu, May 15, 2008 at 7:32 PM, scabooz [EMAIL PROTECTED] wrote: I might be the 'they', not sure. This is a very hard email thread to follow so let me try to articulate some ideas. First, bindingType and implementationType were introduced by the SCA Policy FW spec because that spec was the first to need a bit of metadata describing bindings from a typing perspective so that policy could be provided by the type and didn't have to be repeated on every binding instance. Implementation types was an obvious next stop on the journey. The text was driven into the Assembly spec as the result of a realization that these two concepts would be needed by SCA extenders who wish to add bindings and new kinds of components into any SCA runtime that was implemented by some another party. The assembly spec group decided (rightly IMHO) NOT to dive more deeply into filling out these concepts in V1.0. It would be more appropriate to tackle these sorts of issues in a future revision of the technology. Second, Tuscany is an open community where the plethora of talent enables new innovative ideas to be explored. These extensibility points are a great place for Tuscany to experiment with different approaches. I think it would be fantastic if Tuscany could finish the work of the spec group and come up with a reasonable (and workable) model for extensibility and then propose it to the spec group. Building on this thought then is the assertion that bindingType is the starting point for 3rd parties to describe a binding implementation to a runtime not authored by the binding implementer. It would be naive to think that the current structure of bindingType, it's containment within a defintions.xml file or any other related aspect is off limits from change in this experiment. I'm not clear on what all the issues are that have been raised. I see a lot of mis-information and some emotion that's hard to sort through. I saw a strawman that looked like a good start in one of the emails but there seemed to be resistance that I didn't understand. The SCA bindingType and implementationType concepts have nothing to do with policy. Policy was the first functional area that happened to see the need for them. Dave - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 13, 2008 2:40 AM Subject: Re: [DISCUSS] Declaring extensions as being available in the domain On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though
Re: [DISCUSS] Declaring extensions as being available in the domain
Responses inline...for some reason my email client is mishandling the formatting, so I'll mark my responses with dab /dab Dave - Original Message - From: ant elder To: scabooz Cc: tuscany-dev@ws.apache.org Sent: Tuesday, May 20, 2008 2:03 PM Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Thanks thats helpful. Let me take this to the extreme so you can point out where it loses the plot to help me understand what you're saying: The idea is eventually there might be standardized interfaces for all the SCA runtime plug points, many of the Tuscany things for the various SCDL and SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have in org.apache.tuscany.sca namespace might one day be standardized interfaces, just like the org.osoa.sca.* interfaces for application Java implementations to use, and there would be a standard way to define new binidng and implementation extensions in the definitions.xml. dab Yes, that is the idea/theory. /dab Anyone could make an SCA contribution that would add a binding or implementation type which once contributed to an SCA domain then other contributions in the domain could use in their SCA assemblies. And this new binding contribution would work in any runtime that supported SCA just like application SCA contributions should. dab yes /dab So as a simple example, say a file binding that component service or references could use to read and write to a file system. That could be packaged in a regular jar which has a meta-inf/definitions.xml along the lines of: definitions ... bindingType type=binding.file ... ...elements and attributes defining the binding.file schema and implementation classes ... /bindingType /definitions and all the file binding implementation classes within that file binding contribution jar would implement only standard interfaces, nothing at all Tuscany specific in the contribution. dab Good. Only thing to add at this point is that the spec might decide that the jar should be an OSGI bundle. Would such a estriction help, or get in the way? /dab The splitting out all the various Tuscany SCDL classes and SPIs points into interfaces happened when we did the 0.90 rewrite so binding and implementation type extensions can now be written using only interfaces, but the pluggablity mechanism is still quite Tuscany specific. So is whats being suggested with this definitions.xml work starting on the road to coming up with a less Tuscany specific way of doing that, it would still be in a Tuscany namespace for now just as the various Tuscany SPI interfaces are, but in the future all this would be defined in some SCA spec , but it would just be a refactor in Tuscany to move to that spec namespace instead of a complete rewrite? dab Bingo. /dab Is that anything like what you had in mind? ...ant On Thu, May 15, 2008 at 7:32 PM, scabooz [EMAIL PROTECTED] wrote: I might be the 'they', not sure. This is a very hard email thread to follow so let me try to articulate some ideas. First, bindingType and implementationType were introduced by the SCA Policy FW spec because that spec was the first to need a bit of metadata describing bindings from a typing perspective so that policy could be provided by the type and didn't have to be repeated on every binding instance. Implementation types was an obvious next stop on the journey. The text was driven into the Assembly spec as the result of a realization that these two concepts would be needed by SCA extenders who wish to add bindings and new kinds of components into any SCA runtime that was implemented by some another party. The assembly spec group decided (rightly IMHO) NOT to dive more deeply into filling out these concepts in V1.0. It would be more appropriate to tackle these sorts of issues in a future revision of the technology. Second, Tuscany is an open community where the plethora of talent enables new innovative ideas to be explored. These extensibility points are a great place for Tuscany to experiment with different approaches. I think it would be fantastic if Tuscany could finish the work of the spec group and come up with a reasonable (and workable) model for extensibility and then propose it to the spec group. Building on this thought then is the assertion that bindingType is the starting point for 3rd parties to describe a binding implementation to a runtime not authored by the binding implementer. It would be naive to think that the current structure of bindingType, it's containment within a defintions.xml file or any other related aspect is off limits from change in this experiment. I'm not clear on what all the issues are that have been raised. I see a lot of mis-information and some emotion that's hard to sort
Re: [DISCUSS] Declaring extensions as being available in the domain
I might be the 'they', not sure. This is a very hard email thread to follow so let me try to articulate some ideas. First, bindingType and implementationType were introduced by the SCA Policy FW spec because that spec was the first to need a bit of metadata describing bindings from a typing perspective so that policy could be provided by the type and didn't have to be repeated on every binding instance. Implementation types was an obvious next stop on the journey. The text was driven into the Assembly spec as the result of a realization that these two concepts would be needed by SCA extenders who wish to add bindings and new kinds of components into any SCA runtime that was implemented by some another party. The assembly spec group decided (rightly IMHO) NOT to dive more deeply into filling out these concepts in V1.0. It would be more appropriate to tackle these sorts of issues in a future revision of the technology. Second, Tuscany is an open community where the plethora of talent enables new innovative ideas to be explored. These extensibility points are a great place for Tuscany to experiment with different approaches. I think it would be fantastic if Tuscany could finish the work of the spec group and come up with a reasonable (and workable) model for extensibility and then propose it to the spec group. Building on this thought then is the assertion that bindingType is the starting point for 3rd parties to describe a binding implementation to a runtime not authored by the binding implementer. It would be naive to think that the current structure of bindingType, it's containment within a defintions.xml file or any other related aspect is off limits from change in this experiment. I'm not clear on what all the issues are that have been raised. I see a lot of mis-information and some emotion that's hard to sort through. I saw a strawman that looked like a good start in one of the emails but there seemed to be resistance that I didn't understand. The SCA bindingType and implementationType concepts have nothing to do with policy. Policy was the first functional area that happened to see the need for them. Dave - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 13, 2008 2:40 AM Subject: Re: [DISCUSS] Declaring extensions as being available in the domain On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the present moment my belief is that it could evolve to represent information more than just policy related things. This belief of mine is based on the following : - - the name of the file is 'definitions.xml' and is not 'policy-definitions.xml' - this is defined in the assembly model specs and not in the PolicyFwk specs. If its just for policies, I'd reckon that it would have been defined completely in the PolicySpecs and only referred to in the Assembly Model specs. Right now its vice-versa. Maybe some Specs folks should give us their perspective on this. - Venkat Those are good points. Especially the last one as its they that ask for this in an offline discussion so it would be really good to get their input here. ...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
Yes, I think each of those specific ones should be allowed to have its own definitions.xml and bindingType info simply because each of them could have their own list what intents it provides inherently. Maybe I am missing the alternative here. - Venkat On Tue, May 13, 2008 at 2:54 AM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the present moment my belief is that it could evolve to represent information more than just policy related things. This belief of mine is based on the following : - - the name of the file is 'definitions.xml' and is not 'policy-definitions.xml' - this is defined in the assembly model specs and not in the PolicyFwk specs. If its just for policies, I'd reckon that it would have been defined completely in the PolicySpecs and only referred to in the Assembly Model specs. Right now its vice-versa. Maybe some Specs folks should give us their perspective on this. - Venkat On Tue, May 13, 2008 at 11:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes, I think each of those specific ones should be allowed to have its own definitions.xml and bindingType info simply because each of them could have their own list what intents it provides inherently. Maybe I am missing the alternative here. - Venkat On Tue, May 13, 2008 at 2:54 AM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany= http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
On Mon, May 12, 2008 at 10:24 PM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. I don't think thats quite true, as Venkat said there can be multiple definitions files and they get merged together so its no problem at all for each extension to its on extension specific file. ...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the present moment my belief is that it could evolve to represent information more than just policy related things. This belief of mine is based on the following : - - the name of the file is 'definitions.xml' and is not 'policy-definitions.xml' - this is defined in the assembly model specs and not in the PolicyFwk specs. If its just for policies, I'd reckon that it would have been defined completely in the PolicySpecs and only referred to in the Assembly Model specs. Right now its vice-versa. Maybe some Specs folks should give us their perspective on this. - Venkat Those are good points. Especially the last one as its they that ask for this in an offline discussion so it would be really good to get their input here. ...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
On Mon, May 12, 2008 at 10:24 PM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien So I get the impression that you don't like this but you neglect to say whether you think the spec means this or not. Would be useful to know as if we think the spec means that we have to do more with the definitions.xml file and Tuscany doesn't want to do it then we have to take our concerns elsewhere. Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
My understanding is the definitions.xml from the SCA spec can be used to describe what the bindingType/implementationType always or may provide certain intents by the nature of the binding. That's why I think the tuscany extension declaration should be separate from the definitions.xml. Thanks, Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Monday, May 12, 2008 2:34 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain On Mon, May 12, 2008 at 10:24 PM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien So I get the impression that you don't like this but you neglect to say whether you think the spec means this or not. Would be useful to know as if we think the spec means that we have to do more with the definitions.xml file and Tuscany doesn't want to do it then we have to take our concerns elsewhere. Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
Simon, that's pretty much what comes to my mind as well. However, I am still not convinced that the specs says that having the bindingType definition is pre-req to the binding being available. I still feel, what one finds in a definitions.xml is just meta-data about an extension that is already available i.e. presence of this sort of a definition for an extension is consequential to the loading and availability of the extension. - Venkat On Thu, May 8, 2008 at 9:03 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant Well we could. We still need to discover the definition.xml files in some way, for example by putting them
Re: [DISCUSS] Declaring extensions as being available in the domain
On Thu, May 8, 2008 at 4:33 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant Well we could. We still need to discover the definition.xml files in some way, for example by putting them in a common place such as META-INF where the services info is currently stored. Then we need to load the various extension implementations for each extension. Could we use the services mechanism to do this for a single extension jar? If so it just seems to be a matter of priority. I.e load the defintions.xml first in a Tuscany specific way. If there is a suitable bindingType etc. then load the various extension implementation
Re: [DISCUSS] Declaring extensions as being available in the domain
Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat On Sun, May 11, 2008 at 3:37 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:33 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant Well we could. We still need to discover the definition.xml files in some way, for example by putting them in a common place such as META-INF where the services info is currently stored. Then
[DISCUSS] Declaring extensions as being available in the domain
In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml. And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? Regards Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. Regards Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] wrote: In the SCA Policy framework spec there is a section that talks about bindingType as it appears in the definitions.xml file(s). It says... 702 The bindingType element is used to declare a class of binding available in a SCA Domain. It declares 703 the QName of the binding type, and the set of intents that are natively provided using the optional 704 @alwaysProvides attribute. I hadn't noticed this before but the implication of these words appears to be that a particular binding is not available for use in a domain unless there is a 709 bindingType type=NCName 710 alwaysProvides=listOfQNames? 711 mayProvide=listOfQNames?/ element in the aggregate definitions.xml file. I guess this also applies to implementationType (which is defined in the assembly spec) and interfaceType and databindingType (which aren't defned in the assembly spec so I just made them up here) I am not sure if that's the implication. These defintions are a bit of meta-data about the binding-types and implementation-types in the domain and at the present moment this is restricted to the policy area i.e. the meta data today only talks about the intents supported in some way by an extension. I suppose in the future there could be a few other things that could get added as well. Upto now there no information there that is absolutely necessary to get an extension's basic functionality going. So if its not present nothing actually comes in the way with the basic functioning of the extension. However if you were to specify a policy intent which is inherently supported by the extension but the type info is missing, then the PolicyFwk will complain saying it does not have a PolicySet for this intent. The simple reason being the it does not know that the extension inherently supports this intent. Currently Tuscany uses the Java services approach to detect and load extensions. If an extension is loaded it is available for use. We don't check that bindingType, implementationType, etc is declared before making an extension available. As it happens some for our extensions include a defintions.xml file, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml . And in this particular example a bindingType is defined. However this is not true of all of our extensions. Should we enforce the presence of a definitions.xml file in our extensions and enforce that it contains an appropriate ?Type elemenent? On the face of it there seems little benefit to doing this given our Tuscany specific scheme for loading extensions. However it would tip our hat to the spec, assuming we agree this is what the spec means, and give us a place to put other extension configuration information it the need were to arise. Thoughts? At the present moment I think its all very fine to load the extension even if the type info is not present. For instance if an extension has no intent that it supports inherently then there is no much need for the type info. However, if the scope of type info expands further to include more fundamental things that influence the basic functioning of the extension then we should probably enforce this for the simple reason that we cannot bring the extn up without its information. I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant Well we could. We still need to discover the definition.xml files in some way, for example by putting them in a common place such as META-INF where the services info is currently stored. Then we need to load the various extension implementations for each extension. Could we use the services mechanism to do this for a single extension jar? If so it just seems to be a matter of priority. I.e load the defintions.xml first in a Tuscany specific way. If there is a suitable bindingType etc. then load the various extension implementation artifacts again in a Tuscany specific way to make the extension available. I'm assuming here that the definitions.xml file for an extension is packaged with the extension jar. Simon
