One thought I am left with after our recent design workshop is that there are a wide variety of expectations for Remoting 3. Accumulating all of my notes, emails, etc., I've discovered that there are some requirements that are in conflict or otherwise don't make a lot of sense to me. So, in no particular order... ;) Web Services (if I understand correctly) wants to be able to use Remoting like a URLConnection. In other words, open an HTTP connection or JMS session (which one depends on the URI scheme) and shove SOAP through, and (presumably) it will interoperate with whatever is on the other side without the Web Services implementation having to know what protocol is 'really' being used. And on the receiving side, it would be able to accept requests/messages from arbitrary peers (in other words, possibly not running Remoting). In addition, using HTTP should provide a level of abstraction above the HTTP client or server, such that there is no dependency on any specific implementation library. ESB is less picky - they don't seem to care so much about how message is carried across the protocol. What matters to them are clear semantics of delivery (namely, guaranteed delivery for one-way messages), and a wider variety of transports (including "slower" transports like FTP, Email, etc). Messaging seems to care about performance over everything. Though AMQP was mentioned a number of times, the underlying protocol seems less important that being able to ship large numbers of messages quickly and with as little loss as possible. So... my conclusions thus far are as follows: An HTTP client/server facade library, with implementations wrapping HttpURLConnection/Servlet API/Tomcat/Commons/whatever is definitely a worthwhile project, and could probably be used by many other projects (Remoting included), but I don't see that as part of the core Remoting API. Rather that would be something that could (and should) be its own independent project - maybe even under the higher umbrella of a unified JBoss Connectivity project... As far as creating a JMS "connection" via URL (JBREM-305 btw)... I'm sorry Thomas, but I don't see how that even makes sense. JMS has its own API - there are topics and queues, transactions, multiple message types... if we were to provide a wrapper API to make it look like something else, I'm certain that JBWS would be the only user (we'd be stripping out anything from the JMS API that makes it useful outside of the one problem domain). If we provide a JMS transport (and I'm not saying that we won't), it would meet the requirements for passing Remoting invocations, which I cannot guarantee will match the requirements for passing SOAP messages (unless they're tunneled within a Remoting Request). And I definitely don't want to have to deal with interoperability between Remoting 3 and whatever random SOAP-over-JMS consumer is out there. Right now Remoting 3 focuses on invocation, and moving data from one endpoint to another in a protocol-agnostic fashion. It is not, nor can it become, a protocol-silver-bullet that allows your app to speak any protocol. If such a thing were possible, you wouldn't need separate APIs for HTTP, JMS, AMQP, CORBA, RMI, etc. The fact is that all these protocols have different semantics, and if we try to generically support them all at a low level with the same API, we're going to create a framework that does everything maybe kind of OK, but nothing particularly well. The addition of "slow" protocols is an odd fit to be sure, but I'm pretty sure that it can be done in a way that fulfills the requirements of ESB (or WS for that matter) as long as the format of the message in transit is not important. However I suspect that a better mechanism could be devised with this specific use case in mind (that is, one-way messages only, slow transports, programmable delivery guarantee). So I'm still unsure what the right way to go with this is. I would hope that even using the regular high-level API would perform sufficiently well for JBM. However, Remoting does serialize and deserialize every message sent back and forth, and there are other overheads as well, so it is possible that performance of Remoting will not meet the requirements of JBM no matter what we do. Only the numbers will tell I suppose. I hope this was reasonably coherent - the main point I want to get across is that I think Remoting should be less concerned with protocol interoperability and more concerned with satisfying the requirements of the higher-level API in the most effective way possible for each underlying protocol. Systems that need protocol-specific interoperability cannot make this guarantee without using APIs that are tailored to each protocol. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091768#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...