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

Sessions

Expand Messages
  • Glen Daniels
    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,
    Message 1 of 13 , Mar 27 6:34 PM
      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
    • Simon Fell
      Hi Glen, PocketSOAP currently supports HTTP cookies for session, and could also support a SOAP header for session. If there was a common defined SOAP header
      Message 2 of 13 , Mar 27 7:24 PM
        Hi Glen,

        PocketSOAP currently supports HTTP cookies for session, and could also
        support a SOAP header for session. If there was a common defined SOAP
        header for handling session, then I'd certainly implement that as
        well. I'm all for us defining common approaches what whatever
        additional pieces we think we need above what's covered in the current
        specs. [If i was feeling brave, I'd be tempted to open the dictionary
        serialization can-of-worms as well !]

        Cheers
        Simon
        www.pocketsoap.com

        On Wed, 27 Mar 2002 21:34:29 -0500, in soap you wrote:

        >
        >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/
        >
      • 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 3 of 13 , Mar 27 7:39 PM
          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 4 of 13 , Mar 27 8:32 PM
            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 5 of 13 , Mar 27 9:41 PM
              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 6 of 13 , Mar 27 11:48 PM
                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 7 of 13 , Mar 28 8:50 AM
                  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 8 of 13 , Mar 28 9:12 AM
                    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 9 of 13 , Mar 30 11:27 PM
                      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 10 of 13 , Mar 31 8:48 AM
                        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 11 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 12 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 13 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.