Skip to content

Additional JMS message types for forecasts, ratings, and location levels - #1883

Open
perrymanmd wants to merge 19 commits into
USACE:developfrom
perrymanmd:develop
Open

Additional JMS message types for forecasts, ratings, and location levels#1883
perrymanmd wants to merge 19 commits into
USACE:developfrom
perrymanmd:develop

Conversation

@perrymanmd

Copy link
Copy Markdown
Contributor

Summary

Additional JMS message types for forecasts, ratings, and location levels. Approval is required before addressing more object type

Related Issue

AQJMS Message for additional data types

Validation

Documentation only

Checklist

  • AI tools used

@MikeNeilson MikeNeilson left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually looks fine. For these let's leave out low level implementation details, like which Java package would be use. Message/Event systems are rather generic as a concept.

Additionally, some examples should be provided. The one implementation detail -> in JSON. Unless it just gets awkward and then XML. However, we should be fine with JSON.

Summary
=======

CWMS needs a JMS Pulish/Subscribe message structure to notify clients of forecast-related events.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
CWMS needs a JMS Pulish/Subscribe message structure to notify clients of forecast-related events.
CWMS needs a Message structure to notify clients of forecast-related events.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or "Events" like above.

Opinion 1
---------

Summary: Use the ``jakarta.jms.MapMessage`` structure described below for forecast-related events.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Summary: Use the ``jakarta.jms.MapMessage`` structure described below for forecast-related events.
Summary: Use the message structure described below for forecast-related events.


Summary: Use the ``jakarta.jms.MapMessage`` structure described below for forecast-related events.

All messages will be published to the ``XXX_REALTIME_OPS`` topic, where ``XXX`` represents the appropriate office identifier.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
All messages will be published to the ``XXX_REALTIME_OPS`` topic, where ``XXX`` represents the appropriate office identifier.
All messages will be published to the appropriate ``REALTIME_OPS`` topic. Subscribers can setup appropriate filtering to receive desired messages.

@@ -0,0 +1,167 @@
=======================================
JMS Pub/Sub Message Formats - Forecasts

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
JMS Pub/Sub Message Formats - Forecasts
Data Event Formats - Forecasts

@perrymanmd

Copy link
Copy Markdown
Contributor Author

Conceptually looks fine. For these let's leave out low level implementation details, like which Java package would be use. Message/Event systems are rather generic as a concept.

Additionally, some examples should be provided. The one implementation detail -> in JSON. Unless it just gets awkward and then XML. However, we should be fine with JSON.

Do you want the the "Value Type" columns in the tables to specify JSON types instead of Java types or leave them as they are?

@MikeNeilson

Copy link
Copy Markdown
Contributor

Conceptually looks fine. For these let's leave out low level implementation details, like which Java package would be use. Message/Event systems are rather generic as a concept.
Additionally, some examples should be provided. The one implementation detail -> in JSON. Unless it just gets awkward and then XML. However, we should be fine with JSON.

Do you want the the "Value Type" columns in the tables to specify JSON types instead of Java types or leave them as they are?

I think as they are is fine, they're fairly generic.

@perrymanmd
perrymanmd requested a review from MikeNeilson August 20, 2026 23:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants