Jervis, There's a weekly Muse development call at the following:
Fridays, 11:00 a.m. Eastern US Call-in number: 1-866-711-3137 Passcode: 1667643 Would you be able to join us to discuss how to move this forward? I think we're all eager to make this happen. I'll try and get through the sandbox code beforehand. Thanks, Joel -----Original Message----- From: Liu, Jervis [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 3:21 AM To: [email protected] Subject: RE: Subject: SCA Spec Update and Recursive Core presentation Hi Joel, I am currently looking into Tuscany management capabilities. Hopefully I can have an initial proposal for discussion and review by the end of this week. One of the design objectives for Tuscany management is that Tuscany management should be "protocol neutral", i.e., management will have no hard dependency on any specific management protocols, such as JMX. This allows Tuscany management can be exposed easily to multiple management protocols, such as JMX, SNMP and of course WSDM. It will be a very interesting story if we can show that Tuscany as a SCA-based environment(either Tuscany runtime itself or applications built upon Tuscany) can be accessed and managed by Apache Muse as a WSDM manageable resource . To kick off, can we start to identify basic use cases on the potential integration scenarios we can have between Tuscany an Muse? With the help of use cases, hope we can work out the concrete requirements quickly. Some use cases I can think about: 1. Expose Tuscany runtime as a WSDM compatible manageable resource: There are several things need to be discussed to address this story. For example, what resource properties can be retrieved and changed in Tuscany, and what management events can be provided by Tuscany. How can we derive MUWS WSDL for Tuscany, shall we manually define a MUWS WSDL or this MUWS WSDL can be generated automatically from Tuscany management meta data. Also how SCA management relates to WSDM (though I do not see anything related to management has been published in SCA spec yet)? 2. Expose applications built upon Tuscany as WSDM compatible manageable resources: This requires we provide Tuscany Management APIs that can be used by Tuscany application to define and build manageability resources. Those manageability resources should be managed by Tuscany management then exposed to WSDM. Your comments are welcome. Cheers, Jervis Liu -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 4:38 AM To: [email protected] Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Hi Joel, Great. Do you have some specific areas you are interested in working on w.r.t to Tuscany? I started a skeleton project of getting Tuscany to deploy into Equinox. Also, there has been a thread on providing management capabilities for Tuscany (Jervis I beleive was looking into this). We can definitely use help in these areas as well as the other areas we outlined in the June 9 message from this same thread. Let me know and I can point you at things in more detail. Jim On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote: > Jim, > > My name is Joel Hawkins, and I'm working with the Apache Muse > project on > porting the IBM contribution for the new version of Muse to OSGi. I'm > also working on a recently formed Eclipse project (the Corona > project) - > which has a goal of providing a manageable (using Muse's WSDM > implementation) SCA-type environment (hopefully using Tuscany) for > Eclipse. I've been following the Tuscany project for some time, and > after sitting through the presentation of the latest spec update, I > believe SCA has a very important role to play in moving OSGi's > Declarative Services spec forward, and I'd be very interested in > helping > out in these areas. > > Cheers, > Joel Hawkins > > -----Original Message----- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 10, 2006 1:08 PM > To: [email protected] > Subject: Re: Subject: SCA Spec Update and Recursive Core presentation > > I also forgot one big area that needs work: Management. This is a > topic that is starting to come up in the spec group and it would be > great if we could propose some ideas to them. > > Jim > > On Jun 9, 2006, at 2:48 PM, Jim Marino wrote: > >> Hi, >> >> Thanks everyone who attended today's call. The slides have been >> checked >> into SVN at: >> >> http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ >> doc >> >> We would appreciate any comments, questions, feedback, and >> suggestions >> on the session, and more importantly, the sandbox code at: >> >> http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/ >> >> Most importantly, we would appreciate help from those interested. >> There are a bunch of areas in particular that need a lot of work, >> including: >> >> - Model loading. Jeremy is working on annotations and bootstrapping. >> - Spring support. Ken is moving this along. >> - Binding integration. I'm looking at getting the Celtix stuff >> working. >> Raymond is working on SDO integration. >> - Component implementation types. There is a start of a Groovy >> implementation donated by Meeraj which has partially been ported >> - Transport binding integration. I checked in the skeleton of an HTTP >> Jetty transport. >> - Alternative host environments. I started a skeleton project for >> Equinox as a way to begin tackling OSGI deployment as well as the >> inevitable classloader problems we will encounter in restrictive >> container environments >> - Policy in general: transactions, security, etc. >> - Policy and wire optimization. I have started work here so please >> sync with me. >> - Less "fun" work includes Javadoc and testcases. Contributions >> building >> these areas out would be greatly appreciated; just knowing where we >> are >> lacking would be very valuable. >> - Integration test framework. We discussed having this in the past >> but not much work has been done. >> >> These are just the areas at the front of my mind. If you see other >> things you want to work on, jump on in. >> >> 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] > > The contents of this e-mail are intended for the named addressee > only. It contains information that may be confidential. Unless you > are the named addressee or an authorized designee, you may not copy > or use it, or disclose it to anyone else. If you received it in > error please notify us immediately and then destroy it. > > --------------------------------------------------------------------- > 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] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
