Of course, "extended JMS" is also a proprietary API (unless you push the extensions through Java Community Process), but perhaps we can reduce the percent of code that uses proprietary extensions.
When originally doing this I had hoped the following would occur: 1) our extended JMS is in some way supported by the AMQP working group, perhaps as part of the AMQP->JMS mapping specification (which does not of course exist yet) 2) AMQP becomes a successful protocol 3) JMS 2.0 or 3.0 includes our extensions Obviously (3) entirely depends on AMQP making it into existing popular messaging middleware products. RG
