Graham,
I think that the distinction between synchronous and asynchronous calls
is elementary and must not be abstracted away... as mapping WS calls to
JMS does. We do need a spec for sync calls (EJB) and a spec for async
calls (JMS).
EJBs did a giant leap between 2.1 and 3.0... and I'd like to repeat
exactly the same leap for JMS. Only that it's even more necessary here,
because JMS requires even more boiler plate than EJB 2.1 had.
Rüdiger
On 08/02/2011 10:50 AM, Graham Wallis wrote:
> Ruediger,
>
> I'm concerned that whilst there are obvious merits in abstracting away all
> of the messaging detail behind a business interface, such as insertCustomer
> (), deleteCustomer(); to my mind this is what web services and SCA
> interfaces achieve. From a WS or SCA interface you can specify the
> transport (e.g. JMS) and use an appropriate binding, which maps from the
> "clean" business interface onto the specific transport. The "clutter" is
> all hidden from the business user, and there is flexibility to choose a
> transport that suits the (non-functional) requirements for reliability,
> asynchronous delivery, etc.
>
> So whilst I don't disagree with any of this thread I'm struggling to see
> that it is sufficiently close to JMS to form part of the specification - I
> think it belongs in other standards.
>
> Am I being too traditionalist or are the other standards missing something
> that we *should* provide through JMS?
>
> Graham
>
> Ruediger zu Dohna<ruediger.dohna_at_1und1.de> wrote on 01/08/2011 16:49:18:
>
>> From: Ruediger zu Dohna<ruediger.dohna_at_1und1.de>
>> To: jsr343-experts_at_jms-spec.java.net
>> Date: 01/08/2011 16:49
>> Subject: [jsr343-experts] Re: [jms-spec users] Re: (JMS_SPEC-33)
>> Improving the JMS API with API simplifications, annotations and CDI
>>
>> 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
>
>
>