add RSS feed endpoint for querying AQ message views

[adamkorynta]

Alternate considerations:

• Looked into using a third-party RSS library for building up the XML. Seemed like the only somewhat maintained library is Rome, but that hasn't been updated since 2023 and contains the jdom2 dependency which has a known vulnerability (wouldn't really matter to our use-case of producing XML only, but would matter on the client). didn't seem too much a lift to just use our own DTO's and jackson serialization. If this ends up being a burden, it also wouldn't be too hard to update to something else in the future.
• opted to not set the atom links for self or previous as those would be moving targets given the week lookback limit. We do need a next cursor so the fact that the URL would not be reproducible after a time period is unavoidable. We could also throw out the cursor and only use the since field.
• don't search for messages older than a week. This could be shortened as needed.

[MikeNeilson]

Overall I like it. I do want to make sure that if at all practical we're exposing more standard "queue/topic" semantics.

While this will always be read only, WM staff and core developers will be interacting with the same sources of data and we should make sure things map, preferably into the future and not the past.

Will very likely be making good use of SNS and SQS for queues and topics (of which this is technically the later regardless of Oracle naming).

I'm also currently inclined towards a "queue/topic per concept" vs per-office per-concept. The latter may be an impratical amount of things to deal with when the applications can easily choose to filter and let whatever broker deal.

[MikeNeilson]

interesting trick, taking advantage of the queue persistence.

[adamkorynta]

yeah makes it so that we don't have to pull in all the aqapi and jms dependencies and keeps us from being stateful

[MikeNeilson]

Would it make more sense for SWT to be not shown here and this show up and "TS_STORED"?

I think there is a use case for "everything" and long term these wont be from AQJMS queues anyways and it would be one global queue/topic where we filter by parameter.

Then again it is under "channel". Can RSS present more than one "channel" at a time?

[adamkorynta]

Unfortunately, RSS doesn't allow for multiple channels. I was originally thinking we could do a channel per office. If we want to join AQ$SWT_STATUS, AQ$SWT_TS_STORED, and AQ$SWT_REALTIME_OPS into a single channel we could utilize the elements on the items itself to distinguish types. I didn't go that route because there's no description field on categories, where channels have both title and description.

Even with topics externalized, you'd do a single global? I'd think we would still want to separate by at least office and setup authorization per topic, rather than implementing authorization per message.

[MikeNeilson]

For sqs/sns the authorization is different, there isn't going to be user level authorization on the queues as we don't have a practical way to expose them with the correct semantics... well, not without unneccassary difficulty. If an user or application needs to allow a message to put entered into the queue the backend service would have the authorization, and the front end... say CDA, would take care of any authorization details.

at a minimum though a hierarchy, at least visually of say "concept/office" may be appropriate, i know for mqtt you get "and everything underneath", need to look at sqs and rabbitmq/activemq to get a better sense.