The short answer is that’s there’s no good reason.
SOA, the Service-Oriented Architecture, is a popular approach for organizing business functionality. From the literature it’s clear that SOA’s emphasis is on programming. That’s ironic given that most SOA services deal with the reading and writing of data. We seldom see SOA developers creating substantive data models. This is a flawed approach that needs correction.
What Is SOA?
SOA organizes business functionality into meaningful units of work. Instead of placing logic in application silos, SOA organizes functionality into services that transcend the various departments and fiefdoms of a business. A service is a well-defined unit of work that is packaged for reuse and easy access.
Services communicate by passing data back and forth. Such data is typically expressed in terms of XML, the eXtensible Markup Language. XML combines data with metadata that defines the data’s structure.
XSD, the XML Schema Definition, is the standard language for defining XML data structure. XSD defines the metadata that governs the invocations of a service. XSD can specify data details such as the fields that can be included, their hierarchical nesting, and whether they are required or optional.
Why Have a SOA Data Model?
There are SOA modeling tools that are helpful for individual XSD files. But an individual XSD file is small in scope and fragmentary. A model of a single XSD file hardly qualifies as a serious data model.
What is needed is a proper data model that reaches across XSD files. Such a model can provide a holistic and consistent approach to representing business concepts. A comprehensive SOA model can avoid XSD overlaps and omissions. A large collection of SOA services is difficult to understand, coordinate, and build consistently. Effectively, that won’t happen without the abstraction of a data model.
Why Doesn’t SOA Use Data Models?
One reason is that SOA is dominated by developers. SOA developers tend to work on one project at a time and focus on that. They are not inclined and not tasked to look across projects. Many developers don’t realize the problems that can happen with services in isolation and the opportunity for data modeling to make SOA services more effective.
Another reason that SOA doesn’t use data models is because XSD is a difficult language. It’s complex to understand and has many options and alternatives for representation. It’s difficult to take a data model and forward engineer it into a XSD design. It’s even more difficult to take XSD designs and reverse engineer them into a data model. There’s a conceptual gap in bridging the divide between data modeling and XSD files as well as a gap in tool capabilities.
Data architects need to be added to the SOA project team to bring a broad view. In contrast to developers, data architects are accustomed to looking across individual projects for the interests of the enterprise. Data architects can be advocates for making SOA services consistent and cohesive. The involvement of data architects is a part of proper SOA governance. Currently, this doesn’t seem to happen much.
The involvement of data architects is not a burden on developers, but rather a benefit. With SOA services that are vetted for consistency across the enterprise, developers have a better seed for new services to prepare. They have better documentation for how past concepts were handled so that they can use the same representation again. It becomes clearer how to add new functionality to an existing code mass.
Also more work needs to happen on better relating data models to XSDs. The forward engineering of XSDs from data models is a manageable problem. The reverse engineering of XSDs to data models will be troublesome to resolve.