[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 42: WS-SC HTTP Binding
Furthermore - to do so would violate the charter that we all agreed to when we signed up. IMO - this is a non starter. I quote: "The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular messaging middleware, nor to specific network transports." Look at how routers work with DHCP - they lease an IP address then allow devices to plug in to the router and make outward bound http requests. All the state management is done via the router. There is nothing in the HTTP spec that had to be added for maintaining state in a router environment. Note that this functionality also works with https. I argued against DA's in WS-RX for another reason that is also related here. The basic premise of service orientation is that you talk to the service and do not care or need to know what is behind the service. Whether a service is implemented as a group of trained monkey using abacus's or via an entire neural network of Beowulf clusters is academic. You speak to the interface and any mapping to underlying functionality is the responsibility of the service. One should not assume or demand any architecture beyond the service. Sorry - but I have strong feelings here. To me this is not an issue we should accept since it is not the responsibility of the WS-SX spec. Duane Nickull ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ ******************************* -----Original Message----- From: Jan Alexander [mailto:janalex@microsoft.com] Sent: Tuesday, February 28, 2006 7:36 PM To: Marc Goodner; martin.raepple@sap.com; 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]