Re: [wildfly-dev] EJB over HTTP

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