EJB over HTTP

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

EJB over HTTP

Stuart Douglas
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
gh
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

gh

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.

 

Thank you all.

Alexey, Moscow.

 

 

On Wednesday, May 04, 2016 03:50:22 PM 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.


Stuart






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Darran Lofthouse
In reply to this post by Stuart Douglas
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.

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.

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/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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Tomaž Cerar-2
In reply to this post by gh

On Wed, May 4, 2016 at 11:45 AM, gh <[hidden email]> wrote:
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.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Nicklas Karlsson
In reply to this post by Stuart Douglas

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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Tomaž Cerar-2
In reply to this post by Stuart Douglas
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
In reply to this post by Nicklas Karlsson
Sort of. The intention is not to make a REST API (as JAX-RS already does that), but because we are going to try and map to 'correct' HTTP semantics as much as possible it should be very similar to a REST based API, although the use of JBoss Marshaling means that it can only be used by JDK based clients.

Stuart

On Wed, May 4, 2016 at 7:55 PM, Nicklas Karlsson <[hidden email]> wrote:

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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
In reply to this post by Darran Lofthouse


On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse <[hidden email]> 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/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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Darran Lofthouse
On 04/05/16 11:42, Stuart Douglas wrote:

>
> On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse
> <[hidden email] <mailto:[hidden email]>> 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.

TBH it should be possible to secure a new context with either old or new
- once new is used it will give us an established Elytron identity to
inflow into the EJB container also backed by Elytron.  This will cover
the same case we have for Remoting calls where we have an authenticated
identity for the entry to the server and inflow this identity to the
domain used to secure the EJB deployment.

The server to server case is probably going to be the most problematic
though as that will have the same demands for identity propagation we
are solving with the Remoting case.


>
> 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/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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
In reply to this post by Stuart Douglas
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.

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
In reply to this post by Stuart Douglas
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 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...
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
In reply to this post by David Lloyd-2


On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
On 05/04/2016 08:12 AM, Stuart Douglas wrote:

>
>
> On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >     <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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
>     >[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >[hidden email] <mailto:[hidden email]>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
In reply to this post by Stuart Douglas
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

jtgreene
Administrator
In reply to this post by David Lloyd-2

> On May 4, 2016, at 8:11 AM, David M. Lloyd <[hidden email]> 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 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…

I think pluggable encoding types is essential. IMO I think we should aim for protobufs and marshaling for the first impl. While this isn’t intended as a JAX-RS replacement, we should allow for the possibility of non Java clients to directly trigger EJB invocations.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

jtgreene
Administrator
In reply to this post by David Lloyd-2

> On May 4, 2016, at 9:11 AM, David M. Lloyd <[hidden email]> 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.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
On 05/04/2016 12:51 PM, Jason Greene wrote:

>
>> On May 4, 2016, at 9:11 AM, David M. Lloyd <[hidden email]> 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?

I know it's "just" have a data structure, but it's overhead and
complexity that the server doesn't need and shouldn't have, and it's one
more knob for users to screw around with to trade off between memory
usage and error behavior.  I'd prefer any approach that doesn't have
state maintained by a timeout and can never fail due to misconfiguration
of the server, and has deterministic cleanup properties.

Cancellation is always naturally racy but both of my proposals also
address this: cancellation is idempotent and unrecognized IDs are
ignored.  The cancellation result is sent back on the original request:
it either receives a 200 or 204 indicating success (with or without a
response body), or it receives a 408 indicating that the request was
cancelled cleanly.  The client can ping the server with cancellation
POSTs as much as it wants without mucking up the state of the
invocation, prior cancel requests, or future cancel requests.

>>   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 this misses the complete picture, see below.

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

To me this is a configuration concern: the same issues arise for
REST-ish things.  It's not really long polling per se (which usually
corresponds to using potentially infinitely long connections to
accommodate asynchronous requests or messages from server to client,
something we do not do), just a (possibly) long request (but no longer
than any typical REST request on a potentially slow resource).  We don't
want or need a special one-off solution to this (general, long-standing)
issue in the context of EJB; any solution to this problem should be
general to all long requests.

