Nigel,
On 08/01/2011 04:00 PM, Nigel Deakin wrote:
>> *This* is what the business code programmer wants to see... nothing
>> more.
>> ...
>> Convention-over-configuration.
>
> I think you do raise an interesting and profound question about what JMS
> is for.
>
> As I think I've remarked before, the approach you advocate seems to be
> to hide the actual message-sending and message-receiving behind a layer
> which makes it appear to the application (business layer) as an async
> invocation of a remote (or local) business method.
Rephrasing that just a little: EJB 3 advocates "to hide the actual
[handling of transactions, security, and other aspects of a remote
method invocation] behind a layer which makes it appear to the
application (business layer) as a [simple] invocation of a remote (or
local) business method."... I think it's a good thing to, on the one
hand, hide non-functional aspects by default and add them only on
demand; and, on the other hand, be very precise about the functional
business contract directly within the language, not in WSDL or even Word
documents.
> In addition to
> "hiding" the message, would your approach also "hide" the destination?
It would by default. The current MessageApi trunk simply assumes the FQN
of the message interface as a convention.
> I have no doubt that many applications do indeed view their JMS usage as
> being a way of achieving the async execution of some local or remote
> method. However I suspect that there are many other applications where
> the message itself (or rather its payload) maps on to real business
> entities such as orders, trades and the like, and the concept of a
> message flowing through a system is a useful analog to an order flowing
> through an organisation, and there is no benefit in hiding it behind a
> RPC API.
I don't see a conflicting view here. If I send an order, I'll send an
order. But I prefer the order to be an instance of a class, and not more
or less a Map<String, String>!
> Having said that, what you describe is clearly a major use case for JMS,
> and we could consider the standardising of a RPC-style abstraction on
> top of JMS if EG members thought it would be of benefit (it could even
> be a different spec). Though I think our first priority should be to
> provide an improved API for applications which are perfectly happy to
> see JMS as a way of passing messages (or, perhaps, message payloads)
> around. Obviously I'd like to hear other views on this.
I'd also very much like to hear other views... I've been discussing this
with my colleagues for more than a year by now. The main problem I've
experienced was that of a major shift in how people think about JMS.
> Going back to the idea of JMS as a way of perfoming a remote method
> call, I see an overlap between this and the existing EJB 3.1 feature of
> asynchronous method invocation, at least for the point-to-point case.
> How does this compare with what you have in mind? After all, async
> requests to a session bean would need to be queued in the server. I
> suppose one difference is that JMS offers a defined quality of service
> (e.g. queued requests may be persisted to ensure that they are not be
> lost in the event of server failure) whereas async EJB does not.
Isn't the main point of doing async calls to decouple a client from the
availability of a service? When you do a remote async EJB call while the
server is not available, you'll synchronously get an RemoteException...
and you'll have to repeat the call. If transporting the call to the
server times out, you may not know for sure, if the server received it
or not. If the client fails before the server is done with a call that
returns a Future object, who will handle it?
I think that async EJBs have a very specialized, still very synchronous
purpose, while JMS is applicable to a much broader range of use cases
and supporting Enterprise Integration Patterns.
Rüdiger