SOA and ANSI/SPARC 3-Schema
Applying Lessons from the Past
Some 30 years ago, back in 1975, the Database Management community experienced a great epiphany. It was called the ANSI/SPARC three-schema architecture referring to the Standards Planning and Requirements Committee (SPARC) of the American National Standards Institute Information Processing Systems (ANSI/X3) Committee.
The ANSI/SPARC architecture defined three separate schemas, or views, for describing data in a database:
- External Schema or Application View
- Conceptual Schema or Logical View
- Internal Schema or Physical View
The Conceptual Schema describes data definitions unambiguously, independent of any particular data structure or data representation. Its intent is to represent an enterprise model of data and to support mappings from external to internal layers.
The External Schema describes the data corresponding to part of the conceptual schema as seen by one or more users or programs, as cast in a particular data model and as represented in a given programming language. Relational Views are a classic example of external schemas.
The Internal Schema describes how data is physically represented and structured on the storage media. In terms of data independence, the physical view completely separates a logical model from its underlying implementation.
Obviously, the ANSI/SPARC 3-Schema Data Model is now old hat. On the other hand, perhaps its fundamental principles ought to be applied to today's world of SOA services. One of the chief problems with services is imposing order around their definition and classification. After all, virtually anything with an API (Application Programming Interface) can be described as a service. That's pretty broad.
Imagine an enterprise or conceptual model of services. These would represent the core set of capabilities being offered and supported. The external view would then correspond to the usage of a service by an application or another service. The internal view would map to an underlying implementation of the service. While it's true that data and services are most definitely not the same, I believe both share the same basic need for a coherent way of organizing, classifying, and categorizing. The three schema approach has worked phenomenally well for data. I personally think it's worth considering for services too. As stand-up comedian Dennis Miller used to always say on his Saturday Night Live "Weekend Update" rants, "Of course, that's just my opinion. I could be wrong."
posted by ITscout at 12:30 PM
Site Feed
2 Comments:
I plan to use the ANSI/SPARC three-schema approach to classify services as you describe and I also will use it to classify the inputs and the outputs. My thought is that doing the input and output analysis from the 3 schema perspective might provide some insight from a portfolio optimization and ontology definition perspective.
I also like this way of representing services. ITIL could better be explained in these terms as well. Infrastructure of IT as internal, business services as conceptual, and ITIL processes as the external view.
Post a Comment
<< Home