REST и CRUD против RPC

Развитие сетевых коммуникаций началось со специализированных протоколов, заточенных под прикладные нужды и повторяющих функциональность друг друга во многих случаях. Концепция эта называется RPC (Remote Procedure Call) или вызов удаленных процедур. Характеризуется RPC тем, что функциональность приложения полностью отображена в наборе команд протокола, например: FTP, POP, NNTP, протоколы СУБД, не говоря уже про многочисленные протоколы систем промышленной автоматизации или прикладных систем. Более поздние RPC стали абстрактными, т.е. появился некий стандарт, описывающий протокол, а уже на его основе разрабатывались прикладные службы, обладающие конкретным набором команд, например: SunRPC, DCOM, CORBA, Java RMI, и т.д.

Следующий шаг заключался в ограничении набора команд до "универсального минимума" и перенесении всей смысловой нагрузки в параметры вызовов. Подход этот получил название CRUD по первым буквам команд (create, read, update and delete), а архитектура информационных систем, построенная на базе подхода - REST (Representational State Transfer). Клеинт-серверные приложения в CRUD/REST архитектуре работают ресурсом и вызовом, как основными абстракциями. Ресурс (чаще всего файл) - это ответ сервера, содержащий данные и текущее состояние. Состояние - это набор параметров ресурса, которые изменяются во времени. Запрос приводит к передаче ресурса на клиентскую сторону, где пользователь с ним работает и при следующем запросе отправляет ресурс обратно на сервер вместе с состоянием.

Таким образом, архитектура REST полностью отвергает возможность установления сессии, а следовательно не дает возможности хранения состояния на стороне сервера. В отличие от REST, сервера RPC ставят в соответствие определенную область памяти сервера с каждым подключенного пользователем, создают идентификатор сессии и устанавливают соединение: виртуальное (по идентификатору) или постоянное (не закрывая сокет между вызовами).

Преимуществом CRUD/REST архитектуры является простое масштабирование на кластеры, возможность применения облачных вычислений, простота применения для информационных, гипертекстовых и других типичных задач. Из недостатков можно привести: невозможность создания систем реального времени, избыточность трафика, отсутствие машины состояний, как необходимого средства при разработке сложных систем. Преимуществом же RPC архитектуры является отсутствие ограничений на набор команд, установление соединений и хранение состояния на сервере, в следствии чего, RPC до сих пор являются единственным средством разработки прикладных, промышленных и других сложных систем. А очевидным недостатком RPC является сложность разработки, отладки и внедрения, что естественно при большей гибкости.

Синтеза этих двух направлений пока на горизонте нет, что и заставляет автора данной публикации вести разработки и исследования в данном направлении. Описание гибридной архитектуры распределенных информационных систем с динамическим связыванием с использованием мета-данных мы пока готовим, а тем временем предлагаем Вашему вниманию обобщающую блок-схему, в которой показаны все, нам известные, элементы абстрактного слоя информационной системы. Какие-то элементы могут быть более развиты в конкретной реализации, другие - быть в зачаточном состоянии или отсутствовать, но это уже определяется целесообразностью в каждом конкретном случае.