[ http://jira.jboss.com/jira/browse/JBESB-802?page=comments#action_12371621 ] Tom Fennelly commented on JBESB-802: ------------------------------------ Can you explain what you're thinking in a little more detail, using code examples. The ServieInvoker doesn't expose anything physical to the calling code. That was the whole point of it. To hide the EPR + Courier "stuff". The Message object is a different kettle of fish ;-) -- 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

[ http://jira.jboss.com/jira/browse/JBESB-802?page=comments#action_12371632 ] Mark Little commented on JBESB-802: ----------------------------------- The ServiceInvoker exposes service names and categories yet still allows Messages to be defined in their entirety. That's fine because that's pretty much what Invoker did. However, they are two different abstractions at two different levels in the call hierarchy: service names are a higher level abstraction whereas Messages are lower level. Messages were not intended to be used directly by the majority of developers. Think of them like Web Services Envelopes: you don't manipulate the header information yourself (much); you tend to work on the payload, and even then it's abstracted away by nice tools like WSDL2Java and the underlying SOAP stack. When you say that "ServieInvoker doesn't expose anything physical to the calling code" it does: it's exposing Messages and therefore exposing the header (Call instance). If you look at the pre-Rosetta stuff, you'll see that the (rough) equivalent of SI (ClientPlugin) worked in terms of Body only, so in SI terms, I'd have thought: sendSync(Body b) sendAsync(Body b) would have been more of a logical abstraction. Actually, probably (and in C++ pseudo-code): sendSync(Body b, String replyTo servicename1 = null, String faultTo servicename2 = null); sendAsync(Body b, String replyTo servicename1 = null, String faultTo servicename2 = null); Maybe we're still not connecting on the use of ServiceInvoker, because when you told me last week "it's one instance per service per client" the abstraction I just outlined is more what I expected. What's there breaks your own rule because by allowing Message to be passed in, someone can define their own Call instance that has nothing whatsoever to do with the servicename used to create the SI instance initially and attach it to the Message. Then we have "one instance per many services per client". -- 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

[ 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. -- 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