[wildfly-dev] EJB over HTTP
darran.lofthouse at jboss.com
Tue May 10 11:10:17 EDT 2016
On 10/05/16 15:26, David M. Lloyd wrote:
> On 05/04/2016 12:50 AM, 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.
> I noticed the responses are not coupled with the requests in the
> document, which was a bit confusing at first.
> I have a question though, why have the "EJB new session" response return
> a nonstandard header for the session ID rather than a REST-ish 201
> message that has a Location: header with the SFSB URI in it? Was it
> just message size you were worried about? Also having a content-type
> with no body is a little weird.
> The EJB request payload has to include the "weak affinity" value in
> order to be compatible with the existing protocol. But I think maybe
> the affinity concept should be nuked from orbit in general, as it turns
> out to be kinda broken; we can discuss this separately.
> On the topic of security... The original draft design doc was written
> before we really bit into HTTP authentication in Elytron. Now that we
> have, I think we can safely rely solely on HTTP authentication
> mechanisms to cover all cases for HTTP, including more complex
> mechanisms like Kerberos, OAuth2 and other SSO technologies,
> session-based authentication, and so forth; we don't need any separated
> authentication service over HTTP for any reason that I can think of.
> We may however want to consider adding a custom cookie-based
> authentication mechanism to allow for HTTP-level authentication results
> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
> way it would be possible to toggle between more than one identity
> without requiring every request to repeat the authentication, and
> without overloading JSESSIONID for this purpose (allowing multiple
> identities to be used for a given SFSB and/or transaction).
We would have to be very careful with that one though - for the identity
switching in Remoting we have the ability to use a long running
connection to associate the identity with - if we are not careful cookie
based tracking immediately adds somethign that can be used for replay
unless TLS is mandated as well.
More information about the wildfly-dev