Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ppeshev@gmail.com designates
 209.85.218.210 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=JPybIPf9yH9dqBExeNwvFicp0xTKDitLedCwlv8sZep4Y7nz6579Qm/Gtz63BbxU3I
         JWxJjGNT4b56Ad+13DS0YMUgmU+1GvSa/kynzYsJNnEaOsTibuDWeYLEDp4SNr2Tj5nW
         vpFBqlwFAnKQcRqJrN6qxlmYQfrrfKVmubOb0=
MIME-Version: 1.0
In-Reply-To: <adbf02b10909101218l1a0c9575vbad9166015c936b6@mail.gmail.com>
References: <adbf02b10909010736y2ea39ff2o76634ac210e7f86a@mail.gmail.com>
	 <487a994c0909050131n42ee26f4hfd713d57c26668d3@mail.gmail.com>
	 <4AA23BAE.4070008@gmail.com>
	 <487a994c0909050729q539b7946xfb0ddea0b21a58f5@mail.gmail.com>
	 <4AA29486.4050103@gmail.com>
	 <adbf02b10909070757t1e78fc10m43254d5fc286118f@mail.gmail.com>
	 <2d46a5dc0909081449r2a183afcw5f334db02e8f1938@mail.gmail.com>
	 <adbf02b10909100159s1282a679m9c878a873626b99@mail.gmail.com>
	 <2d46a5dc0909100912y2192129dx1358311ad13d47f1@mail.gmail.com>
	 <adbf02b10909101218l1a0c9575vbad9166015c936b6@mail.gmail.com>
Date: Fri, 11 Sep 2009 19:31:11 +0300
Message-ID: <2d46a5dc0909110931p7ce4895eoc6cc8a7ca8533b07@mail.gmail.com>
Subject: Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
From: Peter Peshev <ppeshev@gmail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <hughesj@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 <ppeshev@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 =A0stable =A0so it's no=
t
>> 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" =A0mentioned in the proposal could bring as
>> well metainformation about =A0JMS resources (connection factories,
>> destinations) that are going to be used from the application =A0and 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 <hughesj@apache.org> wro=
te:
>>> 2009/9/8 Peter Peshev <ppeshev@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 =A0personally suggest even t=
o
>>>> 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 =A0non-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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org