To reiterate what I said during the meeting, I feel confident Microsoft will officially invest into an effort to modernize Messaging via a Lite Profile (while also moving forward more minor, non provider related enhancements in the older full profile) as well as AMQP interoperability.
I hope we achieve broad consensus to move forward one or both these items.
From a purely personal standpoint, I would like to see MDB replaced by a modern CDI based equivalent. The MDB/EJB programming model is a very damaged brand, inflexible and now quite out of date. It doesn’t help moving the Jakarta brand forward. Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. On Jun 21, 2021, at 7:09 PM, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
Hi all,
16th June 2021
Attendees
- Ivar Grimstad (Eclipse Foundation)
- Ed Bratt (Oracle)
- David Blevins (Tomitribe)
- Jonathan Gallimore (Tomitribe)
- Emmanuel Hugonnet (Red Hat).
- Daniel Kec (Oracle)
- Tanja Obradovic (Eclipse Foundation)
- Luke Saker (IBM)
- Reza Rahman
- Clebert Suconic (Red Hat)
- Ondro Mihalyi (Payara)
Minutes
- (Ondro) EE Messaging 3.1 plan as was approved recently didn’t have
high goals, maybe we can add new features, but we aim here to discuss
longer plans for EE Messaging
- (Clebert) JMS is more than 20 years long and has a lot of legacy,
which isn’t needed anymore and there’s a lot of usecases where it’s
complicated or not possible to use it in the current state
- (Reza) Presented a document that triages existing issues into categories and priorities
- (Ondro) An idea: old API should be separated or maybe even create a new messaging spec side by side with the old spec
- (David) it makes sense to separate the old API and and make it
optional, maybe even create a “lite” profile with only the new API
- (David and Clebert) The new API should be simple and allow that semantics are up to the implementation
- (Ondro) We should revisit MicroProfile Messaging because they tried to achieve a similar goal
- (David) it seems we have a consensus
- (Reza) If there’s a consensus, MS (Azure Service Bus team) is interested to join and collaborate
- (Ivar) To confirm a consensus, there should be a vote
- (David) if we leave semantics to the implementations then it’s
possible to find a good trade-off between speed and reliability by
choosing an appropriate implementation
- (David) We should create a new issue to cover the “lite” profile
or reuse existing related issues - optional/relaxed delivery semantics
and guarantees, etc.
- Some existing related issues
- (David) Let’s have an issue for each specific guarantee to relax them or make them optional
- (David) Presented a proposed structure for the messaging-propsals repository, with a structure in the README file for each proposal, for example README for JSON-B proposal
|
