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

Re: [soapbuilders] Sessions

Expand Messages
  • Chris Radcliff
    Hi Glen, Blue Titan doesn t currently support sessions, but I m about to start adding them. If this group came up with a de facto standard, we d be happy to
    Message 1 of 13 , Mar 27, 2002
      Hi Glen,

      Blue Titan doesn't currently support sessions, but I'm about to start
      adding them. If this group came up with a de facto standard, we'd be
      happy to support it.

      Is any cross-pollination possible from BEA's conversation headers? I
      haven't looked at them very closely, but it looks like a two-way session
      with callback support.

      Cheers,
      ~chris

      Glen Daniels wrote:
      > Axis supports session semantics over SOAP in one of two ways. 1)
      > When using HTTP, we can use cookies to piggyback on top of Java
      > Servlet sessions, and 2) we have a very simple custom
      > SOAP-header-based solution.
      >
      > Do other toolkits support sessions at this stage in the game? If
      > so, how do you do it? If some group of us got together on the
      > phone or IRC and banged out a spec for a SOAP header based (i.e.
      > transport independent) solution, would you support it in your
      > software so we could all interoperate?
      >
    • Bob Cunnings
      Hi, I m all for a SOAP header based mechanism, and would implement any reasonable spec. RC
      Message 2 of 13 , Mar 27, 2002
        Hi,

        I'm all for a SOAP header based mechanism, and would implement any reasonable spec.

        RC

        >
        > Hi y'all.
        >
        > Axis supports session semantics over SOAP in one of two ways. 1) When using HTTP, we can use cookies to piggyback on top of Java Servlet sessions, and 2) we have a very simple custom SOAP-header-based solution.
        >
        > Do other toolkits support sessions at this stage in the game? If so, how do you do it? If some group of us got together on the phone or IRC and banged out a spec for a SOAP header based (i.e. transport independent) solution, would you support it in your software so we could all interoperate?
        >
        > Comments/thoughts very much appreciated!
        >
        > Thanks,
        > --Glen
        >
        >
        > -----------------------------------------------------------------
        > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      • Tomas Bahnik
        Systinet WASP Server uses SOAP Header approach (called per-client instantiation) . Sample SOAP messages are at [1] [1]
        Message 3 of 13 , Mar 27, 2002
          Systinet WASP Server uses SOAP Header approach (called per-client
          instantiation) . Sample SOAP messages are at [1]

          [1] http://soap.systinet.net/demo/accounts.html

          Tomas Bahnik
          Systinet

          ----- Original Message -----
          From: "Glen Daniels" <gdaniels@...>
          To: <soapbuilders@yahoogroups.com>
          Sent: Thursday, March 28, 2002 3:34 AM
          Subject: [soapbuilders] Sessions


          >
          > Hi y'all.
          >
          > Axis supports session semantics over SOAP in one of two ways. 1) When
          using HTTP, we can use cookies to piggyback on top of Java Servlet sessions,
          and 2) we have a very simple custom SOAP-header-based solution.
          >
          > Do other toolkits support sessions at this stage in the game? If so, how
          do you do it? If some group of us got together on the phone or IRC and
          banged out a spec for a SOAP header based (i.e. transport independent)
          solution, would you support it in your software so we could all
          interoperate?
          >
          > Comments/thoughts very much appreciated!
          >
          > Thanks,
          > --Glen
          >
          >
          > -----------------------------------------------------------------
          > This group is a forum for builders of SOAP implementations to discuss
          implementation and interoperability issues. Please stay on-topic.
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
        • Jacek Kopecky
          Yes, and we ll gladly try to get with other to spec something useful and standard. Our header is directed as instance IDs but in fact it is a sessioning
          Message 4 of 13 , Mar 27, 2002
            Yes, and we'll gladly try to get with other to spec something
            useful and standard.
            Our header is directed as instance IDs but in fact it is a
            sessioning mechanism. It would be very easy to make it a generic
            session ID (some renaming) but being instance IDs now, it can
            assume some things. It works as follows:
            1) it is possible to specify an instance ID in the message (it
            should be one or more pairs of sessionName/sessionID in the
            generic case),
            2) it is possible to send back that such-and-such instance ID
            was not found (in generic sessions, there can be policies like
            "create-if-unknown" and "fault-if-unknown" etc. so this error
            reporting should probably stay)
            3) it is possible for the server to set an instance ID on the
            client (with a header in the response, like cookies).

            The latter poses an interesting question: what is the scope of a
            session ID? In our instanceID case it's easy - the scope is one
            WSDL service and one client stub. In the generic sessionID, there
            can be many scopes:
            a) URI scope,
            b) server (DNS name) scope,
            c) WSDL anything scopes (service, port, binding?, portType?,
            port/operation etc.)
            d) others?

            There may be other stuff on sessions like TTL, explicit
            expiration, extending WSDL to specify references to specific
            sessionID etc.

            Do you think this about covers sessioning? 8-)

            Jacek Kopecky

            Senior Architect, Systinet (formerly Idoox)
            http://www.systinet.com/



            On Thu, 28 Mar 2002, Tomas Bahnik wrote:

            > Systinet WASP Server uses SOAP Header approach (called per-client
            > instantiation) . Sample SOAP messages are at [1]
            >
            > [1] http://soap.systinet.net/demo/accounts.html
            >
            > Tomas Bahnik
            > Systinet
            >
            > ----- Original Message -----
            > From: "Glen Daniels" <gdaniels@...>
            > To: <soapbuilders@yahoogroups.com>
            > Sent: Thursday, March 28, 2002 3:34 AM
            > Subject: [soapbuilders] Sessions
            >
            >
            > >
            > > Hi y'all.
            > >
            > > Axis supports session semantics over SOAP in one of two ways. 1) When
            > using HTTP, we can use cookies to piggyback on top of Java Servlet sessions,
            > and 2) we have a very simple custom SOAP-header-based solution.
            > >
            > > Do other toolkits support sessions at this stage in the game? If so, how
            > do you do it? If some group of us got together on the phone or IRC and
            > banged out a spec for a SOAP header based (i.e. transport independent)
            > solution, would you support it in your software so we could all
            > interoperate?
            > >
            > > Comments/thoughts very much appreciated!
            > >
            > > Thanks,
            > > --Glen
            > >
            > >
            > > -----------------------------------------------------------------
            > > This group is a forum for builders of SOAP implementations to discuss
            > implementation and interoperability issues. Please stay on-topic.
            > >
            > > To unsubscribe from this group, send an email to:
            > > soapbuilders-unsubscribe@yahoogroups.com
            > >
            > >
            > >
            > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            > >
            > >
            >
            >
            >
            > -----------------------------------------------------------------
            > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
            >
          • Dick Brooks
            Glen, The company I work for, Systrends, has an ebXML Message Service product that supports sessions in accordance with ebXML, Open Travel Alliance and Energy
            Message 5 of 13 , Mar 28, 2002
              Glen,

              The company I work for, Systrends, has an ebXML Message Service product that
              supports sessions in accordance with ebXML, Open Travel Alliance and Energy
              industry specifications.

              A very good description of OTA's Session support can be found in section 4.8
              of
              http://www.opentravel.org/opentravel/downloads/2001CInfrastructure.PDF


              Dick Brooks
              Systrends, Inc
              7855 South River Parkway, Suite 111
              Tempe, Arizona 85284
              Web: www.systrends.com <http://www.systrends.com>
              Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714


              -----Original Message-----
              From: Glen Daniels [mailto:gdaniels@...]
              Sent: Wednesday, March 27, 2002 8:34 PM
              To: 'soapbuilders@yahoogroups.com'
              Subject: [soapbuilders] Sessions



              Hi y'all.

              Axis supports session semantics over SOAP in one of two ways. 1) When using
              HTTP, we can use cookies to piggyback on top of Java Servlet sessions, and
              2) we have a very simple custom SOAP-header-based solution.

              Do other toolkits support sessions at this stage in the game? If so, how do
              you do it? If some group of us got together on the phone or IRC and banged
              out a spec for a SOAP header based (i.e. transport independent) solution,
              would you support it in your software so we could all interoperate?

              Comments/thoughts very much appreciated!

              Thanks,
              --Glen


              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss
              implementation and interoperability issues. Please stay on-topic.

              To unsubscribe from this group, send an email to:
              soapbuilders-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Bob Cunnings
              Hello, It s a good start. What stands out in particular as important from my pov: -- provision for explicit expiration as an option -- definition of fault
              Message 6 of 13 , Mar 28, 2002
                Hello,

                It's a good start. What stands out in particular as important from
                my pov:

                -- provision for explicit expiration as an option
                -- definition of fault messages (header entries sent in SOAP fault
                messages) so that they can be referenced in WSDL bindings.

                As for session scope, I would lean toward tying it to a WSDL
                construct, namely the <service>. Over the life of the session more
                than one port might need to be used. If this creates an unpopular
                dependency on WSDL, then the next best thing imo would be the
                URI (regardless of server name).

                RC

                > Yes, and we'll gladly try to get with other to spec something
                > useful and standard.
                > Our header is directed as instance IDs but in fact it is a
                > sessioning mechanism. It would be very easy to make it a generic
                > session ID (some renaming) but being instance IDs now, it can
                > assume some things. It works as follows:
                > 1) it is possible to specify an instance ID in the message (it
                > should be one or more pairs of sessionName/sessionID in the
                > generic case),
                > 2) it is possible to send back that such-and-such instance ID
                > was not found (in generic sessions, there can be policies like
                > "create-if-unknown" and "fault-if-unknown" etc. so this error
                > reporting should probably stay)
                > 3) it is possible for the server to set an instance ID on the
                > client (with a header in the response, like cookies).
                >
                > The latter poses an interesting question: what is the scope of a
                > session ID? In our instanceID case it's easy - the scope is one
                > WSDL service and one client stub. In the generic sessionID, there
                > can be many scopes:
                > a) URI scope,
                > b) server (DNS name) scope,
                > c) WSDL anything scopes (service, port, binding?, portType?,
                > port/operation etc.)
                > d) others?
                >
                > There may be other stuff on sessions like TTL, explicit
                > expiration, extending WSDL to specify references to specific
                > sessionID etc.
                >
                > Do you think this about covers sessioning? 8-)
                >
                > Jacek Kopecky
                >
                > Senior Architect, Systinet (formerly Idoox)
                > http://www.systinet.com/
                >
                >
                >
                > On Thu, 28 Mar 2002, Tomas Bahnik wrote:
                >
                > > Systinet WASP Server uses SOAP Header approach (called per-client
                > > instantiation) . Sample SOAP messages are at [1]
                > >
                > > [1] http://soap.systinet.net/demo/accounts.html
                > >
                > > Tomas Bahnik
                > > Systinet
                > >
                > > ----- Original Message -----
                > > From: "Glen Daniels" <gdaniels@...>
                > > To: <soapbuilders@yahoogroups.com>
                > > Sent: Thursday, March 28, 2002 3:34 AM
                > > Subject: [soapbuilders] Sessions
                > >
                > >
                > > >
                > > > Hi y'all.
                > > >
                > > > Axis supports session semantics over SOAP in one of two ways. 1) When
                > > using HTTP, we can use cookies to piggyback on top of Java Servlet sessions,
                > > and 2) we have a very simple custom SOAP-header-based solution.
                > > >
                > > > Do other toolkits support sessions at this stage in the game? If so, how
                > > do you do it? If some group of us got together on the phone or IRC and
                > > banged out a spec for a SOAP header based (i.e. transport independent)
                > > solution, would you support it in your software so we could all
                > > interoperate?
                > > >
                > > > Comments/thoughts very much appreciated!
                > > >
                > > > Thanks,
                > > > --Glen
                > > >
                > > >
                > > > -----------------------------------------------------------------
                > > > This group is a forum for builders of SOAP implementations to discuss
                > > implementation and interoperability issues. Please stay on-topic.
                > > >
                > > > To unsubscribe from this group, send an email to:
                > > > soapbuilders-unsubscribe@yahoogroups.com
                > > >
                > > >
                > > >
                > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                > > >
                > > >
                > >
                > >
                > >
                > > -----------------------------------------------------------------
                > > This group is a forum for builders of SOAP implementations to discuss implementation and inter
                operability issues. Please stay on-topic.
                > >
                > > To unsubscribe from this group, send an email to:
                > > soapbuilders-unsubscribe@yahoogroups.com
                > >
                > >
                > >
                > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                > >
                > >
                >
                >
                >
                > -----------------------------------------------------------------
                > This group is a forum for builders of SOAP implementations to discuss implementation and interope
                rability issues. Please stay on-topic.
                >
                > To unsubscribe from this group, send an email to:
                > soapbuilders-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
              • Jorgen Thelin
                The SAML working group at OASIS already has work in progress for a standard way to perform session management with XML (using what they call Session
                Message 7 of 13 , Mar 30, 2002
                  The SAML working group at OASIS already has work in progress for a
                  standard way to perform session management with XML (using what they
                  call "Session Assertions").
                  http://www.oasis-open.org/committees/security/
                  Given that by far the main usage scenarios for sessions are in the
                  context of security and authentication, it is very likely that this
                  specification will rapidly become the de-facto representation for such
                  "system-level" session information.

                  There will always be the possibility of using application-level session
                  infrastructures, as used by UDDI and vertical market schemes such as
                  OTA. These will largely continue to remain outside the scope of systems
                  software such as a web services platform product.

                  Transport-level session support such as HTTP cookies are already well
                  defined standards and largely well understood.

                  Whether ebXML should be treated as a system-level or application-level
                  implementation is something that could result in hours of interesting
                  debate, but I don't really want to open up that avenue just yet ;-)

                  At the end of the day, SoapBuilders is not a standards body, so the only
                  way to achieve real and widespread interoperability IMHO will be through
                  the existing standards efforts occurring elsewhere.

                  - Jorgen


                  ----
                  Try Cape Clear for all your Web Services software needs.
                  http://www.capeclear.com/
                  CapeConnect - Enterprise-grade Web Services Runtime Platform
                  CapeStudio - Professional Web Services Development Suite
                  ----



                  > -----Original Message-----
                  > From: Glen Daniels [mailto:gdaniels@...]
                  > Sent: 28 March 2002 02:34
                  > To: 'soapbuilders@yahoogroups.com'
                  > Subject: [soapbuilders] Sessions
                  >
                  >
                  >
                  > Hi y'all.
                  >
                  > Axis supports session semantics over SOAP in one of two ways.
                  > 1) When using HTTP, we can use cookies to piggyback on top
                  > of Java Servlet sessions, and 2) we have a very simple custom
                  > SOAP-header-based solution.
                  >
                  > Do other toolkits support sessions at this stage in the game?
                  > If so, how do you do it? If some group of us got together
                  > on the phone or IRC and banged out a spec for a SOAP header
                  > based (i.e. transport independent) solution, would you
                  > support it in your software so we could all interoperate?
                  >
                  > Comments/thoughts very much appreciated!
                  >
                  > Thanks,
                  > --Glen
                  >
                • Bob Cunnings
                  Hello, Thanks, http://www.oasis-open.org/committees/security/docs/draft-orchard-itml-session-00.pdf is an interesting read. RC
                  Message 8 of 13 , Mar 31, 2002
                    Hello,

                    Thanks,

                    http://www.oasis-open.org/committees/security/docs/draft-orchard-itml-session-00.pdf

                    is an interesting read.

                    RC

                    >
                    > The SAML working group at OASIS already has work in progress for a
                    > standard way to perform session management with XML (using what they
                    > call "Session Assertions").
                    > http://www.oasis-open.org/committees/security/
                    > Given that by far the main usage scenarios for sessions are in the
                    > context of security and authentication, it is very likely that this
                    > specification will rapidly become the de-facto representation for such
                    > "system-level" session information.
                    >
                    > There will always be the possibility of using application-level session
                    > infrastructures, as used by UDDI and vertical market schemes such as
                    > OTA. These will largely continue to remain outside the scope of systems
                    > software such as a web services platform product.
                    >
                    > Transport-level session support such as HTTP cookies are already well
                    > defined standards and largely well understood.
                    >
                    > Whether ebXML should be treated as a system-level or application-level
                    > implementation is something that could result in hours of interesting
                    > debate, but I don't really want to open up that avenue just yet ;-)
                    >
                    > At the end of the day, SoapBuilders is not a standards body, so the only
                    > way to achieve real and widespread interoperability IMHO will be through
                    > the existing standards efforts occurring elsewhere.
                    >
                    > - Jorgen
                    >
                    >
                    > ----
                    > Try Cape Clear for all your Web Services software needs.
                    > http://www.capeclear.com/
                    > CapeConnect - Enterprise-grade Web Services Runtime Platform
                    > CapeStudio - Professional Web Services Development Suite
                    > ----
                    >
                    >
                    >
                    > > -----Original Message-----
                    > > From: Glen Daniels [mailto:gdaniels@...]
                    > > Sent: 28 March 2002 02:34
                    > > To: 'soapbuilders@yahoogroups.com'
                    > > Subject: [soapbuilders] Sessions
                    > >
                    > >
                    > >
                    > > Hi y'all.
                    > >
                    > > Axis supports session semantics over SOAP in one of two ways.
                    > > 1) When using HTTP, we can use cookies to piggyback on top
                    > > of Java Servlet sessions, and 2) we have a very simple custom
                    > > SOAP-header-based solution.
                    > >
                    > > Do other toolkits support sessions at this stage in the game?
                    > > If so, how do you do it? If some group of us got together
                    > > on the phone or IRC and banged out a spec for a SOAP header
                    > > based (i.e. transport independent) solution, would you
                    > > support it in your software so we could all interoperate?
                    > >
                    > > Comments/thoughts very much appreciated!
                    > >
                    > > Thanks,
                    > > --Glen
                    > >
                    >
                    >
                    >
                    > -----------------------------------------------------------------
                    > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
                    >
                    > To unsubscribe from this group, send an email to:
                    > soapbuilders-unsubscribe@yahoogroups.com
                    >
                    >
                    >
                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    >
                    >
                  • Rich Salz
                    Wow, Jorgen, where to begin? I disagree with just about everything in your note. So, if only to get an alternate opinion into the record let me make state
                    Message 9 of 13 , Apr 1, 2002
                      Wow, Jorgen, where to begin? I disagree with just about everything in
                      your note. So, if only to get an alternate opinion "into the record"
                      let me make state the following. First off, this mailing list has
                      already done more for interop than the SAML group ever will. :) I say
                      that as a former member of the SAML lists.

                      For quite some time, security sessions will be SSL/TLS, much more than
                      it will be SAML. The current installed base of name/password over SSL is
                      not going to throw that out for SAML as part of their move to XML. When
                      you throw in the Liberty/Hailstorm issues, it's gonna be even worse.

                      I predict SSL will dominate for at least the next two years.
                      Therefore,application-specific sessions -- XML cookies, if you will --
                      are more important for the foreseeable future. It would be nice if the
                      frameworks supported a common mechanism to UDDI (gak) could have the
                      same state mechanism as a Goole search, all supported by the SOAP
                      infrastructure without having to recreate it all the time.

                      A strong +1 to the suggestions.
                      /r$
                    • Jorgen Thelin
                      ... Wow, Rich, I think you have misunderstand almost everything in my note ;-) ... That is because this group is focused on interoperability testing, and the
                      Message 10 of 13 , Apr 2, 2002
                        > -----Original Message-----
                        > From: Rich Salz [mailto:r.salz@...]
                        > Sent: 01 April 2002 15:18
                        > To: soapbuilders@yahoogroups.com
                        > Subject: Re: [soapbuilders] Sessions
                        >
                        >
                        > Wow, Jorgen, where to begin? I disagree with just about everything in
                        > your note.

                        Wow, Rich, I think you have misunderstand almost everything in my note
                        ;-)


                        > First off, this mailing list has
                        > already done more for interop than the SAML group ever will.

                        That is because this group is focused on interoperability testing, and
                        the SAML group is focused on standards setting.
                        That was EXACTLY my point!


                        >
                        > For quite some time, security sessions will be SSL/TLS, much
                        > more than
                        > it will be SAML. The current installed base of name/password
                        > over SSL is
                        > not going to throw that out for SAML as part of their move to
                        > XML. When
                        > you throw in the Liberty/Hailstorm issues, it's gonna be even worse.

                        I completely agree that transport level session features will remain
                        important for a very long time. However, transport-level features such
                        as SSL work on a hop-by-hop basis, so the only way to achieve end-to-end
                        session functionality with a complex network infrastructure topology
                        involving SOAP routers, SOAP firewalls and SOAP processing nodes is at
                        the XML level. This can either be done on an application-specific basis
                        or using some sort of "standardized representation".
                        We cannot and should not stop people using app-specific ways of doing
                        this if they want to, but I am saying that there are already emerging
                        standard for this "standardized representation" without trying to invent
                        yet another one. We already have more than enough competing and
                        overlapping standards in the XML space to confuse the market for some
                        considerable time to come!


                        >
                        > I predict SSL will dominate for at least the next two years.
                        > Therefore,application-specific sessions -- XML cookies, if
                        > you will --
                        > are more important for the foreseeable future.

                        See comments above, although I think am making a distinction between XML
                        cookies being used at the application level and the same ideas begin
                        used at the system level under the guise of infrastructure standards
                        such as SAML Session Assertions, whereas you may not be.
                        Nothing would stop you taking the SAML Sessions document and using it on
                        an application-by-application basis right now. Or for that matter the
                        OTA Sessions or UDDI Sessions systems. They are all just schemas, after
                        all.


                        > It would be nice if the
                        > frameworks supported a common mechanism to UDDI (gak) could have the
                        > same state mechanism as a Goole search, all supported by the SOAP
                        > infrastructure without having to recreate it all the time.

                        I agree it might be "nice", but this is not something that we
                        (SoapBuilders) can mandate use of in practice for every application in
                        the world!
                        I suggest that over time the focus will move away from session support
                        on an application-specific basis towards this being part of standard web
                        services platform services once the necessary standards specifications
                        (such as SAML Session Assertions) are in place and agreed.
                        Transport-level session support such as SSL or HTTP Cookies will run
                        alongside and throughout this evolution, and are totally orthogonal to
                        it in my opinion.


                        I don't think you actually disagree with me so much at all, Rich! :-)

                        - Jorgen

                        ----
                        Try Cape Clear for all your Web Services software needs.
                        http://www.capeclear.com/
                        CapeConnect - Enterprise-grade Web Services Runtime Platform
                        CapeStudio - Professional Web Services Development Suite
                        ----
                      • Rich Salz
                        Okay, we agree more than I thought. :) I think cookie/set-cookie are a useful need to fill right now. You think SAML headers could/should be used right now, I
                        Message 11 of 13 , Apr 7, 2002
                          Okay, we agree more than I thought. :)

                          I think cookie/set-cookie are a useful need to fill right now. You think
                          SAML headers could/should be used right now, I think.
                          /r$
                        Your message has been successfully submitted and would be delivered to recipients shortly.