SOA vs db-centric приложения
А вот скажите, чем может быть полезна SOA и кто это дело использовал на практике?
А вот тут учинился спор между мной(адептом баз данных, реляционных моделей и db-centric приложений) и программистом на жабе, который рекомендует SOA, на базе своего опыта.
Я с ходу не представлю, чем настолько хороша SOA, кроме сплошного админского напряга следить за всеми этими сервисами и их доступностью, согласовывать протоколы взаимодействия и прочей энтерпрайзности.
А вот тут учинился спор между мной(адептом баз данных, реляционных моделей и db-centric приложений) и программистом на жабе, который рекомендует SOA, на базе своего опыта.
Я с ходу не представлю, чем настолько хороша SOA, кроме сплошного админского напряга следить за всеми этими сервисами и их доступностью, согласовывать протоколы взаимодействия и прочей энтерпрайзности.
no subject
Что где-то на Марсе какие-то неведомые науке Васи Пупкины добились удивительных результатов - вполне верю, вон, в цирке воздушные гимнасты, жонглеры-наездники да эквилибристы-эксцентрики еще и не то выделывают. Только вот я - не эквилибрист, и окружен далеко не жонглерами.
no subject
В качестве даунсайда, убивающего идею на практике — геморрой с интеропом: внутри джавы это ещё хоть как-то работает, но если начинается C, PHP, etc — туши свет. Стандарты то сырые (WSDL 2.x), то устаревшие (WSDL 1.x).
Фактически, получается, SOA — это очередная пляска типа CORBA: система достаточно сложна, чтобы написать полностью конформного клиента на коленке, а автоматические средства генерации выдают плохо совместимый друг с другом и с версиями WSDL код.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
no subject
SOA позволяет нескольким людям или небольшим командам работать над разными частями проекта почти независимо (координация осуществляется на уровне спецификаций/контрактов сервисов), а DB-centric проекты требуют интенсивной коммуникации/координации между участниками проекта, где DB guy — царь и бог.
Для небольших проектов SOA не нужна.
no subject
All you have to do now is cross your fingers that no requirements ever change for just one service. If something happens to cause a schema change, you could find yourself needing to rebuild, retest, and redeploy lots of services. I know of one company with 2,500 web services. As Sponge Bob Square Pants says, good luck with that.
no subject
no subject
а мне другого интерфейса не дали -- не html же парсить?
no subject
no subject
(no subject)
(no subject)
(no subject)
no subject
(no subject)