Hi Im newbie at wildfly-dev, i know Java (we use JBOSS EAP for our internal project at my work) and C++11 and want to participate, may be even in this task. What i have to do? Fork->pull request? Our may be you will attach someone of a real dev group to me.

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. Stuart _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

So this will be sort of REST with the exception of the state, transactions etc? ;-) (oops, previous post had wrong distribution) On Wed, May 4, 2016 at 8:50 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com > 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. > > Stuart > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote: I wonder how much this should be integrated with the new client that David is currently working on, if the two were closely integrated it would make it much easier for clients to switch between the two as well as taking advantage of all of the new shared configuration. This should be implemented as a transport provider for the HTTP Client, one of the goals is to be able to use this in place of remoting basically transparently (just a configuration change). Server side Elytron will have a full set of HTTP mechanisms so all the mechanisms you list will be available going forward. Would this be used for server to server as well or just client to client? We may end up with additional requirements that we already have for native calls regarding clients running with multiple identities and the propagation of identities from server to server. It could be used for server -> server and client -> server. I think auth should be based on existing HTTP mechanisms, but I am not sure if something as simple as hooking up our existing HTTP mechanisms to this will meet all the use cases.

Stuart Regards, Darran Lofthouse. On 04/05/16 06:50, 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. Stuart

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.

On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com>> wrote: Getting transactions and SFSB to share a load-balancing behavior will hopefully be possible though. I guess it'll require some thought to make it easy to avoid situations where (for example) two SFSB are spread to different nodes and then you try to create a UserTransaction which includes both. Once you start using a SFSB or a Transaction you should get a session cookie, which should give you affinity to the relevant node (based on the assumption the load balancer supports sticky sessions).

Stuart On 05/04/2016 05:36 AM, Stuart Douglas wrote: > The purpose is to enable load balancer based clustering to work. > Basically even though there is no underlying web session the JSESSIONID > cookie will make sure that the load balancer delivers the request to the > correct backend server. > > Basically existing load balancers already support sticky sessions, and > we are just piggy backing on that, as the primary customer use case for > this is allowing EJB calls through a HTTP load balancer. > > Stuart > > On Wed, May 4, 2016 at 7:56 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com> > <mailto:tomaz.cerar@gmail.com <mailto:tomaz.cerar@gmail.com>>> wrote: > > One thing that seems somewhat odd to me is the usage of JSESSIONID > for tracking session state. > That cookie/param is used for servlet http sessions and given that > this is pure EJB without any servlets > it would be bit confusing to require it. Or will this rely on > session tracking from undertow-servlet? > > -- > tomaz > > On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas > <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com> <mailto:stuart.w.douglas@gmail.com <mailto:stuart.w.douglas@gmail.com>>> 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. > > Stuart > > > > _______________________________________________ > wildfly-dev mailing list &gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > wildfly-dev mailing list &gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

On May 4, 2016, at 8:11 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; 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/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. One thing I was thinking was that we could possibly support multiple marshalling strategies in the future by way of content-type, since that header has a useful negotiation strategy already defined. It could even be done using the defined types e.g. application/x-ejb-invocation;version=2;m=protobuf or whatever. Something to think about for the future…

> On May 4, 2016, at 9:11 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > > One thing I noticed is that you went a different way with async > invocations and cancellation support. > > The way I originally proposed was that the request/response works as per > normal, but a 1xx header is used to send the client a cancellation token > which can be POSTed back to the server to cancel the invocation. I > understand that this approach requires 1xx support which some clients > might not have. > > In your proposal, the async EJB request always returns immediately and > uses an invocation ID which can later be retrieved. I rejected this > approach because it requires the server to maintain state outside of the > request - something that is sure to fail. I don’t think this is too big of a deal, I mean you just have a data structure with a built-in automated expiration mechanism. However, it does have a negative in the its naturally racy, which I guess is your concern?

> Also the client doesn't > really have any notion as to when it can GET the response: it would have > to do it more or less immediately to avoid a late response (or when > Future.get() is called), meaning you need two round trips in the common > case, which is not so good. Yeah I think a key aspect of this is the client has to be able to say it wants blocking behavior, even if the server side is mapped asynchronously.

> > I think that the best compromise solution is to treat async invocations > identically to regular invocations, and instead let the *client* give a > cancellation ID to the server, which it can later POST to the server as > I described in my original document. If the server receives the > client's ID (maybe also matching the client's IP address) then the > request can be canceled if it is still running. I think thats a reasonable way to do it, provided the ID is sufficiently unique to not be repeated. Actually with HTTP 2, we could just hang-up the stream for cancellation, as the stream-id is an effective invocation id. However, it’s perhaps best to keep consistent semantics between h1 and h2. I think a key question, which I don’t have the answer for, is if we need to support more concurrent long-running invocations than connections(h1)/streams(h2). If the answer is yes then long polling is bad. I am also slightly worried about HTTP intermediaries imposing timeouts for long running operations.

