[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 42: WS-SC HTTP Binding
Hi Jan, I agree that an XML/SOAP load balancer would be a better choice in such a scenario but since this is a relatively new technology I assume that most installed systems today are still HTTP-based load balancers. I'm sure that many implementations will solve this issue by using different mechanisms (e.g. cookies, http headers etc.) and my thinking was to give a recommendation for a preferred solution by this TC. I don't feel so strong about this issue and it's up to the TC to decide. If it violates the charter as Duane mentioned in his mail we should probably drop it. - Martin -----Original Message----- From: Jan Alexander [mailto:janalex@microsoft.com] Sent: Mittwoch, 1. März 2006 04:36 To: Marc Goodner; Raepple, Martin; ws-sx@lists.oasis-open.org Subject: RE: [ws-sx] Issue 42: WS-SC HTTP Binding 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:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]