You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Ryan Zoerner <ry...@gmail.com> on 2011/07/17 18:54:47 UTC

Stateless EJB's and JAX-WS (no comment necessary)

There were only StatelessSessionBeans in the CXF factory because:

===================================================
The client of a stateless session bean may be a web service client.
Only a *stateless *session bean may provide a web service client view.

===================================================

(page 40)
ejb-3_0-fr-spec-ejbcore.pdf
EJB Final Release Spec

Re: Stateless EJB's and JAX-WS (no comment necessary)

Posted by Sergey Beryozkin <sb...@gmail.com>.
Then just have a stateless session bean exposed as JAX-RS endpoint too
for a start

On Sun, Jul 17, 2011 at 5:54 PM, Ryan Zoerner <ry...@gmail.com> wrote:
> There were only StatelessSessionBeans in the CXF factory because:
>
> ===================================================
> The client of a stateless session bean may be a web service client.
> Only a *stateless *session bean may provide a web service client view.
>
> ===================================================
>
> (page 40)
> ejb-3_0-fr-spec-ejbcore.pdf
> EJB Final Release Spec
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: Stateless EJB's and JAX-WS (no comment necessary)

Posted by Sergey Beryozkin <sb...@gmail.com>.
Ryan - this is a CXF dev list so if you just intend to think aloud
then the dev list is not the best place to do it :-), I'm sorry if I
misunderstood your "no comment necessary" bit in the subject.

Once again, I like the fact you are trying to approach the issue
fundamentally, but IMHO you have to
keep the focus and learn to get to the target the fastest possible
way. Just deploy a JAX-WS endpoint or/and focus on understanding how
the JAX-WS integration is done, don't be concerned too much at this
stage about all the subtleties of which EJB beans can be exposed as
(SOAP) web services and which can not, because the goal is to make
sure an EJB JAX-RS endpoint can be deployed - lets limit the goal of
this project to this task - because if you manage to deploy even a
simple EJB JAX-RS endpoint then you'll get the knowledge needed to
continue and complete the integration, if you will be interested

Cheers, Sergey

On Sun, Jul 17, 2011 at 7:28 PM, Ryan Zoerner <ry...@gmail.com> wrote:
> I'm not sure why this is. (in regards to the above specification detail).
>
> JAX-WS calls for support for sessions. The web service mechanism should
> easily allow for the
> identification of which session, before an instantiated (Client-facing)
> Business Interface implementing
> EJB bean is directly engaged by the Client request.
>
> ?
>
> Is this supposed to be StatelessSession "session delegators" only?
>
> They might mean here, by "view", that the rendering of the client-viewed
> data is not session dependent. (although session data might be dependent
> upon previous session data.) But what about Web Services that only
> return Session-specific data and do not render a client view at all? What
> if the data is a list of words that the client has uploaded in previous
> requests,
> across one session?
>
> ============
> Ryan
> ============
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: Stateless EJB's and JAX-WS (no comment necessary)

Posted by Ryan Zoerner <ry...@gmail.com>.
I'm not sure why this is. (in regards to the above specification detail).

JAX-WS calls for support for sessions. The web service mechanism should
easily allow for the
identification of which session, before an instantiated (Client-facing)
Business Interface implementing
EJB bean is directly engaged by the Client request.

?

Is this supposed to be StatelessSession "session delegators" only?

They might mean here, by "view", that the rendering of the client-viewed
data is not session dependent. (although session data might be dependent
upon previous session data.) But what about Web Services that only
return Session-specific data and do not render a client view at all? What
if the data is a list of words that the client has uploaded in previous
requests,
across one session?

============
Ryan
============