Following my post regarding Class Specialisation concept implementation in XML schemas, I decided to give an overview of the end-to-end process for deriving XML schemas from an Enterprise Canonical/Information Model.
As I’ve said before, I like to use the Object Management Group’s (OMG) Model Driven Architecture (MDA) approach because it promotes reusability through technology agnostic design and separation of concerns. This is achieved through the separation of business logic from the underlying technology.
The process presented below is just a suggestion to illustrate how we can manage Information Model at enterprise level and derive the integration services message model. Adaptation of activities and roles to your organisation’s environment (i.e. structure, culture…) is an essential pre-requisite to success.
The main idea here is to use this process with Sparx EA, so we can benefit from a single repository to maintain traceability for a better support change management (i.e. impact assessment) and reutilisation of architecture assets (leveraging ROI through economies of scope and scale…).
Create the Platform Independent Model (PIM)
The first step is to create a Platform Independent Model that will represent your Enterprise Information Model. Here you can start a model from scratch or use an industry standard as reference (i.e. SID for Telecom, ARTS for retail…). If you are going for the later, I would suggest to customise the model to your business and not use it as-is.
Another common situation is when the organisation already has an Enterprise Data Model defined in other tool (i.e. relational models in Erwin). In this case you can import the existing models or even create a synchronisation process if both repositories are needed (i.e. I’ve seen some cases where the Enterprise Data Model is maintained as a relational model in Erwin and synchronised as a Class Model in Sparx EA via a tool called ToolBus)
Transform into a Platform Specific Model (PSM)
One of my favourite features from Sparx EA is the Model Transformation. It really saves time on the realisation of logical model into a specific technology model. I only used it for XML schemas so far, and it has been very helpful. The main point here is to use the scripts from the respective model transformation templates to perform all the adjustments the you probably would do manually. Some examples are: data type mapping, namespace definition, schema location…
If you want to modify the templates, go to menu ‘Package’ and select ‘Model Transformation (MDA) -> MDA Transformation Templates’ (alternatively you can go through the shortcut ‘Ctrl+Alt+H’). For more info information about how to customise the transformation templates, please visit the following link:
To transform your PIM into a PSM, just right-click the package and select ‘Advanced -> Transform Package’
Adjusting the XSD Model
At this step we need to understand that if the XSD requires any further adjustments that were not considered during the transformation. An example would be my previous post ‘An approach to implement Class specialisation in XML schemas (XSD)’.
Another useful adjustment is the definition of your XSD schema ‘root element’. By default, Sparx EA convert the class elements from PIM as a XSD Complex Type in the resulting PSM. I usually create an element (XSDtopElement) that specialises the respective complex type that I want to use as my XML schema ‘root element’. The diagram below shows an example where Customer is my ‘root element’.
Note: In the new ‘Schema Composer’ tool (introduced in Sparx EA 12) you don’t need to define the ‘root element’ in the XSD model (PSM), there is functionality to set the ‘root element’ when creating the schema subset. I’m still testing this new functionality and writing a post about it, I will update this post when the link is available.
Generating the XSD file
The last step is to finally generate the physical XSD file. I will describe here the ‘traditional’ XSD schema generation functionality. As I have mentioned in my last post, Sparx EA version 12 comes with a new tool/functionality called ‘Schema Composer’ which enables the creation of a model subset, and I am currently testing and writing another post about it (I will post the link here once I finish it).
In order to generate the XSD file, you need to right-click the XSD Schema package and select ‘Code Engineering -> Generate XML Schema…’ as shown in the example below.
I have couple points that may be useful for you at this step:
- In my case I want the final version of the XSD files to be flat as they will be used as part of my service contracts. Therefore I decided to follow the ‘Venetian Blind’ style (if not familiar with XSD styles, check this link) and not select the ‘Garden of Eden’ option. This is also why I suggested to define a ‘root element’ in the ‘Adjusting XSD Model’ section.
- If you haven’t defined the schemaLocation tag (manually or as part of your MDA transformation), you will need to specify the file location here. However, you need to bear in mind that if you set the file location here, it will overwrite the schemaLocation tag setting.