You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2011/03/15 19:48:54 UTC
Advice for CAMEL-3476
Hello dev!
I would like to get an advice from your for [1].
I would prefer to implement the AWS SNS component to "only" provide a
producer (which sends notification to the AWS SNS topic).
In my opinion, the user should be responsible to configure the subscription
for this topic (outside of Camel with the Amazon management web console). If
the user subscribe to an AWS SQS queue, he can use the AWS SQS component and
poll this queue (already available since Camel 2.6.0).
Another guy would like to make this subscription via Camel, which has in my
opinion the following disadvantages:
- The Camel SNS consumer acts like the Camel SQS consumer. It polls an AWS
SQS queue. Therefore we have some code duplications and two different
components which do the same thing.
- It's only planned to make a subscription to an AWS SQS queue. If the user
would like to make a subscription to HTTP, HTTPS, E-Mail or so, he has to do
it still manually.
- The subscription functionality will be the biggest part of this component:
at startup:
1) Create the AWS SQS queue (mandatory web service call)
2) Query the queue ARN (mandatory web service call)
3) Provide the policy to allow the AWS SNS topic to write into the AWS
SQS queue (mandatory web service call) --> For this, the user has to provide
its own policy file in JSON format
4) Make the subscription from the AWS SNS topic to the AWS SQS queue
(mandatory web service call)
at shutdown:
5) remove the subscription (web service call if required)
6) remove the AWS SQS queue (web service call if required)
- I have some bad feelings therefore (which I cannot express good) and I
would like to provide a cleaner, easier to use and to maintain component.
Also with the absence of functionality which may be only a few people use
and a good alternative exists (Amazon management web console to make the
subscription)
What are your thoughts? Could you please comment this issue?
[1] https://issues.apache.org/jira/browse/CAMEL-3476
Cheers,
Christian
Re: Advice for CAMEL-3476
Posted by Mark Ford <ma...@massfords.com>.
I thought this was settled in the issue comments already. You haven't
raised any new points except the percentage of code devoted to the
consumer which I think is irrelevant. That code is only exercised when
the user provides the appropriate switches and it also may shrink when
Tracy refactors the component to share code between the SQS and SNS
components which were developed separately.
Also, steps 1, 2, 3, and 6 below are optional. Their execution depends
on whether you created the subscription with a SQS name as opposed to
a SQS ARN. I don't think it's fair to criticize having to make a call
to the server to create the subscription (step 4 below). I don't know
how else to do this apart from not supporting it at all like you've
proposed.
That said, I can't imagine more than a dozen people in the world will
use this component for either pub or sub so it's not that big of a
deal. I'll keep the google code project up if people crave this
functionality.
-- "Another guy"
On Tue, Mar 15, 2011 at 2:48 PM, Christian Müller
<ch...@gmail.com> wrote:
> Hello dev!
>
> I would like to get an advice from your for [1].
>
> I would prefer to implement the AWS SNS component to "only" provide a
> producer (which sends notification to the AWS SNS topic).
> In my opinion, the user should be responsible to configure the subscription
> for this topic (outside of Camel with the Amazon management web console). If
> the user subscribe to an AWS SQS queue, he can use the AWS SQS component and
> poll this queue (already available since Camel 2.6.0).
>
> Another guy would like to make this subscription via Camel, which has in my
> opinion the following disadvantages:
> - The Camel SNS consumer acts like the Camel SQS consumer. It polls an AWS
> SQS queue. Therefore we have some code duplications and two different
> components which do the same thing.
> - It's only planned to make a subscription to an AWS SQS queue. If the user
> would like to make a subscription to HTTP, HTTPS, E-Mail or so, he has to do
> it still manually.
> - The subscription functionality will be the biggest part of this component:
> at startup:
> 1) Create the AWS SQS queue (mandatory web service call)
> 2) Query the queue ARN (mandatory web service call)
> 3) Provide the policy to allow the AWS SNS topic to write into the AWS
> SQS queue (mandatory web service call) --> For this, the user has to provide
> its own policy file in JSON format
> 4) Make the subscription from the AWS SNS topic to the AWS SQS queue
> (mandatory web service call)
> at shutdown:
> 5) remove the subscription (web service call if required)
> 6) remove the AWS SQS queue (web service call if required)
> - I have some bad feelings therefore (which I cannot express good) and I
> would like to provide a cleaner, easier to use and to maintain component.
> Also with the absence of functionality which may be only a few people use
> and a good alternative exists (Amazon management web console to make the
> subscription)
>
> What are your thoughts? Could you please comment this issue?
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-3476
>
> Cheers,
> Christian
>
Re: Advice for CAMEL-3476
Posted by Mark Ford <ma...@massfords.com>.
What do you mean by implementing it as a connector?
On Wed, Mar 16, 2011 at 2:46 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Christian,
>
> It looks like the subscription can be implemented as a connector.
> In this way user could configure the connector as they want and your SNS
> component could be free to this kind detail message.
>
> If you take a look at camel-jms component, it resolve the same question by
> setting the connector to the component.
>
> Just my 2 cents.
>
> Willem
> On 3/16/11 2:48 AM, Christian Müller wrote:
>>
>> Hello dev!
>>
>> I would like to get an advice from your for [1].
>>
>> I would prefer to implement the AWS SNS component to "only" provide a
>> producer (which sends notification to the AWS SNS topic).
>> In my opinion, the user should be responsible to configure the
>> subscription
>> for this topic (outside of Camel with the Amazon management web console).
>> If
>> the user subscribe to an AWS SQS queue, he can use the AWS SQS component
>> and
>> poll this queue (already available since Camel 2.6.0).
>>
>> Another guy would like to make this subscription via Camel, which has in
>> my
>> opinion the following disadvantages:
>> - The Camel SNS consumer acts like the Camel SQS consumer. It polls an AWS
>> SQS queue. Therefore we have some code duplications and two different
>> components which do the same thing.
>> - It's only planned to make a subscription to an AWS SQS queue. If the
>> user
>> would like to make a subscription to HTTP, HTTPS, E-Mail or so, he has to
>> do
>> it still manually.
>> - The subscription functionality will be the biggest part of this
>> component:
>> at startup:
>> 1) Create the AWS SQS queue (mandatory web service call)
>> 2) Query the queue ARN (mandatory web service call)
>> 3) Provide the policy to allow the AWS SNS topic to write into the AWS
>> SQS queue (mandatory web service call) --> For this, the user has to
>> provide
>> its own policy file in JSON format
>> 4) Make the subscription from the AWS SNS topic to the AWS SQS queue
>> (mandatory web service call)
>> at shutdown:
>> 5) remove the subscription (web service call if required)
>> 6) remove the AWS SQS queue (web service call if required)
>> - I have some bad feelings therefore (which I cannot express good) and I
>> would like to provide a cleaner, easier to use and to maintain component.
>> Also with the absence of functionality which may be only a few people use
>> and a good alternative exists (Amazon management web console to make the
>> subscription)
>>
>> What are your thoughts? Could you please comment this issue?
>>
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-3476
>>
>> Cheers,
>> Christian
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
Re: Advice for CAMEL-3476
Posted by Willem Jiang <wi...@gmail.com>.
Hi Christian,
It looks like the subscription can be implemented as a connector.
In this way user could configure the connector as they want and your SNS
component could be free to this kind detail message.
If you take a look at camel-jms component, it resolve the same question
by setting the connector to the component.
Just my 2 cents.
Willem
On 3/16/11 2:48 AM, Christian Müller wrote:
> Hello dev!
>
> I would like to get an advice from your for [1].
>
> I would prefer to implement the AWS SNS component to "only" provide a
> producer (which sends notification to the AWS SNS topic).
> In my opinion, the user should be responsible to configure the subscription
> for this topic (outside of Camel with the Amazon management web console). If
> the user subscribe to an AWS SQS queue, he can use the AWS SQS component and
> poll this queue (already available since Camel 2.6.0).
>
> Another guy would like to make this subscription via Camel, which has in my
> opinion the following disadvantages:
> - The Camel SNS consumer acts like the Camel SQS consumer. It polls an AWS
> SQS queue. Therefore we have some code duplications and two different
> components which do the same thing.
> - It's only planned to make a subscription to an AWS SQS queue. If the user
> would like to make a subscription to HTTP, HTTPS, E-Mail or so, he has to do
> it still manually.
> - The subscription functionality will be the biggest part of this component:
> at startup:
> 1) Create the AWS SQS queue (mandatory web service call)
> 2) Query the queue ARN (mandatory web service call)
> 3) Provide the policy to allow the AWS SNS topic to write into the AWS
> SQS queue (mandatory web service call) --> For this, the user has to provide
> its own policy file in JSON format
> 4) Make the subscription from the AWS SNS topic to the AWS SQS queue
> (mandatory web service call)
> at shutdown:
> 5) remove the subscription (web service call if required)
> 6) remove the AWS SQS queue (web service call if required)
> - I have some bad feelings therefore (which I cannot express good) and I
> would like to provide a cleaner, easier to use and to maintain component.
> Also with the absence of functionality which may be only a few people use
> and a good alternative exists (Amazon management web console to make the
> subscription)
>
> What are your thoughts? Could you please comment this issue?
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-3476
>
> Cheers,
> Christian
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang