2

Goal: understand options for processing a JMS feed using AWS serverless principles when the JMS feed originates outside of AWS.

All of the JMS subscribe examples I've seen on AWS assume the JMS producers are writing to SQS or AmazonMQ. The JMS subscribers can simply use the AWS SDK to manage the subscription, especially when using a Lambda function with finite compute time to batch process messages off an unbounded stream. I haven't seen a reference architecture for using AWS serverless to subscribe to a JMS feed that originates outside of AWS.

Is Lambda even an option here? Is Kinesis analytics (a.k.a Apache Flink) the better option? A Java JMS consumer running under Docker on EKS? Apache Camel running on EKS?

I would suspect the correct serverless answer here is for the initial AWS side subscribers to subscribe to the non-AWS JMS source, and simply replicate the messages onto SQS, AmazonMQ or Kinesis, where the normal AWS serveless architecture patterns for message processing can take over.

mark.lewis688
  • 41
  • 2
  • 1
    This question is too broad. There are lots of potential solutions to this problem (some of which you've asked about specifically) each with their own pros and cons. Which one is right for you will depend on your use-case. Try implementing one of the potential solutions and if you run into trouble then you can ask a question about whatever specific problem you have. – Justin Bertram Jun 17 '20 at 17:16
  • 1
    Specifically: Are there any reference AWS serverless architectures for subscribing to a JMS service not native to AWS? Something that captures all the AWS discipline of being serverless? If not then I shall invent, rather than re-invent the wheel. – mark.lewis688 Jun 18 '20 at 12:29

0 Answers0