Loading ...
Sorry, an error occurred while loading the content.

Fw: SOAPBuilders Sessions

Expand Messages
  • Glen Daniels
    Hi y all! Here s James first cut at spec ing a very simple sessions-over-SOAP-headers implementation which we came up with at the soapbuilders F2F this week.
    Message 1 of 3 , Jun 6, 2002
    • 0 Attachment
      Hi y'all!
       
      Here's James' first cut at spec'ing a very simple sessions-over-SOAP-headers implementation which we came up with at the soapbuilders F2F this week.  I've got this working (client + server) in Axis, and I hear tell that there will be versions from certain other companies in the near term.  This is NOT meant to provide anything more than simple correlation of a message to a client-session (like a SOAP header cookie), and it is intentionally kept very simple.  If toolkits agree to implement this, however, we would gain the ability to do transport-independent server-managed sessions interoperably!  IMHO, this is super cool.
       
      If we all like this, I would suggest the next steps are probably to a) implement first versions, b) get the spec cleaned up and inline with the SOAP 1.2 Module rules, and c) submit it to the W3C as a note?
       
      Thoughts, comments?
       
      --Glen
       
      ----- Original Message -----
      Sent: Monday, June 03, 2002 10:46 PM
      Subject: SOAPBuilders Sessions

      Sam, Glen:

      Can you please pass this on to the SOAP builders forum, unfortunately I'm
      having some difficulty in sending to the SB list.


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

      All, here is an extremely simple first pseudo-spec runthrough of the
      interoperable Session header.  Scott and Glen were going to try to demo
      this on Tuesday morning.  I'll refine this into something that actually
      looks like a spec hopefully by the end of the week.



      - James M Snell/Fresno/IBM
          Web services architecture and strategy
          Internet Emerging Technologies, IBM
          544.9035 TIE line
          559.587.1233 Office
          919.486.0077 Voice Mail
          jasnell@...
       Programming Web Services With SOAP, O'reilly & Associates, ISBN
      0596000952

      ==
      Have I not commanded you?  Be strong and courageous.  Do not be terrified,

      do not be discouraged, for the Lord your God will be with you wherever you
      go. 
      - Joshua 1:9

    • Prasad Yendluri
      Folks, A few comments: 1. I agree that session management is a very desirable thing and should ultimately become a W3C recommendation. I support the plan to
      Message 2 of 3 , Jun 6, 2002
      • 0 Attachment
        Folks,

        A few comments:

        1. I agree that session management is a very desirable thing and should ultimately become a W3C recommendation. I support the plan to submit this to W3C as a note.

        2. I do think this is a little more complex issue than what we might be seeing in it so far. I don't like the fact that the server will always create a session as soon as it sees an invocation w/o a session handle (i.e. no Session Header targeted at it). This will result in unnecessary overhead when many invocations are not session oriented. Why create sessions always when there is no need for it and tax the server side to incur the resource overhead to maintain the session as well as the client side to track all session handles with different services and invocations to pass the correct handle back etc.

        IMO the need for a session must be determined by the invoker (client) rather than a server. It is the client that would know if it is going to do something in session. We will then need to create a simple protocol where the client requests the server (intermediary) for creation of a new session and receives a session handle (or rejection?) that the client would use with subsequent invocations. When the client wishes to close the session a "close-session (session-handle)" request is sent. This requires services that support sessions to implement the session management calls but I think this is a cleaner way rather than creating a session all the time.

        Sessions can still expire after certain amount of inactivity and exceptions (Faults) can still result as was discussed in the proposal.

        This would also eliminate the need for the server keep the sessions open unnecessarily until the expiration time if the client doe not need the session anymore.

        3. The proposal shows an operation being invoked and a session handle being returned. I think it is a more practical situation that multiple operations in a port would need to be invoked multiple times and in random sequence within a session. Can a session created with invocation of an operation be used with invocation of another? IMO creation of a session needs to happen one level above the invocation of an operation (as in #2 above?).

        4. In the proposal, the way <Session> header is defined, there is no difference in syntax between a server returning a session handle and subsequent use of it by the client. There needs to be a difference lest things would get confusing. This of course will not be the case if the handle were to be exchanged via a light protocol as I stated above.

        5. The examples used show updating a counter and counter going from 1->2 etc. However we need to make a more compelling case for the session and define the semantics more thoroughly and carefully. What if the same operation on a port is being invoked by multiple clients simultaneously in their respective sessions?

        6. I think the use of 'mustUnderstand=1' must be a MUST on the Session Header. We can not make it optional. The server (or intermediary) must understand the session-handle (id) or fail. It can not ignore it.

        Just a few thoughts for discussion.

        Regards, Prasad

        Glen Daniels wrote:

        Hi y'all!
        Here's James' first cut at spec'ing a very simple sessions-over-SOAP-headers implementation which we came up with at the soapbuilders F2F this week.  I've got this working (client + server) in Axis, and I hear tell that there will be versions from certain other companies in the near term.  This is NOT meant to provide anything more than simple correlation of a message to a client-session (like a SOAP header cookie), and it is intentionally kept very simple.  If toolkits agree to implement this, however, we would gain the ability to do transport-independent server-managed sessions interoperably!  IMHO, this is super cool.
        If we all like this, I would suggest the next steps are probably to a) implement first versions, b) get the spec cleaned up and inline with the SOAP 1.2 Module rules, and c) submit it to the W3C as a note?
        Thoughts, comments?
        --Glen
        ----- Original Message ----- To: Sam Ruby ; gdaniels@...
        Sent: Monday, June 03, 2002 10:46 PM
        Subject: SOAPBuilders Sessions
        Sam, Glen:

        Can you please pass this on to the SOAP builders forum, unfortunately I'm
        having some difficulty in sending to the SB list.
         

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

        All, here is an extremely simple first pseudo-spec runthrough of the
        interoperable Session header.  Scott and Glen were going to try to demo
        this on Tuesday morning.  I'll refine this into something that actually
        looks like a spec hopefully by the end of the week.
         
         

        - James M Snell/Fresno/IBM
            Web services architecture and strategy
            Internet Emerging Technologies, IBM
            544.9035 TIE line
            559.587.1233 Office
            919.486.0077 Voice Mail
            jasnell@...
         Programming Web Services With SOAP, O'reilly & Associates, ISBN
        0596000952
         

        --
        ---------------------------------------------------------------
        Principal Architect, ATG; webMethods Inc.,
        432 Lakeside Drive, Sunnyvale, CA 94088-3793, USA
        Tel: (408) 962-5226 mailto: pyendluri@...
        ---------------------------------------------------------------
         
      • Simon Fell
        ... The session token can be arbitrary XML, is it expected that the client will preserve things like comments & PIs ?, It will also need to preserve all the in
        Message 3 of 3 , Jun 8, 2002
        • 0 Attachment
          On Thu, 6 Jun 2002 00:30:47 -0700, in soap you wrote:

          >Hi y'all!
          >
          >Here's James' first cut at spec'ing a very simple sessions-over-SOAP-headers implementation which we came up with at the soapbuilders F2F this week. I've got this working (client + server) in Axis, and I hear tell that there will be versions from certain other companies in the near term. This is NOT meant to provide anything more than simple correlation of a message to a client-session (like a SOAP header cookie), and it is intentionally kept very simple. If toolkits agree to implement this, however, we would gain the ability to do transport-independent server-managed sessions interoperably! IMHO, this is super cool.
          >
          >If we all like this, I would suggest the next steps are probably to a) implement first versions, b) get the spec cleaned up and inline with the SOAP 1.2 Module rules, and c) submit it to the W3C as a note?
          >
          >Thoughts, comments?
          >
          >--Glen

          The session token can be arbitrary XML, is it expected that the client
          will preserve things like comments & PIs ?, It will also need to
          preserve all the in scope namespace prefix's from the source message,
          as you can't tell where there might be QNames in attribute or element
          content within the session token.

          The actor handling doesn't seem to handle all the cases, if there's a
          message path of

          Client A -> Intermediary B -> Server C
          Then there are potentially 3 different sessions
          between A & B
          between A & C
          between B & C

          whilst actor and sessionActor solve some of these, there's a problem
          that if there's active sessions between A & C and B & C for a given
          message, there's no way for C to distinguish which Session header is
          from which source.

          Personally, I think we should start by codifying current practice
          [session token is always a string, no attempt to do anything special
          for intermediaries]

          Cheers
          Simon
          www.pocketsoap.com
        Your message has been successfully submitted and would be delivered to recipients shortly.