CODEWITHSUNDEEP
javac++idldata-distribution-serviceopendds
aabceh
aabceh

Reputation: 95

DDS IDL Compiler

I am using IDLs to define data for an application using OpenDDS.

I also want to use IDLs to define interfaces for the application, but OpenDDS (and most other DDS implementations it seems) does not support interfaces in IDLs.

Are there any compilers that will generate simple stubs from IDL interfaces? I need it to support at least C++ and Java.

All of the IDL compilers that are a part of CORBA ORBs generate a lot of CORBA-specific code and boilerplate. I want something that does a simple mapping from IDL to C++/Java/etc. For example, if I have this IDL:

module sample_module {
  interface sample_interface {
    attribute char sample_field;
    boolean sample_func();
  };
};

I want the compiler to generate files like this in C++:

namespace sample_module {
  class sample_interface {
    char sample_field;
    boolean sample_func();
  };
};

Upvotes: 1

Views: 879

Answers (3)

C Tucker
C Tucker

Reputation: 301

There is an OMG standard called Remote Procedure Call over DDS (RPC over DDS) that defines how IDL interfaces can be mapped to code (it is in the family of DDS standards). CoreDX DDS does support this standard for several target languages (including C++, Java, and C#).

In addition to simply mapping the interface to the target language, the RPC over DDS standard provides a way to use DDS as the underlying transport for the RPC operations. It provides for both low-level interfacing (that is, dealing with sending a receiving requests manually), and high-level (invoking a method the 'interface') API's. In either case, the inter-process communication is handled via DDS in a way that is interoperable. In my opinion, it is a very powerful approach.

Here's some example IDL:

module robot {
  exception TooFast {};
  enum Command { START_COMMAND, STOP_COMMAND, TERMINATE_COMMAND };
  struct Status 
  {
    string msg;
  };
  @DDSService
  interface RobotControl 
   {
     void  command(Command com);
     float setSpeed(float speed) raises (TooFast);
     float getSpeed();
     void  getStatus(out Status status); 
  };
};

NOTE: The '@DDSService' annotation informs an aware IDL compiler to generate RPC over DDS support for the interface.

Without @DDSService annotation, our code generator will simply generate a class declaration [which I think you are looking for] that looks something like this:

class RobotControl {
  public:
    RobotControl();
    ~RobotControl();

  public:
    virtual void                 command (
                                 /* IN    */  const enum robot::Command   com ) = 0;
    virtual float                setSpeed (
                                 /* IN    */  const float  speed ) = 0;
    virtual float                getSpeed ( ) = 0;
    virtual void                 getStatus (
                                 /* OUT   */  struct robot::Status & status ) = 0;

};

With the @DDSService annotation, there is a lot more code generated that provides a full client-side implementation (robot.RobotControlClient) and an abstract server side ready for implementation (robot.RobotControlService). With that, your client application can simply do this:

RobotControlClient robotClient = new RobotControlClient( client_params );
robotClient.setSped( 10 );

The server application can extend robot.RobotControlService, and implement the service calls, something like this:

public class MyRobotControlService  extends RobotControlService {
   ....
   private static final float MAX_SPEED = (float)20.0;

   public float                       
   setSpeed ( /* in    */ float speed ) throws TooFast
   {
     float retval = (float)0.0;
     if (speed < MAX_SPEED)
       {
         current_speed = speed;
         retval = this.current_speed;
       }
     else
       {
         /* EXCEPTION: */
         throw new robot.TooFast();
         /* not reached... */
       }
     return retval;
   }

Upvotes: 2

Johnny Willemsen
Johnny Willemsen

Reputation: 3002

You could use the local interface support, that results in a C++ base class with pure virtual methods to implement. This is for example used by LwCCM to define components, see for example AXCIOMA, there we use local interfaces combined with data defined in IDL. See one of our articles for some more information.

As alternative you could also create your own custom generation based on IDL, in TAOX11/AXCIOMA/R2CORBA we are using RIDL, you could create a custom backend to generate some code specific for interfaces

Upvotes: 2

Fred Hornsey
Fred Hornsey

Reputation: 329

Outside the interfaces in the IDL of DDS specs, DDS itself doesn't have a use for interfaces as far as I know. It's always restricted its own IDL to a subset of CORBA's. Because of this OpenDDS doesn't have support for user-defined interfaces outside the support that already comes with using tao_idl. The optional C++11 mapping that can be generated by opendds_idl is free of all the CORBA boilerplate like you want, but it doesn't support interfaces at the moment. I think the Java mapping only supports them for OpenDDS's specific JNI-based situation. Even when using TAO's C++ mapping, OpenDDS doesn't support using interface types as a DDS topic type or inside one.

I can't speak as much for other DDS implementations as I can for OpenDDS, but I know this support page for Connext says they don't support interfaces either. It does say they support valuetype, which is sorta like an interface, but they treat it as a struct and ignore the operations on them.

Upvotes: 1

Related Questions