Custom XSD Schema or Public Standard: Some Perspectives

XSD schema are a key part of the inteface exposed by Web Services to enterprise and external clients of services, however, organisations need to decide how to go about deriving the schema that will be used by their services.  The choices are simple, either adopt an external standard such as OAGIS, HL7, etc. or create/reuse an internal standard.  Making the choice is not so simple though, and benefits from consideration from a number of perspectives.

This is an “insight” post; it aims to stimulate discussion around the subject it discusses; these articles may appear prescriptive and perhaps dogmatic, but the objective really is for debate that leads to reusable knowledge and that is accessible to the wider community of software engineers in the area of focus.

Due to IPR constraints, the full text of the document that informed this article is not yet available for public access – the essence of the document will be synthesised and made available in the very near future.

There are three things to bear in mind when deciding on the sourcing of XSD schema:
1). The purpose of your message architecture – what vision is it going to support
2). The technologies available to you
3). The size of your team

The first and most important is the architectural vision that you are working towards. If your goal is to facilitate B2B collaboration with business partners, then you have little choice than to investigate if the partner community already has a canon that they use, be it OAGIS, HL7, NIEM, or some other standard, then it will be wise that you simply take the hit and negotiate the resource issue with management and HR. If on the other hand the vision is primarily to support a domain or enterprise SOA, or if the organisation is just exploring SOA adoption, then you should consider creating your own canon; ideally derived from your enterprise/domain data model(s).

The second key issue is technology. You will need dedicated tools for working with public standards like OAGIS, as the schemas tend to be quite complex and will usually involve some customisation (extension and/or restriction) to get it to work for your own context – not everything that partner-A wants is useful to partner-B. On the other hand, if you make your own canonical schema, they can be as simple as you choose. While you could view OAGIS files using JDeveloper, Eclipse, and other developer IDEs, in practise, you would benefit from investing in something like Oxygen, Stylus Studio, or XML Spy to make the work easy and efficient.

The last, but not least, is the size and competence of your team. If your team is small and/or inexperienced, you are better off starting with your own schema, especially if you have fixed/in-elastic timescales for delivery. Learning to work with a standard such as HL7 takes time, and you may all need to attend courses to understand the structures employed and how to adapt them for your context and use. Experienced staff will obviously learn quickly, and may be able to read up on existing documentation and online examples as an alternative to formal instruction. Less experienced personnel, and young developers may struggle though, and this could end up in a person/group that designs schema and another group that are told how to use them!

Whatever way you decide to go though, standard or custom, you will find help with tools such as IgniteXML or consultants/consultancies that specialise in standard (OAGIS, UBL, HL7, etc.) or custom (canonical and other) schema design and development. It is an important area though as it is a neck that aligns the view of data from SOA service interfaces and IT, with that of the business and client community. The decision made (industry standard or bespoke) is vital; in an Agile context, a wrong turn here could severely impact the velocity of Sprints, so time invested before making a decision will be well spent.

If the decision is to create a a canonical schema for the domain/enterprise/centre-of-excellence, then the following advice will be useful:

• Always begin with an information model (domain, or enterprise) a.k.a domain/enterprise inventory
• Derive a canonical schema from the information model
• Choose between using a virtual or physical canonical schema
• Keep the initial canonical schema small and simple
• Leverage conventions like document literal wrapped
• Do not try to replicate the information in the service interface, especially the input
• Make a clear distinction between business data and non-business/infrastructure data
• Apply namespaces as a governance tool rather than a design tool

Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 [0] 793 920 3120