When you’ve been around the “software programming block” for a while, you can almost telepathically understand the motivation behind certain programming constructs and tools.
In particular, the concept of serialization and deserialization. In a nutshell, it’s a way to “freeze dry” code, much in the same way you can take freeze-dried coffee and other perishable food items with you on a camping trip, to save weight, and restore them back to their original flavorful state with a little water.
To understand why serialization and deserialization is such a powerful and popular mechanism in software programming, it’s helpful to understand what problem it’s trying to solve.
When the internet as we know it today was first born, it ushered in a brand new age of software programming. The internet suddenly opened up the ability to connect different applications and systems together in a super-connected way.
Suppose the sales division of an organization built an application to track new and existing sales orders. Before the advent of the internet, this sales order application was most likely operating in an isolated environment… typically only salespeople would be able to access the data from this application.
But internet technology suddenly opened up a whole new world of possibilities for software development. Now the data stored from that sales application could suddenly be shareable with other applications within the same organization. From a business perspective, the sales and order fulfillment/shipping departments are closely related to each other.
A customer initiates a sales order, but the sale isn’t complete until the product or service is delivered to the customer. So it stands to reason you want to share as much data as possible between the sales and shipping departments. And the internet brought about a whole new set of technologies and tools to make this happen much easier and faster.
Two of the core concepts that allowed for this new age of superconnectivity between software systems and applications come from XML and web services.
1. XML
XML, short for Extensible Markup Language, was created as a universal data exchange format.
Going back to the example of the sales and shipping departments of an organization, let’s examine how one would go about attempting to share data between the two systems.
Many organizations have typically operated in silos. I like to call it the “fiefdom” syndrome, where each department or division is responsible for their own sliver of the business. The sales department is only concerned with sales orders, shipping is only concerned with shipping details, etc, etc.
The problem with silos from a software application perspective is it typically results in highly siloed applications and systems that make it difficult to share data and functionality with each other.
Perhaps the sales department stores all their sales data in Microsoft Excel data sheets.
And maybe the shipping department stores all their shipping related data inside of an Oracle database.
It becomes a challenge trying to figure out how to share the data between both systems.
The problem is each system uses its own unique data formats that aren’t interchangeable.
Enter the invention of XML.
XML is an easy to understand data format. Even if you’ve never heard of XML, you can take a quick glance at an XML snippet and get a rough idea of what the data is supposed to convey.
Take a sales order. Using the XML data format, you could create a sales order that could look something like this:
<sales-order>
<create-date>10-1-2017</create-date>
<sales-total>$120.00</sales-total>
<customer-name>John Smith</customer-name>
<sales-item>widget1</sales-item>
<quantity>2</quantity>
</sales-order>
The XML format is self descriptive. Even if you’ve never worked with or seen XML before, it doesn’t take a lot to understand what the XML snippet is trying to convey.
Based on the sample XML, one can deduce it represents a sales order created on 10-1-2017 for a sales total of $120.00 by a customer named John Smith, who ordered 2 quantities of a sales item called “widget1”.
2. Web services
The second core technology concept that helped to revolutionize the way different systems could communicate and share data with each other was the invention of the web service.
Web services allow two systems or applications to send and receive XML data payloads to each other, typically via the http internet communication protocol.
If you were the enterprise architect or developer responsible for developing a way for the sales department application to share data and communicate with the shipping department application, you could create a web service endpoint that would shuttle XML data back and forth between the sales and shipping departments.
Web services are an extremely versatile and powerful tool to connect different disparate systems together. Web services are so flexible and versatile, you can even connect different systems and applications together between completely different organizations across the internet.
Thanks to the power of web services and XML, you could create a web service endpoint to shuttle important data back and forth between one company from China and a completely different company halfway around the globe in South America.
The problem for software developers is manipulating and parsing XML is a tedious process.
Back in the early days of XML, you really had no choice as a software programmer, but to manually parse out the XML data with a lot of string manipulation and dealing with all the angle brackets in an XML document.
Querying for certain data elements could be challenging, the more complex the XML data structure became.
And if there’s one thing that software developers absolutely hate, is doing things THE HARD WAY.
Enter stage left, the magic of serialization and deserialization.
How Serialization and Deserialization Works
Object-oriented programming became popular just around the same time when web services first came about. Object-oriented programming allows software developers to break down complex software application requirements into more manageable chunks of functionality referred to as objects.
With the power of serialization and deserialization, a software developer can take the raw XML traveling across the wire inside of a web service, and convert it into a fully hydrated object, which is much easier for a developer to query and manipulate. This process of converting raw XML to an object is referred to as “deserialization”. By deserializing a raw XML data string into an object, a developer no longer has to deal with the tedious intricacies of XML angle bracket parsing.
Serialization is the opposite process of take a fully hydrated object and converting it to the XML data format needed from web services, as it travels across the wire from a source endpoint to a destination endpoint.
You’re essentially “freeze drying” a hydrated object into an XML data string, using serialization, and “hydrating” the raw XML back into an object through deserialization.
XML is still very much in use in today’s technology landscape, but as with anything else in technology, there is always some new technology or concept around the corner.
JSON, short for Javascript object notation, is a newer data format that is more compact than XML, which makes web service communication more efficient and quicker across the wire.
So an XML document that would look something like this:
<!DOCTYPE glossary PUBLIC “-//OASIS//DTD DocBook V3.1//EN”>
<glossary><title>example glossary</title>
<GlossDiv><title>S</title>
<GlossList>
<GlossEntry ID=”SGML” SortAs=”SGML”>
<GlossTerm>Standard Generalized Markup Language</GlossTerm>
<Acronym>SGML</Acronym>
<Abbrev>ISO 8879:1986</Abbrev>
<GlossDef>
<para>A meta-markup language, used to create markup
languages such as DocBook.</para>
<GlossSeeAlso OtherTerm=”GML”>
<GlossSeeAlso OtherTerm=”XML”>
</GlossDef>
<GlossSee OtherTerm=”markup”>
</GlossEntry>
</GlossList>
</GlossDiv>
</glossary>
could be expressed in the JSON data format like this:
{
“glossary”: {
“title”: “example glossary”,
“GlossDiv”: {
“title”: “S”,
“GlossList”: {
“GlossEntry”: {
“ID”: “SGML”,
“SortAs”: “SGML”,
“GlossTerm”: “Standard Generalized Markup Language”,
“Acronym”: “SGML”,
“Abbrev”: “ISO 8879:1986”,
“GlossDef”: {
“para”: “A meta-markup language, used to create markup languages such as DocBook.”,
“GlossSeeAlso”: [“GML”, “XML”]
},
“GlossSee”: “markup”
}
}
}
}
}
While the data format is different, the need to easily parse through the data remains the same for software developers.
Which is why there are also lots of tools and software libraries that allow you to serialize and deserialize JSON data into objects as well.
I’ve been using the power of serialization and deserialization a lot, for one of my recent projects… freeze-drying XML and hydrating XML back to my favorite objects.
It’s nice to know someone lazier than myself had the foresight to invent serialization and deserialization… who says laziness isn’t the mother of invention?
