Tuscany and Websphere

2007-10-08 Thread Matthew Peters
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.

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). 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, which as far as I can see is 
roughly what the SOA feature pack for WAS does: you define Business Level 
Applications (which must be related to domains in some way) and then you 
can add contributions to them explicitly and start and stop them explictly 
from extra panels in the admin console. I imagine (only imagine, note, I 
haven't looked) that when you add the contribution it gets put somewhere; 
when you start the BLA a domain gets created, and the SOA FP is in charge 
while classes get loaded and instantiated and dependency injection gets 
done. But, I don't know what would happen with a contribution with an ejb 
in it since the SOA FP doesn't handle JEE artifacts yet. At what point 
would the ejb get given to the ejb container? 

The other approach is to leave WAS in charge as far as possible. Normal 
WAS deployment time behaviour is to examine the ear file and to pass 
whatever it finds to the appropriate handler for deployment: servlets to 
the web containre, ejbs to the ejb container etc. I can imagine just 
adding in a new step which is "during normal ear file processing, if you 
find an SCA contribution, locate an SCA domain and give the contribution 
to it". In fact with WAS 6.1 which is based on OSGI you can add in 
processing like this non-invasively. But then in this case if Tuscany 
opened the contribution and found an ejb that was a component would it 
have to give the ejb back to WAS?

That's just thinking about deployment. I have various things that are 
puzzling me about what should happen at runtime: who should create, start 
and stop the SCA domain, who actually does class loading, Tuscany or WAS, 
and if WAS loads a class and instantiates it and it is a component then 
how does it give the instance to Tuscany for dependency injection.

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?

Matthew Peters





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







Re: Tuscany and Websphere

2007-10-12 Thread Jean-Sebastien Delfino

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):




 
   
   
 

 
   
 




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  is instantiated by the Tuscany 
implementation-java container, according to the rules in the SCA Java 
C&I spec.
- An  is instantiated by Apache ODE (the BPEL 
engine integrated with Tuscany).
- An  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]



Re: Tuscany and Websphere

2007-10-15 Thread Matthew Peters
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):



  


  

  

  




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