<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wonder how much this should be integrated with the new client that David is currently working on, if the two were closely integrated it would make it much easier for clients to switch between the two as well as taking advantage of all of the new shared configuration.<br></blockquote><div><br></div><div>This should be implemented as a transport provider for the HTTP Client, one of the goals is to be able to use this in place of remoting basically transparently (just a configuration change).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Server side Elytron will have a full set of HTTP mechanisms so all the mechanisms you list will be available going forward. Would this be used for server to server as well or just client to client? We may end up with additional requirements that we already have for native calls regarding clients running with multiple identities and the propagation of identities from server to server.<br></blockquote><div><br></div><div>It could be used for server -> server and client -> server. I think auth should be based on existing HTTP mechanisms, but I am not sure if something as simple as hooking up our existing HTTP mechanisms to this will meet all the use cases.<br><br></div><div>Stuart<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Darran Lofthouse.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 04/05/16 06:50, Stuart Douglas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
I have started looking into support for service invocation over HTTP.<br>
Unlike our existing HTTP upgrade support this will map EJB<br>
requests/responses directly to HTTP requests and responses, which should<br>
allow it to be used behind existing load balancers.<br>
<br>
I have started an initial description of the protocol at:<br>
<a href="https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc" rel="noreferrer" target="_blank">https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc</a><br>
<br>
The intention is to follow HTTP semantics as closely as possible.<br>
Clustering will be provided in a similar manner to web clustering (i.e.<br>
it will require a load balancer, and work in a similar manner to web<br>
clustering).<br>
<br>
There is still plenty work that needs to be done (especially around<br>
security), so if anyone has any feedback let me know.<br>
<br>
Stuart<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>