Hi Jeremy, No I don't feel strongly for this, I am not suggesting a change of the proposal, I am just trying to build a detailed picture for myself (and perhaps for the community) what exactly some parts of Aries project would look like. I am not Apache experienced, so I am not sure whether I should have the discusison here or wait till the proposal is voted and trigger it on the Aries mailing list if accepted, since those are really technical details. So please stop me if you feel like it's not the right time
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. 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. It's a JMS scenario but the same model is valid to the other stuff if there is interest to integrate - JCA, web services, proprietary SCA bindings for backend connectivity, etc.. Is this correct, or I am describing something totally new and different than what you are proposing? Best regards Peter On Thu, Sep 10, 2009 at 10:18 PM, Jeremy Hughes <hugh...@apache.org> wrote: > Sorry, I didn't mean we would exclude applications from using the JMS > API. There are cases where a Blueprint component isn't concerned what > async comms is being used, and there are times when that level of > detail is needed. There are many use cases which of course we haven't > thought about and that is a reason why we're coming to Apache - to > explore that. So the proposal is the initial scope and the project > will hopefully grow from there. If you feel strongly about it then we > can add something to the proposal. > > Thanks, > Jeremy > > 2009/9/10 Peter Peshev <ppes...@gmail.com>: >> Hi Jeremy, >> >> Well, I had some other use cases in mind besides "Message driven >> Blueprint components" >> >> At least in my view JMS API is quite popular and stable so it's not >> a rare case to be used from web applications as it is. An interesting >> use case would be the resource provisioning. I would expect that >> those "deployable units" mentioned in the proposal could bring as >> well metainformation about JMS resources (connection factories, >> destinations) that are going to be used from the application and I >> would expect the Aries would be the glue code between the resource >> creation in the JMS broker and the deployment. >> >> Best regards >> Peter >> >> On Thu, Sep 10, 2009 at 11:59 AM, Jeremy Hughes <hugh...@apache.org> wrote: >>> 2009/9/8 Peter Peshev <ppes...@gmail.com>: >>>> Hi Jeremy, >>>> >>>> Since you are asking about potential committers - at least to me a new >>>> OSGi project focused on Java EE sounds quite interesting. >>>> >>>> Btw, when looking at the proposal I would personally suggest even to >>>> expand the scope and include other Java enterprise concepts - for >>>> example integration with JMS (i.e. ActiveMQ) , JCA resource adapters , >>>> or addressing the usecase for integration of non-Apache Java EE >>>> components (EclipseLink, etc.). Would you consider these as in scope >>>> for the project ? >>> >>> I think these are in scope. They're just not explicitly called out in >>> the proposal. On the asynchronous messaging side, we do call out >>> "Message driven Blueprint components" which would (potentially) use >>> JMS to achieve that. >>> >>> Thanks, >>> Jeremy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
