Да, упомянутые вами технологии (веб-службы, EJB, REST и т. Д.) Предназначены для развертывания сервисных инфраструктур.Ключевым моментом в совместимости является то, что интерфейсы должны быть стандартными.В этом смысле, например, EJB - это, по сути, технология J2EE, стандартная только для JCP (Процесс сообщества Java), достаточно справедливая, если вы заботитесь только о совместимости в мире J2EE.Вы не сможете совершать вызовы от клиента .Net к EJB, просто для примера.
С другой стороны, веб-службы (как в SOAP, WSDL и XML) - это стандарт W3C,это означает, что протоколы, сообщения, форматы и т. д. не зависят от технологии.Так, например, вы можете опубликовать сервис с Java с использованием Axis и разработать клиент на .Net, python, C или любом другом языке для отправки сообщений.Это хорошо, но в случае с веб-сервисами уровень стандартов просто сходил с ума в последние годы.Если честно, действительно легко потеряться во вселенной стандартов, которые возникли вокруг сервис-ориентированных архитектур и веб-служб.
Службы REST также являются своего рода стандартом, они в основном полагаются на композицию URL и HTTP для создания механизма связи между серверами и клиентами.Гораздо проще, чем SOAP / WSDL.Сегодня большинство языков предлагают библиотеки для использования и публикации таких сервисов с использованием JSON в качестве формата данных.В REST интерфейсы легче, чем в SOAP / WSDL, у вас нет XML-файла, который определяет вашу службу, но обычно преимущество заключается не в том, чтобы быть проблемой.
В конце концов, если вызаботьтесь о совместимости, затем кодируйте стандарты и не привязывайте себя к каким-либо проприетарным форматам.С REST и веб-сервисами вы должны быть в безопасности.Из этих двух вариантов REST услуги будут моим выбором.
PS: другие распределенные архитектуры, которые не так широко используются сегодня, как те, что вы упомянули, это: RPC / XML, COM и CORBA.