• Artykuł

     

OData – nowy standard udostępniania i korzystania z danych, cz. 1

Udostępnij na: Facebook

Autor: Tomasz Wiśniewski

Opublikowano: 2010-12-01

Wstęp

Obecnie nie spotyka się już prawie w ogóle aplikacji, które nie korzystałyby z jakiegoś źródła danych. Począwszy od zwykłych plików tekstowych, poprzez bazy danych. W dobie coraz powszechniejszego dostępu do Internetu oraz szybkości, z jaką jest dostarczany użytkownikom końcowym, coraz więcej aplikacji korzysta z internetowych źródeł danych. Źródła mogą być różnego rodzaju, może to być np. baza danych, która do tej pory działała na serwerze bazodanowym, w serwerowni firmy, a teraz została przniesiona do chmury i umieszczona na platformie SQL Azure. Dużo częściej jednak spotykaną sytuacją jest korzystanie z różnego rodzaju serwisów. Takie podejście powoduje, że brak jest spójności w sposobie dostarczania danych przez takie serwisy. Implikuje to poważne problemy zarówno od strony aplikacji, która ma korzystać z jednego bądź wielu źródeł danych, jak i od strony producenta takich danych, który być może chce, aby maksymalnie wielu klientów mogło z nich korzystać.

Powyższy problem rozwiązuje nowy protokół stworzony przez firmę Microsoft – Open Data Protocol, w skrócie OData.

Ta seria artykułów ma na celu przedstawienie protokołu począwszy od informacji o samym protokole, sposobów korzystania z takiego źródła danych, manipulowania tymi danymi oraz tworzenia własnych źródeł, które będą udostępnione za pomocą nowego mechanizmu.

Wprowadzenie

Przede wszystkim należy uświadomić sobie, jaka zmiana zaszła w sposobie korzystania przez użytkowników z aplikacji, a w szczególności aplikacji internetowych. Przykładem takiej witryny może być popularny serwis „mikroblogowy” – Twitter. Trzonem tego serwisu jest API (Application Programming Interface), które jest wykorzystywane przez witrynę internetową stworzoną przez twórców serwisu. Witryna ta oczywiście jest uruchamiana standardowo przez przeglądarkę internetową znajdującą się na komputerze użytkownika:

Rys.1. Schemat serwisu internetowego.

Należy zwrócić uwagę, że serwis chcący stać się popularnym i często odwiedzanym przez użytkowników musi być dostępny na wielu platformach. Począwszy od systemu operacyjnego zainstalowanego na komputerze użytkownika, jego telefonie komórkowym, a w ostatnim czasie także w  telewizorze, który może mieć dostęp do Internetu. W związku z czym obecny schemat aplikacji/serwisu można zilustrować poniższym rysunkiem:

Rys.2. Schemat serwisu i korzystających z niego klientów.

Taki schemat jasno wiąże się z dwoma pojęciami istniejącymi obecnie w branży, a są to:

  • Three screens – czyli idea, o której wspomniano wcześniej. Idea, która mówi, że użytkownik powinien mieć dostęp do swoich danych, serwisu w zunifikowany sposób zarówno na swoim komputerze osobistym, telefonie czy urządzeniu multimedialnym, jak i np. w telewizorze.
  • Services PoweringExperience - idea głosząca, że to różnego rodzaju serwisy/usługi są motorem doświadczeń użytkowników z ich ulubionymi portalami, aplikacjami. Niezależnie od wybranej platformy klienckiej, te doświadczenia podczas użytkowania powinny być jednakowe.

W związku z tym ponownie pojawia się pytanie, w jaki sposób można dostarczyć dane dla aplikacji końcowych, a dodatkowo – aby sposób, w jaki będę korzystać aplikacje z tych danych, był spójny i zestandaryzowany.

OData – definicja i budowa

Open Data Protocol jest to protokół sieciowy, który służy do pobierania i aktualizowania danych. Jego ogólną budowę można przedstawić za pomocą następującego równania:

OData = HTTP/ATOM + Query + JSON + Metadane

Omówmy poszczególne elementy:

— HTTP – komunikacja przy użyciu OData odbywa się poprzez standardowy protokół HTTP. Obsługiwane są podstawowe metody protokołu, takie jak GET, PUT, POST czy DELETE, dzięki czemu istnieje pełen zakres możliwości manipulowania danymi. Oczywiście to, co użytkownik może wykonać, można bardzo szczegółowo zdefiniować, co zostanie omówione w innym artykule z tej serii.

— ATOM – dane reprezentowane są domyślnie w standardzie Atom Publishing Protocol (AtomPub), który z kolei zbudowany jest na bazie formatu Atom Syndication Format (Atom). Dzięki temu już od dawna istniejące aplikacje, takie jak np. czytniki RSS, potrafią w odpowiedni sposób zinterpretować źródło OData. Oczywiście sam protokół dodaje nowe elementy. Są to m.in.: sposób, w jaki reprezentowane są dane strukturalne, schemat adresowania oraz opcje omówione poniżej.

