RE: OSGi host
Hi Andy, I'm pretty new to it, too, hence the questions. :-) For me, SCA seems like wiring technology that's very useful for things with a bit of an impedance mismatch, whereas Spring is more focused on IOC. Spring is very good at wiring things together that are meant to be wired, and functionality like the OSGi binding for Spring is a means of bringing more wiring targets into the fold. I guess my question is, could SCA be the standard way for Spring and EJB3 to deal with these impedance mismatches, so that all Spring would need to implement is an SCA bean type, and all SCA would need to implement is an OSGi binding? Then anything bind-able by SCA could be consumed by Spring - BPEL components, Javascript, whatever. This seems like what the OSOA Client and Implementation spec for Spring implies. I just wonder how it's viewed from the Spring side of the fence. Oh well, it looks like we need those OSGi services and bindings in Tuscany regardless, so I'll get back to working on them. For the OSGi crowd, size matters - and smaller is better. They won't want to include the Spring jars if they don't have to. Thanks again for the link - it helps to level-set what the SCA binding should be capable of! Cheers, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 6:07 PM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Hi Joel, I'm new to SCA, so don't believe everything I say :) OSGi is IMO an infrastructure technology suitable for building container technologies such as SCA. Spring is a Java component wiring technology, so inevitably overlaps with some of what SCA is trying to achieve (and EJB3 for example). That's ok - customers will decide what is appropriate for them. For me the sweet spot of SCA is SOA which has no overlap at all with either Spring or OSGI. andy At 02:50 PM 8/21/2006, Hawkins, Joel wrote: Hi Andy, Thanks for the link. You bring up a question that's been troubling me about some of this. What is the role of OSGi in SCA? How does it differ from the role of something like Spring? Or, asked in the larger sense, where does SCA fit into the world of Containers? My assumption has been that OSGi is analogous to Tomcat - it is the outer container for hosting SCA runtime instances (the Hosting Platform). I saw Spring as something contained by an SCA runtime. In my simple world view, that would mean that the SCA runtime should mediate between the OSGi and Spring worlds. I'm assuming that we would want an SCA wire between Spring beans accessing OSGi services, etc. so that SCA would have a place to inject code (for whatever reason), and so that the SCDLs would more closely reflect the actual application's interrelationships (a really nice side-effect that enhances manageability). All of this argues for a separate OSGi binding for SCA (and a single SCA bean-type in Spring for 'outside' beans). On the other hand, there is quite a bit of overlap between what Spring and SCA do, and I am getting the feeling that this code could rapidly become wheel-shaped. :-) Do you have any suggestions for how to proceed? What are your thoughts on the big-picture relationship between SCA and these fully-featured containers like Spring and J2EE? Thanks, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 6:40 AM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Note that you will get a lot of this stuff for free if you use Spring. http://opensource.atlassian.com/projects/spring/secure/attachment/11891 / spring_and_osgi.html andy At 14:44 18/08/2006, Hawkins, Joel wrote: Jim, I've done an intial checkin of your patch for OSGi host support. I did some mods and didn't check in the samples as we have a discussion ongoing on how best to structure the samples and didn't want to create more issues for now related to the restructuring. Yes, how to deal with samples is always and issue. I'm sure dealing with test cases will be as well. 1. I didn't check in support for OSGi services as component implementation types. For SCA, our model has typically been that implementation types are created for artifacts that are deployed and evolved as part of a composite. Services that are not deployed with the composite are treated as external and modeled as References. I think this fits with OSGi as well, whose services are more dynamic in nature. Given that, I think we should be providing an OSGi binding that accesses those services as References and publishes SCA components as OSGi Services. I agree. I think where I went for Implementation rather than Reference is when the core wanted me to specify a target declared in the component. In the spec, you can declare a reference without a target, but that didn't appear to be the case in the code I had. My thought process (such as it is..) was that at a certain
Re: OSGi host
On Aug 23, 2006, at 5:00 AM, Hawkins, Joel wrote: Hi Andy, I'm pretty new to it, too, hence the questions. :-) For me, SCA seems like wiring technology that's very useful for things with a bit of an impedance mismatch, whereas Spring is more focused on IOC. Spring is very good at wiring things together that are meant to be wired, and functionality like the OSGi binding for Spring is a means of bringing more wiring targets into the fold. I guess my question is, could SCA be the standard way for Spring and EJB3 to deal with these impedance mismatches, so that all Spring would need to implement is an SCA bean type, and all SCA would need to implement is an OSGi binding? Then anything bind-able by SCA could be consumed by Spring - BPEL components, Javascript, whatever. I view things similarly as well I generally characterize Java SCA Tuscany as wiring infrastructure which involves connecting services both remotely and locally. Tuscany handles remote or coarse grained connections through bindings which may involve delegation to some transport. Tuscany handles local wiring (i.e. from source to target in a shared memory space) either directly through a proxying strategy or through delegation to a container extension (e.g. Spring). While Java SCA Tuscany may use web services technology for interop, it is just one option among many and it does not mandate them. Tuscany supports (or should support since it is a work in progress) multiple programming models to author services with. For Java, there's an SCA POJO model, Spring and (hopefully at some point others such as EJB, JAX-WS, etc.). The SCA programming model supported by Tuscany is principally focused on exposing assembly concepts to the service developer, so things like non-blocking invocations, conversations, statefull interactions, etc. Spring, in addition to having a programming model, is also an application framework so it has a broader range of functionality including UI, persistence abstraction, AOP, etc. From a Spring perspective, I'd say the value in SCA is (as you stated) that it allows remote wiring to and from Spring beans. Spring has a basic remoting technology but SCA provides more thorough capabilities in this regard. I'd probably characterize it more as remote/coarse-grained wiring as opposed to mediated wiring since Spring's AOP infrastructure supports mediation on a local scale. Similar to Spring, there is some overlap with SCA with OSGi, specifically around the OSGI r4 service model. However, I also see a lot of complimentary function and actually view OSGi services as fitting into an SCA environment. In this case OSGi provides a host environment for Tuscany and OSGi services may be wired to from Tuscany (as well as the latter publishing services into OSGi). Jim This seems like what the OSOA Client and Implementation spec for Spring implies. I just wonder how it's viewed from the Spring side of the fence. Rod and Adrian are one the spec group. Most of where they have concentrated has been on the Spring Client and Implementation model so my assumption would be the value they see is in integration of Spring with SCA's remote wiring capabilities. Oh well, it looks like we need those OSGi services and bindings in Tuscany regardless, so I'll get back to working on them. For the OSGi crowd, size matters - and smaller is better. :-) One of the things we should talk about is embedding the Tuscany runtime in somewhat small devices. I think it would be interesting to have my Tivo wired with SCA. Seriously, I think this is a really interesting scenario as there is no reason Tuscany should not be able to scale down as well as up. Jim They won't want to include the Spring jars if they don't have to. Thanks again for the link - it helps to level-set what the SCA binding should be capable of! Cheers, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 6:07 PM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Hi Joel, I'm new to SCA, so don't believe everything I say :) OSGi is IMO an infrastructure technology suitable for building container technologies such as SCA. Spring is a Java component wiring technology, so inevitably overlaps with some of what SCA is trying to achieve (and EJB3 for example). That's ok - customers will decide what is appropriate for them. For me the sweet spot of SCA is SOA which has no overlap at all with either Spring or OSGI. andy At 02:50 PM 8/21/2006, Hawkins, Joel wrote: Hi Andy, Thanks for the link. You bring up a question that's been troubling me about some of this. What is the role of OSGi in SCA? How does it differ from the role of something like Spring? Or, asked in the larger sense, where does SCA fit into the world of Containers? My assumption has been that OSGi is analogous to Tomcat - it is the outer container
RE: OSGi host
Hi Andy, Thanks for the link. You bring up a question that's been troubling me about some of this. What is the role of OSGi in SCA? How does it differ from the role of something like Spring? Or, asked in the larger sense, where does SCA fit into the world of Containers? My assumption has been that OSGi is analogous to Tomcat - it is the outer container for hosting SCA runtime instances (the Hosting Platform). I saw Spring as something contained by an SCA runtime. In my simple world view, that would mean that the SCA runtime should mediate between the OSGi and Spring worlds. I'm assuming that we would want an SCA wire between Spring beans accessing OSGi services, etc. so that SCA would have a place to inject code (for whatever reason), and so that the SCDLs would more closely reflect the actual application's interrelationships (a really nice side-effect that enhances manageability). All of this argues for a separate OSGi binding for SCA (and a single SCA bean-type in Spring for 'outside' beans). On the other hand, there is quite a bit of overlap between what Spring and SCA do, and I am getting the feeling that this code could rapidly become wheel-shaped. :-) Do you have any suggestions for how to proceed? What are your thoughts on the big-picture relationship between SCA and these fully-featured containers like Spring and J2EE? Thanks, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 6:40 AM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Note that you will get a lot of this stuff for free if you use Spring. http://opensource.atlassian.com/projects/spring/secure/attachment/11891/ spring_and_osgi.html andy At 14:44 18/08/2006, Hawkins, Joel wrote: Jim, I've done an intial checkin of your patch for OSGi host support. I did some mods and didn't check in the samples as we have a discussion ongoing on how best to structure the samples and didn't want to create more issues for now related to the restructuring. Yes, how to deal with samples is always and issue. I'm sure dealing with test cases will be as well. 1. I didn't check in support for OSGi services as component implementation types. For SCA, our model has typically been that implementation types are created for artifacts that are deployed and evolved as part of a composite. Services that are not deployed with the composite are treated as external and modeled as References. I think this fits with OSGi as well, whose services are more dynamic in nature. Given that, I think we should be providing an OSGi binding that accesses those services as References and publishes SCA components as OSGi Services. I agree. I think where I went for Implementation rather than Reference is when the core wanted me to specify a target declared in the component. In the spec, you can declare a reference without a target, but that didn't appear to be the case in the code I had. My thought process (such as it is..) was that at a certain layer exposure to the SCA runtime as an implementation or a service was really just a layering operation, and converting from one to the other wouldn't be a big effort. I should have pointed that out in the patch. I'll take a shot at converting this to a Reference today if you'd like. 2. Related to the binding, I started to make a bunch of mods to the builder and removed the wiring and connector implementation since the core will provide those now. For example, the core will wire a Component to a Reference with an OSGi binding and will wire a Service with an OSGi binding to a target component. I haven't finished this, but did put some basics in. I wish I'd have waited another week to start - trying to grok all that wiring code made my head hurt. It was a good day when y'all decided to move that into the core. :-) 3. I added the OSGi project as a runtime project. I was imagining having a generic OSGi project that provided the binding capabilities and then platform specific projects for running on various OSGi implementations such as Equinox, Felix, or Knoplerfish. Makes sense. There's only one class that's equinox-specific, so hopefully the move to multiple OSGi implementations shouldn't be too painful. 4. I started to make specific refactorings in the code to follow some of the patterns we have in the container. For example, instead of BundleContextUtil, I was thinking we would have a system service (another SCA component) that is an OSGiHost which allows the OSGi extension to talk to the OSGI container to do things such as publish services. I didn't move the code over in BundleContextUtil yet, though. That's cool, so then OSGiHost may be the only platform-specific bit of code in the distribution. I like it. 5. I also renamed Activator to LauncherActivator as I think the SCA runtime should be packaged as a bundle and launched through it. Sure. Eclipse made the Activator class (it's a default). I assume you
RE: OSGi host
Hi Joel and other OSGi interested guys, What is the role of OSGi in SCA? I see several roles of OSGi in SCA: 1) OSGi Binding and Reference: a) A SCA application can access an OSGi application running outside of the SCA container via a reference/external service. b) A Service Component could be exposed as OSGi Component, similar to EJBs as described in http://www.osoa.org/display/Main/EJB+Integration+White+Paper That's from my understanding what your implementation is supposed to do? 2) OSGi implementation type If the SCA container provides an OSGi implementation type, it would be possible to deploy existing OSGi applications/bundles in the SCA container and use them like SCA components (with all advantages). 3) Use OSGi as underlying technology for a SCA container OSGi could be the base for a SCA container and could provide implementation types for EJB, Spring, BPEL etc. OSGi bundles could run natively in this SCA container. How does it differ from the role of something like Spring? Fromy my point of view OSGi and Spring could be implementation types like 2) In addition Spring is very useful in an SCA container (to build a SCA container) due to its dependency injection feature. Or, asked in the larger sense, where does SCA fit into the world of Containers? In my world SCA is the meta-model on top of existing technologies which is able to combine all the different components/services which are hosted in different containers in a standardized way. It's possible to combine EJB with OSGi, BPEL with C++, Spring with PHP and whatever else we can imagine in a standardized way. New applications should be deployed directly in a SCA container. To be able to fulfill all requirements it would be helpful having a SCA container with different implementation types (no need to restrict the developers to one technology, use always the technology best suited). In the Java world, from my point of view, OSGi (due to its dynamic behaviour and the flexibility) would be the best technology to build a SCA container. I'm looking forward to reading your thoughts on this topic. Best regards Nicole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi host
Hi Nicole, Comments inline... On Aug 21, 2006, at 10:15 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Joel and other OSGi interested guys, What is the role of OSGi in SCA? I see several roles of OSGi in SCA: 1) OSGi Binding and Reference: a) A SCA application can access an OSGi application running outside of the SCA container via a reference/external service. Yes, this would be one of the capabilities b) A Service Component could be exposed as OSGi Component, similar to EJBs as described in http://www.osoa.org/display/Main/EJB+Integration +White+Paper That's from my understanding what your implementation is supposed to do? Yes, it should do this as well 2) OSGi implementation type If the SCA container provides an OSGi implementation type, it would be possible to deploy existing OSGi applications/bundles in the SCA container and use them like SCA components (with all advantages). I think this an interesting use case, particularly if the implementation type would be a composite. I'm not sure about atomic components since OSGi services are more transient in nature. Joel, what do you think? 3) Use OSGi as underlying technology for a SCA container OSGi could be the base for a SCA container and could provide implementation types for EJB, Spring, BPEL etc. OSGi bundles could run natively in this SCA container. This was also one of the goals: the Tuscany runtime could be embedded in an OSGi container such as Equinox. We've started to separate out the projects so there is a generic OSGi host integration project with the pieces necessary to embed Tuscany in any OSGi container and an Equinox project for specifically running on that OSGi implementation. We could also run on other OSGi containers. How does it differ from the role of something like Spring? Fromy my point of view OSGi and Spring could be implementation types like 2) In addition Spring is very useful in an SCA container (to build a SCA container) due to its dependency injection feature. Or, asked in the larger sense, where does SCA fit into the world of Containers? In my world SCA is the meta-model on top of existing technologies which is able to combine all the different components/services which are hosted in different containers in a standardized way. It's possible to combine EJB with OSGi, BPEL with C++, Spring with PHP and whatever else we can imagine in a standardized way. New applications should be deployed directly in a SCA container. To be able to fulfill all requirements it would be helpful having a SCA container with different implementation types (no need to restrict the developers to one technology, use always the technology best suited). In the Java world, from my point of view, OSGi (due to its dynamic behaviour and the flexibility) would be the best technology to build a SCA container. I'm looking forward to reading your thoughts on this topic. Yes, I think this is an important feature of SCA, i.e. the ability to be able to re-use existing technologies. If you would like to jump in and help, I'm sure Joel, I, and others would appreciate any time/ suggestions you could give. I believe Joel is working on revising the OSGi projects as we speak so I'll let him relay what he is up to. Jim Best regards Nicole - 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: OSGi host
Jim, I've done an intial checkin of your patch for OSGi host support. I did some mods and didn't check in the samples as we have a discussion ongoing on how best to structure the samples and didn't want to create more issues for now related to the restructuring. Yes, how to deal with samples is always and issue. I'm sure dealing with test cases will be as well. 1. I didn't check in support for OSGi services as component implementation types. For SCA, our model has typically been that implementation types are created for artifacts that are deployed and evolved as part of a composite. Services that are not deployed with the composite are treated as external and modeled as References. I think this fits with OSGi as well, whose services are more dynamic in nature. Given that, I think we should be providing an OSGi binding that accesses those services as References and publishes SCA components as OSGi Services. I agree. I think where I went for Implementation rather than Reference is when the core wanted me to specify a target declared in the component. In the spec, you can declare a reference without a target, but that didn't appear to be the case in the code I had. My thought process (such as it is..) was that at a certain layer exposure to the SCA runtime as an implementation or a service was really just a layering operation, and converting from one to the other wouldn't be a big effort. I should have pointed that out in the patch. I'll take a shot at converting this to a Reference today if you'd like. 2. Related to the binding, I started to make a bunch of mods to the builder and removed the wiring and connector implementation since the core will provide those now. For example, the core will wire a Component to a Reference with an OSGi binding and will wire a Service with an OSGi binding to a target component. I haven't finished this, but did put some basics in. I wish I'd have waited another week to start - trying to grok all that wiring code made my head hurt. It was a good day when y'all decided to move that into the core. :-) 3. I added the OSGi project as a runtime project. I was imagining having a generic OSGi project that provided the binding capabilities and then platform specific projects for running on various OSGi implementations such as Equinox, Felix, or Knoplerfish. Makes sense. There's only one class that's equinox-specific, so hopefully the move to multiple OSGi implementations shouldn't be too painful. 4. I started to make specific refactorings in the code to follow some of the patterns we have in the container. For example, instead of BundleContextUtil, I was thinking we would have a system service (another SCA component) that is an OSGiHost which allows the OSGi extension to talk to the OSGI container to do things such as publish services. I didn't move the code over in BundleContextUtil yet, though. That's cool, so then OSGiHost may be the only platform-specific bit of code in the distribution. I like it. 5. I also renamed Activator to LauncherActivator as I think the SCA runtime should be packaged as a bundle and launched through it. Sure. Eclipse made the Activator class (it's a default). I assume you updated the manifest as well. We can discuss the changes in more detail. I think we also need to figure out a bunch of things, including application deployment, extension deployment and how classloading will play out. For example, in our component tree, a composite may have the following classloader relationships. For system extensions: SNIP/ We'll need to map that into OSGi bundles and classloader management. Yes, that's where the fun starts. Can you suggest a good experimental scenario based on what's in Tuscany today? If you're online tomorrow, I will be happy to chat in more detail. I'm on googletalk at [EMAIL PROTECTED] or (preferrably) on IRC #tuscany. I'm stuck behind a corporate firewall that doesn't allow IRC traffic. I'll try and get that fixed, but I can guarantee that it won't happen in one day. Thanks for submitting this and sorry I started to butcher parts of it so quickly! No problem - I was planning on a fair amount of tear-up just based on what was going on in the mailing list! 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]
RE: OSGi host
If you're online tomorrow, I will be happy to chat in more detail. I'm on googletalk at [EMAIL PROTECTED] or (preferrably) on IRC #tuscany. How about a good old-fashioned conference call? I'm in the Eastern time-zone. I'm pretty much clear all afternoon. I'll be happy to set this up. Cheers, Joel 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]
