Jean-Sebastien, thanks for your thoughtful reply. Things have come a lot clearer now.
Please excuse the top-posting rather than threading - I am using Notes. Perhaps I should move elsewhere for mailing list stuff. Thanks for the reference to the white paper. Last week I also found a document that is being discussed within the osoa group on a regular Friday call at http://www.osoa.org/download/attachments/1048948/SCA_JAVAEE_integration.doc and I recognise some of the text so I guess the white paper is an early version. But this document is only visible to people who have an id on that site, though, which I guess might be why you put a link to the white paper instead. The osoa people would probably be willing to make the document public, by the way, if we ask. Anyway I now realise that there are people who have been thinking this through for quite a while. What I grasped from their document, and your reply, is that I was worrying about a bogus scenario - I was imagining a contribution with web, java, ejb all mixed in and repackaged in some new and strange way. Your sample composite which just reuses the existing packaging methods makes much more sense. I do have a question about it though. I am guessing that in your example the ear file is the contribution. If there were more than one servlet in the ui.war file, and I wanted these servlets to be components and have references, I am not quite sure where that information goes. I suppose it is in the ui.war file itself and it is up to the way implementation.web is implemented to find that information. Likewise, your principle that Tuscany should be reusing the class loading and instantiation that comes with the host runtime makes complete sense to me. So, I understand that to mean that for example, an SCA-aware web container that was in charge of a servlet that was a component would either drive its normal class loading and instantiation, then pass the instance to Tuscany to do dependency injection on...or...would ask Tuscany to do it all but provide Tuscany a route to the runtime so it can get class loading and instantiation done in the normal way. But I should take a step back, stop guessing and let you work it out. I have got the basic idea that although we need something somewhat new - a so-called SCA-enabled JEE runtime - it's not absurdly new but reuses most existing ways of doing things. So, thanks for this - you've given me some fixed points which makes everything much easier to get my mind round. Matthew Jean-Sebastien Delfino <[EMAIL PROTECTED]> 13/10/2007 02:15 Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: Tuscany and Websphere Matthew Peters wrote: > I am trying to understand how a contribution that contains a mix of > artifacts, including JEE artifacts, should be handled by Tuscany and the > runtime into which it is being deployed. > SCA-enabling of a JEE runtime and the scenarios that this will address are introduced in a whitepaper at: http://www.osoa.org/pages/viewpage.action?pageId=3980 Tuscany currently supports what's described in this whitepaper as "Single Module Assembly": A Web module is used as an SCA contribution containing component implementations. Components are assembled inside the Web module using SCA composites. The whitepaper mentions a single META-INF/web.composite, right now in Tuscany we allow you to name your composite however you want. I'd like to tacke the main other scenarios described in the whitepaper in the next releases, as mentioned in the Tuscany Roadmap discussion at: http://marc.info/?l=tuscany-user&m=119203494411767&w=2 Some of this work has already started in the context of the Tuscany - Geronimo plugin at http://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk. > Here's a scenario just to make it concrete. Imagine I have a contribution > that includes some JEE UI components like some servlets or JSPs, some Java > SCA components, and just to make it tricky an EJB that is also an SCA > component (if that's not possible yet then I am guessing it will be in the > future). If I understand correctly, this will probably translate to something like follows (using the terminology from the whitepaper): <composite> <component name="MyUI"> <implementation.web module="ui.war"/> <reference name="myBackendService" target="MyBackend/MyService"/> </component> <component name="MyBackend"> <implementation.ejb ejb="backend.jar"/> </component> </component> </composite> As a first step, I think we could just represent Web modules and EJB modules as component implementations and not necessary try to boil the ocean right away with individual EJBs as component implementations, maybe later... > And suppose, to be specific, that I want to deploy this onto > Websphere Application Server (WAS). > > In this scenario I really want to understand things like what should > happen during deployment and runtime, and how Tuscany and WAS should > cooperate during class loading and instantiation and do any dependency > injection. > > I can think of two different approaches. > > The first is to put Tuscany firmly in charge [snip] > The other approach is to leave WAS in charge as far as possible. [snip] Tuscany is not trying to reinvent a JEE container. It seems that the JEE container should be running the JEE artifacts and Tuscany would just inspect the JEE artifacts and derive their SCA ComponentType from it would find in them. [snip] > Essentially it seems to me that Tuscany and WAS are both meaty runtimes > that are used to being in charge by themselves, especially WRT class > loading and instantiation. Has anyone thought this all through and can > tell me how it ought to work? > We only started to discuss the JEE integration in the roadmap this week... so it's a little too early to say how it ought to work :). I don't think that Tuscany should impose its own classloading and instantiation mechanism. I think that Classloading is a function of the hosting environment. Tuscany needs to use the ClassLoader provided by your particular J2SE / OSGi / Tomcat / Geronimo / WebSphere / WebLogic / JBoss / Glassfish / etc hosting environment. If it doesn't, then it's a bug which ought to be fixed. It looks like there's active discussions on our dev list and people working on it to help Tuscany play well with OSGi as we speak :). IMO instantiation of an implementation is a function of the particular implementation type container: - An <implementation.java> is instantiated by the Tuscany implementation-java container, according to the rules in the SCA Java C&I spec. - An <implementation.bpel> is instantiated by Apache ODE (the BPEL engine integrated with Tuscany). - An <implementation.web> is instantiated by the Web container in which it is deployed. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
