WORKBOOK Messaging Data Formats

03
LESSON
and Data Models

® ® ®

TRAINING TRAINING CERTIFIED

Fundamental Fundamental Microservice
Module 02 Microservice Microservice
Technology
Service
Technology
Professional

Technology Concepts
Lesson 3: Messaging Data Formats and Data Models
Service consumers interact with Web-based services through the exchange of messages that
are expressed using industry data format languages. The two most common data formats are:
• Extensible Markup Language (XML)
• JavaScript Object Notation (JSON)
Schema definition languages are used to describe the vocabulary, structure, and data types of
message contents, many of which can represent common business documents, such as
invoices and purchase orders.
A schema language essentially provides a means of expressing the definition of a data model
for the message vocabulary in a manner that enables message contents to be validated against
a schema definition at runtime.
When messages are formatted in XML, XML Schema Definition (XSD) can be used to define
the structure of these messages. When the messages are exchanged in JSON format, JSON
Schema can be used to define their data models.
XML messaging is relevant to both SOAP-based Web services and REST services. JSON
messaging is relevant primarily to REST services.

Serialization and Deserialization

The process of preparing or moving data from an in-memory format (like a Java object) to a
neutral format is called serialization. Data that has been serialized typically exists in a text-
based format (such as XML or JSON) and is suitable for storage or network transmission.
When serialized data is used to reconstruct an in-memory format, deserialization is performed.
Schema languages must have the ability to describe complex data types, which represent
nested structures. For example, an invoice has a relationship to a customer. Therefore, one
entity contains another. In this way, a schema is somewhat comparable to database data
models, which in turn makes serialized documents comparable to database records. Unlike
data representation in relational databases, serialized data needs to be based on a nested or
hierarchical structure, as shown in Figure 2.10.

Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0

Figure 2.10 – Relational data becomes hierarchical when serialized in XML format.

XML
The Extensible Markup Language (XML) allows both the meaning and context of any piece of
information to be encoded, allowing data to be represented in a standardized manner. XML is
the basis of a wide range of related technologies, including:
• XML Schema Definition Language (XSD) – for data model definition
• XML Style Sheet Language Transformations (XSLT) – for XML document transformation
• XML Query Language (XQuery) – querying of XML documents
• XML Path Language (XPath) – addressing specific content in an XML document
Of these technologies, we’ll be taking a closer look at XSD.

XML Schema
The XML Schema Definition language is used to create a data model for XML-formatted
documents. An XML schema defines a set of related XML elements which represent a
vocabulary. Each element is defined to have a specific vendor-neutral data type.
Elements that only contain values have simple types. All attributes have simple types because
they only contain values. Simple types are used to refer to built-in data types. However, they
may be further specialized via restrictions.
Elements that contain child elements or attributes have complex types. Complex types are
typically element hierarchies that represent a collection of related data. For example, Figure
2.11 shows that an Address is a hierarchy of related elements. When creating service
contracts, it is common for complex types to represent the entire structure of input and output
messages.
Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0
Figure 2.11 – Address information organized into a hierarchy to form the basis of a complex type.

As shown in Figure 2.12, XML schemas protect the integrity of XML documents by allowing
them to be validated against defined:
• structure
• validation rules
• constraints

Figure 2.12 – An XML schema defining the structure, rules, and data types of XML document data.

An XML schema usually exists as a separate file in which the data model and vocabulary for a
specific type of XML document is defined, as shown in Figure 2.13.

Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0

Figure 2.13 – An example of an XML schema.

Multiple XML documents can link to the same XML schema definition. One XML document can
link to multiple XML schema definitions. XML schemas can also be embedded within XML
documents. But most commonly, XML schemas exist as separate files.
Since an XML schema document is an XML document, it is capable of linking to other XML
schema documents. This capability enables the creation of modular schemas that can be
combined. The use of modular schemas promotes reuse and the ability to create reusable
standardized schemas.
Schema definitions can also be dynamically extended with supplementary constructs, further
promoting reuse of existing schema definitions. Parts of a schema definition can also be
redefined (overridden) by other schema definitions. The practice of redefinition must be applied
with care and not as an excuse not to correct modularity concerns or other deficiencies in the
base schema.

Namespaces
Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0
Namespaces are an important aspect of XML-based document exchange as they establish a
means of creating unique identifiers. Every standardized XML vocabulary (including XML
Schema, WSDL, SOAP, WS-Addressing, WS-Policy, etc.) has an associated namespace.
When elements from different vocabularies are mixed together in the same XML document, the
XML parser can figure out which vocabulary each element belongs to.
A namespace declaration establishes a prefix:
abc=“123”
In this case, abc is an alias used to represent the namespace 123. The prefix is associated
with elements as follows:
abc:Invoice
The Invoice element is associated with the 123 namespace because it is prefixed with abc.

JSON
The JavaScript Object Notation (JSON), like XML, is a text-based data interchange format. It is
considered to be more lightweight than XML. Although originally closely tied to JavaScript,
JSON is supported by many programming languages.
JSON can represent four primitive types: strings, numbers, booleans, and null. It also supports
two structured types: objects and arrays.
JSON syntax is derived from JavaScript syntax:
• data is in name/value pairs
• data is separated by commas
• curly braces hold objects
• square brackets hold arrays

Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0

Figure 2.14 shows an example JSON document with contact information.

Figure 2.14 – A JSON format representation of a contact, which consists of an address object and phoneNumber
array.

Some common JSON-based technologies include:

• JSON Schema - defines a JSON-based format for describing the structure of JSON data
• JSON Pointer – defines a string syntax for identifying a specific value within a JSON
document
• JSON Patch – defines a JSON document structure for expressing a sequence of operations
to apply to a JSON document to update its contents
Of these technologies, we’ll be taking a closer look at JSON Schema.

JSON Schema
Much like XML Schema, the JSON Schema language allows for the definition of a data model.
Specifically, JSON Schema is a declarative language for defining and validating the format and
structure of a JSON document (Figure 2.15). It has capabilities for combining, reusing, and
extending schemas.

Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0

Figure 2.15 – A JSON schema that defines the data model for the contact information shown in Figure 2.14.

References and definitions are the main mechanisms within JSON Schema that support reuse.
The root schema may contain a definition container that holds the definitions for named sub-
schemas that can then be referenced.

Service Technology Concepts (Copyright © Arcitura Education Inc. www.arcitura.com) v10.0