Standardize Abstractions for Common Message Processing Patterns

I came across a very interesting idea while discussing the declarative message listener feature
([https://java.net/jira/browse/JMS_SPEC-134](https://java.net/jira/browse/JMS_SPEC-134)) at NFJS that I think is worth sharing.

We can actually think of standardizing some common JMS message processing patterns declaratively via
the feature. We have actually sort of already discussed this above but it can be flushed out/extended far
more. It's best to explain this via examples.

Batch processing messages is something we've already discussed:

```
@ApplicationScoped @Lock(WRITE)
public class MyListenerComponent {

@JmsListener(destinationLookup="...", batchSize="...", retry="...", retryDelay="...", ...)
// Batch delivery, retry, retry delay, etc new features.
public void listen (Message... messages) {
...
}

}
```

On top of this we can think of ordering the batched messages by priority, timestamp, etc:

```
@ApplicationScoped @Lock(WRITE)
public class MyListenerComponent {

@JmsListener(destinationLookup="...", batchSize="...", orderBy=TIMESTAMP)
// Messasages automatically ordered. Options could be priority, timestamp and delivery time.
public void listen (Message... messages) {
...
}

}
```

It could also be possible to use application defined "Dead Letter Queues" where messages are forwarded
once a delivery/retry count is exceeded:

```
@ApplicationScoped @MaxConcurrency(10)
public class MyListenerComponent {

@JmsListener(destinationLookup="...", retry="...", dlqLookup="...")
// After a certain number of retries, automatically forward to the specified DLQ.
public void listen (String message) {
...
}

}
```

Another interesting case is provinding a simple abstraction for the request/reply pattern:

```
@ApplicationScoped @MaxConcurrency(10)
public class MyListenerComponent {

@JmsListener(destinationLookup="...")
// Send the return response to the reply-to queue, populating a correlation ID
// from the incoming message.
// Could potentially have a collection of responses, although that's probbaly rare.
public String listen (String request) {
String response = ... // Some default value.
...
// Process the request and set the corresponding response.
...
return response;
}

}
```

I am sure there are other patterns I am missing that the community or the expert group could
fill in.

Please note that these are my opinions only and not necessarily those of Oracle as a company.

Start by reviewing the JMS_SPEC-134 discussion and the message-listener examples in this issue. Determine which processing patterns should be standardized and what declarative API would cover batching, ordering, retries, dead-letter forwarding, and request/reply; done requires agreement on the scope and design.

Written by the indexing model from the issue text.