Utilities

Using the message type

The message type class may be used even if you do not intend to use the Hybrid type system. As it is mainly based on the data types of the common AMETAS messages, it may be used to verify that a message has the correct type.

Supposed that you want to check that your message has the following format:

• The first element is a string (the discriminator);
• the second element is an array of AMETASPlaceUserIDs,
• the third element is an instance of AMETAS.data.AInteger.

Usually, you would check this in the following way:

private boolean processMessage(AMETASMessage msg) {
    Object[] aBody = msg.getBody();
    if ((aBody.length>3)
        && (aBody[0] instanceof String) 
        && (aBody[1] instanceof AMETASPlaceUserID[]) 
        && (aBody[2] instanceof AInteger)) {
        // format OK
    }
    else {
        // Invalid format
    }
}

This may be formulated in a more elegant way using message types and the method canBeAssigned(java.lang.Object[]):

private boolean processMessage(AMETASMessage msg) {
   MessageType mtExpected = 
      new MessageType("java.lang.String,AMETAS.data.AMETASPlaceUserID[],AMETAS.data.AInteger");
   
   if (mtExpected.canBeAssigned(msg.getBody())) {
      // format OK
   }
   else {
      // Invalid format
   }
}

(You still need to catch a possible MalformedTypeException.)

Using the Hybrid type compiler

You can invoke the Hybrid type compiler on the command line in order to create compiled type files.

The compiled file may again be used within the ContainerBuilder tool.

Checking constants

Constants have a special role within the type systems. On one hand, constants are used for discriminators and thus have a very important role. On the other hand, they are defined within the annotations which are sometimes ignored because of possible unintended mismatches. Therefore, constants have a specific type conformance flag (ANN_VALUE_MISMATCH) in contrast to ANN_MISMATCH.

The MessageType class provides two methods which allow to specifically check for constants. This is very useful when you do not yet know the message type; your match possibly depends on the semantic type only. In that case, you need some way to find out what the constants are.

With getConstantAt, you can determine the constant at the position given by the first integer argument - provided that this element actually has an annotation.

Example. By calling

Object value = (Along)mt.getConstantAt(3, "Const", ont)

the message type returns a value 1234 if and only if the annotation of the fourth message item type is

...
annotations {
   FourthItem: S = { Const:1234 };
}

or

...
annotations {
   FourthItem: CG = { [Item]->(has)->[Const:1234]; }
}

while the name "Item" and "has" is not important, but there must be a child concept with the name "Const". (It is also allowed to take the "Const" concept as the root concept without any relations.) The associated value is returned. If the value is a string list, the list must have length 1.

A second method is provided, called getValueConstantAt. This method actually calls getConstantAt(int, "Value", ont).

Creating the ontologies

Both methods expect the CGOntologySet to be passed; that is, you need to read the concept.ont and relation.ont file and create the ontologies:

Ontology ontConcept = new Ontology(new FileInputStream("concept.ont"));
Ontology ontRelation = new Ontology(new FileInputStream("relation.ont"));

CGOntologySet ont = new CGOntologySet("MyOntology", ontConcept, ontRelation);