Давайте представим, что у нас есть система обработки заказов для пиццерии для проектирования и сборки.

Требования следующие:

R1. Система должна быть независимой от клиента и варианта использования, что означает, что клиент может получить доступ к системе, что не было учтено при первоначальном проектировании. Например, если магазин пиццы решит, что многие из его клиентов будут использовать смартфоны Samsung Bada позже, написание клиента для ОС Bada не потребует переписывания API системы и самой системы; или, например, если окажется, что использование iPad вместо устройств Android как-то лучше для драйверов доставки, тогда будет легко создать клиент iPad и никак не повлиять на системный API;

R2. Возможность повторного использования, что означает, что система может быть легко перенастроена без переписывания большого количества кода в случае изменения бизнес-процесса. Например, если позже в пиццерии начнут принимать платежи в режиме онлайн наряду с приемом наличных водителями доставки (прием платежей до принятия заказа и прием платежей при доставке), то будет легко адаптировать систему к новому бизнес-процессу. ;

R3. Высокая доступность и отказоустойчивость, что означает, что система должна быть в сети и принимать заказы 24/7.

Итак, чтобы соответствовать R3, мы могли бы использовать Erlang / OTP и иметь следующую архитектуру:

Проблема здесь в том, что в архитектуре такого типа много «жестко запрограммированного» кода. функциональность в нем. Если, например, магазин пиццы перейдет от приема наличных платежей при доставке к принятию онлайн-платежей до размещения заказа, тогда потребуется много времени и усилий, чтобы переписать всю систему и изменить системный API.

Более того, если в магазине пиццы потребуются некоторые улучшения в своем клиенте CRM, нам снова придется переписать API, клиентов и саму систему.

Таким образом, следующая архитектура направлена на решение этих проблем и, таким образом, на удовлетворение требований R1, R2 и R3:

Каждый «сервис» в системе находится веб-сервер Webmachine с API RESTful. Такой подход имеет следующие преимущества:

all goodness of Erlang/OTP, since each Webmachine is an Erlang application, which can be supervised and can be put into an Erlang release; service oriented architecture with all the benefits of SOA; easy adaptable to changes in the business process; easy to add new clients and new functions to clients (e.g. to the CRM client), because a client can use RESTful APIs of all the services in the system instead of one 'central' API (Service composability in terms of SOA).

Таким образом, по существу, системная архитектура, предложенная на втором рисунке, представляет собой сервис-ориентированную архитектуру, где каждый сервис имеет RESTful API вместо WSDL-контракта и где каждый сервис является приложением Erlang / OTP.

И вот мои вопросы:

Picture 2: Am I trying to reinvent the wheel here? Should I just stick with the pure Erlang/OTP architecture instead? ("Pure Erlang" means Erlang applications packed into a release, talking to each other via gen_server:call and gen_server:cast function calls); Can you name any disadvantages in suggested approach? (Picture 2) Do you think it would be easier to maintain and grow (R1 and R2) a system like this (Picture 2) than a truly Erlang/OTP one? The security of such a system (Picture 2) could be an issue, since there are many entry points open to the web (RESTful APIs of all services) instead of just one entry point (Picture 1), isn't it so? Is it ok to have several 'orchestrating modules' in such a system or maybe some better practice exists? ("Accept orders", "CRM" and "Dispatch orders" services on Picture 2); Does pure Erlang/OTP (Picture 1) have any advantages over this approach (Picture 2) in terms of message passing and the limitations of the protocol? (partly discussed in my previous similar question, gen_server:call VS HTTP RESTful calls)