Как вы оцениваете архитектуру обмена сообщениями?

Question

Я работаю над проектом, который основан на интеграции с компаниями-агрегаторами SMS / MMS-сообщений для развертывания приложений на мобильные телефоны, а также для осуществления мобильных платежей через SMS. Многие концепции в таких архитектурах тесно связаны с обменом сообщениями в корпоративной интеграции и мире SOA. В настоящее время я нахожусь в процессе оценки различных поставщиков SMS-сообщений и хотел бы знать, существуют ли какие-то особые критерии, которые архитектор ищет в архитектурах обмена сообщениями, которые должны вызывать беспокойство.

Мой подход состоит в том, чтобы использовать «возможности» архитектуры (производительность, доступность, масштабируемость, безопасность и т. Д.), Чтобы создать модель оценки для системы каждого поставщика. Тем не менее, кто-нибудь рекомендует другие подходы или критерии, чтобы искать при интеграции с такими архитектурами?

Спасибо большое.

Answer 1

Полное раскрытие: я работал на одного из крупнейших SMS / MMS-брокеров, поэтому, возможно, я немного предвзят.

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

1. Масштабируемость: мы выбрали горизонтальную масштабируемость), используя большинство аппаратных средств

2. Пропускная способность: сколько соединений с каждым оператором поддерживает посредник в режиме реального времени / откат

3. Методология отработки отказа: подключен ли брокер к избыточным SMSC / MMSC для каждого оператора, для которого они доступны?

4. Методология подключения: это брокер, подключенный напрямую через SMPP / MM4 | 7, или они используют магистральную линию SS7 напрямую, то есть имеют точечный код.

5. Емкость очереди: сколько времени может составлять очередь сообщений агрегатора в случае перебоев в работе оператора до потери сообщений?

6. Прямые и одноранговые соединения: сколько ваших потенциальных MNO для доставки напрямую связано с брокером и сколько достигается через одноранговые сети?

7. сквозное время прохождения

8. QOS

Answer 2

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

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

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

Answer 3

Чтобы правильно оценить «болезни», вы должны принять во внимание требования.

Вы можете попытаться оценить все «болезни» как можно более объективно, а затем взвесить каждую оценку в соответствии с требованиями.

P.S. Не должно стоить (€), также является частью уравнения. Для пользователей и провайдеров конечно!