Technology

Binding and function definition issues

Current CTS approach

The current CTS specification defines the information model using UML and defines the API using the OMG Interface Definition Language (IDL). A sample IDL declaration follows:

     typedef string  OID;
     typedef OID     CodeSystemId;
     typedef string  ConceptCode;
     exception UnexpectedError {
          string possible_cause;
     };
     exception UnknownCodeSystem {
          CodeSystemId codeSystem_id;
     };

     struct ConceptId {
          CodeSystemId codeSystem_id;
          ConceptCode  concept_code;
     };

     boolean isConceptIdValid(
          in ConceptId concept_id,
          in boolean   activeConceptsOnly
     )
     raises (UnknownCodeSystem,
             UnexpectedError);

IDL was chosen because there is a definitive, standard mapping defined between IDL and most programming languages. There are two problems, however. The first is that, while IDL is supposedly technology neutral, the language mappings carry some CORBA related artifacts. The ConceptID declaration above compiles to:

public final class ConceptId implements org.omg.CORBA.portable.IDLEntity
{
  public String codeSystem_id = null;
  public String concept_code = null;

  public ConceptId ()
  {
  } // ctor

  public ConceptId (String _codeSystem_id, String _concept_code)
  {
    codeSystem_id = _codeSystem_id;
    concept_code = _concept_code;
  } // ctor

} // class ConceptId

org.omg.CORBA.portable.IDLEntity is not a serious issue, as it defines an interface with no properties or methods and is present in most JRE's. You will note, however, that this mapping is not an interface specification, but rather a concrete class. This turns out to be a serious issue for many implementations, including SOAP, which expect bean-style interfaces. The compliler also creates the CORBA specific files:

• ConceptIdHelper.java
• ConceptIdHolder.Java

Both of which can be ignored or discarded.

---

The exception declaration has more problems of problems. It generates the Java:

public final class UnexpectedError extends org.omg.CORBA.UserException
{
  public String possible_cause = null;

  public UnexpectedError ()
  {
    super(UnexpectedErrorHelper.id());
  } // ctor

  public UnexpectedError (String _possible_cause)
  {
    super(UnexpectedErrorHelper.id());
    possible_cause = _possible_cause;
  } // ctor


  public UnexpectedError (String $reason, String _possible_cause)
  {
    super(UnexpectedErrorHelper.id() + "  " + $reason);
    possible_cause = _possible_cause;
  } // ctor

} // class UnexpectedError

Not only is this not an interface, it contains references to a CORBA specific UserException which is NOT benign as well as referencing UnexpectedErrorHelper which contains many CORBA specific references.

---

The actual isConceptValid operation can be generated in a variety of different ways, the Portable Object Adaptor (POA) approach being the most neutral. The IDL compiler generates RunTime.java:

public interface Runtime extends RuntimeOperations, org.omg.CORBA.portable.IDLEntity 
{
} // interface Runtime

as well as RunTimeOperations.java

public interface RuntimeOperations  extends org.hl7.CTSVAPI.IdentificationOperations
{
   ...
   boolean isConceptIdValid (org.hl7.CTSVAPI.ConceptId concept_id,
                             boolean activeConceptsOnly) 
              throws org.hl7.CTSVAPI.UnknownCodeSystem, 
                     Org.hl7.CTSVAPI.UnexpectedError;