On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse <darran.lofthouse@jboss.com> wrote:
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.

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).

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.

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.


Darran Lofthouse.

On 04/05/16 06:50, Stuart Douglas wrote:
Hi everyone,

I have started looking into support for service invocation over HTTP.
Unlike our existing HTTP upgrade support this will map EJB
requests/responses directly to HTTP requests and responses, which should
allow it to be used behind existing load balancers.

I have started an initial description of the protocol at:

The intention is to follow HTTP semantics as closely as possible.
Clustering will be provided in a similar manner to web clustering (i.e.
it will require a load balancer, and work in a similar manner to web

There is still plenty work that needs to be done (especially around
security), so if anyone has any feedback let me know.