Xomega is an XML-based object modeling technology that enables extensible generation
of various system artifacts using the standard XSLT transformation technology. It
provides a powerful framework for capturing the most essential elements of the model
in an easy and flexible way so that it can be further refined and enhanced to support
different generators. This Xomega unique approach helps building clean and well
organized models that are easier to maintain, which results in more robust and consistent
system designs. This is important when, following the best practices of Model Driven
Development, the models are put at the core of the development process and serve
as a source for generating and possibly regenerating other system artifacts from
it. In addition to increasing developers productivity, improving the product quality
and reducing development costs and time-to-market, Model Driven Development can
make your system more portable and thus future-proof your investment.
Being defined in a plain text format, XML-based models lend themselves to a better
collaboration and change control management as opposed to the models defined in
a graphical form, since text files are much easier to compare, merge and resolve
conflicts. Nevertheless, they can still be transformed into any other format that
can be displayed graphically, such as XMI for UML diagrams.
Basic Structure of Xomega Models
Xomega models allow declaring various entities such as objects, types, field-sets,
structures and enumerations that help you describe your business objects and relationships
between them and define a service layer for the business objects. All related entities
are logically organized into modules to help you manage your model more effectively.
Most model elements have an associated child element (<doc>) for a short description
and detailed documentation, which helps you keep all the relevant information together
and also allows generating more formal documentation from the model in your preferred
All the essential elements have a dedicated node (<config>) for additional
configuration to be used by different generators. Such nodes serve as extension
points where you can supply your own configuration for your custom generators.
At the core of the model is the definition of a business object, which consists
of the object name followed by a list of fields that can be declared as a mix of
individual fields and references to reusable field-sets that are declared separately
in the model. Each field has a name and a type that should reference one of the
types defined in the model.
One of the fields is typically marked as a key with a specifier whether this is
a serial auto generated key, a user supplied key or a reference to another object's
key. Unless it's a reference to another key, the key field should use a dedicated
type that no other object uses for its key type. This way whenever any other field
is using this type or any type derived from it, it will be automatically considered
as referencing this object and a foreign key will be generated unless specifically
overridden by the field configuration. Composite keys are defined in a similar way
where a field-set reference on the object is marked as a key.
In addition to the list of fields an object may consist of a number of sub-objects
whose definitions are nested inside the definition of their parent object. A sub-object
(also referred to as a child object) cannot exist without its parent object and
should be deleted whenever the parent object is deleted. Unless the child object's
key is serial and hence unique, the parent's key is automatically included into
the child's key. There is also an implicit foreign key relationship between the
child and the parent objects with cascading object deletion.
Xomega allows defining logical type hierarchies right in the model. The declared
types are then used in other model elements, such as object fields. Any type may
extend another type and inherit its properties and additional configuration, such
as a mapping to a corresponding physical type, e.g. SQL type, which can be overridden
in the derived type. If certain configuration is not specified in the derived type,
the one from the base type will typically be used.
Generally, a type hierarchy is built on top of a set of base framework types, which
defines most of the mappings to the physical types. Xomega comes with a set of predefined
base types that you can extend and customize for your needs. The derived types will
then typically specialize the base types according to the business domain structure.
Using the same Xomega types in the model helps to ensure consistency between different
system's elements both vertically and horizontally. For example, if you define a
user name to be of a certain length then all generated database columns that contain
a user name will have consistent lengths and appropriate validations to restrict
the length could be added to the corresponding editing UI controls or business layer
fields. By the same token, any Boolean field can be consistently represented by
the same SQL type (e.g. bit) or a UI control (e.g. checkbox).
Field-sets define a named group of fields in the model that can be used for one
or multiple object definitions. On one hand, field-sets provide a mechanism for
declaring composite object keys, which can be referenced by other objects thus establishing
a foreign key relationship.
On the other hand, they enable support for reusability where the same set of fields
is used by many objects. This comes in handy in aspect-oriented designs. If, for
instance, most or all of your objects are supposed to have a modification stamp,
which can include a timestamp and the user of object's creation and the last update,
then you will be able to declare a field-set with these four fields and then just
reference it in every object.
In the spirit of extensibility, you can override any field in the referenced field-set
by adding a child field element to the reference and then setting the properties
you want to override on that field.
Each business object may support a number of operations, which form a service layer
for the business objects. The structure of the service layer may be totally different
from the structure of the underlying business objects, however typically there are
a lot of similarities between the two.
A business object operation consists of a definition of its input and output structures,
operation description and a set of additional extensible configuration parameters
such as WCF operation attributes, etc.
You can define the structure of operation’s input and output either inline by listing
the parameters and nested structures explicitly or by referencing existing reusable
structures that are defined in the model or both as a combination of the two approaches.
This clearly implies that you can define any named structure in the model and use
it for specifying business object operations or as part of other more complex structures.
Parameters that have a matching field in the object definition do not need a type
as it can be derived from the field’s type. Also, any parameter or structure can
have a list attribute set to true indicating that it represents an array of values
One of the key features of defining structures in the Xomega object model is the
ability to indicate which presentation data object the structure should be a part
of. The idea behind that is that in the multi-tiered applications where the presentation
layer communicates with the business layer through a service layer, the structure
of the service layer is much more suitable for
generation of the presentation data model than the structure of the business
layer itself. However, since a presentation object that serves as a data model for
a single UI form may use several service operations to read its data or to make
updates, it may need to be combined from the structures of those operations. In
other words, this feature allows you to easily define presentation data objects
built from the parts of existing model structures and operations.
In business object modeling certain fields may sometimes assume only a limited set
of predefined values, which typically have a short code and a longer description.
These static lists of possible values and each of their individual values may have
very important business meanings, such as different statuses of an order. Unfortunately,
this information is oftentimes not included into the formal business object models
and developers just keep it in special database lookup tables and maintain SQL scripts
to populate those at best, or have these values hard coded all over the program
Xomega provides an easy and flexible way of defining these static lists as named
enumerations, which can also be associated with any logical type. Each item in the
enumeration has a standard unique descriptive name and a short value that gets actually
stored in the database. In addition, you can specify any number of additional properties
for each enumeration that enumeration items may also have.
Once you have defined the enumerations in your business object model, you will be
able to generate an SQL script that populates the database lookup tables or build
a simple XML file that the program may be using for the lookups instead. You can
also generate static constants that you can use in the code to work with individual