Issue 3917: OTS RTF --EDITORIAL? (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, nobody) Nature: Uncategorized Issue Severity: Summary: c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a per/request basis and states on page 10-5 "The Transaction Service does not require that all requests have the same behavior even when issued in the scope of a transaction. An object can choose to not support transactional behavior, or to support transactional behavior for some request but not others". Recommendation - this should merely be an editoral change to clean up the text unless someone sees some reason otherwise. The suggestion would be that the sentence just be deleted. Resolution: Revised Text: Actions taken: September 27, 2000: received issue Discussion: End of Annotations:===== From: TJFREUND@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.93) with SMTP id JAA153584; Wed, 27 Sep 2000 09:10:40 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256967.002CEB37 ; Wed, 27 Sep 2000 09:10:37 +0100 X-Lotus-FromDomain: IBMGB To: blakeb@gemstone.com cc: ots-rtf@omg.org Message-ID: <80256967.002CEA32.00@d06mta10.portsmouth.uk.ibm.com> Date: Wed, 27 Sep 2000 09:08:17 +0100 Subject: OTS/RTF - Additional issues Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: M^O!!cold90N7e9@F"e9 Blake, Just so these issues don't get lost would you please enter the following three issues again the OTS specification & add them to the unresolved list: c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a per/request basis and states on page 10-5 "The Transaction Service does not require that all requests have the same behavior even when issued in the scope of a transaction. An object can choose to not support transactional behavior, or to support transactional behavior for some request but not others". Recommendation - this should merely be an editoral change to clean up the text unless someone sees some reason otherwise. The suggestion would be that the sentence just be deleted. From: Jeffrey Mischkinsky Message-Id: <200009272151.OAA24915@wheel.dcn.davis.ca.us> Subject: Re: OTS/RTF - Additional issues To: blakeb@gemstone.com (Blake Biesecker) Date: Wed, 27 Sep 2000 14:51:52 -0700 (PDT) Cc: TJFREUND@uk.ibm.com, ots-rtf@omg.org In-Reply-To: <20000927140514.B549@gemstone.com> from "Blake Biesecker" at Sep 27, 2000 02:05:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KKSd94&/!!4n2e9T(?!! Hang on a second. Haven't we already been over the ground that these issues cover? I understand that IBM voted NO because it didn't like the proposed resolution. If you insist, then you can of course have the issues created. But I would suggest that the proper action (which I think is purely administrative one) should be close, no action, already discussed and voted upon. jeff 'Blake Biesecker' writes: > > Thanks for the summaries. Juergen, could you please open three > issues based on Tom's email below. As soon as the report is > filed, I'll put out a voting schedule. I'd like to have regular > votes every two weeks until Orlando since we got so side tracked > on issue 3425. > > Tom, are you interested in writing up proposals for these issues? > > Blake > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > Blake, > > > > Just so these issues don't get lost would you please enter the following > > three issues again the OTS specification & add them to the unresolved list: > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > OTSPolicy should allow for such a client-side optimization but make the > > check optional at the client without making it a requirement. > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > always propagate context) to OTS1.2 server interoperability by adding the > > addition of the PERMITS/PREVENTS check rather than only performing a check > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested this > > might be part of the NonTxTargetPolicy discussion. As long as that > > discussion includes both client and server side checking that's would be > > fine with me.) > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > per/request basis and states on page 10-5 "The Transaction Service does not > > require that all requests have the same behavior even when issued in the > > scope of a transaction. An object can choose to not support transactional > > behavior, or to support transactional behavior for some request but not > > others". Recommendation - this should merely be an editoral change to clean > > up the text unless someone sees some reason otherwise. The suggestion would > > be that the sentence just be deleted. > > > > Regards, > > Tom, > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 08:35 > > --------------------------- > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > Please respond to TJFREUND@uk.ibm.com > > > > To: Edward Cobb > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > Freund/UK/IBM) > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > Ed, > > > > I'm surprized you would make such a statement ... IBM did NOT vote against > > Interoperability - we voted AGAINST 3425. The directions in the vote were > > "to vote for or against the text 'exactly' as stated in the document". I > > understand the urgency of reaching closure on Issue 3425 considering the > > schedule for inclusion in J2EE - however I do not feel that this pressure > > should force out a proposal that is incomplete. As such I logged the > > objections that I currently had with the proposal/text, if these were > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > proposal. These comments reflected the consensus of the IBM development > > community. Here are my clarifications and suggestions for the improvements > > (see below ... . > > > > Regards, > > Tom > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > Please respond to Edward Cobb > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > cc: ots-rtf@omg.org > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on this > > initiative to enable transactional interoperability for J2EE especially > > after being so intrumental in getting RMI semantics added to IIOP in the > > first place, but I will make some comments on your objections below. > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > >additional problems exist in the text which IBM considers as major > > >objections --- > > > > > >a.) The proposal does not resolve the inconsistency with the base document > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > >per/request basis (the proposal would require all methods on an object > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 states > > >"The Transaction Service does not require that all requests have the same > > >behavior even when issued in the scope of a transaction. An object can > > >choose to not support transactional behavior, or to support transactional > > >behavior for some request but not others". > > > > First of all, inheritance is at the object level, not the operation level > > as are the policy definitions, so nothing has really changed. The original > > submitters of the OTS document abandoned operation level declarations > > because it led to a large number of permutations of otherwise equivalent > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > from transactional object (which was originally called ALLOWS) permitted > > the object to use or abuse the active transaction as it saw fit, so one > > operation could choose to use it while another could be transaction > > agnostic. Even thought the ALLOWS behavior was dropped in the latest round > > of changes, one can argue that the text you refer to is still true with the > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS can > > be used for all EJB (or CCM) objects, regardless of how the operation level > > policies are set in the transaction descriptor. > > > > *************************** > > What I was attempting to point out was that there were additional > > modifications that are required in the baseline OTS specification. The > > recommendation is fairly straight-forward & would remove the text on page > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > behavior for a client-server instance (however it does allow for other > > instances an object to run with a differing policy). > > *************************** > > > > >b.) The proposal requires implementation of client-side checks, checking > > at > > >the client should be optional and not mandatory. The proposal should only > > >specify policy 'behavior' and thereby allow an implementation to implement > > >the check anywhere in the 'invocation path', i.e. it should be sufficient > > >to perform these checks server-side. (Throughout the document pgs. 10-1, > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > >3425.10, 3425.13, 3425.16) > > > > Client-side checks are required for certain combinations, because they must > > be detected before an invocation is made and therefore cannot be done on > > the server side. The most glaring example is routed invocations where only > > the client can detect policy mismatches. Client-side checks are also > > essential to guarantee that transactions will never be exported to an > > environment which may be unsafe. As documented in the initial notes on page > > 10-1, these assumptions were agreed to in Burlingame. > > > > *************************** > > To clarify - this objection relates only to OTSPolicy (not to the > > InvocationPolicy). Having separated the policies, it is has always been > > agreed that the InvocationPolicy is a required client-side check. However > > the OTSPolicy check can be performed either at the client or server. It > > should not be a mandatory client-side check & client-side checking should > > be an implementation option/optimization. > > *************************** > > > > >c.) The proposal does not support interoperability between OTS1.1 clients > > & > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > >removed the PREVENT/PERMITS checking). > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > *************************** > > The issue outlined above is different from that contained in the > > voting direction - the voting directions merely state the debate is over > > establishing a default for the NonTxTargetPolicy. The issue stated above > > regards the specifics checking that is done at the server. By removing the > > check in the lastest version of the proposal - the proposal no longer > > supports interoperability between an OTS1.1 client (that propagates > > context) and an OTS1.2 server. Such interoperability can be listed as a > > restriction - however as stated previously the IBM's implementation is one > > that unconditionally propagates. > > *************************** > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > >part of the EJB specification. > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put it > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > such a specification. That means that OTS 1.1 is the official spec of > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > document. Since most of them have to do which client-side checking and the > > splitting of the old TransactionPolicy into two, this proposal (or > > something very close to it) is a necessary pre-requisite. > > > > *************************** > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > attempting replace something that's "unimplementable" - I'm just trying to > > make sure we've at least visited issues which may have been overlooked > > during the previous review cycles. It's not an easy problem - and getting > > the policy stuff right is certainly a bit frustrating at times. But I think > > we are getting there & I do appreciate all the work you've done on this. > > > > *************************** > > > > > >Regards, > > >Tom > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > >Please respond to Andrew Watson > > > > > >To: Edward Cobb > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > >Ed, > > > > > >You wrote: > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly to > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes that > > >takes it into account. Please could everyone ignore the previous note, and > > >vote in reply to this call (and apologies for the confusion). > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > >described in his document 092100: > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > stated in the document. > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated in > > > the document, excluding the single sentence on page 10-12 reading > > >"If > > > a NonTxTargetPolicy policy object is not established by the client, > > > the OTS 1.2 implementation will default to PREVENT". > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not to > > >require that the policy value always be set explicitly (i.e. no default). > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > >ignore the result of the less-specific 3425b. However, if 3425a fails and > > >3425b passes, we can produce a partial specification that J2EE > > implementors > > >can work from, while allowing the RTF more time to discuss the correct > > >NonTxTargetPolicy default. > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote on > > >either proposal that introduces other options ("I would vote FOR if is > > >changed to .") will count as a vote AGAINST that motion. > > > > > >It seems that the voting list I sent out last time is out of date, but > > >unfortunately it's the most up-to-date one that OMG staff has. Blake has > > >the most recent list, and since he'll be counting the votes on Monday, > > this > > >should all come out in the wash. People who are no longer voting members > > of > > >the RTF presumably know it already. > > > > > >BTW, please note that our mail server will be off the air for a few hours > > >on Saturday morning, EDT, because they're cutting the power to our > > >building. > > > > > > Thanks, > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > Ed Cobb, Vice President, Advanced Technology & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 > > E-mail: ed.cobb@beasys.com > > ************************************************************** > > > > > > > > > > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: "Eric Newcomer" To: "Jeffrey Mischkinsky" , "Blake Biesecker" Cc: , Subject: RE: OTS/RTF - Additional issues Date: Wed, 27 Sep 2000 18:23:03 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009272151.OAA24915@wheel.dcn.davis.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: kBCe9/VL!!`<0e9 > Thanks for the summaries. Juergen, could you please open three > issues based on Tom's email below. As soon as the report is > filed, I'll put out a voting schedule. I'd like to have regular > votes every two weeks until Orlando since we got so side tracked > on issue 3425. > > Tom, are you interested in writing up proposals for these issues? > > Blake > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > Blake, > > > > Just so these issues don't get lost would you please enter the following > > three issues again the OTS specification & add them to the unresolved list: > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > OTSPolicy should allow for such a client-side optimization but make the > > check optional at the client without making it a requirement. > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > always propagate context) to OTS1.2 server interoperability by adding the > > addition of the PERMITS/PREVENTS check rather than only performing a check > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested this > > might be part of the NonTxTargetPolicy discussion. As long as that > > discussion includes both client and server side checking that's would be > > fine with me.) > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > per/request basis and states on page 10-5 "The Transaction Service does not > > require that all requests have the same behavior even when issued in the > > scope of a transaction. An object can choose to not support transactional > > behavior, or to support transactional behavior for some request but not > > others". Recommendation - this should merely be an editoral change to clean > > up the text unless someone sees some reason otherwise. The suggestion would > > be that the sentence just be deleted. > > > > Regards, > > Tom, > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 08:35 > > --------------------------- > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > Please respond to TJFREUND@uk.ibm.com > > > > To: Edward Cobb > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > Freund/UK/IBM) > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > Ed, > > > > I'm surprized you would make such a statement ... IBM did NOT vote against > > Interoperability - we voted AGAINST 3425. The directions in the vote were > > "to vote for or against the text 'exactly' as stated in the document". I > > understand the urgency of reaching closure on Issue 3425 considering the > > schedule for inclusion in J2EE - however I do not feel that this pressure > > should force out a proposal that is incomplete. As such I logged the > > objections that I currently had with the proposal/text, if these were > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > proposal. These comments reflected the consensus of the IBM development > > community. Here are my clarifications and suggestions for the improvements > > (see below ... . > > > > Regards, > > Tom > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > Please respond to Edward Cobb > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > cc: ots-rtf@omg.org > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on this > > initiative to enable transactional interoperability for J2EE especially > > after being so intrumental in getting RMI semantics added to IIOP in the > > first place, but I will make some comments on your objections below. > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > >additional problems exist in the text which IBM considers as major > > >objections --- > > > > > >a.) The proposal does not resolve the inconsistency with the base document > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > >per/request basis (the proposal would require all methods on an object > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 states > > >"The Transaction Service does not require that all requests have the same > > >behavior even when issued in the scope of a transaction. An object can > > >choose to not support transactional behavior, or to support transactional > > >behavior for some request but not others". > > > > First of all, inheritance is at the object level, not the operation level > > as are the policy definitions, so nothing has really changed. The original > > submitters of the OTS document abandoned operation level declarations > > because it led to a large number of permutations of otherwise equivalent > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > from transactional object (which was originally called ALLOWS) permitted > > the object to use or abuse the active transaction as it saw fit, so one > > operation could choose to use it while another could be transaction > > agnostic. Even thought the ALLOWS behavior was dropped in the latest round > > of changes, one can argue that the text you refer to is still true with the > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS can > > be used for all EJB (or CCM) objects, regardless of how the operation level > > policies are set in the transaction descriptor. > > > > *************************** > > What I was attempting to point out was that there were additional > > modifications that are required in the baseline OTS specification. The > > recommendation is fairly straight-forward & would remove the text on page > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > behavior for a client-server instance (however it does allow for other > > instances an object to run with a differing policy). > > *************************** > > > > >b.) The proposal requires implementation of client-side checks, checking > > at > > >the client should be optional and not mandatory. The proposal should only > > >specify policy 'behavior' and thereby allow an implementation to implement > > >the check anywhere in the 'invocation path', i.e. it should be sufficient > > >to perform these checks server-side. (Throughout the document pgs. 10-1, > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > >3425.10, 3425.13, 3425.16) > > > > Client-side checks are required for certain combinations, because they must > > be detected before an invocation is made and therefore cannot be done on > > the server side. The most glaring example is routed invocations where only > > the client can detect policy mismatches. Client-side checks are also > > essential to guarantee that transactions will never be exported to an > > environment which may be unsafe. As documented in the initial notes on page > > 10-1, these assumptions were agreed to in Burlingame. > > > > *************************** > > To clarify - this objection relates only to OTSPolicy (not to the > > InvocationPolicy). Having separated the policies, it is has always been > > agreed that the InvocationPolicy is a required client-side check. However > > the OTSPolicy check can be performed either at the client or server. It > > should not be a mandatory client-side check & client-side checking should > > be an implementation option/optimization. > > *************************** > > > > >c.) The proposal does not support interoperability between OTS1.1 clients > > & > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > >removed the PREVENT/PERMITS checking). > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > *************************** > > The issue outlined above is different from that contained in the > > voting direction - the voting directions merely state the debate is over > > establishing a default for the NonTxTargetPolicy. The issue stated above > > regards the specifics checking that is done at the server. By removing the > > check in the lastest version of the proposal - the proposal no longer > > supports interoperability between an OTS1.1 client (that propagates > > context) and an OTS1.2 server. Such interoperability can be listed as a > > restriction - however as stated previously the IBM's implementation is one > > that unconditionally propagates. > > *************************** > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > >part of the EJB specification. > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put it > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > such a specification. That means that OTS 1.1 is the official spec of > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > document. Since most of them have to do which client-side checking and the > > splitting of the old TransactionPolicy into two, this proposal (or > > something very close to it) is a necessary pre-requisite. > > > > *************************** > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > attempting replace something that's "unimplementable" - I'm just trying to > > make sure we've at least visited issues which may have been overlooked > > during the previous review cycles. It's not an easy problem - and getting > > the policy stuff right is certainly a bit frustrating at times. But I think > > we are getting there & I do appreciate all the work you've done on this. > > > > *************************** > > > > > >Regards, > > >Tom > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > >Please respond to Andrew Watson > > > > > >To: Edward Cobb > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > >Ed, > > > > > >You wrote: > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly to > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes that > > >takes it into account. Please could everyone ignore the previous note, and > > >vote in reply to this call (and apologies for the confusion). > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > >described in his document 092100: > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > stated in the document. > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated in > > > the document, excluding the single sentence on page 10-12 reading > > >"If > > > a NonTxTargetPolicy policy object is not established by the client, > > > the OTS 1.2 implementation will default to PREVENT". > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not to > > >require that the policy value always be set explicitly (i.e. no default). > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > >ignore the result of the less-specific 3425b. However, if 3425a fails and > > >3425b passes, we can produce a partial specification that J2EE > > implementors > > >can work from, while allowing the RTF more time to discuss the correct > > >NonTxTargetPolicy default. > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote on > > >either proposal that introduces other options ("I would vote FOR if is > > >changed to .") will count as a vote AGAINST that motion. > > > > > >It seems that the voting list I sent out last time is out of date, but > > >unfortunately it's the most up-to-date one that OMG staff has. Blake has > > >the most recent list, and since he'll be counting the votes on Monday, > > this > > >should all come out in the wash. People who are no longer voting members > > of > > >the RTF presumably know it already. > > > > > >BTW, please note that our mail server will be off the air for a few hours > > >on Saturday morning, EDT, because they're cutting the power to our > > >building. > > > > > > Thanks, > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > Ed Cobb, Vice President, Advanced Technology & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 > > E-mail: ed.cobb@beasys.com > > ************************************************************** > > > > > > > > > > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 27 Sep 2000 16:02:43 -0700 From: Blake Biesecker To: Jeffrey Mischkinsky Cc: TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: OTS/RTF - Additional issues Message-ID: <20000927160243.C669@gemstone.com> References: <20000927140514.B549@gemstone.com> <200009272151.OAA24915@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <200009272151.OAA24915@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Wed, Sep 27, 2000 at 02:51:52PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: E!+e9\Fbd9\nnd9)]C!! I must admit that I just skimmed the email as I'm distracted by the report. I assumed that these were new issues that I could look at later, but I think that these issues were resolved with Vote 5. Jeff is right in that we discussed client side checking behavior at length and the current compromise was passed by an overwhelming majority. My memory was that many would have preferred to avoid the client side checks, but everyone was convinced that they were necessary to ensure safe transactions. Opening new issues that simply ask us to revisit these issues is a waste of time. We've already voted on them. Tom, my assumption was that your issues were bringing up topics that we hadn't addressed, but a closer look indicates that these are 3425 sub-issues that have already been closed by the last vote. I'm not sure if we are required to give issue numbers to all issues submitted, so if possible, I think we shouldn't open issues on these points. If OMG rules demand that we do, we'll need to close them as duplicates of 3425. Tom, do you disagree that the 14-1 vote to pass the 3425 resolution didn't give a clear statement about the issues you outline below? Blake On Wed, Sep 27, 2000 at 02:51:52PM -0700, Jeffrey Mischkinsky wrote: > Hang on a second. > > Haven't we already been over the ground that these issues cover? > I understand that IBM voted NO because it didn't like the proposed resolution. > > If you insist, then you can of course have the issues created. > > But I would suggest that the proper action (which I think is purely > administrative one) should be close, no action, already discussed and voted > upon. > > jeff > > > 'Blake Biesecker' writes: > > > > Thanks for the summaries. Juergen, could you please open three > > issues based on Tom's email below. As soon as the report is > > filed, I'll put out a voting schedule. I'd like to have regular > > votes every two weeks until Orlando since we got so side tracked > > on issue 3425. > > > > Tom, are you interested in writing up proposals for these issues? > > > > Blake > > > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > Blake, > > > > > > Just so these issues don't get lost would you please enter the following > > > three issues again the OTS specification & add them to the unresolved list: > > > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > > OTSPolicy should allow for such a client-side optimization but make the > > > check optional at the client without making it a requirement. > > > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > > always propagate context) to OTS1.2 server interoperability by adding the > > > addition of the PERMITS/PREVENTS check rather than only performing a check > > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested this > > > might be part of the NonTxTargetPolicy discussion. As long as that > > > discussion includes both client and server side checking that's would be > > > fine with me.) > > > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > > per/request basis and states on page 10-5 "The Transaction Service does not > > > require that all requests have the same behavior even when issued in the > > > scope of a transaction. An object can choose to not support transactional > > > behavior, or to support transactional behavior for some request but not > > > others". Recommendation - this should merely be an editoral change to clean > > > up the text unless someone sees some reason otherwise. The suggestion would > > > be that the sentence just be deleted. > > > > > > Regards, > > > Tom, > > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 08:35 > > > --------------------------- > > > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > > > Please respond to TJFREUND@uk.ibm.com > > > > > > To: Edward Cobb > > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > > Freund/UK/IBM) > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > I'm surprized you would make such a statement ... IBM did NOT vote against > > > Interoperability - we voted AGAINST 3425. The directions in the vote were > > > "to vote for or against the text 'exactly' as stated in the document". I > > > understand the urgency of reaching closure on Issue 3425 considering the > > > schedule for inclusion in J2EE - however I do not feel that this pressure > > > should force out a proposal that is incomplete. As such I logged the > > > objections that I currently had with the proposal/text, if these were > > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > > proposal. These comments reflected the consensus of the IBM development > > > community. Here are my clarifications and suggestions for the improvements > > > (see below ... . > > > > > > Regards, > > > Tom > > > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > > > Please respond to Edward Cobb > > > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > > cc: ots-rtf@omg.org > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on this > > > initiative to enable transactional interoperability for J2EE especially > > > after being so intrumental in getting RMI semantics added to IIOP in the > > > first place, but I will make some comments on your objections below. > > > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > > >additional problems exist in the text which IBM considers as major > > > >objections --- > > > > > > > >a.) The proposal does not resolve the inconsistency with the base document > > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > > >per/request basis (the proposal would require all methods on an object > > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 states > > > >"The Transaction Service does not require that all requests have the same > > > >behavior even when issued in the scope of a transaction. An object can > > > >choose to not support transactional behavior, or to support transactional > > > >behavior for some request but not others". > > > > > > First of all, inheritance is at the object level, not the operation level > > > as are the policy definitions, so nothing has really changed. The original > > > submitters of the OTS document abandoned operation level declarations > > > because it led to a large number of permutations of otherwise equivalent > > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > > from transactional object (which was originally called ALLOWS) permitted > > > the object to use or abuse the active transaction as it saw fit, so one > > > operation could choose to use it while another could be transaction > > > agnostic. Even thought the ALLOWS behavior was dropped in the latest round > > > of changes, one can argue that the text you refer to is still true with the > > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS can > > > be used for all EJB (or CCM) objects, regardless of how the operation level > > > policies are set in the transaction descriptor. > > > > > > *************************** > > > What I was attempting to point out was that there were additional > > > modifications that are required in the baseline OTS specification. The > > > recommendation is fairly straight-forward & would remove the text on page > > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > > behavior for a client-server instance (however it does allow for other > > > instances an object to run with a differing policy). > > > *************************** > > > > > > >b.) The proposal requires implementation of client-side checks, checking > > > at > > > >the client should be optional and not mandatory. The proposal should only > > > >specify policy 'behavior' and thereby allow an implementation to implement > > > >the check anywhere in the 'invocation path', i.e. it should be sufficient > > > >to perform these checks server-side. (Throughout the document pgs. 10-1, > > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > > >3425.10, 3425.13, 3425.16) > > > > > > Client-side checks are required for certain combinations, because they must > > > be detected before an invocation is made and therefore cannot be done on > > > the server side. The most glaring example is routed invocations where only > > > the client can detect policy mismatches. Client-side checks are also > > > essential to guarantee that transactions will never be exported to an > > > environment which may be unsafe. As documented in the initial notes on page > > > 10-1, these assumptions were agreed to in Burlingame. > > > > > > *************************** > > > To clarify - this objection relates only to OTSPolicy (not to the > > > InvocationPolicy). Having separated the policies, it is has always been > > > agreed that the InvocationPolicy is a required client-side check. However > > > the OTSPolicy check can be performed either at the client or server. It > > > should not be a mandatory client-side check & client-side checking should > > > be an implementation option/optimization. > > > *************************** > > > > > > >c.) The proposal does not support interoperability between OTS1.1 clients > > > & > > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > > >removed the PREVENT/PERMITS checking). > > > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > > > *************************** > > > The issue outlined above is different from that contained in the > > > voting direction - the voting directions merely state the debate is over > > > establishing a default for the NonTxTargetPolicy. The issue stated above > > > regards the specifics checking that is done at the server. By removing the > > > check in the lastest version of the proposal - the proposal no longer > > > supports interoperability between an OTS1.1 client (that propagates > > > context) and an OTS1.2 server. Such interoperability can be listed as a > > > restriction - however as stated previously the IBM's implementation is one > > > that unconditionally propagates. > > > *************************** > > > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > > >part of the EJB specification. > > > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put it > > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > > such a specification. That means that OTS 1.1 is the official spec of > > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > > document. Since most of them have to do which client-side checking and the > > > splitting of the old TransactionPolicy into two, this proposal (or > > > something very close to it) is a necessary pre-requisite. > > > > > > *************************** > > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > > attempting replace something that's "unimplementable" - I'm just trying to > > > make sure we've at least visited issues which may have been overlooked > > > during the previous review cycles. It's not an easy problem - and getting > > > the policy stuff right is certainly a bit frustrating at times. But I think > > > we are getting there & I do appreciate all the work you've done on this. > > > > > > *************************** > > > > > > > >Regards, > > > >Tom > > > > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > > > >Please respond to Andrew Watson > > > > > > > >To: Edward Cobb > > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > >Ed, > > > > > > > >You wrote: > > > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly to > > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes that > > > >takes it into account. Please could everyone ignore the previous note, and > > > >vote in reply to this call (and apologies for the confusion). > > > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > > >described in his document 092100: > > > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > > stated in the document. > > > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated in > > > > the document, excluding the single sentence on page 10-12 reading > > > >"If > > > > a NonTxTargetPolicy policy object is not established by the client, > > > > the OTS 1.2 implementation will default to PREVENT". > > > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not to > > > >require that the policy value always be set explicitly (i.e. no default). > > > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > > >ignore the result of the less-specific 3425b. However, if 3425a fails and > > > >3425b passes, we can produce a partial specification that J2EE > > > implementors > > > >can work from, while allowing the RTF more time to discuss the correct > > > >NonTxTargetPolicy default. > > > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote on > > > >either proposal that introduces other options ("I would vote FOR if is > > > >changed to .") will count as a vote AGAINST that motion. > > > > > > > >It seems that the voting list I sent out last time is out of date, but > > > >unfortunately it's the most up-to-date one that OMG staff has. Blake has > > > >the most recent list, and since he'll be counting the votes on Monday, > > > this > > > >should all come out in the wash. People who are no longer voting members > > > of > > > >the RTF presumably know it already. > > > > > > > >BTW, please note that our mail server will be off the air for a few hours > > > >on Saturday morning, EDT, because they're cutting the power to our > > > >building. > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Advanced Technology & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > > > > > > > > > > > > > > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 Date: Wed, 27 Sep 2000 16:16:36 -0700 From: Blake Biesecker To: Eric Newcomer Cc: Jeffrey Mischkinsky , TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: OTS/RTF - Additional issues Message-ID: <20000927161636.D669@gemstone.com> References: <200009272151.OAA24915@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from eric.newcomer@iona.com on Wed, Sep 27, 2000 at 06:23:03PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Me`!!9B*e9]mpd98&Sd9 The difference I see is that the current text requires client side checks while it is silent about the default issue. I don't remember that we decided to defer discussions about allowing unconditional propoagation of tx context and allowing only server side checks. The proposal definitely doesn't indicate that. (Also, my memory might be incorrect, but isn't Bernard's position that client side checks are a good idea because it stops unnecessary propagation.) Blake On Wed, Sep 27, 2000 at 06:23:03PM -0400, Eric Newcomer wrote: > Just to note that a. and b. in IBM's list are basically the same as the ones > we also raised. We do not think these are resolved by the current text. We > think we agreed to postpone the discussion on them until after the vote. > Therefore they belong in the same category as the client side default policy > issue already on the table. > > > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 > > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Wednesday, September 27, 2000 5:52 PM > To: Blake Biesecker > Cc: TJFREUND@uk.ibm.com; ots-rtf@omg.org > Subject: Re: OTS/RTF - Additional issues > > Hang on a second. > > Haven't we already been over the ground that these issues cover? > I understand that IBM voted NO because it didn't like the proposed > resolution. > > If you insist, then you can of course have the issues created. > > But I would suggest that the proper action (which I think is purely > administrative one) should be close, no action, already discussed and voted > upon. > > jeff > > > 'Blake Biesecker' writes: > > > > Thanks for the summaries. Juergen, could you please open three > > issues based on Tom's email below. As soon as the report is > > filed, I'll put out a voting schedule. I'd like to have regular > > votes every two weeks until Orlando since we got so side tracked > > on issue 3425. > > > > Tom, are you interested in writing up proposals for these issues? > > > > Blake > > > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > Blake, > > > > > > Just so these issues don't get lost would you please enter the following > > > three issues again the OTS specification & add them to the unresolved > list: > > > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > > OTSPolicy should allow for such a client-side optimization but make the > > > check optional at the client without making it a requirement. > > > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > > always propagate context) to OTS1.2 server interoperability by adding > the > > > addition of the PERMITS/PREVENTS check rather than only performing a > check > > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested > this > > > might be part of the NonTxTargetPolicy discussion. As long as that > > > discussion includes both client and server side checking that's would be > > > fine with me.) > > > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > > per/request basis and states on page 10-5 "The Transaction Service does > not > > > require that all requests have the same behavior even when issued in the > > > scope of a transaction. An object can choose to not support > transactional > > > behavior, or to support transactional behavior for some request but not > > > others". Recommendation - this should merely be an editoral change to > clean > > > up the text unless someone sees some reason otherwise. The suggestion > would > > > be that the sentence just be deleted. > > > > > > Regards, > > > Tom, > > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 > 08:35 > > > --------------------------- > > > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > > > Please respond to TJFREUND@uk.ibm.com > > > > > > To: Edward Cobb > > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > > Freund/UK/IBM) > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > I'm surprized you would make such a statement ... IBM did NOT vote > against > > > Interoperability - we voted AGAINST 3425. The directions in the vote > were > > > "to vote for or against the text 'exactly' as stated in the document". I > > > understand the urgency of reaching closure on Issue 3425 considering the > > > schedule for inclusion in J2EE - however I do not feel that this > pressure > > > should force out a proposal that is incomplete. As such I logged the > > > objections that I currently had with the proposal/text, if these were > > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > > proposal. These comments reflected the consensus of the IBM development > > > community. Here are my clarifications and suggestions for the > improvements > > > (see below ... . > > > > > > Regards, > > > Tom > > > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > > > Please respond to Edward Cobb > > > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > > cc: ots-rtf@omg.org > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on > this > > > initiative to enable transactional interoperability for J2EE especially > > > after being so intrumental in getting RMI semantics added to IIOP in the > > > first place, but I will make some comments on your objections below. > > > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > > >additional problems exist in the text which IBM considers as major > > > >objections --- > > > > > > > >a.) The proposal does not resolve the inconsistency with the base > document > > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > > >per/request basis (the proposal would require all methods on an object > > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 > states > > > >"The Transaction Service does not require that all requests have the > same > > > >behavior even when issued in the scope of a transaction. An object can > > > >choose to not support transactional behavior, or to support > transactional > > > >behavior for some request but not others". > > > > > > First of all, inheritance is at the object level, not the operation > level > > > as are the policy definitions, so nothing has really changed. The > original > > > submitters of the OTS document abandoned operation level declarations > > > because it led to a large number of permutations of otherwise equivalent > > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > > from transactional object (which was originally called ALLOWS) permitted > > > the object to use or abuse the active transaction as it saw fit, so one > > > operation could choose to use it while another could be transaction > > > agnostic. Even thought the ALLOWS behavior was dropped in the latest > round > > > of changes, one can argue that the text you refer to is still true with > the > > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS > can > > > be used for all EJB (or CCM) objects, regardless of how the operation > level > > > policies are set in the transaction descriptor. > > > > > > *************************** > > > What I was attempting to point out was that there were additional > > > modifications that are required in the baseline OTS specification. The > > > recommendation is fairly straight-forward & would remove the text on > page > > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > > behavior for a client-server instance (however it does allow for other > > > instances an object to run with a differing policy). > > > *************************** > > > > > > >b.) The proposal requires implementation of client-side checks, > checking > > > at > > > >the client should be optional and not mandatory. The proposal should > only > > > >specify policy 'behavior' and thereby allow an implementation to > implement > > > >the check anywhere in the 'invocation path', i.e. it should be > sufficient > > > >to perform these checks server-side. (Throughout the document pgs. > 10-1, > > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > > >3425.10, 3425.13, 3425.16) > > > > > > Client-side checks are required for certain combinations, because they > must > > > be detected before an invocation is made and therefore cannot be done on > > > the server side. The most glaring example is routed invocations where > only > > > the client can detect policy mismatches. Client-side checks are also > > > essential to guarantee that transactions will never be exported to an > > > environment which may be unsafe. As documented in the initial notes on > page > > > 10-1, these assumptions were agreed to in Burlingame. > > > > > > *************************** > > > To clarify - this objection relates only to OTSPolicy (not to the > > > InvocationPolicy). Having separated the policies, it is has always been > > > agreed that the InvocationPolicy is a required client-side check. > However > > > the OTSPolicy check can be performed either at the client or server. It > > > should not be a mandatory client-side check & client-side checking > should > > > be an implementation option/optimization. > > > *************************** > > > > > > >c.) The proposal does not support interoperability between OTS1.1 > clients > > > & > > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > > >removed the PREVENT/PERMITS checking). > > > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > > > *************************** > > > The issue outlined above is different from that contained in the > > > voting direction - the voting directions merely state the debate is over > > > establishing a default for the NonTxTargetPolicy. The issue stated above > > > regards the specifics checking that is done at the server. By removing > the > > > check in the lastest version of the proposal - the proposal no longer > > > supports interoperability between an OTS1.1 client (that propagates > > > context) and an OTS1.2 server. Such interoperability can be listed as a > > > restriction - however as stated previously the IBM's implementation is > one > > > that unconditionally propagates. > > > *************************** > > > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > > >part of the EJB specification. > > > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put > it > > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > > such a specification. That means that OTS 1.1 is the official spec of > > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > > document. Since most of them have to do which client-side checking and > the > > > splitting of the old TransactionPolicy into two, this proposal (or > > > something very close to it) is a necessary pre-requisite. > > > > > > *************************** > > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > > attempting replace something that's "unimplementable" - I'm just trying > to > > > make sure we've at least visited issues which may have been overlooked > > > during the previous review cycles. It's not an easy problem - and > getting > > > the policy stuff right is certainly a bit frustrating at times. But I > think > > > we are getting there & I do appreciate all the work you've done on this. > > > > > > *************************** > > > > > > > >Regards, > > > >Tom > > > > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > > > >Please respond to Andrew Watson > > > > > > > >To: Edward Cobb > > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > >Ed, > > > > > > > >You wrote: > > > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly > to > > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes > that > > > >takes it into account. Please could everyone ignore the previous note, > and > > > >vote in reply to this call (and apologies for the confusion). > > > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > > >described in his document 092100: > > > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > > stated in the document. > > > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated > in > > > > the document, excluding the single sentence on page 10-12 > reading > > > >"If > > > > a NonTxTargetPolicy policy object is not established by the > client, > > > > the OTS 1.2 implementation will default to PREVENT". > > > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not > to > > > >require that the policy value always be set explicitly (i.e. no > default). > > > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > > >ignore the result of the less-specific 3425b. However, if 3425a fails > and > > > >3425b passes, we can produce a partial specification that J2EE > > > implementors > > > >can work from, while allowing the RTF more time to discuss the correct > > > >NonTxTargetPolicy default. > > > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote > on > > > >either proposal that introduces other options ("I would vote FOR if > is > > > >changed to .") will count as a vote AGAINST that motion. > > > > > > > >It seems that the voting list I sent out last time is out of date, but > > > >unfortunately it's the most up-to-date one that OMG staff has. Blake > has > > > >the most recent list, and since he'll be counting the votes on Monday, > > > this > > > >should all come out in the wash. People who are no longer voting > members > > > of > > > >the RTF presumably know it already. > > > > > > > >BTW, please note that our mail server will be off the air for a few > hours > > > >on Saturday morning, EDT, because they're cutting the power to our > > > >building. > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Advanced Technology & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > > > > > > > > > > > > > > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 > From: TJFREUND@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.93) with SMTP id JAA129124; Thu, 28 Sep 2000 09:23:31 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256968.002E16AC ; Thu, 28 Sep 2000 09:23:24 +0100 X-Lotus-FromDomain: IBMGB To: Blake Biesecker cc: Eric Newcomer , Jeffrey Mischkinsky , ots-rtf@omg.org Message-ID: <80256968.002E14EC.00@d06mta10.portsmouth.uk.ibm.com> Date: Thu, 28 Sep 2000 09:21:02 +0100 Subject: Re: OTS/RTF - Additional issues Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: NEPe9N[#!!L2H!!#a on 28/09/2000 00:16:36 Please respond to Blake Biesecker To: Eric Newcomer cc: Jeffrey Mischkinsky , Tom Freund/UK/IBM@IBMGB, ots-rtf@omg.org Subject: Re: OTS/RTF - Additional issues The difference I see is that the current text requires client side checks while it is silent about the default issue. I don't remember that we decided to defer discussions about allowing unconditional propoagation of tx context and allowing only server side checks. The proposal definitely doesn't indicate that. (Also, my memory might be incorrect, but isn't Bernard's position that client side checks are a good idea because it stops unnecessary propagation.) Blake On Wed, Sep 27, 2000 at 06:23:03PM -0400, Eric Newcomer wrote: > Just to note that a. and b. in IBM's list are basically the same as the ones > we also raised. We do not think these are resolved by the current text. We > think we agreed to postpone the discussion on them until after the vote. > Therefore they belong in the same category as the client side default policy > issue already on the table. > > > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 > > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Wednesday, September 27, 2000 5:52 PM > To: Blake Biesecker > Cc: TJFREUND@uk.ibm.com; ots-rtf@omg.org > Subject: Re: OTS/RTF - Additional issues > > Hang on a second. > > Haven't we already been over the ground that these issues cover? > I understand that IBM voted NO because it didn't like the proposed > resolution. > > If you insist, then you can of course have the issues created. > > But I would suggest that the proper action (which I think is purely > administrative one) should be close, no action, already discussed and voted > upon. > > jeff > > > 'Blake Biesecker' writes: > > > > Thanks for the summaries. Juergen, could you please open three > > issues based on Tom's email below. As soon as the report is > > filed, I'll put out a voting schedule. I'd like to have regular > > votes every two weeks until Orlando since we got so side tracked > > on issue 3425. > > > > Tom, are you interested in writing up proposals for these issues? > > > > Blake > > > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > Blake, > > > > > > Just so these issues don't get lost would you please enter the following > > > three issues again the OTS specification & add them to the unresolved > list: > > > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > > OTSPolicy should allow for such a client-side optimization but make the > > > check optional at the client without making it a requirement. > > > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > > always propagate context) to OTS1.2 server interoperability by adding > the > > > addition of the PERMITS/PREVENTS check rather than only performing a > check > > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested > this > > > might be part of the NonTxTargetPolicy discussion. As long as that > > > discussion includes both client and server side checking that's would be > > > fine with me.) > > > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > > per/request basis and states on page 10-5 "The Transaction Service does > not > > > require that all requests have the same behavior even when issued in the > > > scope of a transaction. An object can choose to not support > transactional > > > behavior, or to support transactional behavior for some request but not > > > others". Recommendation - this should merely be an editoral change to > clean > > > up the text unless someone sees some reason otherwise. The suggestion > would > > > be that the sentence just be deleted. > > > > > > Regards, > > > Tom, > > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 > 08:35 > > > --------------------------- > > > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > > > Please respond to TJFREUND@uk.ibm.com > > > > > > To: Edward Cobb > > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > > Freund/UK/IBM) > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > I'm surprized you would make such a statement ... IBM did NOT vote > against > > > Interoperability - we voted AGAINST 3425. The directions in the vote > were > > > "to vote for or against the text 'exactly' as stated in the document". I > > > understand the urgency of reaching closure on Issue 3425 considering the > > > schedule for inclusion in J2EE - however I do not feel that this > pressure > > > should force out a proposal that is incomplete. As such I logged the > > > objections that I currently had with the proposal/text, if these were > > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > > proposal. These comments reflected the consensus of the IBM development > > > community. Here are my clarifications and suggestions for the > improvements > > > (see below ... . > > > > > > Regards, > > > Tom > > > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > > > Please respond to Edward Cobb > > > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > > cc: ots-rtf@omg.org > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on > this > > > initiative to enable transactional interoperability for J2EE especially > > > after being so intrumental in getting RMI semantics added to IIOP in the > > > first place, but I will make some comments on your objections below. > > > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > > >additional problems exist in the text which IBM considers as major > > > >objections --- > > > > > > > >a.) The proposal does not resolve the inconsistency with the base > document > > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > > >per/request basis (the proposal would require all methods on an object > > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 > states > > > >"The Transaction Service does not require that all requests have the > same > > > >behavior even when issued in the scope of a transaction. An object can > > > >choose to not support transactional behavior, or to support > transactional > > > >behavior for some request but not others". > > > > > > First of all, inheritance is at the object level, not the operation > level > > > as are the policy definitions, so nothing has really changed. The > original > > > submitters of the OTS document abandoned operation level declarations > > > because it led to a large number of permutations of otherwise equivalent > > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > > from transactional object (which was originally called ALLOWS) permitted > > > the object to use or abuse the active transaction as it saw fit, so one > > > operation could choose to use it while another could be transaction > > > agnostic. Even thought the ALLOWS behavior was dropped in the latest > round > > > of changes, one can argue that the text you refer to is still true with > the > > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS > can > > > be used for all EJB (or CCM) objects, regardless of how the operation > level > > > policies are set in the transaction descriptor. > > > > > > *************************** > > > What I was attempting to point out was that there were additional > > > modifications that are required in the baseline OTS specification. The > > > recommendation is fairly straight-forward & would remove the text on > page > > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > > behavior for a client-server instance (however it does allow for other > > > instances an object to run with a differing policy). > > > *************************** > > > > > > >b.) The proposal requires implementation of client-side checks, > checking > > > at > > > >the client should be optional and not mandatory. The proposal should > only > > > >specify policy 'behavior' and thereby allow an implementation to > implement > > > >the check anywhere in the 'invocation path', i.e. it should be > sufficient > > > >to perform these checks server-side. (Throughout the document pgs. > 10-1, > > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > > >3425.10, 3425.13, 3425.16) > > > > > > Client-side checks are required for certain combinations, because they > must > > > be detected before an invocation is made and therefore cannot be done on > > > the server side. The most glaring example is routed invocations where > only > > > the client can detect policy mismatches. Client-side checks are also > > > essential to guarantee that transactions will never be exported to an > > > environment which may be unsafe. As documented in the initial notes on > page > > > 10-1, these assumptions were agreed to in Burlingame. > > > > > > *************************** > > > To clarify - this objection relates only to OTSPolicy (not to the > > > InvocationPolicy). Having separated the policies, it is has always been > > > agreed that the InvocationPolicy is a required client-side check. > However > > > the OTSPolicy check can be performed either at the client or server. It > > > should not be a mandatory client-side check & client-side checking > should > > > be an implementation option/optimization. > > > *************************** > > > > > > >c.) The proposal does not support interoperability between OTS1.1 > clients > > > & > > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > > >removed the PREVENT/PERMITS checking). > > > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > > > *************************** > > > The issue outlined above is different from that contained in the > > > voting direction - the voting directions merely state the debate is over > > > establishing a default for the NonTxTargetPolicy. The issue stated above > > > regards the specifics checking that is done at the server. By removing > the > > > check in the lastest version of the proposal - the proposal no longer > > > supports interoperability between an OTS1.1 client (that propagates > > > context) and an OTS1.2 server. Such interoperability can be listed as a > > > restriction - however as stated previously the IBM's implementation is > one > > > that unconditionally propagates. > > > *************************** > > > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > > >part of the EJB specification. > > > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put > it > > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > > such a specification. That means that OTS 1.1 is the official spec of > > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > > document. Since most of them have to do which client-side checking and > the > > > splitting of the old TransactionPolicy into two, this proposal (or > > > something very close to it) is a necessary pre-requisite. > > > > > > *************************** > > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > > attempting replace something that's "unimplementable" - I'm just trying > to > > > make sure we've at least visited issues which may have been overlooked > > > during the previous review cycles. It's not an easy problem - and > getting > > > the policy stuff right is certainly a bit frustrating at times. But I > think > > > we are getting there & I do appreciate all the work you've done on this. > > > > > > *************************** > > > > > > > >Regards, > > > >Tom > > > > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > > > >Please respond to Andrew Watson > > > > > > > >To: Edward Cobb > > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > >Ed, > > > > > > > >You wrote: > > > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly > to > > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes > that > > > >takes it into account. Please could everyone ignore the previous note, > and > > > >vote in reply to this call (and apologies for the confusion). > > > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > > >described in his document 092100: > > > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > > stated in the document. > > > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated > in > > > > the document, excluding the single sentence on page 10-12 > reading > > > >"If > > > > a NonTxTargetPolicy policy object is not established by the > client, > > > > the OTS 1.2 implementation will default to PREVENT". > > > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not > to > > > >require that the policy value always be set explicitly (i.e. no > default). > > > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > > >ignore the result of the less-specific 3425b. However, if 3425a fails > and > > > >3425b passes, we can produce a partial specification that J2EE > > > implementors > > > >can work from, while allowing the RTF more time to discuss the correct > > > >NonTxTargetPolicy default. > > > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote > on > > > >either proposal that introduces other options ("I would vote FOR if > is > > > >changed to .") will count as a vote AGAINST that motion. > > > > > > > >It seems that the voting list I sent out last time is out of date, but > > > >unfortunately it's the most up-to-date one that OMG staff has. Blake > has > > > >the most recent list, and since he'll be counting the votes on Monday, > > > this > > > >should all come out in the wash. People who are no longer voting > members > > > of > > > >the RTF presumably know it already. > > > > > > > >BTW, please note that our mail server will be off the air for a few > hours > > > >on Saturday morning, EDT, because they're cutting the power to our > > > >building. > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Advanced Technology & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > > > > > > > > > > > > > > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 > From: "Eric Newcomer" To: "Blake Biesecker" Cc: "Jeffrey Mischkinsky" , , Subject: RE: OTS/RTF - Additional issues Date: Thu, 28 Sep 2000 11:11:44 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000927161636.D669@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: Just to note that a. and b. in IBM's list are basically the same as the ones > we also raised. We do not think these are resolved by the current text. We > think we agreed to postpone the discussion on them until after the vote. > Therefore they belong in the same category as the client side default policy > issue already on the table. > > > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 > > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Wednesday, September 27, 2000 5:52 PM > To: Blake Biesecker > Cc: TJFREUND@uk.ibm.com; ots-rtf@omg.org > Subject: Re: OTS/RTF - Additional issues > > Hang on a second. > > Haven't we already been over the ground that these issues cover? > I understand that IBM voted NO because it didn't like the proposed > resolution. > > If you insist, then you can of course have the issues created. > > But I would suggest that the proper action (which I think is purely > administrative one) should be close, no action, already discussed and voted > upon. > > jeff > > > 'Blake Biesecker' writes: > > > > Thanks for the summaries. Juergen, could you please open three > > issues based on Tom's email below. As soon as the report is > > filed, I'll put out a voting schedule. I'd like to have regular > > votes every two weeks until Orlando since we got so side tracked > > on issue 3425. > > > > Tom, are you interested in writing up proposals for these issues? > > > > Blake > > > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > Blake, > > > > > > Just so these issues don't get lost would you please enter the following > > > three issues again the OTS specification & add them to the unresolved > list: > > > > > > a.) OTSPolicy's should not require mandatory client-side checking. The > > > OTSPolicy should allow for such a client-side optimization but make the > > > check optional at the client without making it a requirement. > > > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client (which > > > always propagate context) to OTS1.2 server interoperability by adding > the > > > addition of the PERMITS/PREVENTS check rather than only performing a > check > > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested > this > > > might be part of the NonTxTargetPolicy discussion. As long as that > > > discussion includes both client and server side checking that's would be > > > fine with me.) > > > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > > per/request basis and states on page 10-5 "The Transaction Service does > not > > > require that all requests have the same behavior even when issued in the > > > scope of a transaction. An object can choose to not support > transactional > > > behavior, or to support transactional behavior for some request but not > > > others". Recommendation - this should merely be an editoral change to > clean > > > up the text unless someone sees some reason otherwise. The suggestion > would > > > be that the sentence just be deleted. > > > > > > Regards, > > > Tom, > > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 > 08:35 > > > --------------------------- > > > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > > > Please respond to TJFREUND@uk.ibm.com > > > > > > To: Edward Cobb > > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > > Freund/UK/IBM) > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > I'm surprized you would make such a statement ... IBM did NOT vote > against > > > Interoperability - we voted AGAINST 3425. The directions in the vote > were > > > "to vote for or against the text 'exactly' as stated in the document". I > > > understand the urgency of reaching closure on Issue 3425 considering the > > > schedule for inclusion in J2EE - however I do not feel that this > pressure > > > should force out a proposal that is incomplete. As such I logged the > > > objections that I currently had with the proposal/text, if these were > > > resolved then I would modify my vote - it is a "qualified" vote FOR the > > > proposal. These comments reflected the consensus of the IBM development > > > community. Here are my clarifications and suggestions for the > improvements > > > (see below ... . > > > > > > Regards, > > > Tom > > > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > > > Please respond to Edward Cobb > > > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > > cc: ots-rtf@omg.org > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on > this > > > initiative to enable transactional interoperability for J2EE especially > > > after being so intrumental in getting RMI semantics added to IIOP in the > > > first place, but I will make some comments on your objections below. > > > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > > > >The key problem with the latest version of the proposal is as follows: > > > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > > >additional problems exist in the text which IBM considers as major > > > >objections --- > > > > > > > >a.) The proposal does not resolve the inconsistency with the base > document > > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > > > >per/request basis (the proposal would require all methods on an object > > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 > states > > > >"The Transaction Service does not require that all requests have the > same > > > >behavior even when issued in the scope of a transaction. An object can > > > >choose to not support transactional behavior, or to support > transactional > > > >behavior for some request but not others". > > > > > > First of all, inheritance is at the object level, not the operation > level > > > as are the policy definitions, so nothing has really changed. The > original > > > submitters of the OTS document abandoned operation level declarations > > > because it led to a large number of permutations of otherwise equivalent > > > IDL. The statement you refer to was true in OTS 1.1 because inheritance > > > from transactional object (which was originally called ALLOWS) permitted > > > the object to use or abuse the active transaction as it saw fit, so one > > > operation could choose to use it while another could be transaction > > > agnostic. Even thought the ALLOWS behavior was dropped in the latest > round > > > of changes, one can argue that the text you refer to is still true with > the > > > ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS > can > > > be used for all EJB (or CCM) objects, regardless of how the operation > level > > > policies are set in the transaction descriptor. > > > > > > *************************** > > > What I was attempting to point out was that there were additional > > > modifications that are required in the baseline OTS specification. The > > > recommendation is fairly straight-forward & would remove the text on > page > > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes per/method > > > behavior for a client-server instance (however it does allow for other > > > instances an object to run with a differing policy). > > > *************************** > > > > > > >b.) The proposal requires implementation of client-side checks, > checking > > > at > > > >the client should be optional and not mandatory. The proposal should > only > > > >specify policy 'behavior' and thereby allow an implementation to > implement > > > >the check anywhere in the 'invocation path', i.e. it should be > sufficient > > > >to perform these checks server-side. (Throughout the document pgs. > 10-1, > > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to issues > > > >3425.10, 3425.13, 3425.16) > > > > > > Client-side checks are required for certain combinations, because they > must > > > be detected before an invocation is made and therefore cannot be done on > > > the server side. The most glaring example is routed invocations where > only > > > the client can detect policy mismatches. Client-side checks are also > > > essential to guarantee that transactions will never be exported to an > > > environment which may be unsafe. As documented in the initial notes on > page > > > 10-1, these assumptions were agreed to in Burlingame. > > > > > > *************************** > > > To clarify - this objection relates only to OTSPolicy (not to the > > > InvocationPolicy). Having separated the policies, it is has always been > > > agreed that the InvocationPolicy is a required client-side check. > However > > > the OTSPolicy check can be performed either at the client or server. It > > > should not be a mandatory client-side check & client-side checking > should > > > be an implementation option/optimization. > > > *************************** > > > > > > >c.) The proposal does not support interoperability between OTS1.1 > clients > > > & > > > >OTS1.2 servers due to changes in the lastest version server OTSPolicy > > > >checking table on page 10-21 which raises INVALID_TRANSACTION (having > > > >removed the PREVENT/PERMITS checking). > > > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > > > *************************** > > > The issue outlined above is different from that contained in the > > > voting direction - the voting directions merely state the debate is over > > > establishing a default for the NonTxTargetPolicy. The issue stated above > > > regards the specifics checking that is done at the server. By removing > the > > > check in the lastest version of the proposal - the proposal no longer > > > supports interoperability between an OTS1.1 client (that propagates > > > context) and an OTS1.2 server. Such interoperability can be listed as a > > > restriction - however as stated previously the IBM's implementation is > one > > > that unconditionally propagates. > > > *************************** > > > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 being > > > >adopted by J2EE. Transactional policies for J2EE are already defined as > > > >part of the EJB specification. > > > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi put > it > > > so eloquently) "unimplementable." It is quite difficult to base J2EE on > > > such a specification. That means that OTS 1.1 is the official spec of > > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > > document. Since most of them have to do which client-side checking and > the > > > splitting of the old TransactionPolicy into two, this proposal (or > > > something very close to it) is a necessary pre-requisite. > > > > > > *************************** > > > Ed, I'm sure we are both trying to do the same thing - i.e. we are > > > attempting replace something that's "unimplementable" - I'm just trying > to > > > make sure we've at least visited issues which may have been overlooked > > > during the previous review cycles. It's not an easy problem - and > getting > > > the policy stuff right is certainly a bit frustrating at times. But I > think > > > we are getting there & I do appreciate all the work you've done on this. > > > > > > *************************** > > > > > > > >Regards, > > > >Tom > > > > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > > > >Please respond to Andrew Watson > > > > > > > >To: Edward Cobb > > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > >Ed, > > > > > > > >You wrote: > > > > > > > >> I'd like to suggest we modify Andrew's voting instructions slightly > to > > > >> deal with the disagreement about the default NonTxTargetPolicy value. > > > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes > that > > > >takes it into account. Please could everyone ignore the previous note, > and > > > >vote in reply to this call (and apologies for the confusion). > > > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > > >described in his document 092100: > > > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly as > > > > stated in the document. > > > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as stated > in > > > > the document, excluding the single sentence on page 10-12 > reading > > > >"If > > > > a NonTxTargetPolicy policy object is not established by the > client, > > > > the OTS 1.2 implementation will default to PREVENT". > > > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and not > to > > > >require that the policy value always be set explicitly (i.e. no > default). > > > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, midnight > > > >GMT) on Monday 25th September. If 3425a has passed at that time we will > > > >ignore the result of the less-specific 3425b. However, if 3425a fails > and > > > >3425b passes, we can produce a partial specification that J2EE > > > implementors > > > >can work from, while allowing the RTF more time to discuss the correct > > > >NonTxTargetPolicy default. > > > > > > > >Once again, I will count any qualified FOR as a vote AGAINST, so a vote > on > > > >either proposal that introduces other options ("I would vote FOR if > is > > > >changed to .") will count as a vote AGAINST that motion. > > > > > > > >It seems that the voting list I sent out last time is out of date, but > > > >unfortunately it's the most up-to-date one that OMG staff has. Blake > has > > > >the most recent list, and since he'll be counting the votes on Monday, > > > this > > > >should all come out in the wash. People who are no longer voting > members > > > of > > > >the RTF presumably know it already. > > > > > > > >BTW, please note that our mail server will be off the air for a few > hours > > > >on Saturday morning, EDT, because they're cutting the power to our > > > >building. > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Advanced Technology & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > > > > > > > > > > > > > > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 > From: TJFREUND@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.93) with SMTP id JAA262364 for ; Tue, 3 Oct 2000 09:24:31 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025696D.002E2EEC ; Tue, 3 Oct 2000 09:24:26 +0100 X-Lotus-FromDomain: IBMGB To: ots-rtf@omg.org Message-ID: <8025696D.002E2EA7.00@d06mta10.portsmouth.uk.ibm.com> Date: Tue, 3 Oct 2000 09:22:04 +0100 Subject: Re: OTS/RTF - Additional issues Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Ab2!!S(`d9oA/e9,e2e9 Blake, To clarify issue #3917, attached is an update based on the latest OTS working draft. Regards, Tom ----------------------------------------------------------------------------------------------------------------- Issue # 3917:OTS RTF --EDITORIAL OTS1.2 (working draft 00-09-04) allows transactional behavior to exist on a per/request basis and states on page 10-5, first paragraph "The Transaction Service does not require that all requests have the same behavior even when issued in the scope of a transaction. An object can choose to not support transactional behavior, or to support transactional behavior for some request but not others" and the fourth paragraph "An object can also choose to support transactional behavior for some requests but not others. This choice can be exercised by both the client and server of the request." Recommendation - Since transaction behavior is on a per/object basis - delete both paragraphs. Blake Biesecker on 02/10/2000 18:06:19 Please respond to Blake Biesecker To: Tom Freund/UK/IBM@IBMGB cc: Eric Newcomer , Jeffrey Mischkinsky , ots-rtf@omg.org Subject: Re: OTS/RTF - Additional issues Since Juergen has opened issues up on these points, I think we should vote on whether people think these are duplicates of 3425. Next week (I'll give people a chance to discuss the issues), I'll call a vote that proposes to close 3915, 3916 and 3917 as duplicates of 3425. If the majority votes NO, we can then start discussing solutions. If the majority votes YES, then we can conclude that everyone prefers the text as is. Sound reasonable? Blake On Thu, Sep 28, 2000 at 09:21:02AM +0100, TJFREUND@uk.ibm.com wrote: > > > Blake, > > Now that we have a current baseline it may good to at least reconsider the > mandatory client-side checking issue even if it's only a brief discussion > to checkpoint & reflect where we are at. Given 3425 was a complex issue > with many different aspects I know in my mind I had deferred this > particular point to make sure we agreed to first sort out the other issues > i.e. a.) policy separation (Invocation vs. OTSPolicy), b.) the policy > definitions themselves (for OTSPolicy) and c.) interoperability. And given > the penultimate version of the draft still listed a complete list of checks > at the server - then server-side only checking certainly still seemed to be > one possible interpretation. I certainly do not mean to reopen issue 3425 > ... > > The remaining two issues seem to be new issues - the first deals with > OTS1.1 client interoperability (unless we agreed to preclude the scenario > of OTS1.1 clients who always propagate context from talking to OTS1.2 > servers). If that's the case then we need to document the restriction. But > I'm confused here --- Ed seems to suggest this would be part of the > discussion of the revised text for 3425b (which is limited to the > client-side default), but in fact what OTS1.1 client interoperatibilty > introduces is the need for an additional server-side check for > PERMITS/PREVENTS. > > The last issue deals with the inaccurate text in the document that > describes transactional behavior on a per method basis. It's purely > editorial and as Ed had already stated in his response to this question the > original OTS submitters had abandoned this idea so this must have been left > over text that no one had spotted before (also since J2EE/EJB specification > is also defined to restrict such behavior so we ought to take the > opportunity to clean up the document). > > Regards, > Tom > > Blake Biesecker on 28/09/2000 00:16:36 > > Please respond to Blake Biesecker > > To: Eric Newcomer > cc: Jeffrey Mischkinsky , Tom > Freund/UK/IBM@IBMGB, ots-rtf@omg.org > Subject: Re: OTS/RTF - Additional issues > > > > > The difference I see is that the current text requires client side > checks while it is silent about the default issue. I don't > remember that we decided to defer discussions about allowing > unconditional propoagation of tx context and allowing only server > side checks. The proposal definitely doesn't indicate that. (Also, > my memory might be incorrect, but isn't Bernard's position that > client side checks are a good idea because it stops unnecessary > propagation.) > > Blake > > > On Wed, Sep 27, 2000 at 06:23:03PM -0400, Eric Newcomer wrote: > > Just to note that a. and b. in IBM's list are basically the same as the > ones > > we also raised. We do not think these are resolved by the current text. > We > > think we agreed to postpone the discussion on them until after the vote. > > Therefore they belong in the same category as the client side default > policy > > issue already on the table. > > > > > > Eric Newcomer > > IONA Technologies > > 200 West Street > > Waltham, MA 02451 > > Tel: +1 781 902 8366 > > Fax: +1 781 902 8001 > > > > -----Original Message----- > > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > > Sent: Wednesday, September 27, 2000 5:52 PM > > To: Blake Biesecker > > Cc: TJFREUND@uk.ibm.com; ots-rtf@omg.org > > Subject: Re: OTS/RTF - Additional issues > > > > Hang on a second. > > > > Haven't we already been over the ground that these issues cover? > > I understand that IBM voted NO because it didn't like the proposed > > resolution. > > > > If you insist, then you can of course have the issues created. > > > > But I would suggest that the proper action (which I think is purely > > administrative one) should be close, no action, already discussed and > voted > > upon. > > > > jeff > > > > > > 'Blake Biesecker' writes: > > > > > > Thanks for the summaries. Juergen, could you please open three > > > issues based on Tom's email below. As soon as the report is > > > filed, I'll put out a voting schedule. I'd like to have regular > > > votes every two weeks until Orlando since we got so side tracked > > > on issue 3425. > > > > > > Tom, are you interested in writing up proposals for these issues? > > > > > > Blake > > > > > > On Wed, Sep 27, 2000 at 09:08:17AM +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > > Blake, > > > > > > > > Just so these issues don't get lost would you please enter the > following > > > > three issues again the OTS specification & add them to the unresolved > > list: > > > > > > > > a.) OTSPolicy's should not require mandatory client-side checking. > The > > > > OTSPolicy should allow for such a client-side optimization but make > the > > > > check optional at the client without making it a requirement. > > > > > > > > b.) OTSPolicy checks at the server should allow for OTS1.1 client > (which > > > > always propagate context) to OTS1.2 server interoperability by adding > > the > > > > addition of the PERMITS/PREVENTS check rather than only performing a > > check > > > > for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested > > this > > > > might be part of the NonTxTargetPolicy discussion. As long as that > > > > discussion includes both client and server side checking that's would > be > > > > fine with me.) > > > > > > > > c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a > > > > per/request basis and states on page 10-5 "The Transaction Service > does > > not > > > > require that all requests have the same behavior even when issued in > the > > > > scope of a transaction. An object can choose to not support > > transactional > > > > behavior, or to support transactional behavior for some request but > not > > > > others". Recommendation - this should merely be an editoral change to > > clean > > > > up the text unless someone sees some reason otherwise. The suggestion > > would > > > > be that the sentence just be deleted. > > > > > > > > Regards, > > > > Tom, > > > > ---------------------- Forwarded by Tom Freund/UK/IBM on 27/09/2000 > > 08:35 > > > > --------------------------- > > > > > > > > TJFREUND@uk.ibm.com on 26/09/2000 09:53:11 > > > > > > > > Please respond to TJFREUND@uk.ibm.com > > > > > > > > To: Edward Cobb > > > > cc: Andrew Watson , ots-rtf@omg.org (bcc: Tom > > > > Freund/UK/IBM) > > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > > > I'm surprized you would make such a statement ... IBM did NOT vote > > against > > > > Interoperability - we voted AGAINST 3425. The directions in the vote > > were > > > > "to vote for or against the text 'exactly' as stated in the > document". I > > > > understand the urgency of reaching closure on Issue 3425 considering > the > > > > schedule for inclusion in J2EE - however I do not feel that this > > pressure > > > > should force out a proposal that is incomplete. As such I logged the > > > > objections that I currently had with the proposal/text, if these were > > > > resolved then I would modify my vote - it is a "qualified" vote FOR > the > > > > proposal. These comments reflected the consensus of the IBM > development > > > > community. Here are my clarifications and suggestions for the > > improvements > > > > (see below ... . > > > > > > > > Regards, > > > > Tom > > > > > > > > Edward Cobb on 25/09/2000 17:34:57 > > > > > > > > Please respond to Edward Cobb > > > > > > > > To: Tom Freund/UK/IBM@IBMGB, Andrew Watson > > > > cc: ots-rtf@omg.org > > > > Subject: Re: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > Tom, I'm quite disappointed that IBM would choose to vote NO on > > this > > > > initiative to enable transactional interoperability for J2EE > especially > > > > after being so intrumental in getting RMI semantics added to IIOP in > the > > > > first place, but I will make some comments on your objections below. > > > > > > > > At 01:45 PM 9/25/00 +0100, TJFREUND@uk.ibm.com wrote: > > > > > > > > > > > > > > >IBM votes NO to both 3425a & 3425b: > > > > > > > > > >The key problem with the latest version of the proposal is as > follows: > > > > > > > > > >Although vote 3425b excluded the text for issue 3425.10 - The > > > > >NonTxTargetPolicy default setting PREVENTS/PERMITS, the following > > > > >additional problems exist in the text which IBM considers as major > > > > >objections --- > > > > > > > > > >a.) The proposal does not resolve the inconsistency with the base > > document > > > > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on > a > > > > >per/request basis (the proposal would require all methods on an > object > > > > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 > > states > > > > >"The Transaction Service does not require that all requests have the > > same > > > > >behavior even when issued in the scope of a transaction. An object > can > > > > >choose to not support transactional behavior, or to support > > transactional > > > > >behavior for some request but not others". > > > > > > > > First of all, inheritance is at the object level, not the operation > > level > > > > as are the policy definitions, so nothing has really changed. The > > original > > > > submitters of the OTS document abandoned operation level declarations > > > > because it led to a large number of permutations of otherwise > equivalent > > > > IDL. The statement you refer to was true in OTS 1.1 because > inheritance > > > > from transactional object (which was originally called ALLOWS) > permitted > > > > the object to use or abuse the active transaction as it saw fit, so > one > > > > operation could choose to use it while another could be transaction > > > > agnostic. Even thought the ALLOWS behavior was dropped in the latest > > round > > > > of changes, one can argue that the text you refer to is still true > with > > the > > > > ADAPTS policy, but a stronger client-side guarantee is provided. > ADAPTS > > can > > > > be used for all EJB (or CCM) objects, regardless of how the operation > > level > > > > policies are set in the transaction descriptor. > > > > > > > > *************************** > > > > What I was attempting to point out was that there were > additional > > > > modifications that are required in the baseline OTS specification. > The > > > > recommendation is fairly straight-forward & would remove the text on > > page > > > > 10-5 of OTS1.1(ptc99-10-07).The EJB specification precludes > per/method > > > > behavior for a client-server instance (however it does allow for > other > > > > instances an object to run with a differing policy). > > > > *************************** > > > > > > > > >b.) The proposal requires implementation of client-side checks, > > checking > > > > at > > > > >the client should be optional and not mandatory. The proposal should > > only > > > > >specify policy 'behavior' and thereby allow an implementation to > > implement > > > > >the check anywhere in the 'invocation path', i.e. it should be > > sufficient > > > > >to perform these checks server-side. (Throughout the document pgs. > > 10-1, > > > > >10-2, 10-6, 10-12, 10-18/19, 10-21, 10-22, 10-24 and related to > issues > > > > >3425.10, 3425.13, 3425.16) > > > > > > > > Client-side checks are required for certain combinations, because > they > > must > > > > be detected before an invocation is made and therefore cannot be done > on > > > > the server side. The most glaring example is routed invocations where > > only > > > > the client can detect policy mismatches. Client-side checks are also > > > > essential to guarantee that transactions will never be exported to an > > > > environment which may be unsafe. As documented in the initial notes > on > > page > > > > 10-1, these assumptions were agreed to in Burlingame. > > > > > > > > *************************** > > > > To clarify - this objection relates only to OTSPolicy (not to > the > > > > InvocationPolicy). Having separated the policies, it is has always > been > > > > agreed that the InvocationPolicy is a required client-side check. > > However > > > > the OTSPolicy check can be performed either at the client or server. > It > > > > should not be a mandatory client-side check & client-side checking > > should > > > > be an implementation option/optimization. > > > > *************************** > > > > > > > > >c.) The proposal does not support interoperability between OTS1.1 > > clients > > > > & > > > > >OTS1.2 servers due to changes in the lastest version server > OTSPolicy > > > > >checking table on page 10-21 which raises INVALID_TRANSACTION > (having > > > > >removed the PREVENT/PERMITS checking). > > > > > > > > > Voting YES on 3425b allows us to continue debating this issue. > > > > > > > > *************************** > > > > The issue outlined above is different from that contained in the > > > > voting direction - the voting directions merely state the debate is > over > > > > establishing a default for the NonTxTargetPolicy. The issue stated > above > > > > regards the specifics checking that is done at the server. By > removing > > the > > > > check in the lastest version of the proposal - the proposal no longer > > > > supports interoperability between an OTS1.1 client (that propagates > > > > context) and an OTS1.2 server. Such interoperability can be listed as > a > > > > restriction - however as stated previously the IBM's implementation > is > > one > > > > that unconditionally propagates. > > > > *************************** > > > > > > > > Also I do not see how a vote on 3425 prevents the core of OTS1.2 > being > > > > >adopted by J2EE. Transactional policies for J2EE are already defined > as > > > > >part of the EJB specification. > > > > > > > > > Very simple. The existing OTS 1.1 draft plus messaging is (as Michi > put > > it > > > > so eloquently) "unimplementable." It is quite difficult to base J2EE > on > > > > such a specification. That means that OTS 1.1 is the official spec of > > > > record until the RTF fixes the errors in the "OTS 1.1 plus messaging" > > > > document. Since most of them have to do which client-side checking > and > > the > > > > splitting of the old TransactionPolicy into two, this proposal (or > > > > something very close to it) is a necessary pre-requisite. > > > > > > > > *************************** > > > > Ed, I'm sure we are both trying to do the same thing - i.e. we > are > > > > attempting replace something that's "unimplementable" - I'm just > trying > > to > > > > make sure we've at least visited issues which may have been > overlooked > > > > during the previous review cycles. It's not an easy problem - and > > getting > > > > the policy stuff right is certainly a bit frustrating at times. But I > > think > > > > we are getting there & I do appreciate all the work you've done on > this. > > > > > > > > *************************** > > > > > > > > > >Regards, > > > > >Tom > > > > > > > > > > > > > > >Andrew Watson on 22/09/2000 21:36:39 > > > > > > > > > >Please respond to Andrew Watson > > > > > > > > > >To: Edward Cobb > > > > >cc: ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > > > > >Subject: OTS RTF: Please reply to *THIS* message to vote on 3425 > > > > > > > > > > > > > > > > > > > > > > > > >Ed, > > > > > > > > > >You wrote: > > > > > > > > > >> I'd like to suggest we modify Andrew's voting instructions > slightly > > to > > > > >> deal with the disagreement about the default NonTxTargetPolicy > value. > > > > > > > > > >Thanks for your suggestion. Here's my revision of the Call for Votes > > that > > > > >takes it into account. Please could everyone ignore the previous > note, > > and > > > > >vote in reply to this call (and apologies for the confusion). > > > > > > > > > >I'm calling for TWO votes based on Ed's prposed resolution of 3425 > > > > >described in his document 092100: > > > > > > > > > >3425a: Please vote FOR, AGAINST or ABSTAIN on the resolution exactly > as > > > > > stated in the document. > > > > > > > > > >3425b: Please vote FOR, AGAINST or ABSTAIN on the resolution as > stated > > in > > > > > the document, excluding the single sentence on page 10-12 > > reading > > > > >"If > > > > > a NonTxTargetPolicy policy object is not established by the > > client, > > > > > the OTS 1.2 implementation will default to PREVENT". > > > > > > > > > >The intent of a YES yote on 3425b is to defer the resolution of the > > > > >NonTxTargetPolicy default until a subsequent vote of the RTF, and > not > > to > > > > >require that the policy value always be set explicitly (i.e. no > > default). > > > > > > > > > >The deadline for voting is 5pm Pacific Time (8pm Eastern Time, > midnight > > > > >GMT) on Monday 25th September. If 3425a has passed at that time we > will > > > > >ignore the result of the less-specific 3425b. However, if 3425a > fails > > and > > > From: "Peter Furniss" To: "Blake Biesecker" , Subject: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) Date: Wed, 11 Oct 2000 17:43:03 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001010181001.S21942@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: n/N!!D2G!!j;7!!#-Ae9 As I read the description of 3917, Tom's recommendation was that we change the text to make it consistent with 3425. The proposed resolution, to make no change, would leave the text contradictory to 3425. I don't believe this one was resolved by 3425. It is tidying up of 3425. Peter --- Bluestone Arjuna Lab, London peter.furniss@arjuna.com > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: 11 October 2000 02:10 > To: ots-rtf@omg.org > Subject: Vote 6 of the 2000 OTS RTF > > > I've asked Juergen to post the vote's html file at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote6.htm > > Votes are due by October 18th and 6PM Pacific time. > > We are voting to close the following issues as resolved > by Issue 3425's resolution: > > Issue 3915: OTSPolicy's should not require mandatory client-side checking > Issue 3916: NonTxTargetPolicy > Issue 3917: OTS RTF --EDITORIAL? > > A YES vote means that you want to close these issues without > action. A NO votes means that you think these are separate > issues and that we should allow separate proposals to be > drafted and voted on. You can, of course, vote ABSTAIN, but > I'm not sure what it would mean ... > > Let me know if you have any questions. > > Blake > Date: Wed, 11 Oct 2000 10:06:15 -0700 From: Blake Biesecker To: Peter Furniss Cc: ots-rtf@omg.org Subject: Re: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) Message-ID: <20001011100615.A22915@gemstone.com> References: <20001010181001.S21942@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from p.furniss@mailbox.ulcc.ac.uk on Wed, Oct 11, 2000 at 05:43:03PM +0100 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: b=$!!ZHI!!idfd9%R?e9 Here was the debate during vote 5 on this issue: ---------------------------------------------------------------------------- >a.) The proposal does not resolve the inconsistency with the base document >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a >per/request basis (the proposal would require all methods on an object >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page 10-5 states >"The Transaction Service does not require that all requests have the same >behavior even when issued in the scope of a transaction. An object can >choose to not support transactional behavior, or to support transactional >behavior for some request but not others". First of all, inheritance is at the object level, not the operation level as are the policy definitions, so nothing has really changed. The original submitters of the OTS document abandoned operation level declarations because it led to a large number of permutations of otherwise equivalent IDL. The statement you refer to was true in OTS 1.1 because inheritance from transactional object (which was originally called ALLOWS) permitted the object to use or abuse the active transaction as it saw fit, so one operation could choose to use it while another could be transaction agnostic. Even thought the ALLOWS behavior was dropped in the latest round of changes, one can argue that the text you refer to is still true with the ADAPTS policy, but a stronger client-side guarantee is provided. ADAPTS can be used for all EJB (or CCM) objects, regardless of how the operation level policies are set in the transaction descriptor. ---------------------------------------------------------------------------- The authors were Tom Freund and Ed Cobb. And everyone voted yes rather than no like Tom did. If you think 3917 is valid and needs to be changed, encourage people to vote NO on the proposal to close 3917. If a mojority votes NO, then we can vote on whether to remove the text. I don't think 3917 is simply a tidying up issue so I think a vote will clear up what the RTF would like to do. Blake On Wed, Oct 11, 2000 at 05:43:03PM +0100, Peter Furniss wrote: > As I read the description of 3917, Tom's recommendation was that we change > the text to make it consistent with 3425. The proposed resolution, to make > no change, would leave the text contradictory to 3425. > > I don't believe this one was resolved by 3425. It is tidying up of 3425. > > Peter > --- > Bluestone Arjuna Lab, London > peter.furniss@arjuna.com > > > > -----Original Message----- > > From: Blake Biesecker [mailto:blakeb@gemstone.com] > > Sent: 11 October 2000 02:10 > > To: ots-rtf@omg.org > > Subject: Vote 6 of the 2000 OTS RTF > > > > > > I've asked Juergen to post the vote's html file at: > > > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote6.htm > > > > Votes are due by October 18th and 6PM Pacific time. > > > > We are voting to close the following issues as resolved > > by Issue 3425's resolution: > > > > Issue 3915: OTSPolicy's should not require mandatory client-side checking > > Issue 3916: NonTxTargetPolicy > > Issue 3917: OTS RTF --EDITORIAL? > > > > A YES vote means that you want to close these issues without > > action. A NO votes means that you think these are separate > > issues and that we should allow separate proposals to be > > drafted and voted on. You can, of course, vote ABSTAIN, but > > I'm not sure what it would mean ... > > > > Let me know if you have any questions. > > > > Blake > > > From: "Peter Furniss" To: "Blake Biesecker" , "Peter Furniss" Cc: Subject: RE: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) Date: Thu, 12 Oct 2000 06:56:07 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001011100615.A22915@gemstone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: g~[d92Cgd9*E/e9hCG!! You/the vote 5 summary are right (and I was wrong) in relation to ADAPTS, but the text (understandably) doesn't mention that. It is difficult to fit the idea in with REQUIRES. But the resolution of 5 you quote says it (vote 5) "does not resolve the inconsistency" ! 3917 therefore is not a reopening of vote 5. Not really tidying up after either perhaps. Not a big deal, but if I still had a vote, I might vote no. But I don't have a vote, and this is my view not our discussed wisdom :-) Peter > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: 11 October 2000 18:06 > To: Peter Furniss > Cc: ots-rtf@omg.org > Subject: Re: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) > > > Here was the debate during vote 5 on this issue: > > ------------------------------------------------------------------ > ---------- > >a.) The proposal does not resolve the inconsistency with the > base document > >OTS1.1 (ptc99-10-07) which allows transactional behavior to exist on a > >per/request basis (the proposal would require all methods on an object > >exhibit the same behavior). OTS1.1(ptc99-10-07) states on page > 10-5 states > >"The Transaction Service does not require that all requests have the same > >behavior even when issued in the scope of a transaction. An object can > >choose to not support transactional behavior, or to support transactional > >behavior for some request but not others". > > First of all, inheritance is at the object level, not the operation level > as are the policy definitions, so nothing has really changed. The original > submitters of the OTS document abandoned operation level declarations > because it led to a large number of permutations of otherwise equivalent > IDL. The statement you refer to was true in OTS 1.1 because inheritance > from transactional object (which was originally called ALLOWS) permitted > the object to use or abuse the active transaction as it saw fit, so one > operation could choose to use it while another could be transaction > agnostic. Even thought the ALLOWS behavior was dropped in the > latest round > of changes, one can argue that the text you refer to is still > true with the > ADAPTS policy, but a stronger client-side guarantee is provided. > ADAPTS can > be used for all EJB (or CCM) objects, regardless of how the > operation level > policies are set in the transaction descriptor. > ------------------------------------------------------------------ > ---------- > > The authors were Tom Freund and Ed Cobb. > > And everyone voted yes rather than no like Tom did. If you think 3917 is > valid and needs to be changed, encourage people to vote NO on the proposal > to close 3917. If a mojority votes NO, then we can vote on whether to > remove the text. I don't think 3917 is simply a tidying up issue so I > think a vote will clear up what the RTF would like to do. > > Blake > > On Wed, Oct 11, 2000 at 05:43:03PM +0100, Peter Furniss wrote: > > As I read the description of 3917, Tom's recommendation was > that we change > > the text to make it consistent with 3425. The proposed > resolution, to make > > no change, would leave the text contradictory to 3425. > > > > I don't believe this one was resolved by 3425. It is tidying up of 3425. > > > > Peter > > --- > > Bluestone Arjuna Lab, London > > peter.furniss@arjuna.com > > > > > > > -----Original Message----- > > > From: Blake Biesecker [mailto:blakeb@gemstone.com] > > > Sent: 11 October 2000 02:10 > > > To: ots-rtf@omg.org > > > Subject: Vote 6 of the 2000 OTS RTF > > > > > > > > > I've asked Juergen to post the vote's html file at: > > > > > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote6.htm > > > > > > Votes are due by October 18th and 6PM Pacific time. > > > > > > We are voting to close the following issues as resolved > > > by Issue 3425's resolution: > > > > > > Issue 3915: OTSPolicy's should not require mandatory > client-side checking > > > Issue 3916: NonTxTargetPolicy > > > Issue 3917: OTS RTF --EDITORIAL? > > > > > > A YES vote means that you want to close these issues without > > > action. A NO votes means that you think these are separate > > > issues and that we should allow separate proposals to be > > > drafted and voted on. You can, of course, vote ABSTAIN, but > > > I'm not sure what it would mean ... > > > > > > Let me know if you have any questions. > > > > > > Blake > > > > > > From: "Eric Newcomer" To: "Peter Furniss" , "Blake Biesecker" , Subject: RE: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) Date: Fri, 13 Oct 2000 11:59:22 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Content-Type: text/plain; charset="us-ascii" X-UIDL: G4`!!e/3!!!Zjd9KDJ!! Yes, I can't understand either actually the rationale of the vote since it seems to imply somehow that the text of 3425 can't have any further problems now that it was approved. -----Original Message----- From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] Sent: Wednesday, October 11, 2000 12:43 PM To: Blake Biesecker; ots-rtf@omg.org Subject: Issue 3917 (was RE: Vote 6 of the 2000 OTS RTF) As I read the description of 3917, Tom's recommendation was that we change the text to make it consistent with 3425. The proposed resolution, to make no change, would leave the text contradictory to 3425. I don't believe this one was resolved by 3425. It is tidying up of 3425. Peter --- Bluestone Arjuna Lab, London peter.furniss@arjuna.com > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: 11 October 2000 02:10 > To: ots-rtf@omg.org > Subject: Vote 6 of the 2000 OTS RTF > > > I've asked Juergen to post the vote's html file at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote6.htm > > Votes are due by October 18th and 6PM Pacific time. > > We are voting to close the following issues as resolved > by Issue 3425's resolution: > > Issue 3915: OTSPolicy's should not require mandatory client-side checking > Issue 3916: NonTxTargetPolicy > Issue 3917: OTS RTF --EDITORIAL? > > A YES vote means that you want to close these issues without > action. A NO votes means that you think these are separate > issues and that we should allow separate proposals to be > drafted and voted on. You can, of course, vote ABSTAIN, but > I'm not sure what it would mean ... > > Let me know if you have any questions. > > Blake > Date: Sun, 15 Oct 2000 16:56:56 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: Vote 6 of the 2000 OTS RTF References: <20001010181001.S21942@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OfNe9!Jmd9mZ5e9TYl!! Sun votes YES on 3915, 3916 and NO on 3917. With ADAPTS OTS policy the target guarantees it will not suspend an imported transaction (if one were available), and will partipate in the transaction. Since the transactional behaviour of a target is permanent over the lifetime of the published IOR policy (and not on a per request basis), we beleive issue 3917 needs to be addressed as an editorial issue. thanks Ram Blake Biesecker wrote: > > I've asked Juergen to post the vote's html file at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote6.htm > > Votes are due by October 18th and 6PM Pacific time. > > We are voting to close the following issues as resolved > by Issue 3425's resolution: > > Issue 3915: OTSPolicy's should not require mandatory client-side checking > Issue 3916: NonTxTargetPolicy > Issue 3917: OTS RTF --EDITORIAL? > > A YES vote means that you want to close these issues without > action. A NO votes means that you think these are separate > issues and that we should allow separate proposals to be > drafted and voted on. You can, of course, vote ABSTAIN, but > I'm not sure what it would mean ... > > Let me know if you have any questions. > > Blake