RE: [provision] Liberty Identity Personal Profile example...

["Jeff Bohren" <jbohren@opennetwork.com>]

Matthias,

I don't think any existing provisioning systems require a batch request
to group logically related operations. The batch request has been
discussed in several respects:

1) As a means of organizing mutlitple requests in a single SPML file in
the SPML File Binding. In the SPML File Binding, and SPML File can only
contain a single request which is either a batch request containing
other requests or an atomic request (add, modify, delete).

2) As a convenience to group requests that are not logically related,
but are grouped together for other reasons. I personally don't find this
very useful, but others have expressed the desired to do this to
simplify things like billing and reporting.

3) As means for grouping logically related request. The complex example
is once reason you might want to do this. Another case where you might
want to do this is to support transactions on a set of operations, such
as removing a group of accounts, including the group itself. When we add
support for complex data types in the post SPML 1.0 effort, then there
would be less value in using batch requests to support complex data
types. 

Since the SPML interface in our product is fairly simple, it supports
batch requests, but treats each request in the batch as if it was made
independently. So in our case we support it, but don't require it.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 


-----Original Message-----
From: Matthias Leibmann [mailto:mattleib@microsoft.com] 
Sent: Tuesday, August 05, 2003 12:32 AM
To: Jeff Bohren; Jeff Larson; Gearard Woods
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Liberty Identity Personal Profile example...


I would like to understand what provisioning systems require a <batch />
construct to group logical related operations in a <request />
operation. Can anybody elaborate on this?

Thx, Matthias
////////////////////////////////////////////
Matthias Leibmann
Program Manager
Microsoft Identity Integration Server

mailto:mattleib@microsoft.com
This posting is provided "AS IS" with no warranties, and confers no
rights. 
////////////////////////////////////////////


-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com] 
Sent: Thursday, July 31, 2003 6:15 PM
To: Jeff Larson; Gearard Woods
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Liberty Identity Personal Profile example...

Jeff,
 
I think you are misinterperting the whole purpose of the batch request.
The only reason that you would use a batch request would be to group
logically related operations. While this is implementation dependent, I
would think that a batch request going through workflow would be
approved or denied as a whole. If operations or not logically related
then they should be independent requests.
 
I am not a Liberty expert, but looking at the spec for the Personal
Profile, it is very clearly LDAP oriented (or X.500 oriented). It would
seem that a hierachical model would fit it quite well. But there are
many solutions to this problem in addition to the ones I posted.
 
I do see a lot of value in adding explicit support for complex data
types in the post 1.0 effort. Rami has made some interesting suggestions
and I have some ideas on my own. The only requirement that I would make
is that whatever approach we adopt can support reliable mamagement of
the complex data. Obviously the Liberty group did not feel that was
important since thier spec explicitly says that thier protocol does not
support that.
 
Jeff Bohren
OpenNetwork Technologies
 
 

	-----Original Message----- 
	From: Jeff Larson [mailto:Jeff.Larson@waveset.com] 
	Sent: Thu 7/31/2003 4:29 PM 
	To: Gearard Woods; Jeff Bohren 
	Cc: provision@lists.oasis-open.org 
	Subject: RE: [provision] Liberty Identity Personal Profile
example... 
	
	


	Sorry I haven't had time to remain current on this topic.  I
don't
	have anything to say on the schema representation debate right
now,
	but I did want to comment on the recent examples attempting to
	represent complex data types.
	
	I dislike the notion of describing what will usually be
considered an
	atomic operation on a single object as a batch of SPML requests.
For
	starters, any PSP more complex than a directory will likely
incur a
	substantial amount of overhead processing an add or modify
request so
	you don't want to treat these like discrete transactions even
though
	the end result may be the same.  It is not uncommon to require
	workflow approvals on any modification, this approach could
result in
	multiple approvals.
	
	So now, the PSP has to analyze every batch to determine which
requests
	can be semantically merged into a single transaction.  Batch
execution
	mode better not be sequential.  A similarly complex inverse
	transformation then needs to be performed to make what
internally was
	a single transaction appear as multiple responses in the batch
	response.
	
	Regarding the Hierarchical method:
	
	It isn't obvious to me how the DN-like <spml:id>'s work to
identify
	subcomponents, but I'll assume that's due to my relative lack of
LDAP
	experience.  I don't especially like the data duplication
though.
	
	Regarding the Referential method:
	
	This looked more obvious to me than the Hierarchical method, but
I
	would NOT want to be required to retain these GUIDs for later
	identification of the interior objects.  Again I would expect
many
	PSPs that aren't implemented on directories are going to have
problems
	maintaining GUIDs for things that are not "first class" objects
in
	their database model.
	
	But if the GUIDs aren't retained, how do I issue a modifyRequest
to
	change just the AltCN attribute?
	
	
	While I'm not necessarily suggesting this as a solution, Waveset
	solves very similar problems by flattening a complex
hierarchical data
	model into a list of attributes whose names are "paths" into the
	hierarchy.  Our path syntax is non-standard, but for the sake of
	example,
	the little XML document would be exposed using the following
	attribute names:
	
	     InformalName
	     CommonName.CN
	     CommonName.AltCN
	     LegalIdentity.LegalName
	     LegalIdentity.VAT
	
	We're using this approach right now to squeeze extremely complex
	hierarchical objects through SPML.  We use the same technique to
edit
	these objects in a web GUI.  HTML forms post a flat list of
name/value
	pairs, you have the same problem.
	
	Yes, it is cumbersome.  I would really prefer complex data types
in
	SPML, but this does work and I would choose it over the previous
two
	methods because it maintains the atomicity of the request.
	
	I think we should continue exploring the consequences of
introducing
	complex data types into SPML.  I just wanted to point out what I
think
	is a simpler way to make complex data appear flat.
	
	Regards,
	Jeff