Re: [VOTE] Rewrite kernel model to be based on interfaces
Meeraj, My comments inline. I thought we were going to continue this discussion back in the context of the "Componentizing our runtime" thread at http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html, but the discussion there has stopped, so I'll respond here. Meeraj Kunnumpurath wrote: I can't see how kernel modularization is related to interface based models. Model is only part of the SPI, SPI also provides a set os services, which all have well-defined contracts. Interfaces are important to achieve modularization, define clear and minimal contracts between modules, minimize dependencies and shield modules from implementation changes in others. I'm not sure why we're picking on the models in particular as this design principle applies to all the modules that present SPIs. This applies to all SPIs, but one of the benefits of using model interfaces is the ability to use alternate implementations of these interfaces and/or combine these interfaces with others. To illustrate this I am prototyping the following (in my sandbox at the moment): - The ability for the model to expose different APIs: the base model API in sca/modules/assembly as well as a different "model builder" API in sca/modules/builder. - The ability to have a significantly different implementation of the model, backed by Spring bean definitions for example. I am starting to experiment with this in sca/modules/bean and sca/modules/bean-test and just committed it to my sandbox so that people can take a look. In both cases, the other modules (SCDL handling for example) don't see a difference between the default assembly model implementation under sca/modules/assembly and the variant implementations, they just talk to the same interfaces. More generally, I'd like SCA and its assembly model to be consumable in many different environments, Apache products, J2EE app servers and tool environments, and become as pervasive as the WSDL model for example. Clean interfaces not exposing the implementation details and allowing for alternate implementations will help achieve that goal. I am not sure what extra benefits we have by supporting different data binding mechanisms for the model objects. If I remember right, we had this discussion a long while ago and we decided to go with Java based model objects. I'm not sure that there's a great case for alternate implementations of the model directly backed by XML databinding technologies. A straight mapping to XML using an XML databinding may not be able to populate the logical relationships (e.g. ComponentReferences pointing to target ComponentServices) that you'll expect in a logical assembly model. On the other hand I think it will be useful to be able to implement the model using a modeling technology for integration with tooling for example, or in a form that can be easily backed by a database or some other form of repository. I have never found a need to mock model objects in the tests, as the model objects, as I said earlier, don't have any behaviour. We often mock, service objects that do have behaviour. I don't think that a model never implements any behaviour. The current model in trunk actually already has a little bit of behaviour (for example to synchronize bi-directional relationships or clone itself). I spent some time today working with the Spring bean model and they have some behaviour in their model. If I remember correctly the WSDL model implements some behaviour to resolve portTypes in imported WSDLs for example. As we start to implement more of the actual SCDL spec I'm sure we're going to have to add more behaviour as well, at least to validate/enforce some integrity constraints in the model. If this about modularizing SPI, I would say it is an affort worth discussing. However, the model changes, I can't see any visible benefit in doing that. Since we have already had discussion on this during M1 and we decided to go with Java based POJO model classes, I believe it is water under bridge and can't see the point in bringing this up again. This is about modularizing SPIs, using interfaces, and the assembly model is one of these core SPIs. The discussion we had in M1 was polarized around using SDO, EMF or POJOs, this is not the point here. Ta Meeraj -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Jeremy, Please allow time for discussion. Please withdraw this vote as it is getting hijacked because discussion is not over yet. thanks, dims On 3/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Raymond Feng wrote: > Hi, > > Here's my vote. > > [X] +1 we should do this > [ ] -1 keep things as they are > > The vote is based on my understanding of the benefits of > interface-based models as follows. > > 1) Better pluggability for the model implementation and loading: We > can easily generate the model and loading code using Java/XML binding > frameworks such as JAXB, SDO and XMLBeans. > > 2) Better relationship between model objects: One java class can > implement multiple interfaces, for example, we can use "Extensible" > interface to represent the SCDL extensibilities and "Promotable" to > represent models eligible for promotion. > > 3) Better isolation for dependencies: Other modules only have to > depend on the model interfaces for compilation. We don't have to > release the model interfaces if we just have to fix issues in the > implementation classes without breaking the contract. > > 4) Simpler interface-based mocking for unit tests > > 5) Other projects use interface-based modeling such as Axiom, DOM, > WSDL4J and Woden > > Thanks, > Raymond > > - Original Message ----- From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, March 20, 2007 7:23 AM > Subject: [VOTE] Rewrite kernel model to be based on interfaces > > >> The current model is based on simple POJOs. Sebastien has proposed >> rewriting the configuration model to be based on interfaces with >> separate implementation and factory classes. This will have a major >> impact on the kernel code and all extensions. This vote is not about >> what is in the model, it's is about how the model itself is implemented. >> >> [ ] +1 we should do this >> [ ] -1 keep things as they are >> >> If I was going to vote I would probably vote +1 since I'm doing this work :) but I'm not ready to vote on it yet, as I'm not sure why a vote thread popped up so quickly, independent of the thread I started yesterday to get input from our community and have a technical discussion on the subject: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Raymond Feng wrote: Hi, Here's my vote. [X] +1 we should do this [ ] -1 keep things as they are The vote is based on my understanding of the benefits of interface-based models as follows. 1) Better pluggability for the model implementation and loading: We can easily generate the model and loading code using Java/XML binding frameworks such as JAXB, SDO and XMLBeans. 2) Better relationship between model objects: One java class can implement multiple interfaces, for example, we can use "Extensible" interface to represent the SCDL extensibilities and "Promotable" to represent models eligible for promotion. 3) Better isolation for dependencies: Other modules only have to depend on the model interfaces for compilation. We don't have to release the model interfaces if we just have to fix issues in the implementation classes without breaking the contract. 4) Simpler interface-based mocking for unit tests 5) Other projects use interface-based modeling such as Axiom, DOM, WSDL4J and Woden Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Tuesday, March 20, 2007 7:23 AM Subject: [VOTE] Rewrite kernel model to be based on interfaces The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [ ] -1 keep things as they are If I was going to vote I would probably vote +1 since I'm doing this work :) but I'm not ready to vote on it yet, as I'm not sure why a vote thread popped up so quickly, independent of the thread I started yesterday to get input from our community and have a technical discussion on the subject: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
On Mar 20, 2007, at 9:26 AM, Venkata Krishnan wrote: Hi Jeremy, As part of this discussion and vote could we also summarize the technical reasons for each of us to be going one way or the other. Since this is a major decision point it would be good for everybody to know why we as a community are taking a specific direction and helps us to get back to these design decisions in the future whenever in doubt. I am really keen on understanding each of our technical perspectives in this regard and not necessary in the context of weighing opinions for this vote. I would too. We have actually had this discussion before, around this time last year, and went with simple POJOs because they were easier to use and did not require people to write several classes to wrap a single field. The responsibility of conversion to/from XML was treated as a problem for an XML binding and, at the time, the SDO folk said they would look at a mechanism for loading user-supplied POJOs (much like JAXB already allows). Here is my attempt at this... [X] +1 we should do this [ ] -1 keep things as they are My Reasons : (from whatever little I have been thro) - I see that the interfaces will help us align better with the assembly model stated in the specs. I agree we need to evolve the current model in line with the spec but that is about model content and not about whether the model is implemented as POJOs or interfaces. I wanted to keep discussion of what we need to do to evolve the model separate from this discussion. What is publicly available out of the model is just about what is published in the interfaces and that is just about what the core (or extensions) should be using. Otherwise we might encapsulate into the model all that our core implementation would ideally need. Also basing the model on interfaces us flexibility in that while the model's implementation undergoes change the core that uses it continues unaffected. Thing is, there is no implementation in the model - it is a bunch of simple POJO beans, structs with accessors (I consider set/get methods as a syntactic convention). Interfaces have a role in abstracting implementation but here there is no implementation to abstract. But then we've been here before ... -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
I can't see how kernel modularization is related to interface based models. Model is only part of the SPI, SPI also provides a set os services, which all have well-defined contracts. I am not sure what extra benefits we have by supporting different data binding mechanisms for the model objects. If I remember right, we had this discussion a long while ago and we decided to go with Java based model objects. I have never found a need to mock model objects in the tests, as the model objects, as I said earlier, don't have any behaviour. We often mock, service objects that do have behaviour. If this about modularizing SPI, I would say it is an affort worth discussing. However, the model changes, I can't see any visible benefit in doing that. Since we have already had discussion on this during M1 and we decided to go with Java based POJO model classes, I believe it is water under bridge and can't see the point in bringing this up again. Ta Meeraj From: Jim Marino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Date: Tue, 20 Mar 2007 08:56:40 -0700 On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X ] -1 keep things as they are -1 from me. This is an alternative implementation of what we have with kernel and not just a simple "model refactor" or "modularization". Many of the changes include rolling back directions we decided to take following the issues encountered with M1. For example, the move away from pure POJOs and the reintroduction of AssemblyFactory, the renaming of model objects (e.g. ComponentDefinition to Component) which will clash with the current runtime extension model, and the way model references are maintained. It's unclear how these changes will impact the rest of kernel or why they were necessary. I understand we need to have a model that more accurately reflects SCA 1.0. We've been doing this incrementally to date. Why can't they existing model be evolved? If someone wants to take the model design in a radically new direction, I'm fine with doing so but I don't think it should be done in trunk at this point. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Txt a lot? Get Messenger FREE on your mobile. https://livemessenger.mobile.uk.msn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi, I don't get a formal vote, but as an embedder it is extremely painful to consume and embed a new level of code when the SPI layer (that's supposed to insulate embedders) is changing as often as the underlying kernel implementation. At the moment, the current SPI layer might as well be invisible. I'm not looking for n-1 compatibility in the SPI layer. I'm not expecting zero changes in the SPI layer over time. I am expecting increasing stability over time, which I do not observe, and have not observed for some time. The stable branch is helping in this regard, but I think more will be needed in order to allow an embedder to pick up the function they need. In reading over the related email threads from which this spawned, I would certainly benefit from a decomposition of the kernel as described. There's lots of good work going on in this project, but not all of it is applicable when embedding into an existing runtime. The work on a distributed SCA Domain is an example. I think it's good for that piece of work to continue. The kind design that's proposed for this decomposition will enable the movement of stable new function from the head into the stable branch. As it is now, the stable branch will have to consume everything from head and then stabilize it. That's not a viable model moving forward. A decomposition would also enable me to ignore pieces of function forever, or until it's ready. A clean model definition, which enables plug replace-able parts of the kernel is exactly what is needed. It enables the use of the model at various integration points of an existing runtime. That is, a clean model definition that doesn't change every day. 2 cents from an imbedder. Dave - Original Message - From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]> To: Sent: Tuesday, March 20, 2007 11:46 AM Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Hi, I would like a more elaborate explanation on what is meant in this context by interfaces, factory classes and separate implementations. As we are now, our model classes just encapsulate state, with hardly any behaviour. We quite nicely separate model from the runtime artifacts by moving behaviour to controller classes that translate the model to runtime artifacts. So, if the model classes are just state, why would we want to define interfaces for them and separate implementations, as there is no behaviour to be abstracted. Also, there have been a lot of work that has happened in trunk in the last month or so, in terms of seprarating the physical and logical aspects of the model. We need to take into consideration the impact of this approach on the physical model work, which is very much nearing completion now with the federated deployment story. At this stage by inclination would be to go -1, as I can't see a compelling reason for changing the current design. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Date: Tue, 20 Mar 2007 07:25:15 -0700 On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X] -1 keep things as they are My opinion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - 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]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi, Here's my vote. [X] +1 we should do this [ ] -1 keep things as they are The vote is based on my understanding of the benefits of interface-based models as follows. 1) Better pluggability for the model implementation and loading: We can easily generate the model and loading code using Java/XML binding frameworks such as JAXB, SDO and XMLBeans. 2) Better relationship between model objects: One java class can implement multiple interfaces, for example, we can use "Extensible" interface to represent the SCDL extensibilities and "Promotable" to represent models eligible for promotion. 3) Better isolation for dependencies: Other modules only have to depend on the model interfaces for compilation. We don't have to release the model interfaces if we just have to fix issues in the implementation classes without breaking the contract. 4) Simpler interface-based mocking for unit tests 5) Other projects use interface-based modeling such as Axiom, DOM, WSDL4J and Woden Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Tuesday, March 20, 2007 7:23 AM Subject: [VOTE] Rewrite kernel model to be based on interfaces The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [ ] -1 keep things as they are - 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]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi Jeremy, As part of this discussion and vote could we also summarize the technical reasons for each of us to be going one way or the other. Since this is a major decision point it would be good for everybody to know why we as a community are taking a specific direction and helps us to get back to these design decisions in the future whenever in doubt. I am really keen on understanding each of our technical perspectives in this regard and not necessary in the context of weighing opinions for this vote. Here is my attempt at this... [X] +1 we should do this [ ] -1 keep things as they are My Reasons : (from whatever little I have been thro) - I see that the interfaces will help us align better with the assembly model stated in the specs. What is publicly available out of the model is just about what is published in the interfaces and that is just about what the core (or extensions) should be using. Otherwise we might encapsulate into the model all that our core implementation would ideally need. Also basing the model on interfaces us flexibility in that while the model's implementation undergoes change the core that uses it continues unaffected. Thats one that I see immd. from whatever I am working currently. Thanks - Venkat On 3/20/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: > The current model is based on simple POJOs. Sebastien has proposed > rewriting the configuration model to be based on interfaces with > separate implementation and factory classes. This will have a major > impact on the kernel code and all extensions. This vote is not > about what is in the model, it's is about how the model itself is > implemented. > > [ ] +1 we should do this > [X] -1 keep things as they are My opinion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X ] -1 keep things as they are -1 from me. This is an alternative implementation of what we have with kernel and not just a simple "model refactor" or "modularization". Many of the changes include rolling back directions we decided to take following the issues encountered with M1. For example, the move away from pure POJOs and the reintroduction of AssemblyFactory, the renaming of model objects (e.g. ComponentDefinition to Component) which will clash with the current runtime extension model, and the way model references are maintained. It's unclear how these changes will impact the rest of kernel or why they were necessary. I understand we need to have a model that more accurately reflects SCA 1.0. We've been doing this incrementally to date. Why can't they existing model be evolved? If someone wants to take the model design in a radically new direction, I'm fine with doing so but I don't think it should be done in trunk at this point. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
Hi, I would like a more elaborate explanation on what is meant in this context by interfaces, factory classes and separate implementations. As we are now, our model classes just encapsulate state, with hardly any behaviour. We quite nicely separate model from the runtime artifacts by moving behaviour to controller classes that translate the model to runtime artifacts. So, if the model classes are just state, why would we want to define interfaces for them and separate implementations, as there is no behaviour to be abstracted. Also, there have been a lot of work that has happened in trunk in the last month or so, in terms of seprarating the physical and logical aspects of the model. We need to take into consideration the impact of this approach on the physical model work, which is very much nearing completion now with the federated deployment story. At this stage by inclination would be to go -1, as I can't see a compelling reason for changing the current design. Ta Meeraj From: Jeremy Boynes <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces Date: Tue, 20 Mar 2007 07:25:15 -0700 On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X] -1 keep things as they are My opinion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get Hotmail, News, Sport and Entertainment from MSN on your mobile. http://www.msn.txt4content.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
+1 I'm not sure that the proposal is exactly "Rewrite kernel model to be based on interfaces" but for the sake of this vote I'm +1. Note also that the current trunk code has been undergoing major changes recently/currently anyway and has already made major changes to the extension SPIs with more to come. If there's going to be impact by this modularization/componentization work then now seems a perfect time for that to happen. ...ant On 3/20/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [ ] -1 keep things as they are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Rewrite kernel model to be based on interfaces
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote: The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [X] -1 keep things as they are My opinion. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Rewrite kernel model to be based on interfaces
The current model is based on simple POJOs. Sebastien has proposed rewriting the configuration model to be based on interfaces with separate implementation and factory classes. This will have a major impact on the kernel code and all extensions. This vote is not about what is in the model, it's is about how the model itself is implemented. [ ] +1 we should do this [ ] -1 keep things as they are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
