Now that SOA is taking the world by storm, this is the time to define the format that will be used to exchange data in this new architecture ruled by messages. Welcome to the world of SODA.
SODA stands for Service Oriented Data Access and it has been conceived to provide a mechanism to represent data in a simpler and more powerful way than other formats like XML.
Let's take a look at some basic samples for a better understanding:
Employee { Name = "John Doe"; Age = 35; Hired = 05/10/2003; Salary = 75000.00; isActive = true; }
As you can see, every element has an implicit type which makes its schema definition easier to represent:
Employee { string Name; integer Age; datetime Hired; decimal Salary; boolean isActive; }
By now you may have noticed that tags are not required, reducing the size of the message almost in half, a great advantage over other bloated formats.
Now let me show you the basic syntax rules and types of SODA and what we can do with it:
Syntax:
Type Element [...] // Element definition [Attributes] Element:Type // Element is of Type Parent.Element // Element is child of parent Element=Value // Element has value Element(val1,...) // Element has required values Element{ ... } // Element is complex
The content of a message can be represented with just a few basic types:
string number datetime and boolean.
Other types used to better define the schema of messages are:
byte short long integer decimal complex date datechar and many more.
Now, let's play with SODA to represent all possible kinds of data to see if it fits our needs:
Here are some samples:
// Simple object File { Name="britney.jpg"; Size=145789; Type="JPEG"; Created=2003/12/24 08:30:15-04; }
// Complex object Client { Name="John Doe"; CreditLimit=$9875.50; Address { Street="123 NW"; City="Sunny Beach"; State="FL"; } }
// Arrays Employee { Name="John Doe"; Phones={"555-1234","555-4321","555-9999"}; // Simple array of strings DailyHours ={8,4,8,9,8}; // Simple array of integers WeeklyHours={8,4,8,9,8} // 2D array of integers {8,8,7,8,8} {8,6,7,8,6} {5,4,8,9,8}; }
// Collections Member { Name="John Doe"; PolicyNumber="123456-987"; Dependants={"Jane Doe" ,32,1970/03/20} {"Jimmy Doe", 7,1997/10/12} {"Jamie Doe", 4,1999/08/24}; }
If we already now the schema of the message, we can imply the dependants type:
// Schema Class Member { string Name; string PolicyNumber; Person[] Dependants; } // Schema Class Person { string Name; integer Age; date DateOfBirth; }
Now imagine sending a table or excel sheet over the wire using SODA:
WeeklySales { WeekEnded=2003/12/31 23:59:59-04; SalesData={"Jeans" , $12345.47, $53656.56, $98634.31, $32130.90} {"Shirts", $3655.30, $4245.01, $3644.22, $4532.70} {"Pants" , $45756.57, $53324.55, $96537.13, $63456.50} {"Shoes" , $2455.78, $5432.07, $5654.55, $7232.40} {"Hats" , $7945.69, $3455.56, $3530.67, $4566.30}; }
Note: Don't try this at home with XML, the results can be very frustrating.
The greatest advantage of SODA is that it allows the unification of relational data, objects and messages (ROM) since all of them share the same syntax and schema.
Remember, the underlying architecture for message exchange and web services remain the same, only the format becomes irrelevant.
Let's unify the world!