Issue 15023: Explicit or implicit transaction model is needed (rms-ftf) Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com) Nature: Uncategorized Issue Severity: Summary: Our current service model often requires numerous operations to accomplish a task which must be completed or else the repository will be inconsistent. The task of setting aside a record, for example, is not a single operational call. Should connection be lost between the client server, or any operation fail, the repository can be left in an inconsistent state. This violates one of RMS original design principles Resolution: Revised Text: Actions taken: February 2, 2010: received issue Discussion: End of Annotations:===== s is issue # 15023 Explicit or implicit transaction model is needed Our current service model often requires numerous operations to accomplish a task which must be completed or else the repository will be inconsistent. The task of setting aside a record, for example, is not a single operational call. Should connection be lost between the client server, or any operation fail, the repository can be left in an inconsistent state. This violates one of RMS original design principles From: "Larry L. Johnson" To: Subject: Issue 15023 - Explicit or implicit transaction model is needed. Date: Tue, 28 Dec 2010 04:23:30 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcumcJp+WNUO3DR5RL2lbLvuzpuy7Q== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - capricorn.lunarpages.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tethersend.com X-Source: X-Source-Args: X-Source-Dir: Concerning the transaction approaches. The .or. in the issue title has dumbfounded us, I.m afraid. I think we need both the ability to manage a transaction from a client as well as not, i.e., we need both options. Can we create an abstraction of all operations so that each carries with it the originating xactID & partyID for every request? I had some other attributes in mind though they escape me at the moment. Though not .it. I was thinking also of such things as a dateTime stamp that could be used for metrics. The partyID is needed for ACL control as well as selecting attribute profiles, policy & rule sets, provenance etc. This ability will be essential for shared service environments. Can we then allows the xactID to be optional/null for some operations? This latter set of operations would be complex operations that must complete in whole or not at all. 1.) This would provide .macro. operations that do .customary. units of work without a lot of chit-chat on the network. .One call does it all.. (In PDM Enablers which was essentially an RMS on steroids, Version 1 had the .micro operations. which the client had to knit together to do something useful. It was our undoing. it took too long to get .usual. work done. We devised the .macro operations. for V2, but it was too late. The market collapsed (not being a harbinger here. I don.t think we.re in that situation yet.). I.m thinking of these as primarily .set-aside. centric operations, though environment side operations could also be useful. 2.) It would allow a sophisticated client to start a transaction and use the micro-operations to knit together functionality that accomplishes things that are not anticipated architecturally at the macro level. I.m thinking primarily of records administrator tools that needs to fix things that have gone awry, or do not happen often. We don.t need to worry about retrieval/queries. there is no danger in the database being left inconsistent except on creations/updates. The client simply needs to know if the response is everything it requested. We can establish one or more compliance points (however many make sense) in V2 to enumerate the operations for which the xactID is optional (though it may be used in a xaction stream if required.). Admittedly, the .captureRecordInToto. operation would have a complex argument set, but no more than what is required to do it in pieces. and it would be done without the chit-chat. I remember that we discussed establishing an abstract operation off of which all others are derived that might be useful to effect this (compliments of SoaML). Is that still possible with the model we have now (extended of course)? I.m fairly sure the answer is .yes., but it.s been a while since we discussed it. Regards, Larry Larry L. Johnson TethersEnd Consulting 2023 Cleveland St Clearwater FL 33765-3107 US: 888-502-9847 Intl: +1-202-449-5637 http://www.TethersEnd.com/ From: "John C. Butler" To: "'Larry L. Johnson'" Cc: Subject: RE: Issue 15023 Date: Wed, 5 Jan 2011 11:16:14 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcumcJp+WNUO3DR5RL2lbLvuzpuy7QGfGPSQ I agree I think we need to address these issues. More comments below. From: Larry L. Johnson [mailto:larry.johnson@tethersend.com] Sent: Tuesday, December 28, 2010 4:24 AM To: RMS-RTF@omg.org Subject: Issue 15023 - Explicit or implicit transaction model is needed. Concerning the transaction approaches. The .or. in the issue title has dumbfounded us, I.m afraid. I think we need both the ability to manage a transaction from a client as well as not, i.e., we need both options. While I might agree we need both, I don.t think we need to provide client side transaction control for RMS users. I think that may be asking for trouble. It would have to be an RME client that was trusted IMO. Can we create an abstraction of all operations so that each carries with it the originating xactID & partyID for every request? I had some other attributes in mind though they escape me at the moment. Though not .it. I was thinking also of such things as a dateTime stamp that could be used for metrics. The partyID is needed for ACL control as well as selecting attribute profiles, policy & rule sets, provenance etc. This ability will be essential for shared service environments. My guess is that we would update the messages (aka parameters) of the operations and add those elements to the definition of the parameters. The bigger picture is that we.re now coming back to adding this stuff back in when we had decided it should be part of the infrastructure. I need to do more research on this but from the little I.ve done, there definitely seems to be a void in .best practice. on the transaction and security topics. Can we then allows the xactID to be optional/null for some operations? This latter set of operations would be complex operations that must complete in whole or not at all. I assume these would be operations that might call other operations that might need an xactID but wouldn.t itself. 1.) This would provide .macro. operations that do .customary. units of work without a lot of chit-chat on the network. .One call does it all.. (In PDM Enablers which was essentially an RMS on steroids, Version 1 had the .micro operations. which the client had to knit together to do something useful. It was our undoing. it took too long to get .usual. work done. We devised the .macro operations. for V2, but it was too late. The market collapsed (not being a harbinger here. I don.t think we.re in that situation yet.). I.m thinking of these as primarily .set-aside. centric operations, though environment side operations could also be useful. actually, since the smaller calls still have to be made (though not by the client) it may not have much impact on the .chit-chat. since that may still happen on the provider side behind the scenes. The only way to avoid it would be to mandate an all inclusive implementations and I don.t think that.s appropriate. 2.) It would allow a sophisticated client to start a transaction and use the micro-operations to knit together functionality that accomplishes things that are not anticipated architecturally at the macro level. I.m thinking primarily of records administrator tools that needs to fix things that have gone awry, or do not happen often. yes, agree on the RA functionality but not sure this is the place to put that. We don.t need to worry about retrieval/queries. there is no danger in the database being left inconsistent except on creations/updates. The client simply needs to know if the response is everything it requested. We can establish one or more compliance points (however many make sense) in V2 to enumerate the operations for which the xactID is optional (though it may be used in a xaction stream if required.). Yes, though again, may not want any optional XA in this spec. Admittedly, the .captureRecordInToto. operation would have a complex argument set, but no more than what is required to do it in pieces. and it would be done without the chit-chat. Again, only resolves it between the client and that service. If the services are implemented independently then it.s no better. Admittedly, that.s probably the way they.ll be implemented initially. I remember that we discussed establishing an abstract operation off of which all others are derived that might be useful to effect this (compliments of SoaML). Is that still possible with the model we have now (extended of course)? I.m fairly sure the answer is .yes., but it.s been a while since we discussed it. Need to discuss more. Not sure I.m following your reference here. I think what it would come down to is an abstract message type that includes these elements and then is specialized to add specific elements for specific calls. Regards, Larry Larry L. Johnson TethersEnd Consulting 2023 Cleveland St Clearwater FL 33765-3107 US: 888-502-9847 Intl: +1-202-449-5637 http://www.TethersEnd.com/