Although we haven't yet make the rest of the code use the new EPR or Message changes, it's going into the trunk. As originally outlined in this entry http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77543 ... Endpoint references are encapsulated within the EPR class. All services (and clients) can be represented by an EPR, which is effectively an address. If using SOA principles then the ultimate recipient of the message should be addressed in a loosely-coupled manner: the service should multiplex/demultiplex work across "objects" based on the message content and the EPR should not address a specific "object". (Check http://wscc.info/p51561/files/57-hal.pdf#search=%22Session%20concept%20an... and [url]http://www.idealliance.org/proceedings/xml05/abstracts/paper54.HTML for more details. A Call represents an interaction pattern for a specific message exchange. When sending a message the sender application can specify where errors are to be returned, where responses are to go, along with other interaction information. As per the WS-Addressing specification http://www.w3.org/Submission/ws-addressing/, the fields within the Call class are: | To: the destination. MANDATORY. | From: the sender. OPTIONAL. If not defined, then the sender MAY be inferred from the transport. | ReplyTo: the destination for any response. OPTIONAL. | FaultTo: the destination for any error message. OPTIONAL. | RelatesTo: used to indicate that this message is related to another. OPTIONAL. | Action: used by the sender to indicate the semantics of the message. Must be unique. MANDATORY. | MessageID: used to uniquely identify this message. OPTIONAL. | | | Action should be used with care, as it can lead to closely-coupled interactions. Ideally the semantics of the message should be based on the contents of the message. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975374#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...