JMS Bindings
rcarrascosps opened this issue · 6 comments
Reason/Context
Please try answering few of those questions
-
Why we need this improvement?
JMS is very well known in the industry, there are a lot of implementations of it (IBM, Oracle, JBOSS, etc). And it is still used and very reliable for mission critical systems -
How will this change help?
It will allow us to represent the details needed to describe more technical features of messaging with JMS. -
What is the motivation?
We know JMS. We have implemented JMS in several projects. We know the protocol and in the other hand, the JMS protocol is very well known and used in the market. Systems are and will be still created with JMS as their messaging protocol for event driven architectures.
Description
Please try answering few of those questions
- What changes have to be introduced?
We will provide a new page for the JMS bindings. - Will this be a breaking change?
No. - How could it be implemented/designed?
We will pretty much do a similar thing to what we have in the other bindings
JMS binding placeholder is there so feel free to elaborate more on what changes you want to introduce
Hi.
Thank u.
Yes I see that there is little progress on this one:
https://github.com/asyncapi/bindings/tree/master/jms
My intention is to make progress on that protocol and describe it. I can take care about the channel binding, object and operation binding by myself.
Thank u
best regards
Yes https://github.com/asyncapi/bindings/tree/master/jms is a placeholder open for suggestions. Maybe just start with some Draft PR where you share how channel and operation bindings could look like. Once you are happy with how it looks on your side let me know and I can ask wider community to jump into review and share opinion.
We just got a hackathon submission from IBM folks with code generator for JMS so I bet they could also jump into the review of what you are proposing
This issue has been automatically marked as stale because it has not had recent activity
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience
This issue has been automatically marked as stale because it has not had recent activity
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience
This issue has been automatically marked as stale because it has not had recent activity
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience