OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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

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


-----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

The issues coordinators will notify the list when that has occurred.

Protocol:  ws-sc


Artifact:  spec




WS-SC HTTP Binding


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]