We have a long term solution (8.x+), which is tunneling ejb remoting through the http
server, and a shorter term solution that we would like for 7.x/EAP6.x. The sorter-term
should be something useful for open shift users.
The main requirement is that it be able to share the port of the main web server (8080 by
default), and so this means the short term solution requires that we go a servlet route.
This should use the dynamic context service registration mechanism that web services
framework and the welcome page uses. There should also be a http context per deployment so
that each one can have a different security domain (e.g. something like
/ejb-invocation/fooapp). These contexts should have a servlet that just marshals and
demarshals the ejb invocation payload using jboss marshalling (so that modules are handled
correctly).
The mechanism to activate http invocation should be per deployment, via the jboss-ejb3.xml
deployment descriptor. We could have some global settings in the ejb subsystem. However,
care should be taken so that ejb does not require the web subsystem to be enabled (this
might involve passive services to handle correctly)
The client side should either require a separate, independent, ejb client library or a
plugin library that works with the existing one. I will defer that architectural choice to
Jaikiran. Note that because of the long term route being different, we should ensure that
the code is not too tied to this particular approach.
On Aug 27, 2012, at 9:09 AM, Eduardo Martins <emartins(a)redhat.com> wrote:
Hi everyone, I'm about to (finally) start working on EJB over
HTTP, which seems to be an essential feature that we had in previous AS versions.
I don't know much yet about the previous design and implementation, but here is a doc
wrt AS5 that explains it:
https://community.jboss.org/wiki/EJB3OverHTTPHTTPSInJBossAS-5
The JIRA issue for this development is
https://issues.jboss.org/browse/AS7-4714 , which
contains already some ideas for the implementation.
So, first question, anyone knows if the old design and/or implementation was good enough
to be migrated? Or perhaps someone knows if it had any issues?
In a IRC chat and in the JIRA issue, websockets and xnio were mentioned as possible
foundations for the AS7 implementation, which would mean to discard previous code already
at low level. What is the reasoning for this, i.e., what advantages does the adaption of
either of these bring to the feature and to AS7 as a whole?
Your contribution on this feature discussion is very welcome, thanks ;-)
-- E
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev