These hints may be of help when you are building clients and services:
when developing an action, ensure any payload information specific to it is maintained in unique message body locations.
try not to expose any backend service implementation details within the message as this will make it difficult to change the implementation without affecting clients. Use message definitions (contents, formats and so on) which are "implementation-agnostic" as this will help to keep the coupling loose.
for stateless services, use the
ServiceInvoker as it handles fail-over "opaquely."
When building request/response applications, use the correlation information (MessageID and RelatesTo) within the Message Header.
consider using the Header Action field for the main service opcode.
If using asynchronous interactions in which there is no delivery address for responses, consider sending any errors to the MessageStore so that they can be monitored later.
until the JBoss Enterprise SOA Platform provides better automatic support for service contract definition and publication, consider maintaining a separate repository of these definitions, and make it available to both developers and users.