[
http://jira.jboss.com/jira/browse/JBESB-575?page=comments#action_12363048 ]
Mark Little commented on JBESB-575:
-----------------------------------
We've always talks about logical names (service names) and physical names (EPRs). Both
should be available to the developer and we shouldn't discourage one in favour of
another. The advantage of the former is transparency. The disadvantages of the former is
transparency ;-) and the reliance on the registry. EPRs can be conveyed in a number of
ways, even within messages or via email, written down, etc. So while I agree we should
only have one way of doing the transparent approach, I disagree that using EPRs directly
is bad.
Standardize on a message delivery mechanism...
----------------------------------------------
Key: JBESB-575
URL:
http://jira.jboss.com/jira/browse/JBESB-575
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 4.2 Milestone Release 2
Reporter: Tom Fennelly
Assigned To: Mark Little
Fix For: 4.2
A few "(anti-)patterns" have developed re ESB-Aware message delivery to an
endpoint:
1. Raw code that deals right down to the level of EPRs and Couiers (Yeuukieee...). The
code is littered with this stuff :-(
2. Classes like the ServiceInvoker
(
http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/listeners/...)
and MessageDeliveryAdapter
(
http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/listeners/...).
Both of these classes essentially do the same thing. They're created against a
Service Cat:Name combo and they take care of looking up EPRs and Couriers etc.
Basically, I think we should settle on using one of classes listed in #2, and (where the
opportunity arises) remove that ugly code described in #1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira