Nicole,
More comments inline -
it would be great if you could send us your sample code :-)
Playing with the source code will help us to understand.
Packaging it now. You'll get the samples and the prototype runtime as
well. I'll have it in the mail to you and Robert today. I think it'll
really help our discussions, instead of me waving my hands about my
head
and writing about things you haven't seen! ;-)
I have some comments to your EMail:
I don't want to propose something antithetical to OSGi's philosophy.
We had the OSGi R4 Declarative Service(DS) specification in mind. In
the
bundle manifest you can configure the component.xml files for the
components
contained in the bundle. The DS 'scans" or "searches" for the
component.xml
files and is reponsible for the dependency management (as defined in
the
component.xml
files) and activation/registration of components.
We thought that the proposed "Tuscany runtime service" could do
something similar
to the DS.
Perhaps 'antithetical' is too strong a word... My 'scanner' is
basically
a bundle listener. Scdls in activated bundles get deployed as
applications into the Tuscany runtime. My thought was, don't try and
replace DS. Let DS deal with interdependencies between OSGi services,
and let the OSGi service binding be the mediator between DS and
Tuscany.
The next question (which is not easy to answer for me) is if every
SCA
component should get its
own Tuscany runtime. I would say this depends on the view or the
level
of integration.
From my understanding we're currently talking about "SCA/Tuscany
embedded in OSGi". That's one
level of integration. Another level of integration might be an "OSGi
based SCA container".
For "SCA embedded in OSGi" I have one Tuscany runtime (which consists
of
a small number of
OSGi bundles) in mind and which is able to host many SCA components.
I should probably make a distinction here - if you look at the WebApp
runtime, for example, it creates a single Tuscany system runtime, and
deploys a single application into it. The runtime interface definition
even reflects this mapping. What I've got takes a single system
runtime
and deploys multiple applications into it. So when I said multiple
runtimes, what I meant was multiple application runtimes.
For "OSGi based SCA container" I have an OSGi container in mind,
which
supports 'out-of-the-box'
SCA. We could have an entry in the Manifest pointing to the scdl file
(like today a link to
the component.xml file). Every OSGi service can use the full feature
set
of SCA. In addition we
have implementation types like an EJB implementation type. The
implementation type itself
would provided in another OSGi bundle, e.g. an EJB container
running in
an OSGi bundle. All EJBs will
be deployed in the EJB container bundle. This would mean we have SCA
components written in EJB
technology running in one OSGi bundle and SCA components written in
'OSGi technology' running in
separate bundles.
Here's one way to deal with that - if the bundle has a default.scdl
in a
Tuscany folder under meta-inf, give it it's own system runtime
corresponding to the default.scdl, and deploy it's apps into that
runtime.
If the bundle had application scdls under an Sca folder, then use the
default runtime to deploy into. That way we can provide a single
runtime
to support both models. Sound good?
Best regards
Nicole
-----Original Message-----
From: Hawkins, Joel [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 4:55 PM
To: [email protected]
Cc: Jasny, Robert
Subject: RE: OSGi Binding
Hi guys - answers (and more questions) inline:
-----Original Message-----
From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 10:32 AM
To: [email protected]
Cc: Jasny, Robert
Subject: RE: OSGi Binding
Hi Joel,
I discussed your EMail with my colleague Robert.
We have a lot of questions, I assume because we are new to Tuscany and
SCA :-)
I'm having issues with the Axis2 binding right now.
What is your use case, using the Axis2 binding to invoke an OSGi
Service from a SCA component running outside of the container?
Have you deployed a SOAP bundle in the OSGi container?
(We're using a SOAP bundle provided by the Knopflerfish project, it
runs
in the Equinox container).
I've got an Axis2 bundle that we use for apache Muse. I'd like to try
the Knoplerfish bundle. I'll pop out to their site and grab it.
Thanks!
dual classloader hierarchy' requirement
What exactly do you mean? Do we want to have different
classloaders for
the bindings and the applications?
The down side is that we lose the capacity to start and stop
extension
bundles,
Our understanding about fragments bundles is the following:
If OSGi bundle B has defined a 'Fragment-Host: bundle A', bundle A
will
have one classloader which will be extended by bundle B's exported
classes as soon bundle B is started. As much we understood the OSGi
spec
there's
only
one classloader in bundle A which holds all classes from bundle A as
well from it's fragment bundle B. How can this help to support the
'dual classloader hierarchy'
requirement for SCA applications?
Fragment bundles can be started and stopped independently from their
host bundle.
If you stop a fragment bundle, the host bundle must be refreshed (or
restarted)
to update the host's classloader. Why would we lose the capacity to
start/stop extension bundles?
Well, in equinox, if you try to stop a fragment bundle you get:
org.osgi.framework.BundleException: A fragment bundle cannot be
stopped:
[EMAIL PROTECTED]:file:../../../../workspaces/CORONA_SCA/tuscany-
binding
-osgi/
You can uninstall/re-install to you hearts content, and that will
require a refresh.
Perhaps this is an equinox problem?
One of the major pains of porting existing extensions is the
assumption
about
file locations.
I assume you're talking about the scdl files?
Yup. And wsdls. And schema. ;-)
For each bundle with an application composite (scdls under an "sca"
folder), I create a Tuscany runtime using the extended system
config,
and run the application composite inside it.
If we understand you correctly, this would mean that we have for a
number of x SCA components, x Tuscany runtimes running in the OSGi
container?
Yes.
We would prefer a solution where exactly one Tuscany runtime is
running.
What about having a Tuscany runtime service in the OSGi container
deployed which scans a given directly for scdl.files (contained in
the
JARs of the SCA application composites)?
For every scdl the defined components will be started in the Tuscany
runtime and services with OSGi binding will be registered
automatically
in the OSGi
registry.
It seems like your requirement would be met by just deploying one big
scdl for your application. My view of an OSGi host for Tuscany is
somewhere between an app server (where Tuscany components would
communicate over a remotable interface like WS) and a plain old SCA
composite (where components are directly wired). By supporting
multiple
SCA applications in a single OSGi, you can provide a degree of
isolation
that isn't possible when dumping everything into a single SCA runtime.
You'll have the ability to stop and restart portions of your SCA
'fabric'. Plus, you can provide fast inter-application communication
using the OSGi service binding mechanism. I thought it was kind of
nice!
I really want to stay away from any type of scanning solution, as that
seems antithetical to OSGi's philosophy. Of couse, I'm willing to be
voted down!
void doIt(BundleContext context){
String APP_FILTER =
"(&
((objectclass=org.apache.tuscany.sca.osgi.core.ApplicationContextSe
r
v
ice)(Name="SupplyChainShipper)))";
ServiceReference[] refs =
context.getServiceReferences
("org.apache.tuscany.sca.osgi.core.Applica
t
i
onContextService"
Is there really a need to register the ApplicationContextService is
OSGi?
I thought we could directly register the service interface
provided by
the SCA component. Otherwise I do not understand how a standard OSGi
service
is able to get the reference of the SCA service?
If an SCA component is bound as an OSGi service, all you need to do is
use the typical OSGi service registry code. If an SCA component isn't
bound and an osgi service, but you want to interact with it from
outside, the thought was that you could resolve the SCA context
containing the desired component and invoke it directly.
I'll send you my sample code. That might make it clearer. I'm trying
(really!) to get this stuff back in sync so that I can give Jim
another
patch.
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]
---------------------------------------------------------------------
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]
