[esb-issues] [JBoss JIRA] Commented: (JBESB-802) ServiceInvoker should hide EPRs
[ http://jira.jboss.com/jira/browse/JBESB-802?page=comments#action_12371649 ]
Burr Sutter commented on JBESB-802:
-----------------------------------
Here is what I am using for the SI (for the purposes of discussion):
ServiceInvoker invoker = new ServiceInvoker("ActionServices",
"CustomActionService");
Message requestMessage;
Message replyMessage = null;
requestMessage = MessageFactory.getInstance().getMessage(MessageType.JBOSS_XML);
requestMessage.getBody().setByteArray(msgText.getBytes());
invoker.deliverAsync(requestMessage); // no waiting for a response
// now delivery it and wait for a response
replyMessage = invoker.deliverSync(requestMessage, 20000);
----------
a) Is it also possible to have:
ServiceInvoker.sendAsync("MyCategory", "MyService", "My String
Message");
Message replyMessage = ServiceInvoker.sendSync("MyCategory",
"MyService", "My String Message");
For that one time delivery where I don't intend to hold on to the ServiceInvoker
instance.
b) I do like having access to the whole Message by default (request & response)
because I (the user) might have stuck some content in the attachments, header, properties
etc.
c) I like having the default replyTo and faultTo being "me" but if I'm a
true client (e.g. J2SE main method in this case) then I'm technically not an EPR. I
would want faults to be exceptions and replies to show up as indicated above.
d) Already discussed, the use of setByteArray() should be the "default" a new
user encounters when they normally wish to work with strings & XML to get started
e) I am assuming that if I add a Hashmap via
myMessage.getBody().add("MyData",myHashmap); then it is available in my Action
on the ESB side of things.
f) I would have used "createMessage" instead of "getMessage" in the
following line.
requestMessage = MessageFactory.getInstance().getMessage(MessageType.JBOSS_XML);
The "getMessage" makes it appear as if I'm fetching these from a pool, which
might be the intent.
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