Комментарии 20
Думал, что подобные проблемы встречаются только на уровне малого не ИТ-бизнеса, очень малого, где даже штатный эникейщик непозволительная роскошь.
Увы… многие из описанных проблем были в компаниях, известных, как минимум, на уровне СНГ.
Некоторые в «отраслевых» компаниях (но очень хорошо известных в своей отрасли), производящих собственный (сертифицированный по международным сертификатам) софт.
Малый (и не ИТ) бизнес как раз доставлял меньше всего проблем, т.к. туда, как правило, устанавливался наш софт.
Некоторые в «отраслевых» компаниях (но очень хорошо известных в своей отрасли), производящих собственный (сертифицированный по международным сертификатам) софт.
Малый (и не ИТ) бизнес как раз доставлял меньше всего проблем, т.к. туда, как правило, устанавливался наш софт.
Везло вам, видимо) Из своего небольшого опыта могу сказать, что такие штуки очень распространены даже у федералов второй линии. Т.е. люди считаются в своей области чуть не лидерами рынка СНГ (благо что занимаются не слишком консьюмерским бизнесом), а косяки, внезапные и беспощадные, выдают регулярно чуть не раз в неделю.
Наоборот, чем больше компания, тем больше шансов нарваться на «альтернативный метод» решения задачи… или могут просто сказать «хотите денег — подстраивайтесь под нас».
У маленьких компаний по крайней мере есть шанс быстрее достучаться до нужного человека и все поправить. Также в маленьких компаниях меньше людей/отделов которые знают/не знают/имеют разную информацию.
Даже у очень крупного зарубежного бизнеса иногда такой трешак попадается. В финансово-платёжном, например, лично сталкивался.
истёкшего срока годности сертификата (на это мы, как правило, вообще не обращали внимание
А почему бы не поступать в этой ситуации прямолинейно, правильно? Отказывать в обслуживании. Чем это плохо?
Да я бы с радостью всех завернул читать мануалы, но «Задача от коммерческого отдела была простая и, казалось бы, выполнимая: подключать всех и быстро.» Мы не могли не подключать партнёров, т.к. это сильно бы повредило бизнесовой части. Учить ту сторону жизни также не всегда было возможно, т.к. ещё не известно, кто был больше заинтересован в подключении — мы или они.
Вообще, эта статья была написана после обсуждения вот этого поста.
Там в комментариях я написал, что был вынужден подключать партнёров, но, например, никогда бы не стал работать с такой компанией, если бы у меня был выбор.
Вообще, эта статья была написана после обсуждения вот этого поста.
Там в комментариях я написал, что был вынужден подключать партнёров, но, например, никогда бы не стал работать с такой компанией, если бы у меня был выбор.
Это настолько часто встречается, что если все решат вдруг следовать этому правилу, весь бизнес у всех накроется. А в куче библиотек вообще нет толковой проверки валидности сертификата, поэтому приходится дополнительный уровень проверки целостности вводить, уже на уровне собственно данных (подписи блоков данных использовать, например).
Странно, что <\tagName> искали месяц. Неужели нельзя было спросить: покажите данные, которые вы посылаете и на которых у вас работает? И потом прогнать их у себя.
Думаете «спросить» и «получить» сопоставимо? :)
Когда начальство мне сказало подключить к нашему магазину etargeting_ru, мне пришлось раза три переделывать модуль создания глобального файла выдачи им данных от нас. И ещё примерно раза три способ отдачи. Потому что общаться можно было только с их менеджером. По просьбам перевести разговор на тех спеца, получал другого менеджера. ТЗ их было написано пьяной макакой, с куcками из разных этапов развития их софта (начало ТЗ с первой версии, окончание ТЗ с последующей, но работает только последняя версия). Все вопросы и просьбы дать пример данных которые они ждут. Игнорировались, списывались на коммерческую тайну или попытки надавить на меня через моё руководство, чтобы я «быстрее работал». В итоге за по сути два месяца звонков, переписываний и в конце полного отказа делать что-то ещё, пока не увижу пример. Я сумел получить вариант того что им надо. И выяснилось, что данные им отдавать можно было тем файлом, который уже года полтора у нас формируется для яндекс.маркета. Просто добавить 1 тег с указанием идентификатора товара на сайте.
Когда начальство мне сказало подключить к нашему магазину etargeting_ru, мне пришлось раза три переделывать модуль создания глобального файла выдачи им данных от нас. И ещё примерно раза три способ отдачи. Потому что общаться можно было только с их менеджером. По просьбам перевести разговор на тех спеца, получал другого менеджера. ТЗ их было написано пьяной макакой, с куcками из разных этапов развития их софта (начало ТЗ с первой версии, окончание ТЗ с последующей, но работает только последняя версия). Все вопросы и просьбы дать пример данных которые они ждут. Игнорировались, списывались на коммерческую тайну или попытки надавить на меня через моё руководство, чтобы я «быстрее работал». В итоге за по сути два месяца звонков, переписываний и в конце полного отказа делать что-то ещё, пока не увижу пример. Я сумел получить вариант того что им надо. И выяснилось, что данные им отдавать можно было тем файлом, который уже года полтора у нас формируется для яндекс.маркета. Просто добавить 1 тег с указанием идентификатора товара на сайте.
syschel в общем-то уже ответил :)
У нас в этом случае другой прикол был: примеры были (в описании протокола) и слеши там прямые были.
Данные мы просили — нас посылали в документацию. Т.к. для SOAP используются готовые библиотеки, никто из наших и не подумал экспериментировать со слешами.
У нас в этом случае другой прикол был: примеры были (в описании протокола) и слеши там прямые были.
Данные мы просили — нас посылали в документацию. Т.к. для SOAP используются готовые библиотеки, никто из наших и не подумал экспериментировать со слешами.
Какие бы технологии вы посоветовали для интеграции и/или публичного API? А то у нас сейчас зоопарк технологий — HTTP + XML (прост и удобен в отладке, но несерьезено как-то), REST (прост, но с авторизацией сложности), SOAP (стандартен, но сложноват).
И при этом насмотрелся на всякие многослойные нестандартные от именитых провайдеров. Вроде бы хрень, но ведь люди не первый год работают, наверняка эта хрень не просто так.
И при этом насмотрелся на всякие многослойные нестандартные от именитых провайдеров. Вроде бы хрень, но ведь люди не первый год работают, наверняка эта хрень не просто так.
Вы задаёте вопрос из серии «Какие бы технологии вы посоветовали для разработки ПО». А задаёте его по тому, что не понимаете архитектуру своего протокола (всё ИМХО, конечно :) ).
Тут, с моей точки зрения, очень важно понимать, во-первых, для кого предназначено 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. Ну и не допускайте проблем, описанных в статье :)
Тут, с моей точки зрения, очень важно понимать, во-первых, для кого предназначено 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. Ну и не допускайте проблем, описанных в статье :)
Ещё, что касаемо архитектуры, надо сразу понимать:
— Протокол синхронный / асинхронный;
— Сохраняет ли состояние;
— Насколько надёжен транспорт (HTTP НЕ надёжен);
— Есть ли обратные вызовы (от сервера к клиенту);
— Требуется ли постоянное соединение.
— Протокол синхронный / асинхронный;
— Сохраняет ли состояние;
— Насколько надёжен транспорт (HTTP НЕ надёжен);
— Есть ли обратные вызовы (от сервера к клиенту);
— Требуется ли постоянное соединение.
Архитектуру рассчитывали на высокие нагрузки, поэтому:
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 ничего не нашлось.
По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть. Нету ведь идеальной архитектуры на все случаи жизни.
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 ничего не нашлось.
По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть. Нету ведь идеальной архитектуры на все случаи жизни.
STOMP — не юзал и ничего не могу про него сказать.
> Секурность за счет VPN-соединений
Может быть хорошим решением для систем с «ограниченным набором клиентов» (в том смысле, что о факте каждого подключения вам заранее известно).
> Запросы в HTTP POST
Тут всё зависит от нужд протокола, но я бы, при возможности реализации через GET-запросы, выбрал именно GET.
Часто коробочные решения имеют возможность подключить «http колбэки» и далеко не все из них умеют слать POST.
> Вообщем, пока что лучше HTTP ничего не нашлось.
ИМХО HTTP покрывает очень большое количество нужд.
Следующий шаг после HTTP — это, может быть, готовый брокер сообщений (есть 3-4 популярных решения).
Ну и для бинарных протоколов транспорт (вплоть до физического) может быть какой-то хитрый.
> По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть.
В том проекте, про который я писал в посте, например, был один внутренний «центральный» сервис. Его протокол глобально не менялся с момента реализации (только расширялся с сохранением обратной совместимости), хотя, честно скажу, сил на него проектировку ушло много. А вот внешний один раз претерпел глобальные изменения (в основном, это было связано с а) изменением внутренней архитектурой проекта б) протокол перестал выполнять узкоспециализированные операции и дал много больше возможностей партнёрам). Но при этом старая спецификация была реализована в качестве конвертера к новому протоколу (т.е. получилась такая схема для партнёров, которые не перешли на новую версию: [gateway] <--протокол v2--> [конвертер] < — протокол v1 --> [партнёр]).
> Нету ведь идеальной архитектуры на все случаи жизни.
Здесь полностью согласен. Всегда будут и ошибки, и плюсы и минусы. У всех популярных протоколов не одна версия была…
Вообще, что такое хорошая архитектура? С моей точки зрения — это когда нужно добавить что-то новое или кастомизировать старое и ты такой сразу же «опа, а вот это можно сделать так так и так» и никаких костылей. Как это сделать — у меня пока только на уровне ощущений (я нифига не архитектор и всегда такими вопросами у меня занимались отдельные специалисты).
Вообще (в частности для XML) очень хорошо помогает проектировка с WSDL. Есть графические утилиты (по-моему, в том же Eclipse), с помощью которых можно визуально набросать будущий протокол. Ещё одно моё правило — это включение максимально возможного функционала (даже если сейчас такого требования не стоит) на этапе проектировки.
То есть:
1. Формируем требования — чего мы хотим от протокола в данный момент;
2. Накидываем архитектуру;
3. Смотрим, влезает ли без костылей такой-то функционал;
4. Правим архитектуру и возвращаемся к п.3.
Если сильно не увлекаться и придерживаться минимализма, может получиться хорошая штука.
> Секурность за счет VPN-соединений
Может быть хорошим решением для систем с «ограниченным набором клиентов» (в том смысле, что о факте каждого подключения вам заранее известно).
> Запросы в HTTP POST
Тут всё зависит от нужд протокола, но я бы, при возможности реализации через GET-запросы, выбрал именно GET.
Часто коробочные решения имеют возможность подключить «http колбэки» и далеко не все из них умеют слать POST.
> Вообщем, пока что лучше HTTP ничего не нашлось.
ИМХО HTTP покрывает очень большое количество нужд.
Следующий шаг после HTTP — это, может быть, готовый брокер сообщений (есть 3-4 популярных решения).
Ну и для бинарных протоколов транспорт (вплоть до физического) может быть какой-то хитрый.
> По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть.
В том проекте, про который я писал в посте, например, был один внутренний «центральный» сервис. Его протокол глобально не менялся с момента реализации (только расширялся с сохранением обратной совместимости), хотя, честно скажу, сил на него проектировку ушло много. А вот внешний один раз претерпел глобальные изменения (в основном, это было связано с а) изменением внутренней архитектурой проекта б) протокол перестал выполнять узкоспециализированные операции и дал много больше возможностей партнёрам). Но при этом старая спецификация была реализована в качестве конвертера к новому протоколу (т.е. получилась такая схема для партнёров, которые не перешли на новую версию: [gateway] <--протокол v2--> [конвертер] < — протокол v1 --> [партнёр]).
> Нету ведь идеальной архитектуры на все случаи жизни.
Здесь полностью согласен. Всегда будут и ошибки, и плюсы и минусы. У всех популярных протоколов не одна версия была…
Вообще, что такое хорошая архитектура? С моей точки зрения — это когда нужно добавить что-то новое или кастомизировать старое и ты такой сразу же «опа, а вот это можно сделать так так и так» и никаких костылей. Как это сделать — у меня пока только на уровне ощущений (я нифига не архитектор и всегда такими вопросами у меня занимались отдельные специалисты).
Вообще (в частности для XML) очень хорошо помогает проектировка с WSDL. Есть графические утилиты (по-моему, в том же Eclipse), с помощью которых можно визуально набросать будущий протокол. Ещё одно моё правило — это включение максимально возможного функционала (даже если сейчас такого требования не стоит) на этапе проектировки.
То есть:
1. Формируем требования — чего мы хотим от протокола в данный момент;
2. Накидываем архитектуру;
3. Смотрим, влезает ли без костылей такой-то функционал;
4. Правим архитектуру и возвращаемся к п.3.
Если сильно не увлекаться и придерживаться минимализма, может получиться хорошая штука.
И, кстати, заметьте, что в посте я почти не критиковал архитектуру.
Удалённой стороне, скорее всего, важно:
1. Интеграция в принципе возможна;
2. Есть спецификации и они соответствуют реальному шлюзу (хотел бы написать, реальный шлюз соответствует спецификациям, но...);
3. Шлюз работает и не меняет своего поведения;
4. Для реализации протокола на объектном ЯП не нужно создавать разные классы для одинаковых сущностей.
Какая-та определённая «красота» большинству до фени :)
Удалённой стороне, скорее всего, важно:
1. Интеграция в принципе возможна;
2. Есть спецификации и они соответствуют реальному шлюзу (хотел бы написать, реальный шлюз соответствует спецификациям, но...);
3. Шлюз работает и не меняет своего поведения;
4. Для реализации протокола на объектном ЯП не нужно создавать разные классы для одинаковых сущностей.
Какая-та определённая «красота» большинству до фени :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы технических партнёров и их предупреждение в мини-историях