On 05/04/2016 08:12 AM, Stuart Douglas wrote: > > > On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <david.lloyd(a)redhat.com > <mailto:david.lloyd@redhat.com>> wrote: > > Getting transactions and SFSB to share a load-balancing behavior will > hopefully be possible though. I guess it'll require some thought to > make it easy to avoid situations where (for example) two SFSB are spread > to different nodes and then you try to create a UserTransaction which > includes both. > > > Once you start using a SFSB or a Transaction you should get a session > cookie, which should give you affinity to the relevant node (based on > the assumption the load balancer supports sticky sessions). Yeah I was just thinking though: does that ID apply to all future invocations across all EJBs pointing at the node URL, or just EJB invocations on that SFSB/transaction for its lifetime? It seems like you are suggesting that all invocations then get that session ID (which is probably OK, I just like to play devil's advocate whenever possible).

Also, there is an edge case where separate threads create SFSBs simultaneously which we'd want to ensure works as expected, in either case.

> > Stuart > > > On 05/04/2016 05:36 AM, Stuart Douglas wrote: > > The purpose is to enable load balancer based clustering to work. > > Basically even though there is no underlying web session the JSESSIONID > > cookie will make sure that the load balancer delivers the request to the > > correct backend server. > > > > Basically existing load balancers already support sticky sessions, and > > we are just piggy backing on that, as the primary customer use case for > > this is allowing EJB calls through a HTTP load balancer. > > > > Stuart > > > > On Wed, May 4, 2016 at 7:56 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com> > > <mailto:tomaz.cerar@gmail.com <mailto:tomaz.cerar@gmail.com>>> wrote: > > > > One thing that seems somewhat odd to me is the usage of JSESSIONID > > for tracking session state. > > That cookie/param is used for servlet http sessions and given that > > this is pure EJB without any servlets > > it would be bit confusing to require it. Or will this rely on > > session tracking from undertow-servlet? > > > > -- > > tomaz > > > > On Wed, May 4, 2016 at 7:50 AM, Stuart Douglas > > <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com > > <mailto:stuart.w.douglas@gmail.com > <mailto:stuart.w.douglas@gmail.com>>> 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. > > > > Stuart > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > &gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org>> > >https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > &gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > >https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that). The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.

With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec. Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though. Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers. Stuart On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; 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/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. > > One thing I noticed is that you went a different way with async > invocations and cancellation support. > > The way I originally proposed was that the request/response works as per > normal, but a 1xx header is used to send the client a cancellation token > which can be POSTed back to the server to cancel the invocation. I > understand that this approach requires 1xx support which some clients > might not have. > > In your proposal, the async EJB request always returns immediately and > uses an invocation ID which can later be retrieved. I rejected this > approach because it requires the server to maintain state outside of the > request - something that is sure to fail. Also the client doesn't > really have any notion as to when it can GET the response: it would have > to do it more or less immediately to avoid a late response (or when > Future.get() is called), meaning you need two round trips in the common > case, which is not so good. > > I think that the best compromise solution is to treat async invocations > identically to regular invocations, and instead let the *client* give a > cancellation ID to the server, which it can later POST to the server as > I described in my original document. If the server receives the > client's ID (maybe also matching the client's IP address) then the > request can be canceled if it is still running. > > Failing this I still prefer the 1xx approach where the server gives a > cancellation ID at the beginning of the request, as this avoids problems > where the server has to maintain large object state for indefinite > amounts of time. Either of these two options means only one server > round trip for async invocation, and no server-side caching of responses. > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

I have updated the spec doc to now use client side generated id that is paired with a session cookie to ensure uniqueness and node affinity. If the client does not already have a session id it can request one with an affinity message. Stuart On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that). The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation. I just thought of a way to get around this. If we require the use of an existing JSESSIONID for cancellable invocations both these problems are resolved. The sticky session makes sure the correct node is targeted, and the server can use the session id + invocation id as a unique key. The only overhead of this is that we could need some kind of 'affinity' request message that has no other purpose than generating a session id if the client does not already have one (although this would only need to be executed once). Stuart With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec. Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though. Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers. Stuart On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com>> 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. One thing I noticed is that you went a different way with async invocations and cancellation support. The way I originally proposed was that the request/response works as per normal, but a 1xx header is used to send the client a cancellation token which can be POSTed back to the server to cancel the invocation. I understand that this approach requires 1xx support which some clients might not have. In your proposal, the async EJB request always returns immediately and uses an invocation ID which can later be retrieved. I rejected this approach because it requires the server to maintain state outside of the request - something that is sure to fail. Also the client doesn't really have any notion as to when it can GET the response: it would have to do it more or less immediately to avoid a late response (or when Future.get() is called), meaning you need two round trips in the common case, which is not so good. I think that the best compromise solution is to treat async invocations identically to regular invocations, and instead let the *client* give a cancellation ID to the server, which it can later POST to the server as I described in my original document. If the server receives the client's ID (maybe also matching the client's IP address) then the request can be canceled if it is still running. Failing this I still prefer the 1xx approach where the server gives a cancellation ID at the beginning of the request, as this avoids problems where the server has to maintain large object state for indefinite amounts of time. Either of these two options means only one server round trip for async invocation, and no server-side caching of responses. -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

On 05/10/2016 10:10 AM, Darran Lofthouse wrote: > 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/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). > 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. Yeah it'd have to be checked against the session at the very least, meaning a session may have multiple identities but an identity may not cross sessions. If there's no session, each request would be required to re-authenticate. Alternatively, it could be bound to a TLS session, though how that fits into the protocol model is a bit more nebulous.

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