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 >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] _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- 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]
