Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <[EMAIL PROTECTED]>
Sent: Thursday, June 12, 2008 2:39 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
Hi, Raymond.
Please take a look at my comments inline.
Thanks, Wojtek
Raymond Feng wrote:
Hi, Wojtek.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Wojtek Janiszewski" <[EMAIL PROTECTED]>
Sent: Wednesday, June 11, 2008 11:55 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
Example 1.
Java interface for TestObject implements TestObjectOperations,
org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
user should define this interface using CORBA API types. This is what
you mean?
To access an existing CORBA service with general_tests.idl, I should be
able to use "TestObject" interface generated from the IDL in my SCA
reference with binding.corba. The CORBA reference binding invoker should
be able to marshal/marshal the data from the interface.
What's the use case for reference binding using Java interface? Is it
a) user generates classes from IDL file and uses them in binding
configuration
b) user creates classes basing on IDL file (without extending or
implementing any types from CORBA API) and uses them in binding
configuration
I was following case b) from the beginning. Now I'm little confused.
I think we should support both cases. For case b), the java types have to be
mappable to IDL types based on the Java IDL mapping spec.
Another case is that Java2IDL compliant java interface (for example, the
remote interfaces for EJB). We already have support in the binding.ejb
module.
Example 2.
Operation:
SomeStruct setStruct(inout SomeStruct arg)
for interface TestObject uses SomeStructHolder (for passing INOUT
argument) which implements
org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct
as a structure representation. Again, SomeStruct uses CORBA API
interface - it implements org.omg.CORBA.portable.IDLEntity. In this case
SomeStruct was meant to be INOUT argument, so it uses
SomeStructHolder. If SomeStruct would be declared as OUT, then again
SomeStructHolder would be used, but little different application logic
would be used - argument wouldn't be sent, but only retrieved after
operation invocation (this remaining logic is generated in stubs
and skeletons - so it's outside generated interface). This means, that
user using holders the same way as in the generated style cannot tell
to the binding reference whether the modifier is INOUT or OUT.
This is one example of some real constraints which blocks using Java
interface hierarchy the same way as generated from idlj compiler.
OK. My understanding is that the generated java interface doesn't catch
all the information from the IDL because some of them are in the
generated stubs/skeletons. We probably need to decide what's the best
default here. For example, for the Holder type, we will default to INOUT.
Another perspective is that for SCA remotable interfaces, the data
exchange semantics is pass-by-value. In the case that
@AllowsPassByReference is used, it only means the data is safe to pass by
reference and it does NOT mandate pass-by-reference. So we can perfectly
argue that the binding.corba doesn't support the INOUT and OUT arguments.
So I understand for both reference and service bindings we won't support
INOUT/OUT modifiers.
I think it's reasonable if we cannot find a good way. At least supporting
INOUT/OUT parameters is a second priority.
There is similar problem with CORBA arrays and CORBA sequences - Java
types for them are both arrays, and additional logic is generated in
stubs/skeletons (in arrays we only send fixed length array, in sequences
we additionally send length of sequence first). Should we also make some
default here? If so, then sequences looks more useful.
We might be able to consider the additional metadata to describe the java
type for CORBA as part of the databinding framework. We'll introduce the
annotation if it is inevitable.
