Defining complex types in OCCI extensions

[vincent-zurczak]

Currently, an OCCI extension can only define resources, links and very simple types (that either extend existing types or are enumerations). This is very annoying to model complex objects. There should be a way to define such types.

The only workaround is to create a new resource extension and create links to bridge them. But this makes model navigation much more complex. It may also be a turn-off for OCCIware adopters as soon as extensions become too complex.

[cgourdin]

I have this problem where i want to create datatype object (with properties) and manage them like a collection (list, array etc.) in resources and mixins (for my VMware extension).

[vincent-zurczak]

This problem is now blocking for us. I have started to model our runtime extension for Roboconf, and we have some complex types. Building a kind as a workaround for complex types is not acceptable. It increases the number of REST invocations and results in artificial links.

The alternative would be to reduce the perimeter of our OCCI-based REST API. For the record, we already reduced this perimeter to the basic actions. But we would have to reduce it even more. The third alternative would be to implement an OCCI REST API directly, without an EMF model. Such a choice would imply OCCIware missed one of its objectives as everything rely on EMF modeling.

[mdutoo]

Other workarounds (though I'm fully in favour of supporting complex types):

• do it out of band, i.e. serialize your complex subobjects in JSON and save them in a string attribute. But obviously cumbersome to use, all the more since OCCIware Designer can't help visually anymore, unless custom GUI components are developed
• unless you need lists (which are indeed very useful), you can use attributes with dotted names to simulate an embedded object hierarchy

[philippemerle]

A workaround for complex types without lists, arrays, etc. Let's take the following complex data type: struct coordonnee { x, y : double } Then one could create an attribute for each field of the complex type: xyz.coordonnee.x and xyz.coordonnee.y

[philippemerle]

Could you provide concrete examples of complex data types you would like the support? Thus we could start to support what you really need instead of coding many cases that have no interests for you.

[vincent-zurczak]

We can indeed flatten fields, when we do not have collections of complex types. I also found a new design that limits the needs of complex types. Flattened fields can thus apply to this example for Roboconf. We have a kind called RoboconfInstance. I here put a Java sample showing what we want to manipulate.

public class RoboconfInstance {

        // Simple or flatten fields
        String name, path;

        // Enum
        InstanceStatus status;

        // Complex fields
        RoboconfComponent component;
        Map<String,String> overriddenExports;
        Map<String,String> data;

        public static class RoboconfComponent {

               String name, installerName;
               Map<String,String> imports; 
        }
}

Maps can be managed with EMF types. We had a more complex use case for code generation, with several levels of imbrications. But we already found an alternative solution. So, let's say we can deal with this solution for the runtime use case.