Re: [higgins-dev] STS Architecture Question

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Response inline below.

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/14/2007 04:54:18 PM:

> Mike,
> 
> We have a developer inside Novell that is using the Higgins STS.  He
> would like to be able to use a single common org.eclipse.higgins.
> sts.server.ISecurityTokenService object that can be used with his 
> own bindings or with the Axis binding you provide.  He wants to be 
> able to create and configure the ISecurityTokenService object 
> himself, rather than having a singleton that is created and 
> configured inside the SecurityTokenServiceServerBinding class.  In 
> the case where he is handling his own bindings, he will create 
> create ISTSRequest and ISTSResponse objects himself, and then call 
> ISecurityTokenService.invoke().  In the case where he is leveraging 
> the Axis bindings you provide, he wants to be able to pass the 
> ISecurityTokenService object he created into the 
> SecurityTokenServiceServerBinding class. -- In other words, he wants
> to keep track of the ISecurityTokenService singleton himself - 
> independent of the SecurityTokenServiceServerBinding class - so that
> he can reuse it for his own purposes as well as for the 
> SecurityTokenServiceServerBinding class when needed.
> 
> Right now the SecurityTokenServiceServerBinding class points to a 
> private static instance of the ISecurityTokenService object, which 
> is only created and configured when the 
> SecurityTokenServiceServerBinding object is configured.  This 
> hinders the scenario described in the previous paragraph.  To better
> accommodate this scenario, we would like to suggest the following 
changes:
> 
> 1) Allow the private static SecurityTokenService member in the 
> SecurityTokenServiceServerBinding class to be populated from a 
> constructor or a setter method. 
> 
> 2. When the SecurityTokenServiceServerBinding.configur() method is 
> called, if the SecurityTokenService member is non-null, don't create
> it OR configure it -- right now if it is non-null, you won't create 
> it, but you stlll initialize and configure it.
> 
> 3) Allow the ISecurityTokenService object to be configured 
> independent of the SecurityTokenServiceServerBinding object. -- It 
> appears that the configure method on the 
> SecurityTokenServiceServerBinding class is mostly doing work to 
> configure the ISecurityTokenService object anyway.  It seems like it
> would be appropriate to move nearly all of that code into 
> ISecurityTokenService class.
> 
> Are we overlooking some key thing here?  Are there reasons you have 
> done it in this particular way that we have not taken into account? 
> -- I guess we're just trying to get a little bit cleaner separation 
> between the SecurityTokenServiceServerBinding class and the 
> ISecurityTokenService class.

No good reason, I had not thought of this use case that now seems obvious.
I will think about this on the plane. I am leaning toward #1 of the 
alternatives above.

> 
> Thank you,
> 
> Daniel Sanders
> 
> 
> 
> Daniel Sanders
> Software Engineer
> dsanders@xxxxxxxxxx
> 801-861-4193
> 
> Novell, Inc.
> SUSE* Linux Enterprise 10
>  Your Linux is ready*
>  www.novell.com/linux
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev