[
http://jira.jboss.com/jira/browse/JBESB-802?page=comments#action_12371630 ]
Tom Fennelly commented on JBESB-802:
------------------------------------
I might add... I think you're hitting on something that's dear to my heart ;-) ...
i.e. the idea that using the physical EPR on the Message (for replyTo etc) is a broken
concept (in spite of that WS-A may or may not say). It's anything but loose
coupling!
If I set an EPR for the replyTo, how can I be sure that that EPR will work for the
"other guy". If I set a cat:name, the "other guy" can use that to get
all the EPRs for that service and select the one that works best for him. High
availability etc.
ServiceInvoker should hide EPRs
-------------------------------
Key: JBESB-802
URL:
http://jira.jboss.com/jira/browse/JBESB-802
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.2 Milestone Release 3
Reporter: Mark Little
Assigned To: Mark Little
Fix For: 5.0 Milestone Release 1
EPRs were never intended to be used by the majority of developers. They are the
"physical" address of individual services. The "logical" name is the
service name, that might map down to one or more EPRs. But most of the time developers
would be using the logical name. At least that was the approach in the original
pre-Rosetta days. By the time you get down to working with EPRs and headers (Call)
you're really working at the lowest level and talking about a specific Message going
to a specific service instance.
The higher level abstraction should be working only in terms of the message payload
(Body, Attachments, etc.) and service names. FaultTo, To, ReplyTo etc. would be abstracted
to service names by the API. The implementation would hide the mapping of service name to
specific EPRs when necessary to ultimately deliver a message.
Shouldn't ServiceInvoker work in the same way? On the one hand it seems to be one SI
instance per client per service (you create the instance and pass in the servicename
[equivalent of defining To]). However, because the deliverSync and deliverAsync work in
terms of Messages, it's then entirely possible for that information to be ignored by
the user, i.e., you can use any SI instance to deliver a message to any service as long as
you define the To field correctly.
--
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