Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      One of the items I would like to see better addressed in a future WebSocket API version is integration with EJB and CDI.

      The case for CDI integration is likely fairly self-explanatory so there no point repeating it. However, perhaps it is important to make the case for EJB integration. Direct EJB integration is a very good fit for RAD code where transactions, persistence, etc are used directly in a WebSocket service. Now while much of this functionality is available outside EJB, some of it is not such as thread safety, asynchronous processing and scheduling. Specifically it may be important to hash out the following questions:

      1. Do stateless session beans map to WebSocket endpoints (the likely answer is no)?
      2. Can stateful session beans be WebSocket endpoints? I think the likely answer is yes if you treat the WebSocket session as an EJB session, hence having a stateful session bean instance per remote client. @Remove could be called automatically when the WebSocket session is closed (just like CDI conversations).
      3. Can singleton session beans be WebSocket endpoints? I think the likely answer is yes and it would provide very useful thread safety services across all remote clients on an endpoint (that can be fine tuned as needed).
      4. Is the caller Principal passed on to EJB from WebSocket (I think the answer is yes)?
      5. WebSocket could have some really nice synergy with @Asynchronous.
      6. What methods can overlap with @Schedule, EJB life-cycle callbacks and other remote/local end-points?

      There are similarly interesting questions to address as to CDI integration:

      1. Will @Transactional work in a WebSocket endpoint? How about @Observes, @Stereotype, @Produces, @Disposes, etc?
      2. Perhaps @Dependent could fit per-peer model?
      3. @ApplicationScoped/@Singleton would be a good fit for a shared endpoint model.
      4. @ConversationScoped, @RequestScoped probably do not map well to WebSocket.
      5. I think @SessionScoped would be a great fit for a instance per-peer model, provided HTTP session ~= WebSocket peer.

      Do let me know if anything needs to be explained further - I am happy to help.

      Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Issue Links

          Activity

          Hide
          panga added a comment -

          The answer is No for question number 4 for Java EE 7 compliant app servers (Glassfish and Wildfly).
          See WEBSOCKET_SPEC-238

          Show
          panga added a comment - The answer is No for question number 4 for Java EE 7 compliant app servers (Glassfish and Wildfly). See WEBSOCKET_SPEC-238
          Hide
          Pavel Bucek added a comment -

          The intention was not to have the question answered "right now" - it was meant as a guide to what should be improved in the (websocket) spec in regards to Java EE / CDI integration.

          I already linked your issue to this one, see "Issue links" section.

          Show
          Pavel Bucek added a comment - The intention was not to have the question answered "right now" - it was meant as a guide to what should be improved in the (websocket) spec in regards to Java EE / CDI integration. I already linked your issue to this one, see "Issue links" section.

            People

            • Assignee:
              Unassigned
              Reporter:
              reza_rahman
            • Votes:
              10 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: