Issue 3424: Policy interrogation API? (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Resolution: duplicate Revised Text: Actions taken: March 15, 2000: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 15 Mar 2000 14:38:56 +1000 (EST) From: Michi Henning Reply-To: ots-rtf@omg.org To: ots-rtf@omg.org cc: issues@omg.org Subject: Policy interrogation API? Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ]_ld9AnP!!j2l!!-(Ne9 Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 12 Apr 2000 17:47:18 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3424 Message-ID: <20000412174718.A3334@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: _IS!!TK/e9F>3e9@Ig!! ----------------------------------------- Issue 3424: Policy interrogation API? (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Resolution: Revised Text: Actions taken: March 15, 2000: received issue Discussion: ----------------------------------------- Michi, I agree that the proposed changes made by Messaging are incomlete in that they require the client to find out about a given IOR's transaction policy but do not specifiy how this is to be done. Has anyone given this problem enough thought to propose an API for this? As for you last point, are you suggesting we leave it up to the POA rather than the client ORB to enforce transaction policies? (Currently, the proposal is to have both the client ORB and the POA make tansaction policy checks.) I do find it a bit odd that the specification admits that transaction state as seen by the POA can be different than what is seen by the client and yet requires the client to system exceptions in certain cases. This means that if a client is wrong, it may have inappropriately thrown a system exception. Or am I missing something here? Blake Date: Tue, 18 Apr 2000 08:03:24 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: [blakeb@gemstone.com: Issue 3424] Message-ID: <20000418080324.C18406@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: FQb!!Sd%e9dUFe94b!!! To get a discussion started on this, how about only requiring the POA to check for proper transaction policies and leave the client out of it? Blake ----- Forwarded message from Blake Biesecker ----- Date: Wed, 12 Apr 2000 17:47:18 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3424 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. ----------------------------------------- Issue 3424: Policy interrogation API? (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Resolution: Revised Text: Actions taken: March 15, 2000: received issue Discussion: ----------------------------------------- Michi, I agree that the proposed changes made by Messaging are incomlete in that they require the client to find out about a given IOR's transaction policy but do not specifiy how this is to be done. Has anyone given this problem enough thought to propose an API for this? As for you last point, are you suggesting we leave it up to the POA rather than the client ORB to enforce transaction policies? (Currently, the proposal is to have both the client ORB and the POA make tansaction policy checks.) I do find it a bit odd that the specification admits that transaction state as seen by the POA can be different than what is seen by the client and yet requires the client to throw system exceptions in certain cases. This means that if a client is wrong, it may have inappropriately thrown a system exception. Or am I missing something here? Blake ----- End forwarded message ----- Date: Wed, 26 Apr 2000 16:25:08 -0700 From: Blake Biesecker To: michi@ooc.com.au Cc: ots-rtf@omg.org Subject: Re: Issue 3424 Message-ID: <20000426162508.A7532@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: o>!"!->>!!&[Fe9MV+e9 Michi, What in addition to what is possible with CORBA::Object::get_policy as defined in CORBA 2.3 do you think is needed. Blake ----------------------------------------- Issue 3424: Policy interrogation API? Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Resolution: Revised Text: Actions taken: March 15, 2000: received issue Discussion: ----------------------------------------- Date: Thu, 27 Apr 2000 16:28:28 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 3424 In-Reply-To: <20000426162508.A7532@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c;$!!5J7e9oIVd969Ie9 On Wed, 26 Apr 2000, Blake Biesecker wrote: > Michi, > > What in addition to what is possible with CORBA::Object::get_policy > as defined in CORBA 2.3 do you think is needed. I don't think anything else is needed, actually. You are right -- the get_policy() operation is good enough (in the sense that the client can look at the policy setting). However: > It also strikes me as strange that an object is allowed to prohibit a client > from invoking an object with a transaction context. If we didn't permit > an object to do this, we wouldn't have a need for clients to interrogate > the policies... Is it really necessary to have this feature in the spec, > given the complications it creates? I'm beginning to resign myself to the fact that we have to live with ALLOWS_NONE. I guess that if a client wants to protect itself against invoking on an IOR with ALLOWS_NONE, it will have to do something like the following: CosTransactions::Current_var current = ...; // Start transaction // current->begin(); // Get an objref from somewhere... // SomeObj_var obj = ...; // We want to invoke an operation on this objref. To be safe, // we have to make sure that the objref doesn't disallow // transactions. Check the policy value. // CORBA::Policy_var p = obj1->get_policy(); CosTransactions::TransactionPolicy_var tp = CosTransactions::TransationPolicy_var::_narrow(obj); // If transactions are disallowed, suspend the transaction. // if (tp->tpv() == CosTranscations::ALLOWS_NONE) current->suspend(); // Finally, we get to invoke the operation on our objref. // obj->some_op(); // Hooray! // Make sure to resume the transaction again if it was // suspended above // if (tp->tpv() == CosTransactions::ALLOWS_NONE) current->resume(); // Done. Commit. // current->commit(); Tedious, isn't it? It can be prettied up quite a bit by using helper functions and such, but it's not exactly nice even then... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 27 Apr 2000 12:19:23 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3424 Message-ID: <20000427121923.A18983@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 3FP!!(T,e9@8Pd9~<]d9 In the next vote, I'm planning on proposing that this issue be closed since CORBA::Object::get_policy covers policy interrogation functionality. The issue transaction propagation etc. is also being discussed as part of issue 3425, so we can address the other part of this issue as part of that issue. Michi, is this acceptable to you? If you want an issue that explicitly discusses the need for ALLOWS_NONE, I think we should open another issue. Blake Issue 3424: Policy interrogation API? Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Given that OTS will roll back on at least most system exceptions, the transaction policies create a problem. In particular, we have a policy that requires a transaction and a policy that requires no transaction. There is no way for the client to find out what the transaction policy for a given IOR actually is; as a result, the client is likely have transactions roll back without warning and no possible workaround. Clients could encapsulate each operation invocation in its own nested transaction, but nested transactions are not supported by all OTS implementations and, at any rate, the approach is ugly and very expensive. It appears that clients will require a way to get the transaction policy from an IOR so they can at least suspend a transaction before making a call on an object that disallows a transaction. It also strikes me as strange that an object is allowed to prohibit a client from invoking an object with a transaction context. If we didn't permit an object to do this, we wouldn't have a need for clients to interrogate the policies... Is it really necessary to have this feature in the spec, given the complications it creates? Resolution: Revised Text: Actions taken: March 15, 2000: received issue Discussion: Date: Sat, 29 Apr 2000 09:14:15 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 3424 In-Reply-To: <20000427121923.A18983@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: T?3!!$XJe9d($!!!N-e9 On Thu, 27 Apr 2000, Blake Biesecker wrote: > In the next vote, I'm planning on proposing that this issue > be closed since CORBA::Object::get_policy covers policy > interrogation functionality. > > The issue transaction propagation etc. is also being > discussed as part of issue 3425, so we can address > the other part of this issue as part of that issue. > > Michi, is this acceptable to you? Sure, no problem. > If you want an issue > that explicitly discusses the need for ALLOWS_NONE, > I think we should open another issue. Well, I don't really insist on having yet another issue. But I still would like to know the motivation for ALLOWS_NONE. No-one seems to be able to answer that one... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Bernard Normier" To: "Michi Henning" , "Blake Biesecker" Cc: References: Subject: Re: Issue 3424 Date: Fri, 28 Apr 2000 21:43:30 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: \RE!!(pmd9Y7)!!,[Je9 > > If you want an issue > > that explicitly discusses the need for ALLOWS_NONE, > > I think we should open another issue. > > Well, I don't really insist on having yet another issue. But I still > > would > like to know the motivation for ALLOWS_NONE. No-one seems to be able > > to > answer that one... I agree, we should drop ALLOWS_NONE. Having a transaction policy with no usage scenario is just adding unnecessary complexity. Cheers, Bernard Date: Mon, 01 May 2000 10:45:17 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Normier CC: Michi Henning , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 3424 References: <007101bfb17c$52653a10$6a85413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z$He9-c^d9QT~!!5%Td9 I just spoke with Bernard about this, and realized I had been confused. I was thinking of "ALLOWS_NONE" as something more like "DONT_BOTHER_TO_PROPAGATE". But Bernard tells me that ALLOWS_NONE requires the client OTS implementation to raise an exception if a transaction context exists for the client invocation. I can't see how that is useful, either. If "ALLOWS_NONE" really did mean "DONT_BOTHER_TO_PROPAGATE", then it would be redundant with the lack of a transaction component, but I'd argue redundancy was not enough reason to drop it at this point in time. -Bob Bernard Normier wrote: > > > > If you want an issue > > > that explicitly discusses the need for ALLOWS_NONE, > > > I think we should open another issue. > > > > Well, I don't really insist on having yet another issue. But I still would > > like to know the motivation for ALLOWS_NONE. No-one seems to be able to > > answer that one... > > I agree, we should drop ALLOWS_NONE. Having a transaction policy > with no usage scenario is just adding unnecessary complexity. > > Cheers, > > Bernard Date: Mon, 1 May 2000 10:24:39 -0700 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: Issue 3424 Message-ID: <20000501102439.C3737@gemstone.com> References: <20000427121923.A18983@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Sat, Apr 29, 2000 at 09:14:15AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: X=id9*l5!!+e9 On Sat, Apr 29, 2000 at 09:14:15AM +1000, Michi Henning wrote: > On Thu, 27 Apr 2000, Blake Biesecker wrote: > > > In the next vote, I'm planning on proposing that this issue > > be closed since CORBA::Object::get_policy covers policy > > interrogation functionality. > > > > The issue transaction propagation etc. is also being > > discussed as part of issue 3425, so we can address > > the other part of this issue as part of that issue. > > > > Michi, is this acceptable to you? > > Sure, no problem. > > > If you want an issue > > that explicitly discusses the need for ALLOWS_NONE, > > I think we should open another issue. > > Well, I don't really insist on having yet another issue. But I still would > like to know the motivation for ALLOWS_NONE. No-one seems to be able to > answer that one... > While I'm not tied to keeping ALLOWS_NONE around (I think it complicates transaction propagation too much), I think the idea is that a component or service developer can design and implement an API that should never be part of a distributed transaction. Maybe the implementation controls its own transaction semantics and the developer doesn't want another system which might use same object from unintentionally using the API in a distributed transaction. Also, this looks to equivalent to EJB's Never transaction attribute, so for ease of EJB/CORBA ineroperability we might want to leave it in. Blake > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > Date: Tue, 2 May 2000 07:15:00 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 3424 In-Reply-To: <20000501102439.C3737@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;aR!!#,8e91oWd9@Ygd9 On Mon, 1 May 2000, Blake Biesecker wrote: > > Well, I don't really insist on having yet another issue. But I still would > > like to know the motivation for ALLOWS_NONE. No-one seems to be able to > > answer that one... > > > > While I'm not tied to keeping ALLOWS_NONE around (I think it complicates > transaction propagation too much), I think the idea is that a component > or service developer can design and implement an API that should > never be part of a distributed transaction. Maybe the implementation > controls its own transaction semantics and the developer doesn't want > another system which might use same object from unintentionally using > the API in a distributed transaction. > > Also, this looks to equivalent to EJB's Never transaction attribute, so > for ease of EJB/CORBA ineroperability we might want to leave it in. Hmmm... Couldn't I achieve exactly the same thing without this policy? To do this, I can make my object transactional with a "don't care" policy. Then, when a request with a transaction context arrives, I can simply throw a system exception to force a rollback. While I acknowledge the use case above and the alignment with EJB, I'm still dubious about the motivation for this feature. To me, it looks like this was a case of designers getting carried away and simply filling a feature matrix, instead of designing for a particular use case... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 May 2000 01:51:37 -0700 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: Issue 3424 Cc: ots-rtf@omg.org In-Reply-To: References: <20000501102439.C3737@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: Z>g!!+8)e9HTBe9VPg!! The CCM spec requires the transaction policy value to be allows shared so that it can manage transactions as defined in the deployment descriptor. Assuming EJB on CORBA, that would work equally well for EJB so allows none is not necessary for either component model. At 07:15 AM 5/2/00 +1000, Michi Henning wrote: >On Mon, 1 May 2000, Blake Biesecker wrote: > >> > Well, I don't really insist on having yet another issue. But I still would >> > like to know the motivation for ALLOWS_NONE. No-one seems to be able to >> > answer that one... >> > >> >> While I'm not tied to keeping ALLOWS_NONE around (I think it complicates >> transaction propagation too much), I think the idea is that a component >> or service developer can design and implement an API that should >> never be part of a distributed transaction. Maybe the implementation >> controls its own transaction semantics and the developer doesn't want >> another system which might use same object from unintentionally using >> the API in a distributed transaction. >> >> Also, this looks to equivalent to EJB's Never transaction attribute, so >> for ease of EJB/CORBA ineroperability we might want to leave it in. > >Hmmm... Couldn't I achieve exactly the same thing without this policy? >To do this, I can make my object transactional with a "don't care" policy. >Then, when a request with a transaction context arrives, I can simply throw a >system exception to force a rollback. > >While I acknowledge the use case above and the alignment with EJB, I'm still >dubious about the motivation for this feature. To me, it looks like this >was a case of designers getting carried away and simply filling a feature >matrix, instead of designing for a particular use case... > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, 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 ************************************************************** Date: Wed, 3 May 2000 15:40:52 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 3424 In-Reply-To: <3.0.5.32.20000502015137.00ab7d90@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: R$%"!KNC!!bC!e9ZVWd9 On Tue, 2 May 2000, Edward Cobb wrote: > The CCM spec requires the transaction policy value to be allows shared so > that it can manage transactions as defined in the deployment descriptor. > Assuming EJB on CORBA, that would work equally well for EJB so allows none > is not necessary for either component model. That's good news, thanks for that info! Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html