Hi Amol
If you have the MessageHandler handler implementation already in place, then the framework has nothing left in it. That is the reason why i feel providing a generic interface makes sense.
Here, I think, is where the discrepancy lies. It seems like you want to provide a framework for implementing Amazon SQS messages. But we don't want a framework. We've already chosen a framework with the appropriate abstractions: Spring Integration itself satisfies all of the abstractions and common interfaces. What we need are simple adapters to make SQS, SNS and SES available channels to send/receive messages using existing AWS APIs. Additionally, we need common logic to be shared between all channels, such as type transformations, filtering, etc. By adding another abstraction layer beneath Spring Integration for SQS message transformations, you're making it necessary to implement that transformation for every adapter we want to include.
If you choose to provide your own implementation of AmazonSQSOperations, you might not even need to have a transformer as that implementation might be doing the conversion by itself
Again, going this route, our Amazon SNS implementation would then have to implement the same conversion logic.
Your application's other components do not depend on this interface. If you already have an implementation of the class that does these SQS operations for you, you just need to be implementing this interface and delegate calls to your implementation. You would then need to just define this in your config and pass the adapter a reference to it.
Again, this is the exact same work that would be required to implement the MessageHandler and MessageSource interfaces. The difference being that the MessageHander and MessageSource interfaces are common interfaces in the Spring Integration framework, therefore plug in directly, giving us more flexibility and making the components cooperative with other components in the framework.
Here is the configuration we would like to have in place.
Code:
<!-- inbound -->
<aws-sqs:inbound-channel-adapter
sqsClient="myClientImpl"
channel="inboundChannel"
sqs-queue="https://queue.amazonaws.com/myworkqueue"
transactional="false"
max-redelivery-attempts="3">
<int:json-to-object-transformer type="com.foo.MyDataClass" object-mapper="objectMapper"/>
<int:transformer expression="payload.dataField" />
<int:filter ref="myMessageFilterBean" discard-channel="notReadyChannel" />
<int:service-activator ref="dataProcessor" method="processData" />
</aws-sqs:inbound-channel-adapter>
<!-- outbound -->
<int:chain output-channel="myCustomerOutput" id="customerOutputChannel">
<int:transformer ref="myCustomersCustomDataTransformer" />
<aws-sqs:outbound-channel-adapter
sqsClient="myClientImpl"
channel="inboundChannel"
sqs-queue="https://queue.amazonaws.com/myCustomersQueue" />
</int:chain>
Here we have the SQS messaging set up as two message chains, including filters and transformers. Note that the input channel uses a different transformer from the output channel. The difference is that we produce the input messages being consumed here, therefore always use the same message format. Our customers, however, have different serialization formats- some use JSON, but other use a binary serialization format. The goal is to make it easy to route the right messages to the right customer queue using the right transformer. As mentioned, some messages will go out via SQS, but others will use SNS or SES. Message transformers are common among several output channels, so it does not make sense to implement the conversion in the SQS Operations impl, then implement it again in SNS Operations Impl. Additionally, any new message solutions that might be added in the future (e.g., AMQP, etc.) should also be able to utilize the existing tools.
Hope this helps to clarify the issues for you.
Mike
)
Reply With Quote
