[wildfly-dev] EJB over HTTP

[Darran Lofthouse]

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:
>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>
>> 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
>> clustering).
>>
>> 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.

>