[wildfly-dev] EJB over HTTP

[David M. Lloyd]

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

-- 
- DML