Service Oriented Data Access

In short, SODA.

From http://geekswithblogs.net/rebelgeekz/archive/2004/01/20/1408.aspx

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.