API RESTful являются необходимой технологией для мобильных приложений / приложений интеграции, но их дополнительная стоимость может не гарантироваться для веб- приложений. Проблема в том, что требования к мобильности / интеграции могут появиться позже, и система не предназначена для ответа.
Но можем ли мы представить технологию, которая делает создание API быстрее и проще, чем создание монолитных приложений? Такая технология будет переломным моментом в экономике архитектуры.
Бизнес-драйвер: потребность в скорости
Лидеры отрасли, такие как CA, первыми разработали концепцию бизнеса, управляемого программным обеспечением . Они убедительно утверждают, что стратегическое бизнес-преимущество заключается в «Время выхода на рынок» и «Время принятия решения»:
«Выявить потребность в скорости в экономике приложений. По мере того как компании превращаются в управляемые программным обеспечением предприятия, быстрое продвижение высококачественных приложений на рынок становится одним из важнейших отличий ».
Нам всем до боли известно, что бизнес-пользователи разочарованы тем, сколько времени требуется для создания и пересмотра систем. Они видят проблемы, которые выглядят почти так же просто, как электронные таблицы, занимающие недели… или месяцы.
Как ИТ-отделам может потребоваться месяцы для создания системы, которая занимает несколько дней в электронной таблице?
Техническая реальность: API правильные … но дорогие
На этом фоне рассмотрим архитектуру веб-проекта. Хорошо известно, что RESTful API обеспечивает надежный сетевой доступ к базе данных. Такая архитектура ставит организацию в отличную форму для будущих требований, таких как мобильная связь или интеграция.
Но REST API — это гораздо больше, чем простой доступ к данным. «Пропуск SQL» — простое изменение данных SQL — не соответствует требованиям корпоративного класса для масштабирования, интеграции и применения:
- Масштабирование — API требуют разбиения на страницы для обработки больших результирующих наборов, вложенных документов для уменьшения задержки, оптимистической блокировки для обеспечения параллелизма. Они не предоставляются в простом сквозном коде SQL — вы должны программировать их вручную.
- Интеграция — мастер может создать API из объектов схемы, но он не может обращаться к нескольким базам данных или интегрировать источники данных, отличные от SQL, такие как ERP, другие службы RESTful или NoSQL.
- Enforce — API должен обеспечивать нашу безопасность (вплоть до уровня строк) и целостность данных. Это важные задачи, которые, к сожалению, часто помещаются в клиентские кнопки, где их нельзя разделить.
Предоставление этих услуг корпоративного класса требует значительного времени, опыта и затрат. Таким образом, у нас есть классическое столкновение между «правильным» и временем выхода на рынок:
Мы знаем, что REST — превосходный подход.
Но нехватка времени ведет нас к традиционным подходам.
Толстый клиент: логика (и стоимость) в кнопках
Время не ограничивается API, оно прямо влияет на дизайн приложения. Логизировать целостность и логику безопасности в сервисах гораздо сложнее, поэтому мы просто помещаем их в «кнопки» (контроллеры пользовательского интерфейса). Это иногда называется Fat Client (не путать с rich client), анти-паттерн:
- Толстый клиент копирует логику, что приводит к ошибкам. Например, размещение нового заказа может проверить кредит, но кнопка «выбрать другой продукт» может не сработать.
- Fat Client может снизить производительность с помощью дополнительных вызовов базы данных, которые должны выполняться ближе к базе данных.
- Логика Fat Client не может быть легко извлечена в будущий сервис для доступа через интеграцию или мобильные приложения; переписывание обычно требуется.
- Логика Fat Client не разделяется между гетерогенными технологиями веб-клиента.
Институционализация проблемы
Тем не менее, большинство организаций вынуждены реагировать на нехватку времени, принимая, что бизнес-требования перевешивают техническую корректность. Трудно утверждать, что это неправильно. Вероятно, это правильное деловое решение, учитывая текущий технологический ландшафт.
Некоторые организации, принимая неизбежность времени и качества, зашли настолько далеко, что институционализировали проблему. Определить 2 архитектурных стандарта:
- Ведомственные: для небольших тактических проектов используйте знакомые инструменты RAD и выполняйте работу быстро.
- Предприятие: для крупных стратегических проектов используйте другой подход (например, J2EE) для управления сервис-ориентированной архитектурой
Это довольно ужасно. Мы признаем, что время и качество неизбежно вступают в конфликт, и поэтому продолжаем создавать неоптимальные системы, которые сталкиваются с проблемами мобилизации / интеграции / масштабирования, поддержки нескольких технологий (кривые обучения, специализация персонала) и т. Д.
Но что, если делать все правильно, так же быстро?
На самом деле, что, если делать это правильно, сэкономить деньги?
Что нужно, так это технология, способная устранить компромисс между временем и качеством. Это может изменить экономическую архитектуру программного обеспечения.
Легко сделать «правильно»: Instant Enterprise REST
Такая технология существует. Мы называем это Instant Enterprise REST.
Чтобы включить бизнес, управляемый программным обеспечением, нам необходимо повысить уровень абстракции от кодирования до бизнеса. Нам нужно программное обеспечение для бизнеса.
Он состоит из 3 основных технологий:
- Enterprise Pattern Automation — создает API со встроенной масштабируемостью корпоративного класса (нумерация страниц, вложенные документы, оптимистическая блокировка и т. Д.)
- Декларативный — укажите свой API, политики интеграции и применения с правилами, подобными электронным таблицам, в простом пользовательском интерфейсе «укажи и нажми»
- Расширяемость — позволяет API-интерфейсам RESTful вызывать существующую логику внутри или вне JVM через стандартный серверный JavaScript.
Комбинация этих трех технологий позволяет вам создавать RESTful API-интерфейсы для серверных баз данных — половина вашей системы — в 10 раз быстрее. Давайте кратко рассмотрим их ниже.
Технология 1: Enterprise Pattern Automation
В области данных есть хорошо известные шаблоны, описывающие структуру данных и доступ через SQL. Существуют также хорошо известные шаблоны для управления данными SQL в контексте служб RESTful.
Хорошо известные шаблоны могут быть автоматизированы. Давайте представим сервис (скажем, сервер, доступ к которому осуществляется через браузер), который автоматизирует эти шаблоны, как описано ниже, просто подключив сервис к базе данных:
- Обнаружение схемы — таблицы, представления, хранимые процедуры . Система создает полный (по умолчанию) API для каждого объекта схемы. Обратите внимание, что это включает хранимые процедуры, которые часто представляют собой значительные инвестиции.
- Enterprise Pattern Automation: получившийся API предоставляет хорошо известные сервисы для фильтрации, сортировки, разбивки на страницы, оптимистической блокировки, обработки сгенерированных ключей и так далее.
Таким образом, сервис мгновенно предоставил API по умолчанию для корпоративного класса. Итак, буквально за секунды в вашем проекте вы можете протестировать работающий API:
Не достаточно, не сделано, но отличное начало.
Технология 2: Декларативная
Декларативный является ключом («что, а не как»). Это оказало поразительное влияние на области, где есть хорошо понятные основные модели. Макс Тардиво хорошо выразился:
Все, что может быть декларативным, будет декларативным.
Например, электронные таблицы являются декларативными — и они породили индустрию ПК. А SQL декларативный — сам по себе индустрия. Два изменителя игры.
Таким образом, задача состоит в том, чтобы применить дух декларативного подхода к интеграции и реализации REST. Ставки высоки — успех может доставить захватывающую ловкость.
Декларативная интеграция: пользовательский API для нескольких баз данных, наведите и нажмите
Enterprise Pattern Automation обеспечивает хорошее начало, но API не богат. Это плоский API с одной таблицей, на самом деле просто «восстановленный» SQL. Что нам действительно нужно, так это
- Вложенные документы — возврат нескольких типов (например, заказа, списка товаров и списка имен контактов) в одном вызове может уменьшить задержку (по сравнению с отдельным вызовом для каждого типа). Отдых идеально подходит для этого.
- API для нескольких баз данных — сервер RESTful предоставляет возможность интегрировать несколько баз данных в один вызов, защищая клиентов от основной сложности.
Вложенные документы просты: определяйте их, просто выбирая таблицы (через пользовательский интерфейс или командную строку). Внешние ключи используются для объединения по умолчанию. Добавьте возможность выбирать / псевдоним столбцы, и мы находимся на пути к довольно хорошему API.
Но как насчет баз данных, в которых нет внешних ключей? Или API с несколькими базами данных?
Использование схемы не означает, что мы ограничены ею. Все, что нам нужно сделать, это:
- Предоставить средство для определения «виртуальных» внешних ключей для службы (т. Е. Хранящихся вне схемы)
- Распространите это на Foreign Keys между базами данных
Теперь у нас есть богатый API для работы с несколькими базами данных. Определяется декларативно, как показано ниже, код не требуется, выполняется за несколько минут, готов к разработке клиента:
Декларативное правоприменение: логика целостности с правилами, подобными таблицам
Итак, теперь рассмотрим правоприменение, в частности целостность базы данных Очень значительная часть любого проекта — это проверка нескольких таблиц и вычислений, которые определяют, как обрабатываются данные.
«Ваш код идет сюда» означает, ну, много кода. Нам нужна более мощная, более декларативная парадигма.
В электронной таблице вы назначаете выражения для ячеек. Всякий раз, когда ссылочные данные изменяются, ячейка обновляется. Поскольку ссылки на ячейки могут объединяться, ряд простых выражений может решить удивительно сложные проблемы.
Что если мы сделаем то же самое для данных базы данных? Мы могли бы присваивать производные выражения столбцам, а проверочные выражения таблицам. Затем API мог «отслеживать» запросы, которые изменяют указанный столбец, и повторно вычислять (эффективно) вычисляемый столбец. Как и в электронной таблице, поддержка цепочки и правильного упорядочения необходима и неявна.
Чтобы обратиться к многостоловой логике, такие выражения должны были бы обращаться к ссылкам на связанные таблицы. Только в этот момент логика становится действительно мощной.
Давайте возьмем пример. Чтобы проверить кредит в приложении Клиент / Покупатель / Lineitem, мы могли бы определить выражения, подобные электронным таблицам, такие как:
На самом деле существует подразделение декларативного, которое решает эту проблему: Реактивное программирование. Здесь это декларативно , так как вам не нужно кодировать обработчик Observer.
В результате вышеприведенная логика может быть полностью исполняемой. Нет необходимости кодировать Обнаружение изменений / Зависимость изменений — он вызывается и принудительно применяется API в ответ на обновления RESTful. Обработка SQL также неявна, включая базовые оптимизации (кэширование, сокращение и т. Д.).
Влияние огромно — пять выражений выше выражают ту же логику, что и сотни строк кода. Это в 40 раз более кратко . Изменитель игры.
И качество повышается, так как правила применяются автоматически.
Декларативное применение: безопасность, фильтрация выражений для роли / таблицы
Мы можем предоставить аналогичный подход к безопасности: определить выражения фильтра для ролей (например, SalesRep), чтобы при доступе таблицы к роли роль API добавляла фильтр. Таким образом, пользователь с этой ролью видит только те строки, для которых он авторизован.
Технология 3: основанная на стандартах расширяемость
Декларативное замечательно, но вы, вероятно, думаете «хорошо, но вы не можете решить каждую проблему декларативно». И ты совершенно прав.
Бизнес-ценность требует, чтобы мы объединили декларативный подход с процедурным подходом, который знаком, стандартизирован и позволяет нам интегрировать существующее программное обеспечение.
Автоматическая объектная модель JavaScript
Первым этапом многих проектов является создание ORM для естественного программного доступа к данным: JPA, Hibernate, Entity Framework. Это не маленький проект, и его трудно поддерживать, когда происходят изменения.
Фактически, объектная модель может быть создана непосредственно из схемы. Таким образом, у вас будет тип объекта для покупателя, для Lineitem и так далее. Модель обеспечивает доступ к атрибутам и связанным данным, а также сервисам сохранения. Затем вы можете использовать его, как показано ниже.
JavaScript кажется лучшим выбором языка: разумный по всем технологическим базам (все используют JavaScript), а его динамическая природа устраняет трудности генерации кода.
События JavaScript
В дополнение к аксессорам и персистентности, объекты JavaScript являются Logic Aware. То есть вышеуказанная операция сохранения выполняет все правила, связанные с OrderAudit (например, updated-by) и событиями JavaScript .
Вот пример события для PurchaseOrderобъекта, где вы получаете доступ к объектной модели JavaScript через системную rowпеременную:
Расширяемая логика
Аудит — это обычная модель. Должна быть возможность решить эту проблему один раз в общем виде, а затем повторно использовать ее (например, для аудита сотрудников, заказов и т. Д.).
Таким образом, Instant Enterprise REST должен позволить вам предоставить расширяемую логику — загрузить свой собственный код JavaScript и вызвать его. Итак, код выше может стать:
MyLibrary.auditFromTo(orderRow, "OrderAudit");
где AuditFromTo создает экземпляр OrderAudit, устанавливает внешний ключ, устанавливает одноименные атрибуты и сохраняет его.
Сменная Аутентификация
Большинство организаций имеют существующие хранилища данных, которые идентифицируют пользователей и их роли, такие как Active Directory, LDAP, OAuth и т. Д. Безопасность должна интегрироваться с такими системами как функция обеспечения доступа к строке / столбцу.
Стандартное развертывание
Наконец, система должна быть развернута знакомым способом: доступна в облаке или локальном виртуальном устройстве или файле военных действий. Стандарты также обеспечивают интеграцию с соответствующей критически важной инфраструктурой, такой как управление API, ERP-системы и т. Д.
Простое подключение клиента
REST — это веб-сервис. Это просто HTTP-вызов, который может быть выполнен на любом языке. Сериализованный ответ (результаты) обычно представляет собой JSON, который может быть легко проанализирован на любом языке.
Есть даже стандарты для документирования REST, такие как Swagger. Это привело к созданию экосистемы ценности, которая включает генерацию SDK для клиентских артефактов, таких как Java POJO или C # POCO. Это облегчает использование RESTful API в веб-приложениях.
Instant Enterprise REST: быстрее / проще, чем «толстый клиент»
Instant Enterprise REST меняет экономику архитектуры, создавая важные части нашего программного обеспечения в основном с деловой точки зрения, а не с технической точки зрения.