The point of my proposals are that there is absolutely no need to
conflate the HTTP request lifecycle with EJB asynchronous invocation
semantics, and in fact doing so is actively harmful.  All EJB request
types - sync and async - have a request and reply and conceptually could
be cancellable (even in the sync case the client may invoke
asynchronously or be cancelled), except for one-way invocations which
would immediately return a 202 status anyway.  The only difference is in
whether the client thread directly waits for the response or whether it
waits via a Future, which the client can independently determine based
on information it already has locally.  By the time the invocation gets
to the transport provider, the asynchronicity of the request has lost
its relevance; the transport provider is merely responsible for
conveyance of the request and response and possibly the cancel request
message.

So really this is just about how we handle cancellation, and
cancellation is not a common case so we should optimize for requests
which aren't cancelled, which means one HTTP request and response per
EJB invocation with cancellation being somehow out-of-band.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

jtgreene
Administrator

> On May 4, 2016, at 1:12 PM, David M. Lloyd <[hidden email]> wrote:
>
> On 05/04/2016 12:51 PM, Jason Greene wrote:
>
> To me this is a configuration concern: the same issues arise for
> REST-ish things.  It's not really long polling per se (which usually
> corresponds to using potentially infinitely long connections to
> accommodate asynchronous requests or messages from server to client,
> something we do not do), just a (possibly) long request (but no longer
> than any typical REST request on a potentially slow resource).  We don't
> want or need a special one-off solution to this (general, long-standing)
> issue in the context of EJB; any solution to this problem should be
> general to all long requests.
>
> The point of my proposals are that there is absolutely no need to
> conflate the HTTP request lifecycle with EJB asynchronous invocation
> semantics, and in fact doing so is actively harmful.  All EJB request
> types - sync and async - have a request and reply and conceptually could
> be cancellable (even in the sync case the client may invoke
> asynchronously or be cancelled), except for one-way invocations which
> would immediately return a 202 status anyway.  The only difference is in
> whether the client thread directly waits for the response or whether it
> waits via a Future, which the client can independently determine based
> on information it already has locally.  By the time the invocation gets
> to the transport provider, the asynchronicity of the request has lost
> its relevance; the transport provider is merely responsible for
> conveyance of the request and response and possibly the cancel request
> message.
>
> So really this is just about how we handle cancellation, and
> cancellation is not a common case so we should optimize for requests
> which aren't cancelled, which means one HTTP request and response per
> EJB invocation with cancellation being somehow out-of-band.

I agree with you on this last point here for sure, with the added note that there are arguably better ways to handle long running tasks than an async ejb method invocation.

That said there are certainly some interesting benefits to handling long running invocations without holding a connection open. For example, if you have a transient connection (like say a mobile network), you gain the benefit of never losing the response. However, the necessity to limit resource overhead likely means a transient connection will be unable to retrieve the response anyway, so again we are back to their are better ways to handle long running tasks than an async ejb invocation.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
In reply to this post by David Lloyd-2


On Wed, May 4, 2016 at 11:15 PM, David M. Lloyd <[hidden email]> wrote:
On 05/04/2016 08:12 AM, Stuart Douglas wrote:
>
>
> On Wed, May 4, 2016 at 11:03 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> 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).

I am not 100% sure the best way to handle it. When a transaction or SFSB session is open this makes sense, although once all sessions/transactions has been closed there is no real reason to keep using the same session id (at the moment there is no real way for the client to know that a SFSB is gone though, maybe we need a response header to let a client know a specified session is no longer valid).
 

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

Yes, it should be possible to make this work as expected.

Stuart
 

>
> 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 <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >     <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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
>     >[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >[hidden email] <mailto:[hidden email]>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12