Johan Eltes wrote:
>
> I do not see any problems with 1)
>
> I think it is appropriate to use JMS in a request/reply scenario with a
> session bean as a client, given that you call receive on your
> TopicSubscriber with a time-out value that is in the spirit of synchronous
> OLTP requests.
>
> Ian, what difference does it make, to invoke a jdbc call blocking for 10ms,
> compared to invoke a JMS receive call blocking for 10 ms? One could even
> argue that JMS gives you a portable way of controlling request time-out,
> whereas jdbc doesn't.
No difference, you are quite right.
But in my experience, legacy integration applications typically need to be
tolerant in waiting for a reply. Although the typical response time may be
sub-second, the timeout may need to be 10 seconds or more to catch 99% of the
answers, and if the legacy system is updating databases it is sometimes just not
acceptable to have an arbitrary hard-coded timeout. The only sensible thing to
do is wait as long as possible for the answer to come back.
Messaging is capable of being timing-tolerant. This is why messaging is the
solution people look to for enterprise integration, supply-chain integration,
EDI, etc.
It's a shame that EJBs aren't timing-tolerant today because EJBs are in effect
locked out of those rapidly expanding areas.
========================================
Ian McCallion
Alexis Systems Limited
Romsey, UK
Tel: +44 1794 514883
Fax: +44 1794 501692
========================================
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
