Я принимаю проект по замене древней устаревшей системы с нуля.Перед тем, как я пришел, компания наняла консультанта, который составил базовый эскиз системы и активно продвигал SOA.Это привело к длинному списку «сущностных услуг» с намерением объединить их в более сложные комбинации услуг.Например, пользователь, которому нужна информация о комитете, попадет в службу «Комитет», которая затем вызывает службу «Персона», чтобы получить своих членов, и службу «Встреча», чтобы получить свои собрания, и т. Д.
Я понимаю, что это повышает гибкость, но я беспокоюсь о производительности.Мне кажется, что система, созданная с такой высокой степенью детализации для ее служб, тратит слишком много ресурсов на перевод служебных сообщений, и производительность будет неприемлемой.Мне также кажется, что выигрыш в гибкости все еще можно получить, используя базовые многократно используемые объекты, хотя в этом случае преимущество технологически независимого интерфейса теряется для повышения производительности.
Для получения дополнительной информации: организация, запрашивающая этоПрограммное обеспечение в настоящее время не имеет стабильного пакета сторонних программ, которые необходимо интегрировать с.Это программное обеспечение заменит все комплекты.В настоящее время также нет внешних потребителей, которым необходим доступ к данным за пределами предоставленного интерфейса веб-сайта - все сервисные вызовы будут поступать из других частей нашей системы.Выбор SOA в этом случае кажется полностью основанным на концепции «подготовки».
Итак, мой вопрос - какой уровень детализации приемлем в стабильном сервисе без ущерба для производительности?Я слишком скептически отношусь к ударам в производительности, которые мы предпримем для реализации всех наших организаций в качестве сервисов?Должны ли функциональные возможности быть доступны в виде веб-сервисов только тогда, когда они необходимы, а вместо этого необходимо сосредоточиться на «подготовке» к разработке бизнес-уровня для вероятности того, что сервисы впоследствии будут отброшены?