[wildfly-dev] EJB over HTTP

David M. Lloyd david.lloyd at redhat.com
Tue May 10 12:40:34 EDT 2016

On 05/10/2016 09:26 AM, 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/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 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.

Looking at the JNDI part, it seems like you are using the content type 
to establish the operation that is to be performed, even when there is 
no actual content.  In the draft, the Accept: type was used to establish 
what kind of result was requested (for JNDI it could be the actual 
binding, or it could be a list of bindings in a couple of forms for 
subcontexts).  The request method determined the operation, and query 
parameters applied behavioral variations.

You did (rightly, IMO) change the lookup operations from GET to POST, 
but I think that response type and query parameters would still suffice 
to get the result, and I'm not sure that using the request content type 
to identify the operation is really appropriate in any event.


More information about the wildfly-dev mailing list