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.
Regards,
Ian Robinson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
