Я не очень разбираюсь в Spring, но я довольно хорошо знаком с SCA, поскольку работал с ним в IDE IBM WebSphere Integration Developer и в средах, в которых он развертывается: WebSphere Enterprise Service Bus и WebSphere Process Server.
На самом деле все это связано с абстракцией и мыслью о том, чтобы позволить разработчикам сосредоточиться на самом важном - бизнес-логике.Мы все знакомы с концепцией объектно-ориентированного программирования и с тем, как эта абстракция лучше представляет "реальный мир".Затем появляются веб-сервисы и сервис-ориентированная архитектура.Веб-сервисы дополнительно абстрагируют нашу логику, делая ее менее зависимой от того, какой язык стоит за нашей логикой.Теперь C ++ или .Net или Java, или даже RPG, или COBOL, или что-то еще может быть за нашим веб-сервисом.Мы можем заставить языки и системы взаимодействовать друг с другом так, чтобы это не зависело от CORBA и библиотек, а что нет.
SCA (Service Component Architecture) пытается вывести SOA на следующий уровень.Он пытается абстрагировать протокол и адрес, используемые для связи с другой системой или службой.И вот почему: работая с веб-сервисами, вы, как разработчик, все еще должны работать с протоколом и писать или подключать МНОГО стандартного кода.Вы должны знать, если вы http или https.Вы должны знать, являетесь ли вы (в мире Java) JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 или даже JAX-RS (на основе REST).Вам нужно знать, работаете ли вы с JSON, XML или SOAP и SOAP, это 1.0, 1.1 или 1.2?И иногда вам даже нужно знать, как поставщик вашего сервера приложений реализует определенные вещи (вы не должны, но это может быть так).А потом, что произойдет, если вы хотите, чтобы ваш веб-сервис говорил с другим сервисом.Но эта вторая служба основана на обмене сообщениями.Означает ли это, JMS?MQ?JMS над MQ?Другой?А как насчет только чистого HTTP POST и GET?
Вот где приходит SCA. SCA пытается абстрагировать конечные точки ваших сервисов и скрыть реализацию протокола от вас, разработчика.Когда вам нужен сервис, вы просто просматриваете его через API SCA и затем вызываете сервис (я думаю, что метод выполняется? По крайней мере, это расширение IBM SCA).Но в любом случае .... Теперь вам не нужно знать, что сервис, с которым вы общаетесь, - это JAX-WS 2.1 или REST или даже MQ.Вам не нужно знать, что вы работаете с SOAP / HTTP, JSON / XML, SOAP / JMS или чем-то еще.SCA скрывает это все от вас.Он позволяет вам соединять сервисы разных реализаций друг с другом, чтобы они могли общаться друг с другом через общий «сервисный интерфейс».
Как вы можете себе представить, это еще один уровень абстракции и технологии поверхсуществующие абстрактные технологии.Но, увидев это сам, я считаю, что это стоит посмотреть.Я знаю, что IBM и Apache (и я думаю, что другие, которые просто не приходят в голову в данный момент) работали над созданием стандарта SCA.(И на самом деле версия SCA от IBM теперь построена на открытом стандарте, представленном Apache. Надеемся, что другие поставщики, поддерживающие SCA, сделают то же самое.)
Я думаю, что стоит потратить время на изучение.Это может помочь вам сосредоточиться не столько на интеграции сервисов, основанных на их протоколах, сколько на бизнес-логике сервисов, которая действительно является ценностью, которую они приносят в таблицу.