mapping local and often partial models that not only are different models
of the same application domain, but
also differ, implicitly or explicitly, in
their associated metamodels.
This challenge is central in the
design of interfaces for machine-to-machine communications over the
Web because in the general case, no
entity can authoritatively and unilaterally define the interfaces and data
models or choose the metamodel that
describes them.b On the Web, when
peers use different conceptual models
internally, they still can collaborate by
using an intermediate model as a representation for their communications.
This requires that each peer has a way
of mapping its own conceptual model
to the intermediary model’s conceptu-
b This of course may be different if single entities or coordinated groups like standards organizations define shared data models, but even
then this “one true model” only applies to the
members of this group, and may not necessarily fit the needs and constraints of other potential users outside of the group.
al model, which is then serialized according to the representation defined
for that model, and then subsequently
parsed, instantiated, and mapped to
the other peer’s conceptual model.
This description may sound as if
the intermediary model now is the
“one true model” mentioned earlier.
The important difference to the assumption that there is an implicit
model in all collaborating applications is that the Web approach focuses on exchange-oriented resource representations and employs those as the
way how data models are represented
for communications. However, this
article is not about the concept of resource-orientation in the abstract (see
Prescod4 for a good discussion of the
fundamental differences of approaches); it is about the question of how to
properly apply this concept by designing representations for the specific
purpose of supporting interactions.
Somewhat paradoxically, mapping
and serializing models is made more
difficult by the flexibility and ubiquity
of the Extensible Markup Language
(XML). Many people assume that
merely by providing XML-based representations, universal interoperability
and loose coupling can be achieved
almost magically5—even though different metamodels that simply have
some XML representation may make
it almost impossible to access the
conceptual information in such an
XML serialization by using XML tools
alone. In many cases, this exaggerated expectation of what XML can do
is caused by mixing modeling layers,
for example by assuming that any data
serialized as XML can be conveniently
processed using XML tools.
Without further qualification, the
argument that “we use XML, which
is a widely accepted data format,
and thus our interface is easy to use”
makes about as much sense as “we
use bits, which are a widely accepted
data format, and thus our interface is
easy to use.” On a simplistic technical level, these statements are true,
but it is essential to understand the
assumptions about application-level
models and required tools that are
implicitly designed into interfaces,
because these assumptions critically
shape their usability and accessibility (borrowing these terms from user
interface design). Usability refers to
the ease of use of a given interface and
how easy it is for users to accomplish
their goals; accessibility measures the
extent to which it is possible to access
all relevant information through a given interface when accessing it using
various access methods.
In the context of designing Web
service APIs, there is an ongoing debate about function-orientation, often associated with the concept of
Remote Procedure Calls (RPC), vs. resource-orientation as the preferred architectural style for designing loosely
coupled information systems. Function-orientation overlaps in many
ways with the concepts of object-ori-entation (encapsulation and access
through public methods), whereas
resource-orientation focuses on the
exchange of purposeful and self-contained documents. While the function-oriented style uses encapsulation
and remote access to encapsulated
data models through application-spe-cific functions, the resource-oriented