Re: Java Kernel Release
I didn't see any mention what bindings are supported or have been tested with this kernel release. In past we had several web services, RMI all validating that the kernel and the SPIs. We also had several implementation supported Java script, Ruby. It was my experience that these really fleshed out a lot of issues and gave a lot of confidences the kernel was working and could be used to build upon by people wanted to build extensions. Jim Marino wrote: Any doc, even incomplete, will help us understand the supported features. Are you developing that doc on our Wiki? O.K. I've just checked in a first cut of the release doc for kernel here: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ There will be other release docs for the runtimes (standalone, webapp, iTest). I'm sure I missed a bunch of things so if people could update the doc I would appreciate it. I know those of us working on trunk would also appreciate it if you could volunteer some of your time to implement them as well. Jim I'd like to. I'm trying to work on some end to end scenarios first to help put these features in context. I've also checked in a sample that demonstrates SCA 1.0 conversational services and callbacks here: https://svn.apache.org/viewvc/incubator/tuscany/java/sca/core-samples/standalone/loanapplication/ Do you have any other samples or suggestions you feel would be useful for the kernel release? Jim - 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: Java Kernel Release
On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote: I didn't see any mention what bindings are supported or have been tested with this kernel release. In past we had several web services, RMI all validating that the kernel and the SPIs. We also had several implementation supported Java script, Ruby. It was my experience that these really fleshed out a lot of issues and gave a lot of confidences the kernel was working and could be used to build upon by people wanted to build extensions. That's one of the goals of having the kernel release, to get feedback and validation on the SPI :-) Also, one of the goals of modularity as I understand it was to enable releases early and often, with kernel coming out before extensions. Otherwise, we will wind up in the unworkable situation we did with the past two milestones releases. In any event, the SPI for bindings has not significantly changed from M2. I suspect they will somewhat when we introduce full support for federation, put IMO it is important we get something out now to validate where we are. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Jim Marino wrote: On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote: I didn't see any mention what bindings are supported or have been tested with this kernel release. In past we had several web services, RMI all validating that the kernel and the SPIs. We also had several implementation supported Java script, Ruby. It was my experience that these really fleshed out a lot of issues and gave a lot of confidences the kernel was working and could be used to build upon by people wanted to build extensions. That's one of the goals of having the kernel release, to get feedback and validation on the SPI :-) Also, one of the goals of modularity as I understand it was to enable releases early and often, with kernel coming out before extensions. Otherwise, we will wind up in the unworkable situation we did with the past two milestones releases. In any event, the SPI for bindings has not significantly changed from M2. I suspect they will somewhat when we introduce full support for federation, put IMO it is important we get something out now to validate where we are. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If I start taking this kernel release and find issues what will be the plan of action? Wait for the next release ? Goto the next SNAPSHOT published driver? I think a release of something should signify the community confidence in what is being released. My experience has been in past releases it wasn't till we had major integration of binding extensions, alternative component implementations and some reasonably more that hello world scenarios driving the kernel that I felt confident it was worth releasing. Curious, how others feel about that ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
On Feb 22, 2007, at 6:47 AM, Rick Rineholt wrote: Jim Marino wrote: On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote: I didn't see any mention what bindings are supported or have been tested with this kernel release. In past we had several web services, RMI all validating that the kernel and the SPIs. We also had several implementation supported Java script, Ruby. It was my experience that these really fleshed out a lot of issues and gave a lot of confidences the kernel was working and could be used to build upon by people wanted to build extensions. That's one of the goals of having the kernel release, to get feedback and validation on the SPI :-) Also, one of the goals of modularity as I understand it was to enable releases early and often, with kernel coming out before extensions. Otherwise, we will wind up in the unworkable situation we did with the past two milestones releases. In any event, the SPI for bindings has not significantly changed from M2. I suspect they will somewhat when we introduce full support for federation, put IMO it is important we get something out now to validate where we are. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If I start taking this kernel release and find issues what will be the plan of action? Wait for the next release ? Goto the next SNAPSHOT published driver? It depends on if the release has gone out. If not, then we need to consider if the fix is small enough to incorporate or should be pushed out to the next release. Assuming the release has gone out, there are two options, which are not exclusive: move to SNAPSHOT (not the 'next' snapshot as SNAPSHOT continually changes) or publish a new release. Now that we are trying to release early, release often, releases can be done at a very quick pace. Those of us working in trunk would like to avoid months-long release processes and hence our desire to start getting these releases out. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
I was going with the scenario that the release was out. Given that unlike past releases we've done where we had major number of bindings running and samples running to give a level of confidence that there was a fair amount that could be done with the release code that wouldn't require updating I'm not seeing quite seeing the value of release code verses just published snapshots following this approach. Jim Marino wrote: On Feb 22, 2007, at 6:47 AM, Rick Rineholt wrote: Jim Marino wrote: On Feb 22, 2007, at 4:40 AM, Rick Rineholt wrote: I didn't see any mention what bindings are supported or have been tested with this kernel release. In past we had several web services, RMI all validating that the kernel and the SPIs. We also had several implementation supported Java script, Ruby. It was my experience that these really fleshed out a lot of issues and gave a lot of confidences the kernel was working and could be used to build upon by people wanted to build extensions. That's one of the goals of having the kernel release, to get feedback and validation on the SPI :-) Also, one of the goals of modularity as I understand it was to enable releases early and often, with kernel coming out before extensions. Otherwise, we will wind up in the unworkable situation we did with the past two milestones releases. In any event, the SPI for bindings has not significantly changed from M2. I suspect they will somewhat when we introduce full support for federation, put IMO it is important we get something out now to validate where we are. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If I start taking this kernel release and find issues what will be the plan of action? Wait for the next release ? Goto the next SNAPSHOT published driver? It depends on if the release has gone out. If not, then we need to consider if the fix is small enough to incorporate or should be pushed out to the next release. Assuming the release has gone out, there are two options, which are not exclusive: move to SNAPSHOT (not the 'next' snapshot as SNAPSHOT continually changes) or publish a new release. Now that we are trying to release early, release often, releases can be done at a very quick pace. Those of us working in trunk would like to avoid months-long release processes and hence our desire to start getting these releases out. Jim - 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: Java Kernel Release
On Feb 22, 2007, at 7:49 AM, Rick Rineholt wrote: I was going with the scenario that the release was out. Given that unlike past releases we've done where we had major number of bindings running and samples running to give a level of confidence that there was a fair amount that could be done with the release code that wouldn't require updating I'm not seeing quite seeing the value of release code verses just published snapshots following this approach. One of the values of the release is that it publishes a fixed SPI set for people to develop against and validate. SNAPSHOT serves a different purpose, to reflect the current status of HEAD, and as such is constantly moving. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
But if we have not done sufficient testing of the release that we feel confident that users won't have to immediately wait for a new release or go to snapshot what has it accomplished ? Jim Marino wrote: On Feb 22, 2007, at 7:49 AM, Rick Rineholt wrote: I was going with the scenario that the release was out. Given that unlike past releases we've done where we had major number of bindings running and samples running to give a level of confidence that there was a fair amount that could be done with the release code that wouldn't require updating I'm not seeing quite seeing the value of release code verses just published snapshots following this approach. One of the values of the release is that it publishes a fixed SPI set for people to develop against and validate. SNAPSHOT serves a different purpose, to reflect the current status of HEAD, and as such is constantly moving. Jim - 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: Java Kernel Release
Jim Marino wrote: I think it will be good to have a stable kernel. Which level of SCDL and which features from the SCA assembly model are you proposing to support in that kernel level? As it says, SCA 1.0 level - not all of it for sure but a baseline for itest, standalone and webapp environments. --Jeremy A baseline? Do you have an idea of which features from the SCA assembly model? includes? nested composition? wiring across composites? promotion of services? complex properties or not? which databindings? any support for WSDL? any support for configured implementations? --Jean-Sebastien Hi Sebastien, I'm not sure I completely follow your questions... It's a simple question. There has been many changes in the SCA assembly model between 0.96 and 1.0, you are proposing a 1.0-alpha release of a Kernel supporting a subset of the 1.0 SCA assembly model. I'm simply asking Which subset of 1.0? to help all of us understand how to integrate the many other pieces of Tuscany with this, which scenarios we will be able to run, which integration tests can be developed etc. Instead of having us compile a laundry list, which would be quite extensive, Isn't there a middle ground between an extensive laundry list and an answer of the type ... SCA 1.0 - not all of it for sure but a baseline...? maybe you could list a few features you are interested in including in the release (keeping in mind we are trying to release sooner and staging larger functionality such as distribution for subsequent releases)? We will have release doco describing the features but it isn't complete yet Any doc, even incomplete, will help us understand the supported features. Are you developing that doc on our Wiki? and it sounds like you have a few specific things in mind. They are listed there: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200702.mbox/[EMAIL PROTECTED] I know those of us working on trunk would also appreciate it if you could volunteer some of your time to implement them as well. Jim I'd like to. I'm trying to work on some end to end scenarios first to help put these features in context. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
It's a simple question. There has been many changes in the SCA assembly model between 0.96 and 1.0, you are proposing a 1.0-alpha release of a Kernel supporting a subset of the 1.0 SCA assembly model. I'm simply asking Which subset of 1.0? to help all of us understand how to integrate the many other pieces of Tuscany with this, which scenarios we will be able to run, which integration tests can be developed etc. Instead of having us compile a laundry list, which would be quite extensive, Isn't there a middle ground between an extensive laundry list and an answer of the type ... SCA 1.0 - not all of it for sure but a baseline...? maybe you could list a few features you are interested in including in the release (keeping in mind we are trying to release sooner and staging larger functionality such as distribution for subsequent releases)? We will have release doco describing the features but it isn't complete yet Any doc, even incomplete, will help us understand the supported features. Are you developing that doc on our Wiki? I planning to do it as part of the distributions. I'm sure we can figure a way to post it to the wiki. In the meantime, I think there is a ton of postings to the list which will help you understand which features we have been working on and their status. Also, the unit tests are all up-to-date. Sorry I don't have the doco finished but will shortly as I've been tied up at work. Another option is if you want to take a stab at compiling an initial list, it would help me out a great deal given I have a bunch of other release-related items to take care of. and it sounds like you have a few specific things in mind. They are listed there: http://mail-archives.apache.org/mod_mbox/ws- tuscany-dev/200702.mbox/[EMAIL PROTECTED] Great! Which ones are you planning on getting into kernel? If you do some of them over the next day or so we can include them in the release. I'm not quite sure where you are at as there has been little discussion on the list related to your plans. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Any doc, even incomplete, will help us understand the supported features. Are you developing that doc on our Wiki? O.K. I've just checked in a first cut of the release doc for kernel here: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/ There will be other release docs for the runtimes (standalone, webapp, iTest). I'm sure I missed a bunch of things so if people could update the doc I would appreciate it. I know those of us working on trunk would also appreciate it if you could volunteer some of your time to implement them as well. Jim I'd like to. I'm trying to work on some end to end scenarios first to help put these features in context. I've also checked in a sample that demonstrates SCA 1.0 conversational services and callbacks here: https://svn.apache.org/viewvc/incubator/tuscany/java/sca/core-samples/ standalone/loanapplication/ Do you have any other samples or suggestions you feel would be useful for the kernel release? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Raymond Feng wrote: +1 on the spec release criteria. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 19, 2007 6:29 PM Subject: Re: Java Kernel Release On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote: On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? Yes, and I think we should have stricter release criteria for these as well. Specifically: +1 I have compared the candidate to the spec and have not found any discrepancy[1] +0 I have reviewed them but have not done a detailed comparison to the spec -1 I have compared the candidate to the spec and have found a discrepancy with any -1 being a veto. Thoughts? +1 on the vote for spec release criteria - 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] +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Jeremy Boynes wrote: On Feb 19, 2007, at 9:45 AM, Jim Marino wrote: There has been quite a bit of activity over the last month-and-a-half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. Works for me. I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant I propose we remove the test module. 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? The extension model is a bit hokey at the moment requiring users to create new or modify existing profiles which basically means duplicating the installation every time. We've had this view for a while that extensions should be dynamically and automatically loaded based on intent and for the 1.0 timeframe I think we should provide that. However, this really requires the Contribution service be fully working to we can match intent to extension and I don't think that will be ready soon. We do support a very primitive extension mechanism where users can add them by modifying the system scdl (which is now externalized as a text file). I'm OK with releasing an alpha version like that with the intent-based support coming later (i.e. 1.0 beta or final). I think we need to do some clean-up on the poms. As Sebastien pointed out, there is a lot of dependency cruft in the SCA pom which should be stripped out - we can probably reduce that to just the configuration of checkstyle etc. I'm happy to don my build-monkey hat again and clean that up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Jim Marino wrote: There has been quite a bit of activity over the last month-and-a-half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it will be good to have a stable kernel. Which level of SCDL and which features from the SCA assembly model are you proposing to support in that kernel level? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
On Feb 20, 2007, at 1:02 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: There has been quite a bit of activity over the last month-and-a- half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it will be good to have a stable kernel. Which level of SCDL and which features from the SCA assembly model are you proposing to support in that kernel level? As it says, SCA 1.0 level - not all of it for sure but a baseline for itest, standalone and webapp environments. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Jeremy Boynes wrote: On Feb 20, 2007, at 1:02 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: There has been quite a bit of activity over the last month-and-a-half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think it will be good to have a stable kernel. Which level of SCDL and which features from the SCA assembly model are you proposing to support in that kernel level? As it says, SCA 1.0 level - not all of it for sure but a baseline for itest, standalone and webapp environments. -- Jeremy A baseline? Do you have an idea of which features from the SCA assembly model? includes? nested composition? wiring across composites? promotion of services? complex properties or not? which databindings? any support for WSDL? any support for configured implementations? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
I think it will be good to have a stable kernel. Which level of SCDL and which features from the SCA assembly model are you proposing to support in that kernel level? As it says, SCA 1.0 level - not all of it for sure but a baseline for itest, standalone and webapp environments. -- Jeremy A baseline? Do you have an idea of which features from the SCA assembly model? includes? nested composition? wiring across composites? promotion of services? complex properties or not? which databindings? any support for WSDL? any support for configured implementations? -- Jean-Sebastien Hi Sebastien, I'm not sure I completely follow your questions...Instead of having us compile a laundry list, which would be quite extensive, maybe you could list a few features you are interested in including in the release (keeping in mind we are trying to release sooner and staging larger functionality such as distribution for subsequent releases)? We will have release doco describing the features but it isn't complete yet and it sounds like you have a few specific things in mind. I know those of us working on trunk would also appreciate it if you could volunteer some of your time to implement them as well. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java Kernel Release
Jim, I think, it is a good idea to a have a set of iterative alpha releases gearing towards a final 1.0 release. These are the features I see in the 1.0 final release .. 1. Full support for heterogeneous federation 2. Distributed assembly and deployment 3. Contribution mechanisms 4. Support for the 1.0 dpec changes 5. Standlone server and support for JMX-based management 6. The itest framework 7. And anything I have missed :) I think for the first alpha release, I would suggest we include spec 1.0 changes with ability to run with the laucher, itest and webapp runtimes. We need to discuss how we want to take the standalone server forward with JMX support. This may have some dependency on the federation stuff we have been working on. That means the standalone server with JMX and support for simple scenarios with federated deployment can go together in the second alpha release. We can plan for rest of the features in the next two releases or the ones after that. My view is to get the first alpha release out as early as we can with 1.0 programming model and support for laucher, webapp and itest runtimes. Ta Meeraj From: Jim Marino [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Java Kernel Release Date: Mon, 19 Feb 2007 09:45:38 -0800 There has been quite a bit of activity over the last month-and-a-half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Upload 500 photos a month blog with your Messenger buddies on Windows Live Spaces. Get yours now, FREE! http://specials.uk.msn.com/spaces/default.aspx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
On Feb 19, 2007, at 9:45 AM, Jim Marino wrote: There has been quite a bit of activity over the last month-and-a- half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. Works for me. I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant I propose we remove the test module. 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? The extension model is a bit hokey at the moment requiring users to create new or modify existing profiles which basically means duplicating the installation every time. We've had this view for a while that extensions should be dynamically and automatically loaded based on intent and for the 1.0 timeframe I think we should provide that. However, this really requires the Contribution service be fully working to we can match intent to extension and I don't think that will be ready soon. We do support a very primitive extension mechanism where users can add them by modifying the system scdl (which is now externalized as a text file). I'm OK with releasing an alpha version like that with the intent-based support coming later (i.e. 1.0 beta or final). I think we need to do some clean-up on the poms. As Sebastien pointed out, there is a lot of dependency cruft in the SCA pom which should be stripped out - we can probably reduce that to just the configuration of checkstyle etc. I'm happy to don my build-monkey hat again and clean that up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? What about java-docs ? On 2/19/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 19, 2007, at 9:45 AM, Jim Marino wrote: There has been quite a bit of activity over the last month-and-a- half enhancing the Kernel. Based on this work, I'd like to cut a release of Kernel, the Standalone Runtime, the Webap Runtime, and the Maven iTest Plugin as a stepping stone to having a 1. release. I was thinking we would call this release 1.0 alpha. Works for me. I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). I see this alpha as evolving into a series of iterative releases over the next month where we introduce some of the more compelling features we have been discussing related to service networks, federation, and deployment. The primary goals of the first alpha release would be centered on enhancements to the programming model that have been introduced with the recent Kernel changes. Specifically, the alpha would provide an enhanced version of Kernel that our users can experiment with, extend and provide us feedback on. This will assist us in validating he programming model supported by Kernel. The key features of the alpha release would be: 1. SCA 1.0 APIs -Support for many of the new SCA 1.0 Java APIs (ComponentContext, Conversational annotations) 2. An enhanced standalone runtime with JMX support 3. An enhanced and SCA 1.0-based model for integration testing (elimination of SCATestCase, which is not spec-compliant I propose we remove the test module. 4. Simplified wiring 5. Simplified extension model 6. Architecture for support of federated deployment 7. Support for web applications using SCA 1.0 concepts I'd like to follow the alpha with additional releases that introduce additional support for federation, deployment, and the SCA 1.0 APIs. To stage this, perhpaps we the following in the next release after the alpha: - Contribution service - Refactor of Databinding (mentioned in a separate thread) - Introduction of master/slave nodes and federated wiring - More complete support for conversational APIs, including ServiceReference In terms of work items, I think we need the following (besides a stable kernel :-) ): 1. Standalone runtime operational and able to deploy application and extension SCDLS 2. At least two samples. I propose the Calculator Sample (Standalone and Web app) and the Loan Application Sample Feel free to suggest additional features. As a general principle, I'd like to get a release out sooner rather than later with big features introduced in the consecutive releases mentioned previously. One thing I'd like to see if we can fit in but may have to cut is the new PhysicalComponent builders. That may be something we stage later. Hopefully, we can cut the release this week. Thoughts? The extension model is a bit hokey at the moment requiring users to create new or modify existing profiles which basically means duplicating the installation every time. We've had this view for a while that extensions should be dynamically and automatically loaded based on intent and for the 1.0 timeframe I think we should provide that. However, this really requires the Contribution service be fully working to we can match intent to extension and I don't think that will be ready soon. We do support a very primitive extension mechanism where users can add them by modifying the system scdl (which is now externalized as a text file). I'm OK with releasing an alpha version like that with the intent-based support coming later (i.e. 1.0 beta or final). I think we need to do some clean-up on the poms. As Sebastien pointed out, there is a lot of dependency cruft in the SCA pom which should be stripped out - we can probably reduce that to just the configuration of checkstyle etc. I'm happy to don my build-monkey hat again and clean that up. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: Java Kernel Release
On Feb 19, 2007, at 3:06 PM, Meeraj Kunnumpurath wrote: Jim, I think, it is a good idea to a have a set of iterative alpha releases gearing towards a final 1.0 release. These are the features I see in the 1.0 final release .. 1. Full support for heterogeneous federation 2. Distributed assembly and deployment 3. Contribution mechanisms 4. Support for the 1.0 dpec changes 5. Standlone server and support for JMX-based management 6. The itest framework 7. And anything I have missed :) +1. Sounds like a reasonable set of features. I think for the first alpha release, I would suggest we include spec 1.0 changes with ability to run with the laucher, itest and webapp runtimes. We need to discuss how we want to take the standalone server forward with JMX support. This may have some dependency on the federation stuff we have been working on. That means the standalone server with JMX and support for simple scenarios with federated deployment can go together in the second alpha release. We can plan for rest of the features in the next two releases or the ones after that. Moving JMX out to the follow-on release sounds good based on the tie- in with federation. Let's start a separate thread to discuss how we want to evolve the JMX support. My view is to get the first alpha release out as early as we can with 1.0 programming model and support for laucher, webapp and itest runtimes. +1 Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
I propose we remove the test module. +1. If you are going to don the build-monkey-suit, do you want to go ahead and remove it? The extension model is a bit hokey at the moment requiring users to create new or modify existing profiles which basically means duplicating the installation every time. We've had this view for a while that extensions should be dynamically and automatically loaded based on intent and for the 1.0 timeframe I think we should provide that. However, this really requires the Contribution service be fully working to we can match intent to extension and I don't think that will be ready soon. Raymond and Luciano, you guys started work on this. Is this something you feel could be ready over the next couple of weeks? We do support a very primitive extension mechanism where users can add them by modifying the system scdl (which is now externalized as a text file). I'm OK with releasing an alpha version like that with the intent-based support coming later (i.e. 1.0 beta or final). For an alpha, I think this is fine. I think we need to do some clean-up on the poms. As Sebastien pointed out, there is a lot of dependency cruft in the SCA pom which should be stripped out - we can probably reduce that to just the configuration of checkstyle etc. I'm happy to don my build- monkey hat again and clean that up. +1 Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? What about java-docs ? Yeah, we'll need to distribute the spec jars. For OSOA JavaDoc, I don't think we need it other than posting something to the web site (the jar is small enough and doesn't contain any implementation). For Kernel JavaDoc, I'd just assume we cut a source distribution which people can use and have online JavaDoc (in addition to the binary distributions). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? Yes, and I think we should have stricter release criteria for these as well. Specifically: +1 I have compared the candidate to the spec and have not found any discrepancy[1] +0 I have reviewed them but have not done a detailed comparison to the spec -1 I have compared the candidate to the spec and have found a discrepancy with any -1 being a veto. Thoughts? -- Jeremy [1] defining discrepancy the same way Sun do for signature verification for API jars (i.e. nothing added, nothing removed) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
The spec jar. -- Jeremy On Feb 19, 2007, at 4:37 PM, Raymond Feng wrote: Hi, Jeremy. Does your comment apply to the whole release or just the SCA spec jar? Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 19, 2007 4:32 PM Subject: Re: Java Kernel Release On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? Yes, and I think we should have stricter release criteria for these as well. Specifically: +1 I have compared the candidate to the spec and have not found any discrepancy[1] +0 I have reviewed them but have not done a detailed comparison to the spec -1 I have compared the candidate to the spec and have found a discrepancy with any -1 being a veto. Thoughts? -- Jeremy [1] defining discrepancy the same way Sun do for signature verification for API jars (i.e. nothing added, nothing removed) - 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]
Re: Java Kernel Release
On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote: On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? Yes, and I think we should have stricter release criteria for these as well. Specifically: +1 I have compared the candidate to the spec and have not found any discrepancy[1] +0 I have reviewed them but have not done a detailed comparison to the spec -1 I have compared the candidate to the spec and have found a discrepancy with any -1 being a veto. Thoughts? +1 on the vote for spec release criteria - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Kernel Release
+1 on the spec release criteria. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 19, 2007 6:29 PM Subject: Re: Java Kernel Release On Feb 19, 2007, at 4:32 PM, Jeremy Boynes wrote: On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote: Quick comment... I'd suggest three release bundles (source): * kernel * runtime (which includes the three runtimes you mention above) * core samples with binary distributions of the standalone assembly plus maven artifacts (including the war and itest plugins). Don't you need to distribute the spec jars as well ? Yes, and I think we should have stricter release criteria for these as well. Specifically: +1 I have compared the candidate to the spec and have not found any discrepancy[1] +0 I have reviewed them but have not done a detailed comparison to the spec -1 I have compared the candidate to the spec and have found a discrepancy with any -1 being a veto. Thoughts? +1 on the vote for spec release criteria - 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: Java kernel release
[snip] There are some JIRA issues created from the test cases in testing\sca\itest\test-spec. We should try to fix them. - Closer alignment with the assembly specification (multiple bindings per service/reference, property overrides) I'd like to help with the release as well. If nobody else is already working on this, I'll start with the JIRAs reporting differences with the latest spec (APIs, annotations, and SCDL). It looks like TUSCANY-909 is already fixed but I'll do a pass through the latest CI spec to verify it. I'll also look into TUSCANY-910. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java kernel release
Hi Jim, as you know my vision about Tuscany architecture is still limited, but I was wondering whether one of the JMX implementation at the Felix project could help you. Take a look at http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html This solution is tied to adopt an OSGi container. I thought that assemblies could be deployed as bundles, and the SCA system controlled using an OSGi-based JMX console. Is this approach feasible for you or you prefer to add JMX support directly to the kernel? francesco Jim Marino wrote: Over the past couple of weeks we have made progress in upgrading the capabilities of the kernel, including starting support for a standalone server, JMX, and SCA deployment. In addition, we have made changes that have allowed us to support existing SCA features such as multiple bindings for services and references as well as implement recent spec changes such as the introduction of autowire in the assembly model. Related to this, Jeremy has begun work to further modularize our source tree with the goal of allowing us to release the kernel and extensions independently. Given this, I would like to get another release of the kernel going shortly. Some of the features I am personally interested in seeing are: - A standalone service with JMX support for management - A functioning deployment implementation that corresponds to the current SCA deployment proposal for contributing and mutating assemblies - Closer alignment with the Java CI specification (scopes, conversations, autowire attributes, eager initialization semantics, support for resources) - Closer alignment with the assembly specification (multiple bindings per service/reference, property overrides) - Improved extension support, including classloader isolation (i.e. use of multiparent classloading) Another key goal I would like to see is a focus on hardening the kernel. We still have a number of critical code paths which are fragile and have little to no test coverage. I would ideally like to get a kernel release out by the end of the month that extension developers can use which is fairly stable and robust. Depending on the outcome of changes under consideration by the SCA collaboration, this would put us in a fairly good position to support a significant number of features by the time the specifications are released in their 1.0 form. Thoughts? Jim - 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: Java kernel release
On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote: Hi Jim, as you know my vision about Tuscany architecture is still limited, but I was wondering whether one of the JMX implementation at the Felix project could help you. Take a look at http:// cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html This solution is tied to adopt an OSGi container. I thought that assemblies could be deployed as bundles, and the SCA system controlled using an OSGi-based JMX console. Hi Francesco, Meeraj has been leading the JMX integration so I'll let him talk about what his plans are for it... In terms of deploying assemblies as bundles, yes, we want to be able to support that but we also have plans to do more. The SCA collaboration is currently working on deployment (it is one of the big missing pieces prior to releasing the specs as 1.0 versions). It is still very much a work in progress but the idea behind SCA deployment is that we want to support a variety of packaging formats as well as the ability to contribute resources (e.g. Java classes, XSDs, WSDL port types, etc.) that an assembly may reference. They key thing we want to do is decouple how resources are referenced in an assembly and how they are physically contributed to the SCA domain. Another key thing is we want the end-user experience to be very simple. Some specific examples may help to explain this further. Say I have the following component definition: component name=FooService implemenation.java class=com.acme.Foo /component How the com.acme.Foo service is contributed to the SCA runtime should not be evident from the assembly SCDL, as shown above. It could have been contributed through any of the following means: 1. The class file was placed in a directory 2. A jar containing the class file was contributed to a deployment service 3. An OSGi bundle containing the class file was contributed to a deployment service ..etc.. Similarly, the same mechanism could be used for WSDLs, XSDs, etc. More specifically, two steps take place in this process. The first is the resource is contributed to the SCA domain. The second step is the assembly is mutated, for example, a component is instantiated using the SCDL above. This allows for reuse. Sometimes these steps may be combined from an end-user perspective. For example, I should be able to drop a Java class in a directory and have the runtime introspect and deploy it as a component. The runtime should also be smart enough to be able to figure out how to provision components to various nodes in the service network. For example, if I have a component that requires high availability, it may deploy to a J2EE host environment running Tuscany. Or, it may provision it to an OSGi container running Tuscany. Ditto for the Standalone server. By the time we are done defining the deployment API, I suspect we will have something similar to Subversion. If you are interested in getting involved in helping implement some of this or other parts of Tuscany, let us know and I am sure people will be able to give you pointers to help get you started. Also, we're always interested in hearing about your requirements, particularly since it sounds as if you have several projects that may be able to make use of these capabilities. Jim Is this approach feasible for you or you prefer to add JMX support directly to the kernel? francesco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java kernel release
Francesco, Most of the discussions on management and JMX are available on the recent thread titled Standalone Server. Here is a brief overview of what we have .. Tuscany provides a standalone server in which one or more tuscany runtimes can be started. The server itself used JMX for management. The managed ops include stating/shutting down named runtimes and shutting down the server itself. However, the individual runtimes may choose to any management mechanism (JMX, WSDM, SNMP etc) to enable management. If a runtime decides to use JMX for management, the server will make sure the same mbean server that hosts the server is available for the runtime for registering the managed components within the runtime. This is, however, transparent through the management service abstraction. The abstraction is defined in ManagementService Tuscany SPI. However, the only implementation we have in core is based on JMX. When components are registered, they make them available for management through the management service. Currently, we support read-only view to the component properties. We are discussing about how to enable management of other aspects like poperty mutations, wire management etc. However, they do have other implications around durability of mutations, thread-safety around instances and scopes etc. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 5:08 PM To: tuscany-dev@ws.apache.org Subject: Re: Java kernel release On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote: Hi Jim, as you know my vision about Tuscany architecture is still limited, but I was wondering whether one of the JMX implementation at the Felix project could help you. Take a look at http:// cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html This solution is tied to adopt an OSGi container. I thought that assemblies could be deployed as bundles, and the SCA system controlled using an OSGi-based JMX console. Hi Francesco, Meeraj has been leading the JMX integration so I'll let him talk about what his plans are for it... In terms of deploying assemblies as bundles, yes, we want to be able to support that but we also have plans to do more. The SCA collaboration is currently working on deployment (it is one of the big missing pieces prior to releasing the specs as 1.0 versions). It is still very much a work in progress but the idea behind SCA deployment is that we want to support a variety of packaging formats as well as the ability to contribute resources (e.g. Java classes, XSDs, WSDL port types, etc.) that an assembly may reference. They key thing we want to do is decouple how resources are referenced in an assembly and how they are physically contributed to the SCA domain. Another key thing is we want the end-user experience to be very simple. Some specific examples may help to explain this further. Say I have the following component definition: component name=FooService implemenation.java class=com.acme.Foo /component How the com.acme.Foo service is contributed to the SCA runtime should not be evident from the assembly SCDL, as shown above. It could have been contributed through any of the following means: 1. The class file was placed in a directory 2. A jar containing the class file was contributed to a deployment service 3. An OSGi bundle containing the class file was contributed to a deployment service ..etc.. Similarly, the same mechanism could be used for WSDLs, XSDs, etc. More specifically, two steps take place in this process. The first is the resource is contributed to the SCA domain. The second step is the assembly is mutated, for example, a component is instantiated using the SCDL above. This allows for reuse. Sometimes these steps may be combined from an end-user perspective. For example, I should be able to drop a Java class in a directory and have the runtime introspect and deploy it as a component. The runtime should also be smart enough to be able to figure out how to provision components to various nodes in the service network. For example, if I have a component that requires high availability, it may deploy to a J2EE host environment running Tuscany. Or, it may provision it to an OSGi container running Tuscany. Ditto for the Standalone server. By the time we are done defining the deployment API, I suspect we will have something similar to Subversion. If you are interested in getting involved in helping implement some of this or other parts of Tuscany, let us know and I am sure people will be able to give you pointers to help get you started. Also, we're always interested in hearing about your requirements, particularly since it sounds as if you have several projects that may be able to make use of these capabilities. Jim Is this approach feasible for you or you prefer to add JMX support directly to the kernel? francesco
