Проблемы технических партнёров и их предупреждение в мини-историях

    Год назад я работал в организации на должности технического руководителя, которая ударными темпами подключала партнёров к своей системе. Задача от коммерческого отдела была простая и, казалось бы, выполнимая: подключать всех и быстро. Это статья написана из личного опыта подключения партёров к системе. Под катом «весёлые истории», много букв, технического треша и небольшой «чек-лист» для отдела интеграции.

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

    Хочу заметить, что всё ниже написанное полная субъективщина и трэш российской специфики, отрасли компании, в которой я работал и поведения отдельных организаций.

    Как-то так это всё и работает...



    По началу у меня дыбом волосы вставали, когда я узнавал, что по ту сторону нет никакой информационной системы, более продвинутой, чем табличка в Excel (в лучшем случае). Но, как оказалось — это одни из лучших партнёров (вторая категория лучших партнёров — это те, кто реализовывал наш протокол). Мы очень быстро написали собственную информационную систему, которая решала не только проблему обмена информацией, но и в какой-то степени автоматизировала бизнес партнёра, за что мы получали плюс в карму.

    Но те, кто были «технологически продвинуты» доставляли бОльшую часть проблем. Очень мало партнёров работали по описанным ими же спецификациями: от незначительных, но хитрых перестановок или «не документированных возможностей» системы до полного несоответствия спецификациям. Кстати говоря, удачным стечением обстоятельств считалось, когда описание (хоть какое-то) вообще было. Иногда получалось, что вот вам «дырка», хотите подключаться — подключайтесь («дырка» могла спокойно оказаться личным кабинетом на сайте партнёра).

    Пример одной крайности: партнёр выдал нам протокол (SOAP). Ок, вот вам Java, вот JCP (т.к. там была ГОСТовая ЭЦП) — работаем. Шлюз написан, на нашем тестовом эмуляторе всё работает — переходим к тестам с партнёрами. И… что бы вы думали? Не работает! Причину искали 3 (три) месяца (саппорт партнёра реагировал очень вяло и в результате проблему подключения пришлось решать на уровне руководства двух компаний). Оказалось, что на той стороне SOAP был реализован с «небольшой особенностью»: вместо
    <tagName></tagName>

    нужно отправлять
    <tagName><\tagName>


    А что же JCP? Не понадобилось, т.к. на той стороне отсутствовала реализация.

    Пример другой крайности: коммерческий отдел приносит протокол, ок, да? Протокол реализован, совместные тесты с партнёром (!) пройдены, нужно включать продакшн.
    У партнёра этим занимается другое подразделение, которое, как оказалось, не в курсе, что реализованный нами протокол — это протокол их же компании. Результат: или реализовывайте другой протокол или ждите n месяцев (точную цифру не помню, но что-то около 10 месяцев).

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

    А был ли мальчик?


    Смог ли партнёр получить, а, самое главное, обработать полученные данные? Если вы думаете, что да, то пора взглянуть на мир по-новому.
    Один из партнёров пропускал 10-20% запросов. Ну как пропускал… Принимал, но не обрабатывал. Это было особенностью их системы и преподносилось как фича. Я немного упростил проблему, т.к. там «отложенная обработка данных» была только для некоторых типов запросов и работала по настроению удалённой стороны, но суть не изменилась. Ещё раз замечу, что мы получали код ответа «запрос успешно принят» (кода ответа «запрос успешно обработан» не было), но по факту ничего не происходило. В описании протокола, естественно, эта особенность не была учтена.

    Другой партнёр сообщал нам о поступлении нового запроса (XML-протокол, транспорт-HTTP), но не особо интересовался принят запрос или нет.
    Тут был забавный прикол при разговоре с руководством компании-партнёра (тех. директора и ком. директора) на тему «как так». Дело в том, что с нашей стороны (в ответ на такую несправедливость) был реализован запрос с частотой раз в 5 минут «а нет ли весточки для нас?» и тех. директор партнёра назвал это dos'ом и заблокировал нас с указанием «пофиксить на своей стороне» (естественно, указание мы получили только после обращения с нашей стороны в саппорт партнёра, а не по факту отключения). Я подключил всё свое «обаяние» и убедительные аргументы при общении с коммерческим директором, а по факту его согласия, что мы со своей стороны всё делаем правильно (о позиции тех. директора он ещё не знал) потребовал e-mail с подтверждением. В результате ответы от ком. директора и тех. директора ушли им обоим на почту с просьбой договориться. Через час нас включили по нашей схеме.

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

    Вы под надёжной защитой.



    Об SSL-сертификатах будет дальше, но я не могу здесь не упомянуть одну забавную историю.
    Мы получили протокол, который подразумевает SSL-шифрование. Всё работает, тесты пройдены, но… не с тем сертификатом.
    В результате небольшого исследования выяснилось, что удалённая сторона вообще не проверяет сертификат.
    Другой партнёр (которые работал по нашему протоколу) слишком буквально принял примеры запросов и во время тестов отправлял сигнатуру из примера (видимо, не осилил раздел N «Подпись сообщения»). Естественно, со словами «ничего не работает» наши коммерсы прибежали в отдел интеграции (который на тот момент уже существовал).

    Третий партнёр приподнёс ещё один сюрприз: однажды, войдя в личный кабинет партнёра, я заметил, что уж очень какие-то большие итоговые цифры, да и транзакции не наши. Как выяснилось, при определённом стечении обстоятельств, партнёр выводил нам в личный кабинет информацию по все системе партнёра. Обещали пофиксить и, что больше не повторится. Ага, щас. Через месяц я наткнулся на ту же проблему. Вот так я непреднамеренно получил инсайд по обороту компании-партнёра и всех её клиентов.

    Есть такая штука, 3-D Secure называется. Реализуется на стороне банка.
    В один прекрасный день, ко мне подходит коммерс и сообщает, что 3-D Secure не работает (на самом деле, не моя проблема, но так уж сложилось, что если никто не знал к кому подойти с проблемой, то подходили ко мне). Как не работает? Ну работает, только там в самом низу страницы (скроллить где-то две пустых страницы в браузере) есть серым по белому кнопка «отмена» (которая просто пропускала платёж без 3DS). Вот так не хитро без регистрации и без смс без авторизации у одного (довольно крупного) банка работал 3-D Secure.

    Правило третье: самостоятельно реализованные системы ограничения доступа не работают.
    Вывод: необходимо дополнительно усиливать меры безопасности стандартными и проверенными средствами (но см. правило 5).

    Спутник в Тихом океане.



    Один раз я получил звонок на мобильный: «Здравствуйте, Алексей! Это компания **** (тут название всем известной компании). Вы оставили заявку на наш продукт ****». Я думаю, что вы понимаете, что если бы я действительно оставлял заявку на этот продукт, то об этом бы здесь не писал. Как выяснилось, двумя минутами раньше, и нашему коммерсу поступил аналогичный звонок.
    Ситуация оказалась простая: мы с коммерсом тестировали свежеиспечённый функционал нашей системы, результатом которой был реестр, предназначенный для передачи партнёру. И партнёр этот реестр получил (вручную отправленный нашим коммерсом по электронной почте менеджеру с той стороны с просьбой проверить формат реестра). Что произошло на удалённой стороне я не знаю, но в результате он как-то попал в обработку.

    Другой случай: в определённый момент наша система была развёрнута одновременно на двух технологических площадках (по бизнесОвым соображениям) и работала то там, то там. Через некоторое время мы получили претензии от некоторых наших клиентов, что их запросы не обработаны. Внезапно. Не знаю как такое может быть, но по каким-то причинам, в зависимости от технологической площадки, запрос уходил либо на продакш-сервер партнёра, либо на тест. Выясняли причину долго, пока наш саппорт не догадался провести traceroute с обеих площадок и выяснилось, что, в зависимости от площадки, запрос, направленный по одному IP-адресу, уходил на разные сервера (судя по traceroute, в случае запроса с одной из площадок, внутри сети клиента запрос проходил даже по разным маршрутизаторам).

    Правило четвёртое: если запрос может уйти не туда, он уйдёт не туда.
    Вывод: см. правило 2.

    Кто здесь?



    А можно ли доверять уважаемым и проверенным решениям? Думаю, что вы уже понимаете, что нет, если настройка этих решений в руках партнёра. Про роутинг история выше, про SSL тоже, но вот ещё парочка:

    Однажды нам выдали шлюз с адресами похожими на: gateXXX.comp_name.com (где XXX не adult, а вид шлюза). Надо ли говорить, что после первой недели продакшена упал DNS партнёра? Думаю, что и лишнем будет говорить, что после подъёма DNS он отдавал ИП-адреса в обратном порядке. Но к этому моменты мы были уже «прошаренные» и не доверяли primary-серверам DNS.

    SSL — это вообще отдельная песня.
    Вы всё ещё доверяете сертификатам? Тогда мы идём к вам. Хорошо, если у партнёра из коробки была хоть какая-то защита данных (хотя бы от подмены в виде ключа и md5). Вообще, у нас был целый отдел информационной безопасности (который работал параллельно с другими отделами безопасности), который на своём уровне проталкивал идею криптографии. Но очень часто и это не помогало. Некоторые партнёры предлагали просто передать md5 от тела сообщения, кто-то использовал, в лучшем случае, самоподписные сертификаты, в худшем — от godaddy, но выданные на другой домен. Про криптографию по ГОСТ (и как саппорт настраивал оборудование) я вообще не хочу писать.

    Одно мы знали точно: без объявления войны в любой момент времени может произойти всё, что угодно: от истёкшего срока годности сертификата (на это мы, как правило, вообще не обращали внимание — только в мониторинге появлялся ещё один аларм) до смены алгоритма шифрования.

    Правило пятое: если уже хорошо известную вам систему настроил партнёр, считайте, что это другая система.
    Вывод: изобретательность и стрессоустойчивость (как саппорта, так и шлюза).

    (Опять) Ничего не работает.


    Ох, как часто я слышал эту фразу от… неееее… не бухгалтера, а от технарей по ту сторону.

    Правило шестое: Если что-то «сломалось», вы не узнаете, что именно.
    Вывод: полное логирование и удобное представление лога.

    Белые и пушистые


    Нет, я не хочу сказать, что мы были такие белые и пушистые, что у нас всё работало. Естественно, и у нас косяки встречались. Были даже очень не приятные, о которых не буду писать (т.к. я последнее время занимался не столько техникой, сколько «бизнесом»). Но соблюдение технологий, глубокое понимание соответствующих стандартных (а так же наших!) протоколов, ответственность, готовность думать «за всех» — это были требования к кандидатам на должность начальника отдела интеграции.

    А вообще, интеграция с on-line системами — это весело, увлекательно и интересно. Я познакомился со многими хорошими специалистами, увидел много интересных архитектур протоколов и систем. И стал лечить по фотографии.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 20

      0
      Думал, что подобные проблемы встречаются только на уровне малого не ИТ-бизнеса, очень малого, где даже штатный эникейщик непозволительная роскошь.
        +2
        Увы… многие из описанных проблем были в компаниях, известных, как минимум, на уровне СНГ.
        Некоторые в «отраслевых» компаниях (но очень хорошо известных в своей отрасли), производящих собственный (сертифицированный по международным сертификатам) софт.
        Малый (и не ИТ) бизнес как раз доставлял меньше всего проблем, т.к. туда, как правило, устанавливался наш софт.
          +2
          Везло вам, видимо) Из своего небольшого опыта могу сказать, что такие штуки очень распространены даже у федералов второй линии. Т.е. люди считаются в своей области чуть не лидерами рынка СНГ (благо что занимаются не слишком консьюмерским бизнесом), а косяки, внезапные и беспощадные, выдают регулярно чуть не раз в неделю.
            0
            Везло если только в смысле, что не приходилось взаимодействовать в этом плане.
            +1
            Наоборот, чем больше компания, тем больше шансов нарваться на «альтернативный метод» решения задачи… или могут просто сказать «хотите денег — подстраивайтесь под нас».
              +1
              У маленьких компаний по крайней мере есть шанс быстрее достучаться до нужного человека и все поправить. Также в маленьких компаниях меньше людей/отделов которые знают/не знают/имеют разную информацию.
                0
                Даже у очень крупного зарубежного бизнеса иногда такой трешак попадается. В финансово-платёжном, например, лично сталкивался.
                0
                истёкшего срока годности сертификата (на это мы, как правило, вообще не обращали внимание


                А почему бы не поступать в этой ситуации прямолинейно, правильно? Отказывать в обслуживании. Чем это плохо?
                  +4
                  Да я бы с радостью всех завернул читать мануалы, но «Задача от коммерческого отдела была простая и, казалось бы, выполнимая: подключать всех и быстро.» Мы не могли не подключать партнёров, т.к. это сильно бы повредило бизнесовой части. Учить ту сторону жизни также не всегда было возможно, т.к. ещё не известно, кто был больше заинтересован в подключении — мы или они.

                  Вообще, эта статья была написана после обсуждения вот этого поста.
                  Там в комментариях я написал, что был вынужден подключать партнёров, но, например, никогда бы не стал работать с такой компанией, если бы у меня был выбор.
                    0
                    Осознал.
                    0
                    Это настолько часто встречается, что если все решат вдруг следовать этому правилу, весь бизнес у всех накроется. А в куче библиотек вообще нет толковой проверки валидности сертификата, поэтому приходится дополнительный уровень проверки целостности вводить, уже на уровне собственно данных (подписи блоков данных использовать, например).
                    0
                    Странно, что <\tagName> искали месяц. Неужели нельзя было спросить: покажите данные, которые вы посылаете и на которых у вас работает? И потом прогнать их у себя.
                      +3
                      Думаете «спросить» и «получить» сопоставимо? :)

                      Когда начальство мне сказало подключить к нашему магазину etargeting_ru, мне пришлось раза три переделывать модуль создания глобального файла выдачи им данных от нас. И ещё примерно раза три способ отдачи. Потому что общаться можно было только с их менеджером. По просьбам перевести разговор на тех спеца, получал другого менеджера. ТЗ их было написано пьяной макакой, с куcками из разных этапов развития их софта (начало ТЗ с первой версии, окончание ТЗ с последующей, но работает только последняя версия). Все вопросы и просьбы дать пример данных которые они ждут. Игнорировались, списывались на коммерческую тайну или попытки надавить на меня через моё руководство, чтобы я «быстрее работал». В итоге за по сути два месяца звонков, переписываний и в конце полного отказа делать что-то ещё, пока не увижу пример. Я сумел получить вариант того что им надо. И выяснилось, что данные им отдавать можно было тем файлом, который уже года полтора у нас формируется для яндекс.маркета. Просто добавить 1 тег с указанием идентификатора товара на сайте.
                        +1
                        syschel в общем-то уже ответил :)
                        У нас в этом случае другой прикол был: примеры были (в описании протокола) и слеши там прямые были.
                        Данные мы просили — нас посылали в документацию. Т.к. для SOAP используются готовые библиотеки, никто из наших и не подумал экспериментировать со слешами.
                        0
                        Какие бы технологии вы посоветовали для интеграции и/или публичного API? А то у нас сейчас зоопарк технологий — HTTP + XML (прост и удобен в отладке, но несерьезено как-то), REST (прост, но с авторизацией сложности), SOAP (стандартен, но сложноват).

                        И при этом насмотрелся на всякие многослойные нестандартные от именитых провайдеров. Вроде бы хрень, но ведь люди не первый год работают, наверняка эта хрень не просто так.

                          0
                          Вы задаёте вопрос из серии «Какие бы технологии вы посоветовали для разработки ПО». А задаёте его по тому, что не понимаете архитектуру своего протокола (всё ИМХО, конечно :) ).
                          Тут, с моей точки зрения, очень важно понимать, во-первых, для кого предназначено API, во-вторых, ваши возможности и ресурсы (с точки зрения владения / использования теми или иными технологиями).

                          Транспорт, я так понимаю, только HTTP?
                          В принципе, вы можете сделать авторизацию просто по SSL-сертификату (если требуется шифрование).
                          Но это, во-первых, потребует правильной настройки web-сервера, во-вторых, хорошо подумайте, сколько минусов в карму получите от пользователей.

                          Если API для крупных корпоратов и/или очень сложной интеграции, то, скорее всего, только SOAP с вменяемым WSDL.
                          SOAP в том числе решает вопросы авторизации / ограничения доступа (практически из коробки) и, самое главное, структурированности / типизации данных.
                          В больших приложениях со сложными протоколами удобно автоматом собирать из WSDL документацию и объекты для работы с протоколом. Всё это дело в последствии легче саппортить / допиливать.

                          > SOAP стандартен
                          SOAP, кончено, стандартен, но только Java (по крайней мере, я не видел вменяемых библиотек и инструментов под другие языки).
                          + по-моему, в различных библиотеках есть разные особенности относительно стандартов (я уже не помню, насколько серьёзные проблемы возникали). Но крайне не рекомендую юзать SOAP для простых протоколов / приложений — и вы и удалённая сторона больше потратите времени на сам SOAP, чем на полезные данные.
                          > SOAP сложноват
                          ИМХО для архитектора он не сложноват, он избыточен. Но за счёт избыточности есть очень много прикольных фич.

                          Если для «физиков» или для простых протоколов (особенно ориентированных на интеграцию web-приложения), то мне нравится, когда ответ приходит в двух вариантах на выбор: XML / JSON. А вот с запросом сложнее. Если это из серии «дай мне информацию об объекте #1234», то тогда просто GET. Если что-то более сложное (например, клиент передаёт вам изображение на обработку), то тогда только POST.
                          Авторизация в этом случае либо по SSL сертификату (как писал выше) либо по ключу, передаваемому одним из параметров.

                          Как два программиста хлеб пекли — если включить фантазию, то Борис — это SOAP, а Маркус — это XML / JSON :)

                          Ещё серьёзный вопрос насколько протокол должен быть безопасен. Нужно ли шифрование? Должен ли сервер / клиент подписывать сообщение (например, в договоре может быть указано, что стороны признают общение по протоколу юридически значимым)? Если должен, то тогда обязательно предусмотреть сигнатуру (она же может являться ключом для авторизации), иначе с SSL придётся дёргать подписанные HTTP запросы…

                          REST мне лично не нравится. Вернее так (у меня примерно такое же отношение к XSLT): идея отличная, но, во-первых, сложно продумать вменяемую архитектуру, во-вторых, REST, по моим наблюдениям, не очень-то популярен (есть риск словить минусов в карму от удалённой стороны). Но если вы осилите (или найдёте человека, который осилит архитектуру), то это будет очень хорошее решение для простых протоколов (или так: для протоколов управления чем-то).
                          С авторизацией проблем нет (она есть «из коробки»): HTTP Basic access authentication (ведь если говорить человеческим языком, то REST — это просто использование HTTP «на полную мощность»).

                          > И при этом насмотрелся на всякие многослойные нестандартные от именитых провайдеров. Вроде бы хрень, но ведь люди не первый год работают, наверняка эта хрень не просто так.

                          В том то и дело, что не первый год работают :) У многих компаний протокол нарастает как снежный ком и в результате превращается в очень тяжелого (в осмыслении и в работе) монстра.
                          Это сделано не специально — просто кто-то не хотел подумать (ну или очень торопился).
                          Если для физиков делаете, то посмотрите публичные API «больших пап» (а-ля Google).
                          Если для корпоратов и/или SOAP, то надо искать вменяемы коммерческие приложения и анализировать.
                          Есть ещё узко специфичные протоколы (например, OAuth) — тут рекомендую просто взять готовую (и популярную) библиотеку, а не изобретать собственный велосипед.
                          Есть ещё одна узкая ниша — бинарные протоколы. Но, думаю, что если перед вами встала такая задача, вы и без меня знаете, что делать :)

                          И последнее. В протоколе главное даже не технологии, а архитектура (что бы вы не использовали, в качестве полезной нагрузки будут передаваться данные вашего приложения и на это стоит обратить внимание).
                          Протокол должен быть:
                          1. Максимально, на сколько это возможно, прост;
                          2. Сложный протокол должен быть хорошо структурирован и разбит на объекты (ООП протокол :) ). За один запрос должно быть выполнено одно простое действие;
                          3. Всегда оставляете задел на будущее (резервируйте имена, коды ответов и т.д.);
                          4. По возможности, сохраняйте обратную совместимость (но если вы понимаете, что с архитектурой в первой версии вы налажали, просто реализуйте второй (отдельный) гейт под новую архитектуру);
                          5. Ну и не допускайте проблем, описанных в статье :)
                            0
                            Ещё, что касаемо архитектуры, надо сразу понимать:
                            — Протокол синхронный / асинхронный;
                            — Сохраняет ли состояние;
                            — Насколько надёжен транспорт (HTTP НЕ надёжен);
                            — Есть ли обратные вызовы (от сервера к клиенту);
                            — Требуется ли постоянное соединение.
                              0
                              Архитектуру рассчитывали на высокие нагрузки, поэтому:
                              1. протокол асинхронный
                              2. состояние не сохраняет, но на всякий случай такое предусмотрено
                              3. транспорт пофиг, потому что п.1. Присматриваемся к STOMP и прочим queue-based штукам, но они очень сырые. HTTP используем, потому как очень стандартен, известен, можно голыми руками запросы писать из браузера или утилит типа curl или wget.
                              4. обратных вызовов нет. Может, в целях безопасности или оперативности понядобятся, но они все усложняют.
                              5. постоянное соединение не требуется, п.1

                              В протоколе только авторизация и контрольные суммы, без шифрования и подписей. Секурность за счет VPN-соединений, это видится более простым, удобным и перспективным, чем SSL.

                              Протоколов несколько:
                              — написаный на питоне. Запросы в HTTP POST, ответы по дефолту в XML, но можно запросить JSON. XML прямо в браузере виден, а JSON компактнее и проще транслируется. Скорострельность невелика, от 100 до 1000 в секунду. Можно больше, запустить паралельно несколько обработчиков на разных портах и поставить обратный прокси, но это как-то не энтерпрайзно. Короче, решение на скорую руку для мелких партнеров и для срочных нужд.
                              — RESTful на жаве. Для собственных нужд используется, партнерам как-то стремно его показывать.
                              — SOAP на жаве, для крупных партнеров и больших объемов. Но на практике очень слабо используется, крупные партнеры сильно тормозят. Мы тоже сильно тормозим в этом направлении, так что реально это делется больше для имиджа, чем для реальной пользы.

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

                              По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть. Нету ведь идеальной архитектуры на все случаи жизни.
                                0
                                STOMP — не юзал и ничего не могу про него сказать.

                                > Секурность за счет VPN-соединений
                                Может быть хорошим решением для систем с «ограниченным набором клиентов» (в том смысле, что о факте каждого подключения вам заранее известно).

                                > Запросы в HTTP POST
                                Тут всё зависит от нужд протокола, но я бы, при возможности реализации через GET-запросы, выбрал именно GET.
                                Часто коробочные решения имеют возможность подключить «http колбэки» и далеко не все из них умеют слать POST.

                                > Вообщем, пока что лучше HTTP ничего не нашлось.
                                ИМХО HTTP покрывает очень большое количество нужд.
                                Следующий шаг после HTTP — это, может быть, готовый брокер сообщений (есть 3-4 популярных решения).
                                Ну и для бинарных протоколов транспорт (вплоть до физического) может быть какой-то хитрый.

                                > По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть.

                                В том проекте, про который я писал в посте, например, был один внутренний «центральный» сервис. Его протокол глобально не менялся с момента реализации (только расширялся с сохранением обратной совместимости), хотя, честно скажу, сил на него проектировку ушло много. А вот внешний один раз претерпел глобальные изменения (в основном, это было связано с а) изменением внутренней архитектурой проекта б) протокол перестал выполнять узкоспециализированные операции и дал много больше возможностей партнёрам). Но при этом старая спецификация была реализована в качестве конвертера к новому протоколу (т.е. получилась такая схема для партнёров, которые не перешли на новую версию: [gateway] <--протокол v2--> [конвертер] < — протокол v1 --> [партнёр]).

                                > Нету ведь идеальной архитектуры на все случаи жизни.

                                Здесь полностью согласен. Всегда будут и ошибки, и плюсы и минусы. У всех популярных протоколов не одна версия была…
                                Вообще, что такое хорошая архитектура? С моей точки зрения — это когда нужно добавить что-то новое или кастомизировать старое и ты такой сразу же «опа, а вот это можно сделать так так и так» и никаких костылей. Как это сделать — у меня пока только на уровне ощущений (я нифига не архитектор и всегда такими вопросами у меня занимались отдельные специалисты).

                                Вообще (в частности для XML) очень хорошо помогает проектировка с WSDL. Есть графические утилиты (по-моему, в том же Eclipse), с помощью которых можно визуально набросать будущий протокол. Ещё одно моё правило — это включение максимально возможного функционала (даже если сейчас такого требования не стоит) на этапе проектировки.
                                То есть:
                                1. Формируем требования — чего мы хотим от протокола в данный момент;
                                2. Накидываем архитектуру;
                                3. Смотрим, влезает ли без костылей такой-то функционал;
                                4. Правим архитектуру и возвращаемся к п.3.
                                Если сильно не увлекаться и придерживаться минимализма, может получиться хорошая штука.
                                  0
                                  И, кстати, заметьте, что в посте я почти не критиковал архитектуру.
                                  Удалённой стороне, скорее всего, важно:
                                  1. Интеграция в принципе возможна;
                                  2. Есть спецификации и они соответствуют реальному шлюзу (хотел бы написать, реальный шлюз соответствует спецификациям, но...);
                                  3. Шлюз работает и не меняет своего поведения;
                                  4. Для реализации протокола на объектном ЯП не нужно создавать разные классы для одинаковых сущностей.

                                  Какая-та определённая «красота» большинству до фени :)

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое