[jboss-as7-dev] EJB Over HTTP

Jaikiran Pai jpai at redhat.com
Tue Aug 28 03:22:36 EDT 2012


The goal is to cover all EJB types which includes stateful and singleton 
remote views too. Furthermore, the intention is to let the application 
use plain EJB applications, if they want to, instead of asking/forcing 
them to add JAX-WS to their applications for achieving this.

-Jaikiran
On Tuesday 28 August 2012 12:08 PM, Richard Opalka wrote:
> JAX-WS operates on top of http&  https and invokes POJOs&  EJBs
> plus provides standard java libraries for WS client.
> So isn't JAX-WS spec. covering all these requirements already?
> Or the main requirement here is to support SFSBs too?
> JAX-WS spec. just support SLSBs and Singleton beans.
>
> Rio
>
> On 08/27/2012 04:45 PM, Jason Greene wrote:
>> 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>



More information about the jboss-as7-dev mailing list