Nigel,
Sorry for the delay - just came back from a trip. Responses below:
* Any changes need to be backwards compatible: applications which are
written to JMS 1.1 will continue to work.
- Generally, yes. But it can certainly make sense to deprecate (but not
remove) some pre-JMS 1.1 stuff like the JMS 1.0 Queue and Topic specific
interfaces.
* We need to make sure that we don't lose sight of the need to be able
to use JMS outside of a Java EE environment: Java EE must not be a
requirement.
- Maybe. I am fine with the Status Quo in that it is undefined how some
things work outside of Java EE (such as Destination/Factory
setup/look-up/Connection Pooling). In practice, non-Java EE users can
simply use vendor-specific extensions/tools just as they do today
without much issues since this is a group of users that in my experience
do not regard standardization/vendor-neutrality as being that important
for them anyway. I definitely think it is a bad idea to start designing
seriously watered down APIs/over-complicate matters just to support
impoverished non-Java EE run-times. In my mind, this does a very large
disfavor to folks that would rather use a solid quality standard Java EE
platform just to try to appease the wrong crowd (it's also probably a
futile effort). For example, things like JCA, connection pooling, XA
and declarative programing are well established concepts in Java EE
whereas it would take a lot of new standardization to make these things
happen in a consistent/vendor-neutral way in non-Java EE environments.
There are already plenty of precedents here in Java EE APIs like JSF,
CDI, JPA and Bean Validation where certain functionality only really
makes sense in a Java EE environment. I think any higher level message
send/receive API belongs in this category. From a pure Caucho
perspective, the difference between Java EE and Java SE environments is
largely academic since we have extensive embedded container support for
Java SE. It makes little sense for us to create yet another embedded
container for our JMS implementation instead of simply using our
existing embedded containers. I think any vendors still interested in
providing full JMS 2 functionality in Java SE should do that as
vendor-specific extensions.
* One of the reasons why JMS has been successful has been its small,
simple API. Let's not see this compromised just for the sake of change.
- Agree 150% percent. Let's kindly keep edge cases as vendor specific
extensions unless the use case is close to 80%. Over-standardization is
bad period. It's especially foolish to take a simple, successful API and
add a bunch of bloat to it to support edge cases.
* I'd like to understand better what it is that people feel are the
problem with MDBs.
- I think a majority people proposing this would agree that it is not
the issue that "something is wrong with MDB". I think making a rational
argument to that effect that stands up to any serious scrutiny is not
that easy. It certainly makes very little sense to introduce yet another
component model in JMS that looks exactly like MDB just to appease a
certain crowd. The real issue the way I see it is that with managed
beans and CDI, the MDB model is redundant and forces Java EE developers
to learn yet another component model. If you look at the mandate for
Java EE 7 and EJB 3.2, a primary goal is to get away from away from
one-off component models and consolidate things around managed beans and
CDI. EJB is also not alone in this. In due course, Servlets will also be
redefined to be annotated managed beans and the redundant JSF component
model is also due to be deprecated. Now, we can question whether any
re-factoring of MDB really belongs in the EJB specification. My opinion
is that EJB already has too many things that really does not rightfully
belong to EJB. In practice, MDBs are just high level declarative APIs
for receiving JMS messages. I think that functionality best belongs in
the JMS specification for this reason, just like a high level
declarative API to send messages.
* The API should make less use of checked exceptions.
- I am honestly shocked some others folks (especially independents) did
not mention this issue. I am going to guess that if we did a poll of
actual JMS API users (not the people that use JMS abstractions like
Spring JmsTemplate that wraps all the checked exceptions into unchecked
exceptions) this would turn out to be a top request. I've always found
it annoying to write mechanical try-catches that do nothing but write
out to a log on error...
* Standardize the "connection string" to define server IPs, timeouts,
etc, as in ActiveMQ.
- I actually think this is a good idea, but not quite from the
perspective of this particular proposal. What I'd like to see is the
equivalent of @DataSourceDefinition and <data-source> in Java EE
environments for JMS 2 resources. This would go a long way towards
making Java EE applications that use JMS far more vendor-neutral. In the
end, this might need to be standardized via the Java EE 7 EG but I think
we will need to do the initial legwork.
* We need to monitor the activities of the Java EE platform EG and
identify any changes to the JMS spec that are needed to support
cloud-related features in Java EE 7.
- Yes, I can certainly help do that and I'm sure so can Adam. The caveat
here is that I am a cloud skeptic myself (in that I think Java EE is
being too quick to adopt the cloud). Beyond my personal/Caucho opinions,
I'll make sure we are on the same page as the Java EE 7 EG as to cloud
requirements...
Cheers,
Reza
On 6/22/2011 10:37 AM, Nigel Deakin wrote:
> Thank you to everyone who has submitted a list of their priorities for
> JMS 2.0. If anyone else wants to add their own priority issues to the
> list, please do so (please only suggest issues that you consider a
> priority). If you're simply waiting to see what the others come up
> with, that's fine too.
>
> Here's a high-level summary of the topics raised so far. I've added
> the name(s) in brackets afterwards of the person(s) who raised each
> topic, to help you identify the topics you raised. Since I've
> re-phrased some topics in my own words, please let me know if you
> think I've mis-represented you. Also, please let me know if you think
> I've missed an issue you raised.
>
> I've added a few comments in [square brackets] where I think that a
> suggestion raises questions or issues, but in general I've tried not
> to act as judge of any of these suggestions at this stage. Everything
> is still on the table.
>
> So what's the next step? I think we need to get these issues (and I
> know more will keep arriving) divided into two groups:
>
> (SHORTLIST) a shortlist of issues which we will definitely discuss
> more over the next few weeks and
> (DEFER) those which we will defer until later. Unless there is a clear
> consensus that an issue can be dropped, we'll keep this on the list
> for later consideration.
>
> (I propose that issues already mentioned in the JSR proposal go
> directly into the shortlist, and are marked (SHORTLIST) below (so you
> can take it as read that we'll be drilling down into the details of
> those shortly)).
>
> So please let me know what you think of these various issues
> (including those marked as (SHORTLIST), but particularly those which
> are not). Feel free to use the +1 or -1 convention (or (SHORTLIST) and
> (DEFER)). If you would prefer we simply drop an issue, please say so.
> If you're name is already down as supporting an issue then there's no
> need to endorse it again.
>
> Note that I don't see this as a vote; I'm looking for consensus but
> will make a judgement based on the responses.
>
> Also feel free to ask for clarification of what a particular issue is
> about, or to state why you have expressed the view that you have.
>
> Finally, I haven't covered proposals made in JIRA here. But I haven't
> forgotten them and will make sure these are considered in due course.
>
> Nigel
>
>
>
> General, overriding issues which need to be kept in mind
> --------------------------------------------------------
>
> * Any changes need to be backwards compatible: applications which are
> written to JMS 1.1 will continue to work (Reza).
>
> * We need to make sure that we don't lose sight of the need to be able
> to use JMS outside of a Java EE environment: Java EE must not be a
> requirement. (Adrian/Shivajee)
>
> * One of the reasons why JMS has been successful has been its small,
> simple API. Let's not see this compromised just for the sake of change
> (Adrian/Shivajee).
>
> [My reaction is to accept all three of these as principles we should
> follow. Any objections?]
>
> Major new API features
> ----------------------
>
> * We should provide a modern, easier-to-use API, probably using
> annotations and CDI (Nigel, John, Reza, Julien, Clerbert, Masoud).
> There seemed to be a variety of ideas of how we might do this, and we
> will need to explore these in detail. Whilst I think we mostly see
> this as a feature for Java EE containers, there seems to be interest
> in offering features to those using a Java SE environment as well.
> (SHORTLIST)
>
> * There was a view from several of you that we should work to improve
> or replace MDBs as a way to asynchonously consume messages in a Java
> EE container. (Emran, Adam, Clebert, Julien). There was also a
> suggestion that we remove the restriction that prevents a application
> calling MessageConsumer.setMessageListener() within an EJB or web
> container (Clebert). This is all closely-related to the previous
> issue. [Given that MDBs are already defined using annotation, I'd like
> to understand better what it is that people feel are the problem with
> MDBs. I'm aware that the introduction of CDI observers in Java EE 6
> means that we have two alternative means of async notification: events
> and messages, and two alternative types of callback: observers and
> message-driven beans, which poses the question of whether they can be
> combined] And as with the previous issue, there was a suggestion that
> we would try to offer features to those using a Java SE environment as
> well. (SHORTLIST)
>
> Better integration with Java EE
> -------------------------------
>
> * We need to standardise the interface between a JMS provider and a
> Java EE application server, to allow portability of JMS providers
> between application servers. (Nigel, Adrian/Shivajee). The frontrunner
> here is to mandate the provision of a JCA resource adapter, though an
> alternative may be to extend and make mandatory the existing Chapter 8
> API. (SHORTLIST)
>
> * Decide on the future of the optional Chapter 8 API "JMS Application
> Server Facilities", which defines API for use by application servers,
> including ConnectionConsumer, XAConnection, XAResource
> (Adrian/Shivajee, Nigel). This is optional and has no compliance
> tests. Should we make it mandatory or simply drop it? If we make a JCA
> API mandatory is this still needed? Experience has shown that this
> chapter leaves some issues undefined and that improvements would be
> necessary if we decide not to drop it. (SHORTLIST)
>
> * Clarify how the JMS provider should interact with Transaction
> Managers. In particular, the responsibilities of the JMS Provider, the
> TM and the App Server during recovery need to be clearly defined.
> (Adrian/Shivajee) (SHORTLIST)
>
> * We need to clarify the relationship between the JMS and other Java
> EE specifications. This is mainly a documentation exercise, especially
> for those methods which are forbidden or modified in a EJB or Web
> container, but there are some ambuguities, especially when the
> transaction context is undefined. (Nigel). (SHORTLIST)
>
> Other API changes
> -----------------
>
> The following, more specific API issues were raised:
>
> - The API should make less use of unchecked exceptions (Reza). Reza
> point out that in many cases the application doesn't know what to do
> when a javax.jms.JMSException is thrown, so for methods to declare
> that they throw a checked exception is not always helpful. [We would
> need to maintain backwards compatibility (which Reza also states the
> need for), which would limit the scope to change things. Also, some
> providers do rely on throwing exceptions to notify the client that
> they need to retry an operation, perhaps the real issue is that this
> is non-standard. ]
>
> - Security (Emran). Emran mentioned this in passing. [This is a large
> topic, and one which JMS has hitherto said little. I've separately
> asked Emran to clarify what he has in mind. ]
>
> - Compression/decompression (Emran). I take it that this is a request
> for an API which would allow a client to define whether a message is
> compressed in transit. [JMS providers are currently free to decide for
> themselves whether to compress a message, and many do, so the question
> here is whether we need to allow clients to control this via the API
> rather than via provider configuration features. ]
>
> - Timed messages (ability to send a message which the provider will
> deliver at a configured time in the future) (Emran)
>
> - Sending/receiving messages in batches (Emran, Clebert).
>
> - API to asynchronously send a message, with the server invoking a
> callback to acknowledge receipt (Clebert)
>
> - Improve existing API method Connection.createSession(boolean
> transacted, int acknowledgeMode). Can we have a single argument?
> (Julien) Do we need a different API for use in a BMT/CMT transactional
> context? (Nigel)
>
> - Add support for message consumption from the same session by
> multiple threads. This implies the need to be able to acknowledge
> individual messages. (Adrian/Shivajee)
>
> - Make use of new language features such as Generics
> (Adrian/Shivajee). [I've separately asked Adrian/Shivajee to clarify
> what they have in mind.]
>
> - Deprecate JMS 1.0 Queue and Topic specific interfaces in favor of
> JMS 1.1 unified interfaces (Adrian/Shivajee). Adding the @Deprecated
> annotation is easy enough, but do we want to formally announce that we
> will remove them from a future, non-backwards-compatible, version of
> the spec?
>
> - Decouple the creation of a Message from a Session (Adrian/Shivajee).
> [I would comment: what alternative mechanism did you have in mind?]
>
> - Ability to send objects directly, without need to wrap in a
> javax.jms.Message (John)
>
> - We need to "scan all of the implementations" and look for features
> to standardise in the spec. (Masoud) [If you're offering to do this,
> please do.]
>
> - Standardise the "connection string" to define server IPs, timeouts,
> etc, as in ActiveMQ (Julien). Currently JMS doesn't define a
> connection string, and expects any connection config to be defined in
> the connection factory which is currently vendor-specific.
>
> Quality of service (QoS) features
> ---------------------------------
>
> - Extend the spec to define clustering and failover behaviour (Emran,
> Julien). [The existing spec deliberately leave this to vendors to
> define their own behaviour; perhaps what we should be focussing on is
> addressing areas where different clustering and failover behaviour
> hinders portability of applications between providers. For example,
> whether a failover causes a JMSException, or causes the transaction to
> be rolled back.]
>
> Support for Java SE environments
> -----------------------------
>
> - the API should not rely on JNDI for creating connection factories
> and destination objects (Julien, Clebert). [I think the issue here is
> not so much JNDI but the idea that the creation of connection
> factories and destination objects is provider-specific and
> non-portable and so should not be done directly by the application. We
> would need to consider whether by removing this principle (presumably
> for Java SE clients only) we would be reducing the portability of
> applications.]
>
> - the API should mandate pooling of JMS resources when used in a Java
> SE environment (Julien). [I suppose the issue here is the extend to
> which we are expecting a JMS client to itself be a kind of lightweight
> container providing services such as connection pooling that are
> already available in, say, the Java EE application client container.]
>
> - define the concept of a JMS "container" for use within a Java SE
> environment which would offer various services, including CDI (John)
>
> Supporting cloud-related features in Java EE 7
> ----------------------------------------------
>
> - We need to monitor the activities of the Java EE platform EG and
> identify any changes to the JMS spec that are needed to support
> cloud-related features in Java EE 7 (Nigel). Since two members of the
> JMS EG are also on the Java EE EG (Reza and Adam) I hope they can help
> with this. I'll also follow the Java EE EG and keep in contact with
> the spec leads. (SHORTLIST)
>
>
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3710 - Release Date: 06/17/11
>
>