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