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 <[email protected]> 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
