Greetings,
I am having a lot of issues during implementation of a model driven architecture. There is a specification for an information model, which makes use of generic types and inheritance. It is meant to be implemented in various languages across multiple platforms (MS, *nix, OsX..)
The problem is, XML schema is seen as the first tool to represent this information model. The assumption is everything is connected to XML. However, XML schema does not support generic types, which correspond to generics in Java, C# etc.. The type erasure in Java generics implementation is also another big issue, but with a modelling formalism that supports generics, I can find a walk around for this.
So I need a computable standard which lets me express this information model using generic types and inheritance. With XML schema, I am not able to express generic types, so there is loss of information when going from [Information model specification] — ~~~ –> [XML Schema] which causes a lot of issues.
Protocol buffers is attractive in many ways, since it seems to allow fast cross platform/language communication, but I have not had a chance to look at its modelling capabilities..
I feel trapped with all these constraints. At the moment, I am forced to use some other form of representation on top of xml schema, to keep track of generic types, and this is not a good solution.
Any suggestions would be much appreciated
Regards
Seref
I feel like you may be asking too much of your model layer.
XML is often used for integration tasks because you can represent and serialize structured data in a semi-standardized way. However, for each subsystem you will still have to address the issues that arise when you are (un)marshalling your live data; there is nearly always a litte impedence mismatch.
So I think you should accept that your canonical datamodel (represented as XML types and events) does not match one-on-one with the OO- or relational model of every subsystem, or cover all their details like use of generics. The connectors (SOAP web services, file parsers, ESB’s or whatever infrastructure you will be using) should translate to/from your canonical model. The canonical data model should be ‘leading’, detailed enough to allow all business requirements and general enough to leave some leeway for different subsystems with different internal representations.
Hope this gives new insight and helps you find the right solution.