cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: Status of WS-RM
Date Fri, 26 Nov 2010 10:56:27 GMT
Relating to this same issue of the WS-RM status, does the current code
handle interactions with WS-Security? In particular, I'm wondering what
happens if you're using timestamps with signing - does the WS-RM code
generate a new timestamp (and signature) when it resends the message, or
just resend the entire original message with the original timestamp?


  - Dennis

Dennis M. Sosnoski
Java SOA and Web Services Consulting <>
Axis2/CXF/Metro SOA and Web Services Training
Web Services Jump-Start <>

On 11/17/2010 02:58 AM, Aki Yoshida wrote:
> On Mon, Nov 15, 2010 at 8:21 PM, Daniel Kulp <> wrote:
>> On Monday 15 November 2010 12:05:56 pm Scott Came wrote:
>>> Thanks, Daniel.
>>> What about the potential to leverage Sandesha or the implementation in
>>> Metro?  My research has indicated that some time ago there was discussion
>>> about trying to create a reusable RM library that could do the job (with
>>> adaptation) across the various open source implementations of WS-*.  While
>>> it seems that never went anywhere (probably with good reason) should I
>>> have any hope of reusing significant chunks of code from either of those
>>> efforts?
>> Well, for Sandesha, I haven't looked at the code there at all so I don't know
>> how reasonable it is to reuse chunks of it.   For WS-SecPol, I did use the
>> Rampart code as a base, but it pretty much ended up as a complete re-write by
>> the time I was done with it.   Sandesha might be in the same ball park.
> It would be nice to share some part of the implementation to save the
> development and maintenance cost.
> But I also have a feeling that using Sandesha won't be a shorter path
> to support WS-RM 1.1 in CXF.
> I am looking into some other issues of the current 1.0 implementation
> but I am also interested in this question of going for 1.1.
> Regards, Aki

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message