| Re: [higgins-dev] Another STS Request |
|
I was under the (perhaps incorrect) assumption that one could implement some kind of IDOMDocument interface. Doing this would allow the source to be XML or set as component data -- avoiding any conversion to/from XML. >>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/27/07 12:50 PM >>> The approach you suggest - bolting on an additional layer to hide XML-isms - has as its goal developer convenience. While we certainly want that, that is not all we were looking at when we made this proposal. We're not in a hurry for the "quick fix." It is our opinion that XML DOM is not only an "inconvenient" way to set up a RequestSecurityToken object, it is also not the most optimal way. We believe that XML DOM should be an "outer" representation - one of many perhaps - from which you MAY build a RequestSecurityToken object, but it should not be the "inner" representation because it is not the most optimal. It is not optimal to start with a perfectly good Java type, convert it to XML, and then later on convert it back from the XML to the perfectly good Java type that you really wanted. Just hiding all of the XML-isms from a developer is not our only goal.
Daniel
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 2/27/2007 11:21 AM >>> Here's another option:
If the existing interface takes a DOM, we could build a "helper" class which presents the get/set methods you describe below, and also implements a DOM document interface. So it's essentially a specific DOM object with get/set methods to make life easy for non-XML cases.
Jim
>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/27/07 9:25 AM >>> Mike,
In discussions yesterday with a developer here at Novell who is using the STS, he made another request for some changes that I thought were reasonable. I thought I would put the request to the dev-list so that it would be documented. This is one that, if you feel ok about, I would be happy to work on and submit a change (when I get some time).
The request is this:
He proposes that the IRequestSecurityToken interface be modified so that instead of passing DOM nodes to/from the various setter/getter methods, we pass higher level types - so that we don't have to set up XML DOM nodes to use the interface. He would like to use the RequestSecurityToken class (which implements the interface) independent of XML. He recognizes that much of the time an RST message will come into the STS as XML, and so it is very important to have code that parses the XML and creates a RequestSecurityToken object. However, he suggests that it be helper code, not intricately woven into the RequestSecurityToken class or the IRequestSecurityToken interface. He has a case where his RST message will be generated by policy as opposed to an explicit XML message. Yes, he could generate an XML message, but it would be much more convenient if he could simply instantiate the RequestSecurityToken object directly and populate it in a more "natural" way than by having to create XML DOM nodes.
So he proposes that all of the code which parses an XML RST be made helper code that creates the "right" kinds of types to be passed into the RequestSecurityToken object. For example:
setClaims/getClaims - passes/returns an IElement, which is then parsed into an array of claims (java.util.ArrayList) later in the IssueHandler.java code. This would be more convenient if the ArrayList object could be passed instead of the XML IElement node, and move the parsing code currently in IssueHandler.java to the BindingHelper.java code.
Other setters/getters could be similarly changed.
Any thoughts? suggestions?
Thank you,
Daniel
|