incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Robinson <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Fri, 11 Sep 2009 18:30:00 GMT
Peter Peshev wrote:
> Anyway - after reading the proposal , my mental model for Aries is the
> following -   a group of bundles or web archives (here comes RFC 66 )
> are grouped via a new extended SCA component type (
> implementation.osgi_application)  or perhaps inherit from the
> implementation.jee that is in the spec.  
An SCA component type describing a collection of bundles is certainly 
what you'd want to see in the SCA services view of the world. There's 
probably a step before that though, for homogenous OSGi assemblies, that 
describes the modularity characteristics of a group of OSGi bundles in a 
more local OSGi dialect (perhaps in the form of a manifest for the group 
of bundles). In such a form that an SCA component type can be derived.
> Since big part of the
> enterprise scenarios are addressing already existing applications,
> there could be an existing code that  uses JMS resources.  I was kind
> of assuming that the definition for those would be  done via the
> standard SCA  binding.jms  -- the application developer should define
> in the SCA artifacts via binding.jms  the resources  used  from the
> code either via @Reference or via a pure JMS API call. So in a way
> Aries would be the glue code - reading the SCA xml-s and propagating
> to all the other involved parties what is needed. For the JMS broker
> case -- create the destinations and factories. For the OSGi runtime -
> provide the bundles.
I can see (at least) 2 ways of looking at JMS: (i) where a component 
programmer wishes to use the JMS API and programing model. For example 
the Aries blueprint container should be able to provide a means for a 
component to declare a reference to a JMS provider (along with its 
configuration) which is resolved through the service registry and 
injected into the component. (ii) where the  component programmer 
doesn't much care about JMS but the deployer specifies JMS resources in 
a remote services binding. For an SCA component these definitions would 
be part of a binding.jms and I think there's potential for some 
Aries/Tuscany collaboration around this.

I'm sure there's plenty of further detail we can discuss around these 
ideas, although that might be better done on the Aries mailing list if 
the proposal is accepted for incubation.

Ian Robinson

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message