Versions Compared

Old Version 4

changes.mady.by.user Wojtek Janiszewski

Saved on

compared with

New Version Current

changes.mady.by.user Wojtek Janiszewski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

1. CORBA

...

 CORBA reference binding will use CORBA reference invocation mechanism, which can be used like this:

DynaCorbaRequest request1 = new DynaCorbaRequest(refCalcObject, "div");

//arguments, output type, exceptions configuration
request1.addArgument(2d);
request1.addArgument(2d);
request1.setOutputType(Double.class);
request1.addExceptionType(DivByZeroException.class);
try {
    //invocation
    DynaCorbaResponse response = request1.invoke();
    Double result = (Double) response.getContent(); //retrieve what you want
} catch (Exception e) {
}

Mechanism arguments, return types, exceptions are configured by Java types, which matches with CORBA types. This API will not be used by end user, but knowledge of remote structures and how they maps to Java is required to consume CORBA objects with success.

2. Features table 

binding general description

1.1 Providing interface

CORBA binding both for service and reference side can be used with two types of Java interface:

1. Generated by idlj compiler

2. Created by user according to rules for Java to CORBA mapping

In both cases interfaces are almost the same. Difference is that generated interfaces extends/implements CORBA types which are ignored by binding.

Mapping rules are available under:
1. Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
2. IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf

Samples of CORBA bindings can be found in sca/itest/corba module.

1.2 CORBA service location

CORBA binding can be configured by:

1. Name, host, port parameters

Example service declaration:

Code Block

<service name="ScenarionOneServiceGenerated" promote="ScenarionOneServiceGenerated">

    <interface.java interface="org.apache.tuscany.sca.test.corba.generated.ScenarioOneOperations"/>

    <tuscany:binding.corba host="localhost" port="5060" name="ScenarioOneTuscanyGenerated"/>

</service>

2. Corbaname URI, which is:

corbaname::<host>:<port>/<NameService>#<Name>

host, port, NameService are optional.

Example reference declaration:

Code Block

<reference name="scenarioOne">

    <tuscany:binding.corba uri="corbaname::localhost:5060#NamedWithURI"/>       

</reference>

 1.3 Usage of "id" attribute in CORBA service bindings

User can also provide id parameter for service binding. It's not required, but helpfull if we want to publish service which will be consumed by some idlj generated code. This generated code contains *Helper classes with narrow(...) methods. Narrow(...) method compares obtained CORBA reference id to some local (which was generated). CORBA binding cannot provide this id automatically because it doesn't have access to Java path of component interface. Workaround is to:

a). provide id manually by "id" attribute

Example of using "id" attribute:

Code Block

<service name="ScenarionOneServiceGenerated" promote="ScenarionOneServiceGenerated">

    <interface.java interface="org.apache.tuscany.sca.test.corba.generated.ScenarioOneOperations"/>

    <tuscany:binding.corba host="localhost" port="5060" name="ScenarioOneTuscanyGenerated" id="IDL:org/apache/tuscany/sca/test/corba/generated/ScenarioOne:1.0"/>

</service>

b). change generated code to use unchecked_narrow(...) methods

1.4 User provided interface exceptions

Exceptions declared by user should be named to match remote exception ID.

Example: we expect remote exception with ID IDL:org/apache/tuscany/sca/test/corba/generated/WrongColor:1.0 then we should create exception org.apache.tuscany.sca.test.corba.generated.WrongColor.

This also works when user is creating service binding. Component exception will be thrown with ID translated from Java name to IDL:... form.

2. TODO list

User defines CORBA structures as simple Java classes, with public fields, ie.
public class SomeStruct {
    public int member1;
    public String member2;
    public InnerStruct member3;
}
means, that user is expecting structure with fields int, String and third field as some other structure.
1. Recurrent  structures are not handled, ie.
public class Recurrent {
    public Recurrent member;
 }
2.  INOUT/OUT modifiers
User defines CORBA sequence as an array, which may be multidimentional, ie operation:
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a6d38330-affa-45e9-81f5-b43abb8c6c77"><ac:plain-text-body><![CDATA[ public int[][] getSequence();
]]></ac:plain-text-body></ac:structured-macro>
...
is equal to IDL declaration:
...
typedef<long> oneDimLong;
typedef<oneDimLong> twoDimLong; 
twoDimLong getSequence();
... CORBA reference binding should provide method to retrieve and populate remote exceptions. Exceptions are similar to structures. If remote operation was declared with more than one exception, then exception which occurred should be determined by CORBA id, which may be ie. IDL:com/smt/SomeException:1.0.
Actual solution works fine for single exception operations. If operation has more than one declared exception and application exception will occur, then general  RequestConfigurationException will be raised.
Determination of exception type can be implemented by comparing remote exception id string to some value declared on users class hierarchy side, ie. annotation.
If remote operation has declared exception and exception was raised, but user has passed  interface with no declared exception RequestConfigurationException will be thrown.

TODO

Description

Solution


Add methods to operations mapping

Merge code from Java2IDLUtil.java

Extract some code to additional module, ie. corba-common, corba-util and use it in binding-ejb-runtime and binding-corba-runtime.


Unions handling

Pure Java interface is not enough to describe CORBA union. There is need to describe which getter method should be executed for obtained discriminator value, and how to handle pass union value to stream.

It can be done by annotation.


Arrays handling

Feature

Description

Solution

 

TODOs

Integration with reference binding provider

CORBA reference binding needs to use CORBA reference mechanism API (DynaCorbaRequest, DynaCorbaResponse classes)

 

Implementation

Primitives

Passing variables as an arguments and retrieving return values

Primitives are mapped as follows (Java - IDL):
byte - octet
short - short
int - Long
long - LongLong 
float - float
double - double
char - char
boolean - boolean
String - string

 

INOUT/OUT modifiers

Structures

Passing variables as an arguments and retrieving return values

 

Sequences

Passing variables as an arguments and retrieving return values

 

1. INOUT/OUT modifiers

References

Retrieving and passing CORBA references as arguments, return types

References matches to Java interfaces. Remote objects can be retrieved and dynamic implementation for its interface will be created. Dynamic implementation will allow further CORBA invocations on remote object - those references won't be managed by Apache Tuscany.

 

1. INOUT/OUT modifiers
2. Passing references as an arguments

Unions

Generated Java classes (which bases on idl files) contains discriminator.

?

 

Propose a solution

Arrays

There should be method to distinguish them from sequences.

Can It can be done by annotating variable ie.
public class SomeStruct {
    @CorbaArray(length=10)
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="10846009-5f38-491b-b7cd-28648012966e"><ac:plain-text-body><![CDATA[     public int[] array;
]]></ac:plain-text-body></ac:structured-macro>
}

 

Choose a solution

annotation.


INOUT and OUT argument types handling

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?). 


Solution for determining if Java object was meant to be passed as an IN, INOUT or OUT argument:
a 1. annotation - but possibility to have argument change would be lost
b 2. by implementing interface, ie:

public interface InOutHolder {
    void setValue(Object value);
    Object getValue();
}
 public interface OutHolder {
    void setValue(Object value);
    Object getValue(); 
}

 

Choose a solution

Exception handling

3. Ignoring INOUT/OUT arguments

 

Choose a solution