На первый взгляд, мне показалось, что rubyrabbit и Мендель разыгрывают сценку «гражданин — чиновник».
Господин Мендель, Вы же, надеюсь, никак не относитесь к РОИ?
Пожалуй, соглашусь с amarao: «Моё мнение — shared-хостинг обречён.»
У меня два корпоративных сайта в Селектеле. Когда изучал вопрос хостинга, был выбор: или искать действительно хороший быстрый хостинг или положить сайты на свои «большие» сервера.
В результате выбрал ни то ни другое — виртуалка Селектела. Для меня по факту тот же хостинг (по цене), но только весь софт настроен оптимально под сайты.
И, кстати, заметьте, что в посте я почти не критиковал архитектуру.
Удалённой стороне, скорее всего, важно:
1. Интеграция в принципе возможна;
2. Есть спецификации и они соответствуют реальному шлюзу (хотел бы написать, реальный шлюз соответствует спецификациям, но...);
3. Шлюз работает и не меняет своего поведения;
4. Для реализации протокола на объектном ЯП не нужно создавать разные классы для одинаковых сущностей.
Какая-та определённая «красота» большинству до фени :)
STOMP — не юзал и ничего не могу про него сказать.
> Секурность за счет VPN-соединений
Может быть хорошим решением для систем с «ограниченным набором клиентов» (в том смысле, что о факте каждого подключения вам заранее известно).
> Запросы в HTTP POST
Тут всё зависит от нужд протокола, но я бы, при возможности реализации через GET-запросы, выбрал именно GET.
Часто коробочные решения имеют возможность подключить «http колбэки» и далеко не все из них умеют слать POST.
> Вообщем, пока что лучше HTTP ничего не нашлось.
ИМХО HTTP покрывает очень большое количество нужд.
Следующий шаг после HTTP — это, может быть, готовый брокер сообщений (есть 3-4 популярных решения).
Ну и для бинарных протоколов транспорт (вплоть до физического) может быть какой-то хитрый.
> По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть.
В том проекте, про который я писал в посте, например, был один внутренний «центральный» сервис. Его протокол глобально не менялся с момента реализации (только расширялся с сохранением обратной совместимости), хотя, честно скажу, сил на него проектировку ушло много. А вот внешний один раз претерпел глобальные изменения (в основном, это было связано с а) изменением внутренней архитектурой проекта б) протокол перестал выполнять узкоспециализированные операции и дал много больше возможностей партнёрам). Но при этом старая спецификация была реализована в качестве конвертера к новому протоколу (т.е. получилась такая схема для партнёров, которые не перешли на новую версию: [gateway] <--протокол v2--> [конвертер] < — протокол v1 --> [партнёр]).
> Нету ведь идеальной архитектуры на все случаи жизни.
Здесь полностью согласен. Всегда будут и ошибки, и плюсы и минусы. У всех популярных протоколов не одна версия была…
Вообще, что такое хорошая архитектура? С моей точки зрения — это когда нужно добавить что-то новое или кастомизировать старое и ты такой сразу же «опа, а вот это можно сделать так так и так» и никаких костылей. Как это сделать — у меня пока только на уровне ощущений (я нифига не архитектор и всегда такими вопросами у меня занимались отдельные специалисты).
Вообще (в частности для XML) очень хорошо помогает проектировка с WSDL. Есть графические утилиты (по-моему, в том же Eclipse), с помощью которых можно визуально набросать будущий протокол. Ещё одно моё правило — это включение максимально возможного функционала (даже если сейчас такого требования не стоит) на этапе проектировки.
То есть:
1. Формируем требования — чего мы хотим от протокола в данный момент;
2. Накидываем архитектуру;
3. Смотрим, влезает ли без костылей такой-то функционал;
4. Правим архитектуру и возвращаемся к п.3.
Если сильно не увлекаться и придерживаться минимализма, может получиться хорошая штука.
Ещё, что касаемо архитектуры, надо сразу понимать:
— Протокол синхронный / асинхронный;
— Сохраняет ли состояние;
— Насколько надёжен транспорт (HTTP НЕ надёжен);
— Есть ли обратные вызовы (от сервера к клиенту);
— Требуется ли постоянное соединение.
Вы задаёте вопрос из серии «Какие бы технологии вы посоветовали для разработки ПО». А задаёте его по тому, что не понимаете архитектуру своего протокола (всё ИМХО, конечно :) ).
Тут, с моей точки зрения, очень важно понимать, во-первых, для кого предназначено API, во-вторых, ваши возможности и ресурсы (с точки зрения владения / использования теми или иными технологиями).
Транспорт, я так понимаю, только HTTP?
В принципе, вы можете сделать авторизацию просто по SSL-сертификату (если требуется шифрование).
Но это, во-первых, потребует правильной настройки web-сервера, во-вторых, хорошо подумайте, сколько минусов в карму получите от пользователей.
Если API для крупных корпоратов и/или очень сложной интеграции, то, скорее всего, только SOAP с вменяемым WSDL.
SOAP в том числе решает вопросы авторизации / ограничения доступа (практически из коробки) и, самое главное, структурированности / типизации данных.
В больших приложениях со сложными протоколами удобно автоматом собирать из WSDL документацию и объекты для работы с протоколом. Всё это дело в последствии легче саппортить / допиливать.
> SOAP стандартен
SOAP, кончено, стандартен, но только Java (по крайней мере, я не видел вменяемых библиотек и инструментов под другие языки).
+ по-моему, в различных библиотеках есть разные особенности относительно стандартов (я уже не помню, насколько серьёзные проблемы возникали). Но крайне не рекомендую юзать SOAP для простых протоколов / приложений — и вы и удалённая сторона больше потратите времени на сам SOAP, чем на полезные данные.
> SOAP сложноват
ИМХО для архитектора он не сложноват, он избыточен. Но за счёт избыточности есть очень много прикольных фич.
Если для «физиков» или для простых протоколов (особенно ориентированных на интеграцию web-приложения), то мне нравится, когда ответ приходит в двух вариантах на выбор: XML / JSON. А вот с запросом сложнее. Если это из серии «дай мне информацию об объекте #1234», то тогда просто GET. Если что-то более сложное (например, клиент передаёт вам изображение на обработку), то тогда только POST.
Авторизация в этом случае либо по SSL сертификату (как писал выше) либо по ключу, передаваемому одним из параметров.
Ещё серьёзный вопрос насколько протокол должен быть безопасен. Нужно ли шифрование? Должен ли сервер / клиент подписывать сообщение (например, в договоре может быть указано, что стороны признают общение по протоколу юридически значимым)? Если должен, то тогда обязательно предусмотреть сигнатуру (она же может являться ключом для авторизации), иначе с SSL придётся дёргать подписанные HTTP запросы…
REST мне лично не нравится. Вернее так (у меня примерно такое же отношение к XSLT): идея отличная, но, во-первых, сложно продумать вменяемую архитектуру, во-вторых, REST, по моим наблюдениям, не очень-то популярен (есть риск словить минусов в карму от удалённой стороны). Но если вы осилите (или найдёте человека, который осилит архитектуру), то это будет очень хорошее решение для простых протоколов (или так: для протоколов управления чем-то).
С авторизацией проблем нет (она есть «из коробки»): HTTP Basic access authentication (ведь если говорить человеческим языком, то REST — это просто использование HTTP «на полную мощность»).
> И при этом насмотрелся на всякие многослойные нестандартные от именитых провайдеров. Вроде бы хрень, но ведь люди не первый год работают, наверняка эта хрень не просто так.
В том то и дело, что не первый год работают :) У многих компаний протокол нарастает как снежный ком и в результате превращается в очень тяжелого (в осмыслении и в работе) монстра.
Это сделано не специально — просто кто-то не хотел подумать (ну или очень торопился).
Если для физиков делаете, то посмотрите публичные API «больших пап» (а-ля Google).
Если для корпоратов и/или SOAP, то надо искать вменяемы коммерческие приложения и анализировать.
Есть ещё узко специфичные протоколы (например, OAuth) — тут рекомендую просто взять готовую (и популярную) библиотеку, а не изобретать собственный велосипед.
Есть ещё одна узкая ниша — бинарные протоколы. Но, думаю, что если перед вами встала такая задача, вы и без меня знаете, что делать :)
И последнее. В протоколе главное даже не технологии, а архитектура (что бы вы не использовали, в качестве полезной нагрузки будут передаваться данные вашего приложения и на это стоит обратить внимание).
Протокол должен быть:
1. Максимально, на сколько это возможно, прост;
2. Сложный протокол должен быть хорошо структурирован и разбит на объекты (ООП протокол :) ). За один запрос должно быть выполнено одно простое действие;
3. Всегда оставляете задел на будущее (резервируйте имена, коды ответов и т.д.);
4. По возможности, сохраняйте обратную совместимость (но если вы понимаете, что с архитектурой в первой версии вы налажали, просто реализуйте второй (отдельный) гейт под новую архитектуру);
5. Ну и не допускайте проблем, описанных в статье :)
syschel в общем-то уже ответил :)
У нас в этом случае другой прикол был: примеры были (в описании протокола) и слеши там прямые были.
Данные мы просили — нас посылали в документацию. Т.к. для SOAP используются готовые библиотеки, никто из наших и не подумал экспериментировать со слешами.
Да я бы с радостью всех завернул читать мануалы, но «Задача от коммерческого отдела была простая и, казалось бы, выполнимая: подключать всех и быстро.» Мы не могли не подключать партнёров, т.к. это сильно бы повредило бизнесовой части. Учить ту сторону жизни также не всегда было возможно, т.к. ещё не известно, кто был больше заинтересован в подключении — мы или они.
Вообще, эта статья была написана после обсуждения вот этого поста.
Там в комментариях я написал, что был вынужден подключать партнёров, но, например, никогда бы не стал работать с такой компанией, если бы у меня был выбор.
Увы… многие из описанных проблем были в компаниях, известных, как минимум, на уровне СНГ.
Некоторые в «отраслевых» компаниях (но очень хорошо известных в своей отрасли), производящих собственный (сертифицированный по международным сертификатам) софт.
Малый (и не ИТ) бизнес как раз доставлял меньше всего проблем, т.к. туда, как правило, устанавливался наш софт.
Я так спрашиваю, потому, что мне не понятен посыл статьи.
Немного расширю свою точку зрения: пользователи Azure Storage и не должны были замечать, что сертификаты скоро закончатся.
Объясню на личном примере: я работал тех. руководителем в организации, которая (в том числе) подключала десятками поставщиков услуг к своей системе. Т.к. у поставщиков услуг шлюзы, мягко говоря, работали не всегда так, как задумано (даже не по протоколам, разработанными этими поставщиками услуг — вроде и сходство есть, а вроде и не работает), то руководитель отдела интеграции от меня получил очень короткое, но ёмкое указание «предусмотреть ЛЮБУЮ нештатную ситуацию».
Там и реверс инженеринг протоколов был. Там и сертификаты проверялись хитрым образом (кстати, большинство сертификатов были самоподписные) и система могла продолжить работу даже с невалидным сертификатом (при соблюдении некоторых других условий) и выдать предупреждение на саппорт. И ДНСу мы не доверяли, сохраняя ИПшники и выбирая подходящий вариант. И другой веселухи было много (кстати говоря, не всегда эти ухищрения помогали — один раз партнёр так хитро поменял роутинг, что вместо продакшн шлюза все наши запросы уходили на тест. после этого было желание начать статические маршруты прописывать). Но это всё делалось только из-за того, что партнёры подключались на «взаимовыгодных условиях».
С другой стороны у нас был дата-центр, где хостился продакшн. И никогда я не давал задачу саппорту изощряться также, как интеграции (естественно, минимальный мониторинг состояния ДЦ был, например, загруженность канала). Тут принцип прост: мы платим деньги и хотим получить качественную услугу. Если что-то не работает по вине ДЦ (даже если мы теоретически могли предупредить эту проблему), то это вина ДЦ и он нёс за это ответственность (в т.ч. финансовую).
Я понимаю, что сравнивать по SLA несколько стоек в ДЦ и хостинг на Azure не совсем корректно, но какие-то уровни разграничения ответственности должны быть. Лично я бы после такой ерунды просто ушёл бы с Azure.
Что хотел сказать автор?
Что у сертификатов есть срок действия и для https его (ого!) можно увидеть прямо в браузере?
Или что «большие папы» тоже косячат?
Или что все сервисы, от которых зависит ваша система, нужно поставить но мониторинг?
Зануда моде он: в gmail есть возможность включить кнопку «отмена» для отправленных писем.
Т.е. вы нажимаете «отправить» и теперь у вас есть несколько секунд на то, чтобы передумать и нажать «отмена».
На первый взгляд, мне показалось, что rubyrabbit и Мендель разыгрывают сценку «гражданин — чиновник».Господин Мендель, Вы же, надеюсь, никак не относитесь к РОИ?
Ёлки, я, чуть было, не повёлся…
У меня два корпоративных сайта в Селектеле. Когда изучал вопрос хостинга, был выбор: или искать действительно хороший быстрый хостинг или положить сайты на свои «большие» сервера.
В результате выбрал ни то ни другое — виртуалка Селектела. Для меня по факту тот же хостинг (по цене), но только весь софт настроен оптимально под сайты.
Представляю, как это будет в новостях ЦОДов:
Наш ЦОД прошёл сертификацию TIER 4. Все сотрудники зарезервированы по схеме 2(N+1).
Нужно только правильно допилить закон.
Я залип на этой картинке минут на пять.
П.С. Включите плавную прокрутку в браузере и покрутите страницу вниз-вверх (действует только на небольших экранах).
Удалённой стороне, скорее всего, важно:
1. Интеграция в принципе возможна;
2. Есть спецификации и они соответствуют реальному шлюзу (хотел бы написать, реальный шлюз соответствует спецификациям, но...);
3. Шлюз работает и не меняет своего поведения;
4. Для реализации протокола на объектном ЯП не нужно создавать разные классы для одинаковых сущностей.
Какая-та определённая «красота» большинству до фени :)
> Секурность за счет VPN-соединений
Может быть хорошим решением для систем с «ограниченным набором клиентов» (в том смысле, что о факте каждого подключения вам заранее известно).
> Запросы в HTTP POST
Тут всё зависит от нужд протокола, но я бы, при возможности реализации через GET-запросы, выбрал именно GET.
Часто коробочные решения имеют возможность подключить «http колбэки» и далеко не все из них умеют слать POST.
> Вообщем, пока что лучше HTTP ничего не нашлось.
ИМХО HTTP покрывает очень большое количество нужд.
Следующий шаг после HTTP — это, может быть, готовый брокер сообщений (есть 3-4 популярных решения).
Ну и для бинарных протоколов транспорт (вплоть до физического) может быть какой-то хитрый.
> По поводу архитектуры — легко сказать, а на деле раз-два в год происходят ключевые изменения в стратегии развития, чего в архитектуре сложно предусмотреть.
В том проекте, про который я писал в посте, например, был один внутренний «центральный» сервис. Его протокол глобально не менялся с момента реализации (только расширялся с сохранением обратной совместимости), хотя, честно скажу, сил на него проектировку ушло много. А вот внешний один раз претерпел глобальные изменения (в основном, это было связано с а) изменением внутренней архитектурой проекта б) протокол перестал выполнять узкоспециализированные операции и дал много больше возможностей партнёрам). Но при этом старая спецификация была реализована в качестве конвертера к новому протоколу (т.е. получилась такая схема для партнёров, которые не перешли на новую версию: [gateway] <--протокол v2--> [конвертер] < — протокол v1 --> [партнёр]).
> Нету ведь идеальной архитектуры на все случаи жизни.
Здесь полностью согласен. Всегда будут и ошибки, и плюсы и минусы. У всех популярных протоколов не одна версия была…
Вообще, что такое хорошая архитектура? С моей точки зрения — это когда нужно добавить что-то новое или кастомизировать старое и ты такой сразу же «опа, а вот это можно сделать так так и так» и никаких костылей. Как это сделать — у меня пока только на уровне ощущений (я нифига не архитектор и всегда такими вопросами у меня занимались отдельные специалисты).
Вообще (в частности для XML) очень хорошо помогает проектировка с WSDL. Есть графические утилиты (по-моему, в том же Eclipse), с помощью которых можно визуально набросать будущий протокол. Ещё одно моё правило — это включение максимально возможного функционала (даже если сейчас такого требования не стоит) на этапе проектировки.
То есть:
1. Формируем требования — чего мы хотим от протокола в данный момент;
2. Накидываем архитектуру;
3. Смотрим, влезает ли без костылей такой-то функционал;
4. Правим архитектуру и возвращаемся к п.3.
Если сильно не увлекаться и придерживаться минимализма, может получиться хорошая штука.
— Протокол синхронный / асинхронный;
— Сохраняет ли состояние;
— Насколько надёжен транспорт (HTTP НЕ надёжен);
— Есть ли обратные вызовы (от сервера к клиенту);
— Требуется ли постоянное соединение.
Тут, с моей точки зрения, очень важно понимать, во-первых, для кого предназначено 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. Ну и не допускайте проблем, описанных в статье :)
У нас в этом случае другой прикол был: примеры были (в описании протокола) и слеши там прямые были.
Данные мы просили — нас посылали в документацию. Т.к. для SOAP используются готовые библиотеки, никто из наших и не подумал экспериментировать со слешами.
Вообще, эта статья была написана после обсуждения вот этого поста.
Там в комментариях я написал, что был вынужден подключать партнёров, но, например, никогда бы не стал работать с такой компанией, если бы у меня был выбор.
Некоторые в «отраслевых» компаниях (но очень хорошо известных в своей отрасли), производящих собственный (сертифицированный по международным сертификатам) софт.
Малый (и не ИТ) бизнес как раз доставлял меньше всего проблем, т.к. туда, как правило, устанавливался наш софт.
Немного расширю свою точку зрения: пользователи Azure Storage и не должны были замечать, что сертификаты скоро закончатся.
Объясню на личном примере: я работал тех. руководителем в организации, которая (в том числе) подключала десятками поставщиков услуг к своей системе. Т.к. у поставщиков услуг шлюзы, мягко говоря, работали не всегда так, как задумано (даже не по протоколам, разработанными этими поставщиками услуг — вроде и сходство есть, а вроде и не работает), то руководитель отдела интеграции от меня получил очень короткое, но ёмкое указание «предусмотреть ЛЮБУЮ нештатную ситуацию».
Там и реверс инженеринг протоколов был. Там и сертификаты проверялись хитрым образом (кстати, большинство сертификатов были самоподписные) и система могла продолжить работу даже с невалидным сертификатом (при соблюдении некоторых других условий) и выдать предупреждение на саппорт. И ДНСу мы не доверяли, сохраняя ИПшники и выбирая подходящий вариант. И другой веселухи было много (кстати говоря, не всегда эти ухищрения помогали — один раз партнёр так хитро поменял роутинг, что вместо продакшн шлюза все наши запросы уходили на тест. после этого было желание начать статические маршруты прописывать). Но это всё делалось только из-за того, что партнёры подключались на «взаимовыгодных условиях».
С другой стороны у нас был дата-центр, где хостился продакшн. И никогда я не давал задачу саппорту изощряться также, как интеграции (естественно, минимальный мониторинг состояния ДЦ был, например, загруженность канала). Тут принцип прост: мы платим деньги и хотим получить качественную услугу. Если что-то не работает по вине ДЦ (даже если мы теоретически могли предупредить эту проблему), то это вина ДЦ и он нёс за это ответственность (в т.ч. финансовую).
Я понимаю, что сравнивать по SLA несколько стоек в ДЦ и хостинг на Azure не совсем корректно, но какие-то уровни разграничения ответственности должны быть. Лично я бы после такой ерунды просто ушёл бы с Azure.
Что у сертификатов есть срок действия и для https его (ого!) можно увидеть прямо в браузере?
Или что «большие папы» тоже косячат?
Или что все сервисы, от которых зависит ваша система, нужно поставить но мониторинг?
Т.е. вы нажимаете «отправить» и теперь у вас есть несколько секунд на то, чтобы передумать и нажать «отмена».
А вот то, что маркетинг может найти своё применение технологии (в случае RFID в купюрах) — это, я думаю, запросто.