|
|
|
|
|
|
Some notes about the basic design ideas and features of ACDK ORB.
For each Client-Server connection should only
one connection held.
Writing messages must be synchronized.
This is implemented on client size with a
ConnectionManager. This manager closes Connection
when no more Objects are active.
The metacompiler of ACDK provides detailed
information for each class, method, argument, etc.
This enables the Dynamic Method Invocation Interface (DMI)
and serialization for each ACDK class.
It is only a little step to traditional middleware like
DCOM and CORBA.
It is not trivial to use CORBA in a project,
especially in C++.
acdkx_orb should provide a very simple way to use
ACDK objects as CORBA components.
The CORBA specification 2.4 or even 3.0 is
a monster not only to implement but even to
understand.
So I've started with a very simple not-compatible
ORB called ARB, in which I implement the basic
routines I found and understand in CORBA.
To reinvent an alredy invented machines gives
a more deep look a the machine.
In the second step I want to implement the CORBA
2.4 and upcomming 3.0 standards.
ARB is a simple build in ORB, which is not CORBA
compatible.
- ARB uses build in ACDK types in most native way.
- ARB doesn't support struct and sequences, simply
because they are superflous using ACDK types and
passing them byval.
- In the first version ARB uses an XML type protocoll
for better debugging. GIIOP should be implemented later.
ARB interfaces should be implement the acdkx::arb::ArbInterface.
// in AnArbInteface.h
class AnArbInteface
: implements ::acdkx::arb::ArbInterface
{
// generate Metainfo
ACDK_WITH_METAINFO
// generate ARB helper
ACDK_CORBA_INTERFACE(AnArbInteface)
public:
// has one public method
virtual RString getNameOfAThing(OUT(RString) name, IN(int) size) throw (RException);
};
|
The ACDK metacompiler acdkmc generates the needed additions:
- The class AnArbInteface_Proxy with used from the client.
- The AnArbInteface::orbDispatch() method, which dispatch incoming
calls on the server side.
- Passing basic types
- Passing Strings
- passing in, out, inout
- Passing Objects by value
- Passing Interfaces
- Exceptions
- oneway
- calling objects in local process without big overhead
Following the CORBA 2.4 standard with a Java type mapping.
The interface definition:
ACDK_DECL_INTERFACE(Hello);
/**
class to test with OB orb
*/
class ACDKX_ORB_PUBLIC Hello
: implements ::org::omg::CORBA::portable::InvokeHandler
{
ACDK_WITH_METAINFO
public:
ACDK_CORBA_INTERFACE(Hello)
public:
virtual void hello() = 0;
};
|
Now the Server implementation:
ACDK_DECL_CLASS(HelloImpl);
class HelloImpl
: extends ::acdkx::orb::ServerDelegate,
implements ::Hello
{
public:
virtual RClass getClass() { return Hello::getClass(); }
virtual void hello()
{
System::out->println("Hello Server");
}
};
|
In the main routine this can be registered:
RORB orb = ORB::init();
RHelloImpl obj = new HelloImpl();
orb->impl_is_ready(obj);
RString ostr = orb->object_to_string(obj);
RString fname = "Hello.ref";
::acdk::io::FileWriter f(fname);
f.write(ostr->c_str());
System::out->println(ostr);
orb->run();
|
And finally the client usage:
RORB orb = ORB::init();
RString refid;
RString fname = "Hello.ref";
::acdk::io::InputReader f(new ::acdk::io::FileReader(fname));
refid = f.readString();
System::out->println("Calling refid: " + refid);
RHello obj = (RHello)orb->string_to_object(refid);
obj->hello();
|
ARB is up and running.
Just started the implementation of org::omg::CORBA::* interfaces,
following the Java mapping specifications.
ORB: I'm just busy on it.
The very basic functionality is working.
- Oriented at the Java portable class structure.
- Basic types in, out, inout
- oneway
- The operations with a very BOA are running!
- Basic tests with OB and mico are running!
The [G|I]IOP-protocols are quite difficult, because and implementation
has to support all
versions (1.0, 1.1, 1.2), so it is quite hard to implement
them all.
I'll try to implement the 1.2 protocol with the mayor messages.
Later I try add the other messages.
As far as possible I'll follow the the java mapping
in the implementation (org.omg.CORBA.*, especially
org.omg.CORBA.portable.*).
With the standard DMI functionality all
classes should be provided for other CORBA clients.
- Polymorphic will be solved through alternative method names.
- For standard functions, like New, invoke, invoke_static, peek, poke, etc. will
be provided by an extra interface (see AcdkObject idl below).
- Generate IDL-defintions with altnames as methods names.
- For New and the static version of methods/peek/poke
Create a Factory class, which exports names by IDL.
These Factory classes should be ordinary ACDK Classes.
- Cannot use standard DMI invoke interface and try to call CORBA services
by standard marschaling with the risk of hanging.
Main-Problem, there is no hint for the type of the return value.
CorObject with hint to an given interface, without generating
static skeleton.
- Make use of the DmiProxy!
Has to rewrite DmiProxy, to provide DMI-Bridge (calling the server)
also ClazzInfo and MethodInfo (for the type of the return value).
- Make use of the Interface-repository?
/**
Interface definition for calling any ACDK object
*/
interface AcdkObject
{
typedef sequence<any> Params;
AcdkObject New(in string classname, in string constructor, in Params outp, out Params inp);
any invoke(in string methodname, in Params outp, out Params inp);
any invoke_static(in string classname, in string methodname, in Params outp, out Params inp);
any peek(in string membername);
any peek_static(in string classname, in string membername);
void poke(in string membername, in any value);
void poke_static(in string classname, in string membername, in any value);
};
|
- Classes for Stup/Proxy
- How make it simple to implement interfaces without many overhead.
- Which classes should be super classes for interfaces?
- One base implementation for CORBA/DCOM/SOAP or different?
- How to avoid to generade meta information for the implemention, and
only for the interfaces.
- Dynamic DMI
- Replace the old DMI mechanism with new flexible CORBA-DMI mechanism.
- Metainfo
- Use/enhance acdk Metainfo for IR?
- CORBA Services
- Which services should be implemented, which used from 3thrd party?
- Which services should be implemented first?
- Native ACDK CORBA support
- Moving the basic CORBA stup/skeleton into the core package
- support all classes/interfaces with CORBA-Support
- DCOM and RMI support
- Implement DCOM support for the CORBA-Classes
- Implement RMI support for the CORBA-Classes.
- Incompatibilities?
Any input appreciated!
|
|