How to create webservice session in cluster ?

Discussions

XML & Web services: How to create webservice session in cluster ?

  1. How to create webservice session in cluster ? (7 messages)

    HTTPSession is not available to WebServices. At least I don't know how to use them.
    But following circumstances should be very typical
    When WebServices is called some proprietary "session" class should be created and some information should be stored in session to keep information about current state. When successive request comes to the server some information is attached to identify the session corresponded to this request. Server extracts information about this session and uses it to fulfill the
    Request. EJB Statefull bean is good candidate to keep session information. Some singleton java class interface keeps references to all statefull beans and provides reference to particular EJB Statefull bean by request.
    Ok. It probably works in the single server environment.

    But how does it work in cluster?
    Tomcat does not support EJB but supports some
    HTTPSession replication.

    Can I use tomcat session replication to synchronize some pool of Java Beans that are not stores inside the HTTPSession?

    Do commercial APP servers like a WebSphere
    support Statefull bean replication?
    Definitely they should do.

    Threaded Messages (7)

  2. Assuming that you tried and it's impossible to redesign the interaction so sessions are no longer required...

    If client is guaranteed to be java, and stateful EJBs fulfil the scalability and fault tolerance requirements of project I'd go ahead and use them.

    If you need web services you will probably have to roll out concept of custom session in your business logic. Kind of like shopping cart that is backed by the database. Client would explicitly pass session ID in the body as part of request. Operations that need session information would load and store them to db. If you are concerned about performance - benchmark it (databases are optimized to scale up extremely well, so it's unlikely that other cluster-wide session storage solutions will be faster).
  3. Custom managed session.[ Go to top ]

    Format of this forum is not allowed me to put here a pictures.
    But let me put them on the internet and make here a link.

    http://sakalou.users.mcs2.netarray.com/webservices/web/clustermodel.jsp

    Correct please if some of these assumtions are wrong.
  4. I agree with conclusion[ Go to top ]

    However diagrams imply that "sessions" will be pooled in memory. It would be much more hassle-free to always keep them in the database. Especially if your requests are big and granular. It will add some latency to time it takes to handle single request, but entire system should scale. Databases are optimized extremely well for fast cached lookups. Updates should be fast enough too (measure it).

    What's your scenario that absolutely requires "sessions in web services"?
  5. It is not required but optional[ Go to top ]

    It is not required but optional. I am currently working on
    the architectural design of a new system so just want to be sure
    that all possible issues are covered at least theoretically
    in the design phase because we could not return back when
    start implementation. We have not received all possible business
    scenarios yet. So I assume that it theoretically some business scenario
    can assume session support. But I agree with you that sessions
    with WebServices should be very rear case.
     
    Thank you for your help.
  6. I've used read-mostly entity beans in BEA to accomplish this. They are replicated across the cluster. We needed to insure session state persistence and failover and this solution was appropriate.
  7. Read mostly bean ?[ Go to top ]

    This is not part of EJB standart ? Right ?
  8. Read mostly bean ?[ Go to top ]

    Right. That's why I specifically cited BEA. For more info, go to this link
    and search/scroll down to "Read-Mostly Pattern".

    http://e-docs.bea.com/wls/docs81/ejb/entity.html