Re: [higgins-dev] STS Servlet Code

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Yes. I agree, I have plan to refactor the code to separate the WS-Trust, 
WS-MetadataExchange, and Profile Editing GUI.
Not just at the servlet but also in the core and binding - no point 
forcing consumers to use/load/configure functionality they may replace.

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 04/10/2007 07:05:47 PM:

> Mike,
> 
> The developer here at Novell that is consuming the STS has another 
> suggestion that I think has merit.  This is an architectural thing. 
> In looking at the Axis1 binding code that implements the Servlet 
> interface (Servlet.java), much of the code is targeted for CardSpace
> interactions.  Three of the URIs that are handled in doGet are 
> really somewhat CardSpace specific:
> 
> /TokenService/services/GetCard.crd
> /TokenService/services/MetadataUsernameToken
> /TokenService/services/MetadataSelfSignedSAMLToken
> 
> The WS-Trust protocol is used to interact with Microsoft CardSpace, 
> and although CardSpace follows the WS-Trust protocol, it is 
> nonetheless a specific "CardSpace flavor" that may not be applicable
> to other products that also use WS-Trust.  Therefore, it seems like 
> it would be appropriate to divide the Servlet class up a little, as 
follows:
> 
> 1. Make the Servlet class with its init, doGet, etc. a little more 
> "generic" - initializing only the things that are "generic" WS-Trust
> (whatever that may be).  We expect this may gut the Servlet.doGet 
> method - basically just calling super.doGet, but we anticipate that 
> much of the init() code will stay in this class.
> 2. Move the code that is intended to handle CardSpace specific 
> interactions into a CardSpaceServlet class that inherits from the 
> generic WS-Trust Servlet class.  Much of the doGet code would end up
> in this class - the code for handling the specific metadata 
> exchanges expected by CardSpace would be there, the card generation 
> code would be there, etc.
> 
> This separation would allow others to create their own "AppServlet" 
> classes that could inherit from the generic Servlet class.  They 
> would get the benefits provided by that class (generic WS-Trust 
> stuff), but not have to carry around the overhead of specific uses 
> of WS-Trust (like CardSpace).  WS-Federation may be an example of 
> this.  It needs to use WS-Trust protocol, but probably not in 
> exactly the same way that CardSpace does.
> 
> Thanks,
> 
> Daniel_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev