Re: Planning kernel release 2.0
On Mar 23, 2007, at 3:29 AM, ant elder wrote: On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: snip/ I don't think the SPI is quite as stable as Dave would like but we should be able to improve things after alpha2. I think we should target an SPI freeze for the beta (June you were suggesting), at least for incompatible changes. To do that we need to have built a couple of bindings/containers on top of it. I definitely agree we need to get the SPI more stable and that having more containers and bindings using it will help a lot. I'd like help with this and to add the Axis2 binding and jsr-223 script container to the list of extensions already mentioned for this release, i've already started work fixing these for the latest trunk code. I'd also like to add the modularity stuff been discussed on other threads to the content of this release. With the current state of the trunk and spi and all the extensions needing work to get going again this seems like the perfect time to get the trunk code to a state that everyone is happy using. ...ant IMO having scripting support is an important thing. At the ServerSide, one of the things that people liked was the idea of multiple language support and having Groovy and Javascript is a nice differentiator. One distinction I would make though is what we are talking about is a kernel release while extensions would be released separately. As part of the extension releases, if people wanted, there could be distributions that package required extensions for various scripting runtimes. The kernel release would be highly modular and its distributions would include the extensions required for particular host environments. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Planning kernel release 2.0
Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A question of federation - was: Planning kernel release 2.0
On 3/22/07, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Meeraj From my perspective having demonstrable code in June would be spot on as I have to speak on SCA then and would consider a demo if we could do it. I don't have the knowledge yet to comment on the details of your proposal just yet (hence the new subject) but a question. From a future demo point of view I would like to show various runtime options some of which are not federated examples some of which are. Can I miss out the federation bit if I want to? For example, I would potentially like to show a variety of scenarios - Hello world. the simplest possible single process example to get people into how SCA works - Standalone domain (a single VM) service provision (perhaps an AJAX style example where an SCA composite provides services to the browser) service consumption (backend service access providing content to my AJAX service) - Federated domain (multiple VM) How SCA describes many connected composites. I'm just starting now to look at how all the kernel stuff works so I expect all this will become clear soon enough (I found your previous posts giving explantion b.t.w - so am starting from there) Regards Simon
RE: A question of federation - was: Planning kernel release 2.0
Simon, As Jim mentioned in an earler email, A single-VM or runtime physical topology is just a degenerate case of a multi-VM model. In a single-VM scenario there is only one profile that runs the master and the slave. With some minor modifications, we should be able to run the TSS demo in a single VM mode from deploying the SCDL within the admin console, through to invoking the application. That has been one of the key drivers for separating logical and physical aspects of the model. Physical model is generated from the logical model based on the targeted runtimes for the components included in the composite that is being contributed. In a single-VM model, all the physical components will be targeted onto the same runtime. In fact, though the demo showed the federation aspects of Tuscany, the actual application after deployment onto the slave ran in single-VM mode using local bindings. HTH Ta Meeraj -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:22 PM To: tuscany-dev@ws.apache.org Subject: A question of federation - was: Planning kernel release 2.0 On 3/22/07, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Meeraj From my perspective having demonstrable code in June would be spot on as I have to speak on SCA then and would consider a demo if we could do it. I don't have the knowledge yet to comment on the details of your proposal just yet (hence the new subject) but a question. From a future demo point of view I would like to show various runtime options some of which are not federated examples some of which are. Can I miss out the federation bit if I want to? For example, I would potentially like to show a variety of scenarios - Hello world. the simplest possible single process example to get people into how SCA works - Standalone domain (a single VM) service provision (perhaps an AJAX style example where an SCA composite provides services to the browser) service consumption (backend service access providing content to my AJAX service) - Federated domain (multiple VM) How SCA describes many connected composites. I'm just starting now to look at how all the kernel stuff works so I expect all this will become clear soon enough (I found your previous posts giving explantion b.t.w - so am starting from there) Regards Simon This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question of federation - was: Planning kernel release 2.0
On Mar 22, 2007, at 8:47 AM, Simon Laws wrote: Ok, cool, so I can run a simple app in a single VM. Let me try it out. Just to set expectations, I don't think the system configuration in the default runtime has been switched over to the federated deployer yet. So if you run the calc sample on that runtime then it will still be using the old stuff. If you want to experiment with the federated stuff, you would need to use the scdl from the master profile in the demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question of federation - was: Planning kernel release 2.0
On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 22, 2007, at 8:47 AM, Simon Laws wrote: Ok, cool, so I can run a simple app in a single VM. Let me try it out. Just to set expectations, I don't think the system configuration in the default runtime has been switched over to the federated deployer yet. So if you run the calc sample on that runtime then it will still be using the old stuff. If you want to experiment with the federated stuff, you would need to use the scdl from the master profile in the demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] so I get the option to include/exclude federation by modifying the system configuration? Nice. Not saying I don't want federation but nice to have the option. S
Re: A question of federation - was: Planning kernel release 2.0
Hi Meeraj From my perspective having demonstrable code in June would be spot on as I have to speak on SCA then and would consider a demo if we could do it. Maybe we can even get something earlier - I'm also speaking at JavaOne. I don't have the knowledge yet to comment on the details of your proposal just yet (hence the new subject) but a question. From a future demo point of view I would like to show various runtime options some of which are not federated examples some of which are. Can I miss out the federation bit if I want to? For example, I would potentially like to show a variety of scenarios - Hello world. the simplest possible single process example to get people into how SCA works - Standalone domain (a single VM) service provision (perhaps an AJAX style example where an SCA +1 I think it would be good to finish out some of the programming model for web apps, in particular allowing injection on Services. If you want to demo something with Flex, let me know as I have some contacts there that may be able to help us. For a simple example, in my talk I used the loan-app example from the core samples. I basically started with a simple LoanClient that talked to a LoanService (pulled from the core-samples) in a stateless manner. I showed how components can be simple POJOs with no annotations and then demonstrated how they are configured in a very simple assembly. I've done a number of SCA presentations and the approach that seems to resonate the most is first providing a high- level picture of what SCA is by comparing it to Microsoft WCF. I then have one slide basically saying components offer services and have references. This is similar to Don Box's description of WCF when he talks about services having ABCs. Right after that slide, I jump into a POJO example with the point of saying you [the audience] already know how to write components in Java using SCA. I usually show the assembly SCDL next which is just a few lines. Then I update the example to apply conversational scope and callbacks to demonstrate why the development paradigm is an evolution from what current exists. At that, point I then say this isn't something entirely new, this can be done today...what is new is federation, runtime selection of bindings, etc. etc. composite provides services to the browser) service consumption (backend service access providing content to my AJAX service) - Federated domain (multiple VM) How SCA describes many connected composites. I'm just starting now to look at how all the kernel stuff works so I expect all this will become clear soon enough (I found your previous posts giving explantion b.t.w - so am starting from there) Cool. I think making this stuff a reality and moving it beyond demoware would be a great way to promote collaboration. Let me know how I can help. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning kernel release 2.0
I have some cleanup work to do on work and on scopes but I would expect to get that done in the next day or so (ready for the next alpha). On the physical model, I would like to get the bytecode based IFP going to simplify the PCD message. We also need to get complex properties working. From the end-user experience, we need to finish implementing the Java CI APIs - stuff like support for the Conversation interface and casting for ServiceReference etc. We should also look at the JavaEE integration spec. I think our tuscany:web impl type may be close. We also need to beef up the console with more management function, support for displaying the state of the assembly and federation, and support for contributing artifacts and managing them afterwards. Plus all the stuff you mention of course :-) I don't think the SPI is quite as stable as Dave would like but we should be able to improve things after alpha2. I think we should target an SPI freeze for the beta (June you were suggesting), at least for incompatible changes. To do that we need to have built a couple of bindings/containers on top of it. -- Jeremy On Mar 22, 2007, at 4:01 AM, Meeraj Kunnumpurath wrote: Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning kernel release 2.0
What happened to the Kernel Alpha 2 release discussion thread that Jim started on March 13th. It looks like we are restarting. On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I have some cleanup work to do on work and on scopes but I would expect to get that done in the next day or so (ready for the next alpha). On the physical model, I would like to get the bytecode based IFP going to simplify the PCD message. We also need to get complex properties working. From the end-user experience, we need to finish implementing the Java CI APIs - stuff like support for the Conversation interface and casting for ServiceReference etc. We should also look at the JavaEE integration spec. I think our tuscany:web impl type may be close. We also need to beef up the console with more management function, support for displaying the state of the assembly and federation, and support for contributing artifacts and managing them afterwards. Plus all the stuff you mention of course :-) I don't think the SPI is quite as stable as Dave would like but we should be able to improve things after alpha2. I think we should target an SPI freeze for the beta (June you were suggesting), at least for incompatible changes. To do that we need to have built a couple of bindings/containers on top of it. -- Jeremy On Mar 22, 2007, at 4:01 AM, Meeraj Kunnumpurath wrote: Hi, Now that the SPI is getting stable and we have the initial end-to-end story for federation working, I would suggest we plan for the final release for kernel 2.0, with emphasis on federation and user experience. I was thinking about aiming for a beta in June in time for TSSJS Barcelona and the final release for August. Maybe we can have couple of alpha releases from now and June as well. These are the features, I would like to see in 2.0. 1. Tidy up anything required in physical model, now that it is starting to take good shape. 2. Tidy up generators from logical to physical model. 3. Fix the JXTA discovery issues, also investigate other discovery protocols. 4. Federation end-to-end fully completed, this would include, maybe, profiles advertising their capabilities and the information being used in intent-based autowiring etc. 5. Intent-based auto wiring 6. Emphasis on end user experience in terms of ease of use. 7. Assembly service, this kind of now related to the generators that have been introduced in the last week or so 8. Artifact management, especially mobile code when we target components to remote profiles. Also, now the SPI has started settling in, we need to start looking at binding and container extensions as well. Some of the bindings I would be interested in are, 1. JMS 2. AMQP 3. Hessian Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
