Сложная архитектура для простого применения

Question

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

Все становится более сложным из-за двухфункциональные требования:

1. Указанная компания требует, чтобы все внутренние приложения предлагались через корпоративный портал (для пользовательского интерфейса, безопасности и технического единообразия)
2. Указанная компания требует, чтобы все приложения создавались с использованием SOAпринципы, позволяющие в конечном итоге публиковать сервисы на ESB и повторно использовать.

Архитектура может быть легко адаптирована к требованиям портала.Презентация будет построена с использованием портлетов и интегрирована в тему портала, и безопасность портала будет использоваться повторно.Ничего страшного.

Требование SOA - это другая история.Многоразовые услуги еще не определены.На мой взгляд, есть несколько вариантов:

1. Бизнес-логика развернута на портале и совмещена с уровнем представления.Службы не предоставляются, и это решение откладывается.
2. Бизнес-логика развернута на отдельном сервере.Разработан API, и все сервисы предоставляются с использованием закрытого протокола (например, RMI или Hessian).Для сервисов, которые необходимо в конечном итоге использовать повторно, поверх этих сервисов может быть добавлен API-интерфейс SOAP.
3. Бизнес-логика развернута на отдельном сервере.Разработан SOAP API, и все сервисы предоставляются с использованием этого механизма.

Я хочу избежать создания чего-то слишком сложного.Я пережил проекты с бизнес-делегатами, удаленными фасадами и DTO, где каждое изменение требовало изменения нескольких уровней.Тем не менее, создается впечатление, что это требование SOA принудительно подталкивает меня в этом направлении.

Обновление : Чем больше я думаю об этом, тем больше понимаю, что сложность возникает из-за необходимости разработкиAPI удаленного взаимодействия.Конечно, это требует создания интерфейсов для сервисов, но как насчет обмениваемых объектов?Либо я иду по пути DTO и получаю две параллельные иерархии объектов (одну для DTO и одну для реальных сущностей), либо я иду по интерфейсу и объявляю интерфейсы для всех сущностей, которые должны проходить через серверы.В любом случае, это порождает целый ряд новых проблем, и мы закончим тем, что напишем много лишнего кода.И я думал, что мы прошли эту эпоху ...

Каков лучший (или наименее худший) способ создать это?

Спасибо всем.

Answer 1

Я бы выбрал первый вариант: , помечающий , тщательно заботящиеся о службах, которые создают интерфейс для бизнес-уровня, и запрещающий вызывать что-либо за этим интерфейсом из уровня представления. Это позволяет вам переключиться на параметры с удаленным взаимодействием (независимо от того, выберете ли вы номер два или три) позже с разумно низкой и предсказуемой стоимостью.

Если это невозможно, второй вариант обещает более эффективное использование ресурсов.

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

Answer 2

Я рад видеть, что у вас есть некоторый реальный опыт построения корпоративных архитектур и вы понимаете последствия различных архитектур.Я видел многих консультантов, которые только что прочитали книгу о какой-то новой модной технологии ...

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

Если вам придется использовать распределенную архитектуру (вариант 2 или 3), я все равно постараюсь поставить столько женасколько это возможно на сервере портала.С этой целью термин бизнес-логика должен быть определен очень узким образом.Все, что даже удаленно связано с представлением (пользовательские настройки, структурирование данных для целей представления, уже подготовленные отчеты и т. Д.), Объявляется логика представления , поэтому оно может быть реализовано на сервере портала.Поэтому, даже если вы не можете избежать дублирования и сложности, связанных с удаленным взаимодействием, вы можете ограничить его меньшим количеством областей.(В зависимости от рассматриваемой проблемы вы можете получить базу данных на сервере портала и базу данных на сервере бизнес-логики, которые лучше объединить в один, потому что между ними существует так много ссылок на данные. Надеюсь, это не такздесь.)

Написание многократно используемого сервиса с учетом только одного приложения, согласно моему опыту, является потраченной впустую инвестицией.Интерфейс servcie станет более сложным для этого отдельного приложения, часть интерфейса никогда не будет использоваться и вряд ли будет протестирована (потому что он был создан для какого-то предполагаемого будущего приложения), и когда второе приложение, наконец, прибудет, понимает, что оно имеет довольно разные требования, чемпредусматривается.Таким образом, сервис должен быть изменен, а уже существующее приложение должно быть изменено.Поэтому не начинайте создавать сервисы, если у вас есть как минимум два (лучше три) приложения, которые существуют или находятся в процессе реализации.Это окупается с точки зрения денег и качества интерфейса службы.

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

Answer 3

Стек SOA WSO2 предлагает различные решения, подходящие для вашей архитектуры. Пожалуйста, посмотрите на http://wso2.org/, чтобы получить представление об этом. Ведь его бесплатный и открытый исходный код:)