Является ли теперь SOAP устаревшей технологией?

Question

Люди все еще пишут SOAP-сервисы или это технология, которая прошла срок хранения архитектуры ? Люди возвращаются в двоичные форматы?

Answer 1

Альтернативой SOAP являются не двоичные форматы.

Я думаю, что вы наблюдаете всплеск желания отказаться от сложностей WS- * в пользу REST и JSON, потому что они намного проще в использовании и не требуют каркасов для успешного использования. Проблемы, которые якобы пытается решить WS- *, не являются проблемой для большинства пользователей, но они должны платить за сложность любым способом.

Answer 2

Я все еще пишу службы WS - * -. Несколько удивительно, у меня было меньше проблем с ними, когда я пытался взаимодействовать с менее способными разработчиками. Это потому, что если я отправляю им файл WSDL, они знают, как запустить его через свой инструмент и получить API, который они могут вызвать, при этом, к счастью, не знают, что происходит внутри. Чтобы предоставить клиентам услугу REST, я должен начать говорить с ними о HTTP и XML, которые они на самом деле не понимают так же хорошо, как думают, а потом у меня начинает болеть голова.

Другими словами, чтобы быть успешным с REST, и поставщик услуг, и потребитель должны знать, что они делают (и они могут упростить задачу и придумать отличное, не & ndash; WS- * решение). С технологиями WS- * это все еще может быть успешным, даже если только одна сторона имеет подсказку.

Я думаю, однако, что REST-ориентированные стандарты, которые намного менее сложны, чем нынешние стандарты WS, в конечном итоге появятся, и когда это произойдет, будут доступны и сопоставимые инструменты.

Answer 3

Я так думаю. Решения RESTful становятся все более разумными для подавляющего большинства случаев использования; сложности SOAP и других технологий RPC больше не стоят усилий.

Answer 4

Мы использовали SOAP, но, поскольку мы контролируем обе конечные точки обмена сообщениями (толстый клиент в Интернете, подключающийся к нашим серверам), мы решили, что «лингва франка» в XML не дает никакой реальной выгоды. Вместо этого мы экспериментируем с двоичной сериализацией через буферы протокола Google, и, как и все, что мы узнали до сих пор. Это в некотором роде CORBA, но меня это не раздражает, как в CORBA. До сих пор не нашли наилучшего соответствия для уровня RPC, но почти уверен, что полезной нагрузкой будут буферы протокола.

Я хочу подчеркнуть, что если вы контролируете обе стороны разговора, то в обход налога на XML есть существенные преимущества в эффективности.

Answer 5

Я бы не стал рассматривать SOAP-наследство вообще. REST vs. SOAP на самом деле является продолжением дискуссии COM / CORBA против HTTP POST / GET и т. Д. SOAP - это не что иное, как обновленная версия тех же принципов, которые определены в C и C (контракты, поставщики, потребители и т. Д.). , Просто SOAP оказался успешным (по крайней мере, частично), когда два других потерпели неудачу (и, возможно, у SOAP просто лучшая маркетинговая команда), то есть SOAP действительно позволяет различным системам подключаться довольно легко по сравнению с предшественники. При этом он по-прежнему страдает от тех же недостатков, что и COM / CORBA ... он может стать действительно сложным.

Я думаю, что REST сейчас возвращается в моду. В этом нет ничего нового, люди просто смотрят на это по-другому. Посмотри в интернете. Это ОТДЫХ, и это было вокруг в течение многих лет. Через 5 лет люди будут оглядываться назад и говорить то же самое о том, что это наследие и необходимость перемен. Это природа разработки программного обеспечения. Все зацикливается.

Дискуссия о том, какой из них лучше, будет похожа на дебаты с табуляторами и пробелами. Будут люди с разных сторон, которые клянутся, что лучше. В конце концов, они оба достигают одной и той же цели. Конечно, в некоторых ситуациях одно будет лучшим решением, чем другое, но в итоге ни один из них не будет превосходить 100% времени.

Answer 6

Да, некоторые люди все еще (а теперь 2011!). Я думаю, что основная причина в том, что MS WCF автоматически генерирует привязки SOAP. Ужас.

Answer 7

Невозможно определить, что является лучшим технологическим решением, не учитывая, в чем проблема, другими словами, каков контекст. И REST, и SOAP имеют свое место. Если у вас есть сайт с высоким трафиком и аудитория разработчиков, которым удобно использовать REST, то SOAP был бы плохим выбором, в первую очередь потому, что размер сообщения невероятно раздутый. Если у вас небольшой сайт со скромным бюджетом на разработку, то SOAP будет лучшим выбором благодаря автоматической генерации прокси из WSDL. Чтобы провести справедливое сравнение, следует отметить, что реализация диалога REST занимает больше времени на разработку и, следовательно, стоит дороже, что очень важно для вашего босса.

Несмотря на то, что SOAP является более сложным протоколом, по моему опыту, это не означает проблем с поддержкой. Это связано с тем, что сообщения работают по протоколу HTTP и могут быть легко отлажены, как и сообщения REST, а стеки SOAP, доступные на основных платформах, очень надежны.

Сложность SOAP, конечно, является преимуществом, если ваши требования включают сложные элементы, такие как федеративная защита сообщений. С другой стороны, такого рода требования не часто встречаются в моем опыте. Комитет по стандартам WS, возможно, был уязвим к некоторым проблемам YAGNI. Теперь, когда общение через веб-сервис стало обычным делом, оказалось, что это было проще, чем первоначально предполагалось.