Hi,
I understand you mean to look at generated classes to determine
Java/CORBA mapping. I followed case A, using existing IDL file:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/resources/general_tests.idl
and focused on interface TestObject. Generated classes are in:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/java/org/apache/tuscany/sca/binding/corba/testing/generated/
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?
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.
Thanks,
Wojtek
Raymond Feng wrote:
Hi,
There are two specifications in these areas.
1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf
Let's try to use a few scenarios to help us understand what rules should
be applied.
Case A: There is an existing CORBA service (Java or C++) with IDL. Now
we want to consume it using SCA.
Here is what I would do:
a) Run idl2java to generate a java interface (ignoring other stubs and
skeletons) from the IDL.
b) Declare a SCA reference with binding.corba and set the interface to
the one generated from a)
c) The Tuscany corba invoker should be able to create a request stream
for input args and parse the response to get the return value.
The corba invoker needs to find the corba operation name from the java
method and know how to marshal/unmarshal the parameters/return value.
Case B: We have a SCA component and we want to expose it as a CORBA
service.
The corba service binding listener will have to unpack/pack data from
the ServerRequest. Let's assume the component service interface is
defined in java, then we need to follow the Java2IDL spec so that we
handle the java parameters/return value following the CORBA IDL rules.
Ideally, the exposed CORBA service would behave as it has an IDL
generated from "rmic -idl <java_interface>".
Thanks,
Raymond
[snip]
Hi,
I recently submitted some code, which helps invoking remote objects.
Mechanism for invoking remote CORBA objects is determining operation
arguments types by Java types and I'm not sure that Java to CORBA
mapping model I proposed is OK.
There is quite nice description of Java to CORBA mapping under [1]. It
shows how idlj compiler creates Java structure basing on idl file and
I believe we shouldn't precisely follow those rules and try to make
them as simple as possible. Am I right?
1. Structures
I proposed that CORBA structures will be Java classes, with public
fields and no get/set methods. So every class field is member for
CORBA structure. Or maybe we should map JavaBean classes to CORBA
structures?
2. Sequences and arrays
Sequences and arrays can be mapped to Java by arrays or lists.
Unfortunately both CORBA types behaves bit different, additionally
CORBA arrays have fixed length so there should be possibility to
distinguish those types somehow. For now on I cannot find any other
solution, but annotating arrays with it's target length. Any opinions?
3. Arguments with inout/out modifiers
In CORBA, operation argument value can be changed. As we know Java
supports passing arguments by values only, so update on argument is
not possible. Such was solved in Java by wrapping arguments in holder
classes, ie:
public class IntHolder {
public int value;
}
This means if user wants to get his argument updated he needs to
create argument in holder class, which could be tough (maybe there are
low-level techniques which allows to manipulate such arguments?).
I know I should provide some method to recognize if users class is
holder for inout/out argument:
a. annotation
b. by implementing interface, ie:
public interface Holder {
void setValue(Object value);
Object getValue();
}
Or maybe there is some other solution? Which one should I choose?
I'll appreciate any comments. Just ask if you need more details.
[1] - http://members.tripod.com/gsraj/corba/chapter/
Thanks,
Wojtek
