Hi,
I've gathered all current/past issues regarding project on wiki page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+reference+binding+features%2C+bugs%2C+issues
Comments are always welcome.
Thanks,
Wojtek
Wojtek Janiszewski wrote:
Wojtek Janiszewski wrote:
Simon Nash wrote:
One comment inline.
Simon
6. If CORBA objects operation argument is object reference, then
user should provide object which was previously obtained from
binding or other CORBA object. User cannot use users-side object
as an argument.
Yes. Let's don't worry object reference too much at this point. We
are in the SOA world instead of distributed object :-).
This is OK if we are exposing a SCA service via CORBA. If we are using
SCA to invoke existing CORBA services that expect object references
to be passed, we will need to come up with an approach for handling
them.
I'd suggest that we start first with exposing SCA services via CORBA
as this seems to be the simplest and most useful form of integration.
Unfortunately I started earlier with reference bindings - even
submitted a patch today.
My thoughts for object references are that after obtaining some remote
reference, it will be enhanced by cglib and connected to users
declared interface. By enhancing I mean interception of methods
invocations and adding dynamic CORBA invocations. Such enhanced object
could be recognizable by dynamic invocation mechanism, and it could be
passed while invoking operations on remote objects.
In this solution we would have two types of CORBA objects - ones that
were intentionally declared, and ones that were obtained from roots,
and which are transparent. It's maybe kind of out of control by
Tuscany runtime, but is there any other way to obtain and use CORBA
references which are not registered in name services?
Thanks,
Wojtek
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
