RebelGeekz' Blog

Service Oriented Data Access or SODA

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!

Print posted @ Tuesday, January 20, 2004 4:01 PM