Yes it is feasible by making your endpoint bean implement the ServiceLifecycle interface.
However, WS are stateless by nature and doing this have you take the risk of having not working some day without any good explanation.
I guess the preferred approach is to implement a SFSB that passes its handle via the stateless webservice to your WS client. On the next inbound call, the client sends the handle back to your WebService which in turn reconnects to the SFSB.
Yes, I've seen that suggested. One problem - these are POJOs, not session beans. ;) Ehh... well, really, I could write my stuff as beans. It's just that I'm not as comfortable yet with the whole EJB architecture. There are still fuzzy spots in my knowledge and understanding.
I could, but I don't want to, since I'm not that far yet in my experience. :D
Is there any other way, or am I really technically being forced into using beans? Thanks!
You are not forced to use SLSB. If you cllient maintains the session you can get it from the ServletEndpointContext
Generally you want to look into the advantages of maintaining client state in SFSB over HttpSession.
Thanks for the input. I finally got it hammered through my head how simple it is to implement ServiceLifecycle. I couldn't figure out where exactly the ServletEndpointContext came from until a few moments ago.
I'll look into maintaining an SFSB over HttpSession. It makes no material difference to me. The only real difference is client-side, between storing the session ID natively, or passing back a Handle to the SFSB as part of my login() method, and then requiring that Handle to be passed back as the first parameter in all my service's operations.