"CptnKirk" wrote : Not to knock the work done by the remoting team, but is there a reason a custom protocol was chosen vs a Seam RemotingEndpoint that would handle remoting via some version of SOAP? | | I would have a thought the benefits of a standard transport protocol would outweigh the down side. Since obviously they did not, what are the benefits of this approach? SOAP was too heavy-weight for my taste; instead I chose to implement the remoting protocol based loosely on the XML-RPC spec, with some minor changes to how object references were handled and the inclusion of a request context to carry additional stuff like the conversation ID. The intent was to make the protocol as lightweight and simple as possible to both keep network traffic minimal and to make it easy to implement remoting clients in other languages (ActionScript, etc). As a side note, there is a more comprehensive web services strategy in the works for Seam which will enable calling Seam components via SOAP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970655#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...