OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Transactional integrity & the XDI protocol (was Re: [xdi] [External] Connection)


I agree with Michael.  Complexity at this point is something to avoid or, at least, put off. 

--phil--

Phillip J. Windley, Ph.D.
www.windley.com
www.kynetx.com
=windley

Download my new whitepaper: 
From Personal Computers to Personal Clouds
http://www.windley.com/cloudos




On Jul 9, 2012, at 10:11 AM, Michael Schwartz wrote:


Drummond,

I don't think we should implement transactions in XDI 1.0. LDAP has lived without transactions for 20 years and not been too much the worse for it. Transactional persistence is the domain on SQL databases right now. Also, nothing would stop an XDI server vendor from implementing transactions, and once the data exists that define the best practices, we define standards at a later time. I just don't think its on the critical must-have features.

Note: I do think that XDI servers should be transactional with regard to single operations!

I thought Yuriy Zabrovarnyy might have some thoughts on this... here they are:

Untill now we agreed on the rules that are described here:
 - https://wiki.oasis-open.org/xdi/XdiMessagePatterns
 - https://wiki.oasis-open.org/xdi/MessagingErrorCode

The rules are:
 a) all operations are independent even if they come in one message.
 b) if one operation is failed then further operation execution is
    stopped and error is send with actual problem and
    statement where problem occurs. More info on the OX wiki
    http://ox.gluu.org/doku.php?id=docs:graphoperations

Example: Lets say we have three operations. Two of them are successfully executed and the last one fails. The error is sent to the client but the two successfully executed operation are NOT ROLLED BACK. c) operations are executed in order they appears in the message request (accept $add operation where sorting is made on server to provide correct execution + variable support)

3. CURRENT oxServer IMPLEMENTATION
Some time ago i've already investigated question about transaction support with LDAP. And problem is that OpenDJ does not provide such feature. There are only one more or less good implementation provided by UnboundID, see http://www.dirmgr.com/blog/2009/4/6/transactions-in-the-unboundid-directory-server.html.

- Mike



-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
office: +1 646-810-8761
mike@gluu.org

On Mon, 9 Jul 2012, Drummond Reed wrote:

Joseph, my intuition is that your intuition is right ;-)

Seriously, it keeps coming up that we need enough transaction integrity
semantics in the XDI protocol so that clients can unambiguously ask a
server to do what the client wants, and servers can unambiguously know how
to tell a client what messages/operations worked and what didn't. In other
words, accurate, unambiguous communication of state.

Since in XDI every operation request in every message is a state change
(even a $get is a state change if it is logged), then maybe we just need to
bite the bullet and apply the multiplicity patterns to XDI messaging. The
basic rules would be:

 1. A single message with a single operation would not need
 any transaction integrity semantics - the message either succeeds or fails,
 and the message ID already identifies the message. However the server may
 need to return the message ID in the response.
 2. A single message with a collection of operations would need to order
 the operations using ordinal statements. The server performs the operations
 in order. If an operation fails, the whole message fails, and the server
 sends back the full XDI statement of the operation that failed (because
 that XDI statement is already unique).
 3. A collection of messages (whether with single operations or
 collections of operations) would need to:
    1. Order the messages so the server can perform them in order.
    2. Include basic commit/rollback semantics for message collections.

If you agree, then we should put together a formal proposal for this so we
can start discussing it.

=Drummond

On Sat, Jul 7, 2012 at 4:50 PM, Joseph Boyle <planetwork@josephboyle.net>wrote:


On Jul 6, 2012, at 6:53 AM, Barnhill, William [USA] wrote:

I propose that rather than deciding which methods to explicitly support,
we instead create a generic authentication mechanism, i.e. something like
SASL.  If XDI messaging were a connection-oriented protocol then I would
suggest an XDI binding of the SASL abstraction layer.  However, to my
knowledge XDI messaging has always been, and is intended to remain, a
connectionless protocol (or more precisely a message-oriented protocol).


I strongly feel that it will turn out to be advantageous to maintain
connections, and that we should anticipate this. I realize we want to get
the simplest case (no connection, minimal HTTP methods/codes, minimal
authentication) out the door quickly, but can we give this a little thought
now? It may be as simple as numbering messages and responses so that the
client knows which response was to which message, or only sending responses
in order received. Is it clear where a message ends - do we have a clear
end of message marker?





---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]