Re: [ws-sx] Issue 42: WS-SC HTTP Binding

[Frederick Hirsch <frederick.hirsch@nokia.com>]

+1

regards, Frederick

Frederick Hirsch
Nokia


On Feb 28, 2006, at 10:36 PM, ext Jan Alexander wrote:

> Hi Martin,
>
> It is questionable whether the usage of HTTP-level load balancers is
> appropriate for ensuring affinity between initiator and receiver that
> are sharing state using XML messaging. An XML/SOAP based load balancer
> might be a better solution in this case.
>
> This issue is not specific to WS-SX specifications. This same argument
> can be used in many other cases. In general, there can be other shared
> state maintained between the initiator and receiver that is identified
> just inside the SOAP message and has the same issues when used in the
> web farm environment. WS-RM sequence state might be one example;
> application-level state might be a second example. Are you proposing
> that all identifiers representing such shared state should be  
> mapped to
> the HTTP headers? What about other transports that do not provide
> extensible metadata information (like tcp or udp)?
>
> So far, all WS-* specifications including WS-SecureConversation,
> WS-Trust and WS-SecurityPolicy do not rely on underlying transport,  
> they
> only use SOAP message-level features. This makes the resulting message
> self describing in the sense that you can take the message from the
> wire, put it somewhere else (different transport connection, database,
> email) and it will still make sense even without the underlying
> transport context. The message processing does not require you to
> carry-over information to or from underlying layers in order to  
> send or
> receive the message properly.
>
> I don't think it will do us any good to introduce such a mapping here,
> since it breaks the architectural principle that is behind all WS-SX
> specs.
>
> Thanks,
> --Jan
>
> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Monday, February 27, 2006 10:52 AM
> To: martin.raepple@sap.com; ws-sx@lists.oasis-open.org
> Subject: [ws-sx] Issue 42: WS-SC HTTP Binding
>
> This is now logged as issue 42.
>
>
> -----Original Message-----
> From: martin.raepple@sap.com [mailto:martin.raepple@sap.com]
> Sent: Monday, February 27, 2006 5:19 AM
> To: ws-sx@lists.oasis-open.org
> Cc: Marc Goodner
> Subject: NEW Issue: WS-SC HTTP Binding
>
> PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
> THE ISSUE IS ASSIGNED A NUMBER.
> The issues coordinators will notify the list when that has occurred.
>
> Protocol:  ws-sc
>
> ws-secureconversation-1.3-spec-ed-01-r03-diff.doc
>
> Artifact:  spec
>
> Type:
>
> design
>
> Title:
>
> WS-SC HTTP Binding
>
> Description:
>
> WS-SC introduces the Security Context (SCT) Token which contains a
> unique identifier for a shared security context among the context
> initiator (requester) and (1 to n) service endpoints. There are
> certainly cases where the service endpoint is actually not one system
> but a collection of systems (server farm) used for cluster computing.
> Server farms are typically co-located with a load balancer which  
> enables
> communication between the different servers of the cluster and the  
> users
> of the cluster and may perform some type of load balancing
>
> Based on the assumption that the servers in the cluster do not share a
> common address space or use any other means to synchronize stateful
> resources (such as the security context), the load balancer needs to
> send all subsequent requests for the same client to same server which
> has access to the previously created security context as part of  
> the SCT
> establishment phase (see section 3.3).
>
> The load balancer could certainly look at the
> wsse:security/wsc:SecurityContextToken/wsc:Identifier element to
> determine the context identifier and route the request to the server
> according to same sort of mapping. But this could have an impact of  
> the
> overall performance since the load balance has to look inside the
> content of the HTTP request and parse the content of the SOAP message.
>
> A much faster approach would be to carry the security context  
> identifier
> in the HTTP header. Such an HTTP binding for WS-SC could specify the
> relationship between the WS-SC security context and the HTTP header  
> and
> should define the name and semantics of new custom HTTP header(s).
>
>
> Related issues:
>
>
> Proposed Resolution: