OData from the ground up….
Welcome to a blog about OData, soon to be the lifeblood of SAP!
OData is fast becoming one of the key technologies here at SAP. It is cutting a swathe across all the key technologies and togther with SAP UI5 will accelerate application development for SAP and partners. It will transform KPI’s by decreasing a broad range of TCO’s and increasing reuse across mobile platforms and desktops through its use of open source frameworks and technologies.
This blog series will begin by examining some of the structure behind OData and then go through some to the questions I have often seen asked by people starting to develop with OData. If you are not familiar with OData now would be a good time to visit the OData website (http://odata.org) and view the specifications, libraries and sample services.
For an environment to experiment in with OData, I recommend you install a REST plugin into your browser or use a command line tool such as cURL (http://en.wikipedia.org/wiki/CURL) to examine the headers and cookies that are returned and uploaded to the server as there is sometimes interaction that is not immediately obvious just from the url.
What is OData? From the OData.org website:
“The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today”
This definition provides the foundation for OData, it is a scopes OData to a protocol to manipulate and retrieve data and expose in an open manner to callers to allow them to manipulate the data and thereby create new uses for the data throughout the enterprise and wider ecosphere.
OData can be thought of as SQL for the internet. Conceptually it may be thought of as applying SQL to a table but not a database. This means that operations such as joins, unions and composite views will not be supported as is changing the structure of the table. Saying that however searching, sorting, filtering, insertion, removal are all supported since these are related to a table.
SQL traditionally has supported a DDL or a Data Definition Language and a DML or Data Manipulation Langage. This is mapped to OData smantics via the Entity Data Model (EDM) for the DML and a Service Data Model that is based on REST type idioms for the DML. The next session will cover the different types of EDM’s and service models.