Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Manu George" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:53 AM
Subject: Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi ,
From Paul's mail I guess a Geronimo plugin would be
the way forward. I am going to list down a few more questions on the
scenarios that Sebastien has explained. The scenarios are given first
and then my understanding, approach and issues. I would be just
listing two of the scenarios and trying to implement them initially.
(a) I develop SCA components, assemble them in a composite, package them
in an SCA contribution. I don't really know what a WAR or an EAR is,
I'm
just using the SCA programming model and packaging model. I deploy my
SCA contribution to Geronimo and run it there.
This will require a tuscany specific deployer that is installed as
part of the plugin. Ususally deployers have access to a server
specific deployment plan at some fixed path say
(META-INF/geronimo-tuscany.xml). If this file is found then the
deployer will know that the module that was supplied to it is a
tuscany module. In case I am deploying a tuscany contribution using
the sca packaging model then there will be a .composite file somewhere
in the module and the deployer will have to search in the module for
scdl files. For now the tuscany contributions will always be
packaged as jars.
I'm not a geronimo expert. My understanding is that the Tuscany deployer
needs a way to recognize the archive is a SCA contribution. It could
be an external deployment plan such as genronimo-tuscany.xml. If the
deployment plan is not present, then a SCA "deployment descriptor" will be
checked. The SCA assembly spec doesn't define a mandatory deployment
descriptor. We might be able to use "META-INF/sca-contributions.xml" as
a starting point.
This will mean that if the deployer finds this file then it will
handle the module as a tuscany module and if not found relinquish
control to other deployers.
The SCA contribution itself can be an EAR. I assume an archive can be
processed by multiple deployers.
Now we come to the question of the Domain. This has been a vexing
question for me. I think that going for a single SCADomain for the
entire server would be a good place to start.
All the applications will have an application composite and that
composite will be deployed on the server wide SCADomain. What the
server wide SCADomain should provide is the ability to add and remove
composites at runtime. If I am not mistaken this will be supported by
the EmbeddedSCADomain. Can someone in the know comment on this.
We can start with a local SCA domain for the Geronimo server.
EmbeddedSCADomain is the right class and it can be extended to support the
Geronimo host.
The other logical approach would be to go for different partial
SCADomain instances per contribution. These different instances will
still have information about the other instances and will do the
wiring across the instances that constitute a complete SCADomain.
From what I could find, this type of an SCADomain is not
supported currently. There is work on an SCADomain spanning multiple
runtimes. This would be a simpler case of an SCADomain spanning
multiple classloaders or (configurations in Geronimo).
SCADomain can span multiple runtimes. Simon Laws from Tuscany is driving the
support of distributed SCADomain. I'm a bit confused by the statement
"different partial SCADomain instances per contribution". Can you clarify?
The reason for not going with the second approach is that it is not
available in tuscany as of today. Please correct me if I am wrong.
(b) This was point (c) in Sebastien's mail.
I want to use a Web app in my SCA assembly and call SCA components
from it. I should be able to declare an SCA component representing
my
Web app, wire that component to other SCA components in the
assembly,
and then magically the wired references will be available as proxies
for
use in my JSPs, allowing me to call an SCA component using a simple
jsp:useBean tag.
In addition to this the J2EE integration whitepaper at the OSOA
site mentions abt being able to annotate Web
artifacts(servlets,filters etc) with the SCA Annotations and get
services injected into servlets/filters etc for usage. The wiring will
be done by the SCA runtime. The whitepaper is here
http://www.osoa.org/pages/viewpage.action?pageId=3980.
The things to be done for achieving this functionality are,
1) Create a new implementation type in Tuscany namely implementation.web.
2) Declare in a .composite file in the war that the war is an
implementation.web type
3) The implementation.web tuscany extension will have functionality
to introspect the web module classes for SCA specific annotations and
build up information. Since there is a single SCADomain instance per
server and all the services that we are going to reference are already
deployed there, the implementation.web extension will take care of
wiring and creating service proxies. These proxies will be bound to
jndi.
I didn't do much investigation in this space but it seems that it's in line
with the white paper.
The injection into geronimo managed objects cannot be done by tuscany
runtime. I am not 100% sure but I think that if I can populate the
injectionMap in the Holder object in the TomcatWebAppContext GBean for
that war with the right information then the injection will be taken
care of by Geronimo. Can someone confirm this?
This will take care of the integration in these two cases. As of now
we are assuming all the services to of scope stateless. All the stuff
in the second case will be done in a deployment watcher after a war
has been deployed.
This is the approach that myself and Vamsi are planning to use. If
there is any problem with this approach that you can see or a better
way to do things or something in the mail is not clear, please fell
free to point it out.
Regards
Manu
On 6/29/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
On Jun 29, 2007, at 3:11 AM, Manu George wrote:
>> >
>> > Some of the questions we have are:
>> > 1. Should we use this plugin approach and host the plugin
>> separatley
>> > or intergrate Tuscany to be bundled as part of the Geronimo
>> > distribution?
>>
>> The plugin approach looks OK to me, but maybe somebody from the
>> Geronimo
>> project could give a more educated opinion?
>>
>
> I believe we can start with a plugin approach but if we run into some
> problems with implementation as a plugin then probably we can think of
> full fledged integration.
> Can someone from the Geronimo community with expertise here, please
> give their opinions on this.
Implementing as a plugin should not affect the technical design of
this component. I don't know of anything you can do in a component
integrated into Geronimo at assembly time that you cannot do in a
plugin integrated after installation. A plugin is really just a
component that has been preconfigured for rapid deployment and
dependency downloading. It's a packaging decision.
IMO new components created for Geronimo that are not required by the
JEE specification should be implemented as plugins. This is a rule
of thumb, and in some cases there may be justification for an
exception. Like for example if we believed that almost every
Geronimo user will need SOA then we should discuss "full fledged
integration". Another type of exception would be if we think that
the component would provide useful services to Geronimo's native
components.
Best wishes,
Paul
