[
https://issues.apache.org/jira/browse/CAMEL-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010292#comment-13010292
]
Christian Müller commented on CAMEL-3476:
-----------------------------------------
It looks like I was too impatient... ;-)
To clarify the naming:
- SQS producer: A class which extends the DefaultProducer to implement the
event driven consumer enterprise integration pattern. Used to consume message
exchanges and send it to the Amazon SQS service (SendMessageRequest).
- SQS consumer: A class which extends the ScheduledPollConsumer to poll
messages from an Amazon SQS service (ReceiveMessageRequest) and create message
exchanges from this.
- SNS producer: A class which extends the DefaultProducer to implement the
event driven consumer enterprise integration pattern. Used to consume message
exchanges and send it to the Amazon SNS service (PublishRequest).
- SNS consumer (not exists yet): A class which extends the DefaultConsumer (or
ScheduledPollConsumer) to receive (or poll) messages from an Amazon SQS service
and create message exchanges from this.
Because the AmazonSNSClient doesn't offer a readXXX(), receiveXXX(), ... method
to receive messages, I think a SNS consumer make no sense. Creating a
subscription to an Amazon SNS service/topic has nothing to do with with
consuming messages from this endpoint and so it's not a SNS consumer.
The subscription can be made to an Amazon SQS queue, to an HTTP(S) endpoint or
to an e-Mail. For *all* this protocols/endpoints, Camel already offer consumers.
The only thing Camel at present do not support is the subscription to an Amazon
SNS service/topic. If we really want/need this, I think the SNS producer should
support this. He can do this in the doStart() method and not each time a
message exchange receive (creating the SNS topic, creating the SQS queue,
making the subscription). And in your second route you use the SQS consumer to
consume the messages.
As you say, the timer and quartz component offer *similar* functionality. But
if the SNS consumer consumes messages from an Amazob SQS queue, the SNS
consumer and SQS consumer offer the *same* functionality. This makes no sense.
I don't understand your last paragraph. I think you cannot "hide" or abstract
the subscription. The user which receives the messages, send to an Amazon SNS
service/topic has to know, where the messages are forwarded to.
And I think the subscription is not so easy as you think. In my opinion, the
value of this Amazon SNS service is to broadcast one message to multiple
recipients (and not to work around a firewall issue). How would you
handle/implement multiple subscriptions? Some subscriptions like e-Mail
requires an acknowledgement (a response mail of the subscription mail) before a
message is forwarded. If this component cannot handle these, I think most (if
not all) of the subscriptions must be made by hand.
Christian
> Contribute camel-sns component to the new camel-aws component.
> --------------------------------------------------------------
>
> Key: CAMEL-3476
> URL: https://issues.apache.org/jira/browse/CAMEL-3476
> Project: Camel
> Issue Type: New Feature
> Components: camel-aws
> Affects Versions: 2.6.0
> Reporter: Mark Ford
> Assignee: Christian Müller
> Priority: Minor
> Fix For: 2.8.0
>
> Attachments: camel-aws-3476.txt, patchfile.txt, patchfile.txt
>
>
> CAMEL-3468 contributes a new component for interacting with the Amazon SQS
> service. The camel-sns component allows users to publish/subscribe to topics
> on Amazon's Simple Notification Service.
> This code is currently hosted as a google code project here:
> http://code.google.com/p/camel-sns/
> I'll coordinate with Tracy (developer of camel-aws) in the creation of the
> patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