— Query – OData dostarcza znane m.in. z języka TSQL operatory, pozwalające zawężać ilość zwracanych danych oraz odpytywać tylko o istotne w danym przypadku informacje. Są to m.in. takie operatory, jak $select, który umożliwia zwracanie, projekcję tylko określonych właściwości encji (http://przykladowyserwis.pl/Kolekcja?$select=Wlasciwosc), $filter (klauzula WHERE) – umożliwia określenie warunków, jakie muszą spełnić dane, aby zostały zwrócone (http://przykladowyserwis.pl/Kolekcja?$filter=(Wlasciwosc eq 15)), czy też $orderby, dzięki któremu można posortować dane wg zadanych kryteriów (http://przykladowyserwis.pl/Kolekcja/?$orderby=Wlasciwosc desc). Więcej operatorów, jak ich używać oraz ich szczegóły zostaną przedstawione w osobnym artykule.

— JSON – nie zawsze wygodnym formatem dla programistów są dane w postaci XML, jak ma to miejsce w przypadku używania AtomPub-a. Jeśli ktoś korzysta w swojej aplikacji z JavaScript lub różnych bibliotek rozszerzających jego możliwości, jak np. jQuery, wygodniej jest korzystać z danych przedstawionych w formacie JavaScript Object Notation. Protokół OData umożliwia jawne zdefiniowanie, w jakim formacie mają zostać zwrócone dane, poprzez użycie operatora $format, który może przyjąć jedną z trzech podstawowych wartości: atom, json, xml. Dodatkowo mogą to być inne wartości, jeśli stworzony serwis będzie potrafił odpowiednio zinterpretować wartość operatora (http://przykladowyserwis.pl/Kolekcja?$format=json). Warto zwrócić uwagę na to, że format JSON zajmuje znacznie mniej miejsca niż jego XML-owy odpowiednik. Może mieć to duże znaczenie w momencie zwracania znacznej ilości danych, w przypadku powolnego łącza lub jego ograniczeń.

— Metadane – każdy serwis udostępnia specjalny dokument serwisowy, który można wyświetlić za pomocą operatora $metadata (http://przykladowyserwis.pl/$metadata). Zawiera on w sobie opis wszystkich kolekcji, encji, ich właściwości czy też relacji pomiędzy nimi. Dzięki takiemu dokumentowi w bardzo prosty sposób, parsując go, można dowiedzieć się wszystkiego o danym serwisie bez potrzeby przeprowadzania pracochłonnej i skomplikowanej analizy danych w celu uzyskania informacji o jego strukturze.

Schemat architektury

Poniższy rysunek przedstawia schemat architektury działania protokołu OData:

Rys.3. Schemat aplikacji wykorzystującej OData.

Pierwszą rzeczą, na którą warto zwrócić uwagę, to fakt, iż protokół OData jest niezależny od źródła danych. Może to być relacyjna baza danych, która w aplikacji jest zmapowana za pomocą narzędzia ORM, takiego jak np. Entity Framework. Mogą to być także klasy zdefiniowane przez programistę, które mają być udostępnione przez protokół. Takie klasy będą implementowały interfejsy IQueryable oraz IUpdatable. Pierwszy z nich będzie umożliwiał zwracanie wyników, drugi natomiast operacje związane z dodawaniem, aktualizowaniem i usuwaniem danych. Źródłem danych może być też cokolwiek innego. Potrzebne w tym momencie staje się napisanie dostawcy dla danego źródła, który będzie implementował wszystkie mechanizmy związane z OData, jak np. translatory, które będą potrafiły przetłumaczyć zapytanie LINQ na adres URL.

Dane publikowane za pomocą Open Data Protocol mogą w pełni respektować logikę biznesową narzuconą przez aplikację, autentyfikację oraz autoryzację. Odbywa się to za pomocą dwóch mechanizmów – service operations oraz interceptors, które zostaną omówione w artykule dotyczącym tworzenia własnego serwisu OData.

Dostawcy, logika, autentyfikacja i autoryzacja publikowane są za pomocą biblioteki, która implementuje protokół OData. W przypadku aplikacji .NET (tak jak na powyższym schemacie) jest to WCF Data Services (.NET 4.0), znane wcześniej jako ADO.NET Data Services (.NET 3.5). W chwili pisania tego artykułu istnieją biblioteki implementujące OData po stronie serwerowej dla Javy oraz Ruby. Przy czym ta druga implementacja jest jeszcze w bardzo wczesnej fazie rozwojowej.

Biblioteki serwerowe poprzez HTTP komunikują się z bibliotekami klienckimi, które są osadzone w aplikacjach końcowych. Obecnie istnieją biblioteki dla .NET, ale także dla PHP, Javy, JavaScript, Objective-C, Ruby czy też Windows Phone 7.

Jak widać, na każdej prawie platformie programistycznej jest możliwość korzystania z danych publikowanych przez OData już za pomocą gotowych bibliotek, dostarczanych zarówno przez firmę Microsoft, jak i społeczności programistów skupione wokół danego języka.

Dodatkowo protokół ten rozprowadzany jest na licencji Microsoft Open Specification Promise, która określa pełną możliwość implementacji protokołu na różnych platformach, z zachowaniem pewności, że firma Microsoft nie będzie w związku tym występowała z żadnymi roszczeniami w stosunku do twórców takiej implementacji.

Podsumowanie

Open Data Protocol (OData) jest otwartym protokołem sieciowym, który umożliwia pobieranie oraz aktualizowanie danych poprzez standardowy protokół HTTP, przy wykorzystaniu spójnych konwencji adresowania. Konwencje te są niezależne od platformy, która publikuje dane, oraz platformy, która z nich korzysta. Protokół jest niezależny od źródła danych, co poszerza jego zastosowanie. Posiada implementacje na wiele platform oraz licencję, a licencja go obejmująca zachęca do tworzenia własnych implementacji.

W kolejnym artykule zostanie przedstawiona struktura dokumentu z danymi zwracanymi przez OData, dokument z metadanymi oraz omówione zostaną operatory, które umożliwiają pobieranie danych oraz ich filtrowanie, sortowanie itp.