Вопрос

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

Это было полезно?

Решение

Это мода в том смысле, что какое-то время найдутся те, кто скажет: «Отныне все должно быть SOA».Тогда через некоторое время хорошие стороны SOA останутся, а более спорные или менее полезные утихнут.

Другие советы

И то, и другое.

Сервис-Ориентированная Архитектура, с реальной инженерной точки зрения, имеет плюсы и минусы.Это слабосвязанная система, и это хорошо, потому что наличие «маленьких, слабо связанных между собой частей» — это надежная стратегия проектирования, которая работала в Unix и имеет много сторонников среди инженеров-программистов.

Однако, как и любое другое программное обеспечение, оно требует очень тщательного проектирования:у вас может быть плохая SOA, как и все остальное, а поскольку эта область еще новая, лучшие практики еще не так хорошо сформулированы.Кроме того, он обычно демонстрирует гораздо худшую производительность, чем другие архитектурные подходы.На данный момент большинство крупных игроков (таких как Google), похоже, считают, что он лучше всего подходит для взаимодействия между различными системами (их API практически являются определением SOA), но не для внутренней архитектуры отдельной системы (используются свои собственные Буферы протоколов для этого).

СОА является причуда, когда дело касается менеджеров, которые ничего не смыслят в инженерном деле.Им это нравится, потому что а) это звучит ново и горячо и б) в нем есть слово «сервис», что заставляет их чувствовать себя полезными.Спросите половину из них, в чем разница между «службой поддержки» и «сервис-ориентированной архитектурой», и им будет сложно вам ответить.

Это отличный способ для поставщиков инструментов заставить вас покупать много вещей (например, ESB), для консультантов — выставлять счета за большое количество оплачиваемых часов, а для Gartner — выдавать больше магических квадрантов.

Я думаю, что это не совсем «причуда»;это скорее эволюция идеи, существовавшей с момента появления сетей:распределенные компоненты.CORBA и DCOM представляли собой проприетарные архитектуры распределенных компонентов.SOA использует HTTP в качестве общего проводного протокола, который может проходить через порт 80 в брандмауэрах.Все остальные стандарты, такие как XML, WSDL и т. д.Это попытки сделать их обнаруживаемыми и автоматически понятными для клиентов.Важно понимать идеи, стоящие за всем этим, и не слишком увлекаться шумихой.

Кажется, он работает для Amazon, Yahoo! и т. д.Возможно, в этом есть что-то полезное и для простых смертных, таких как мы.

Я вижу некоторые опасения:

Задержка поставляется с распределенными компонентами.Если все является службой, взаимодействующей через корпоративную сервисную шину для лучшей развязки, как она может быть быстрой?Возможно, нам грозит опасность создания красивой, разъединяющей свиньи предприятия.

Дизайн — это сложно.Никто не может договориться о том, что представляет собой услуга.Сколько их должно быть на вашем предприятии?Десятки?Сотни?Тысячи?Насколько мелкозернистыми они должны быть?

Если ваш работодатель традиционно финансировал работу по проектной модели, как долгосрочные услуги могут вписаться в эту модель?

Самое важное, что нужно понимать в отношении SOA, — это то, что на самом деле это не технология, а способ организовать ИТ-инфраструктуру как набор повторно используемых сервисов, которые можно комбинировать, а не как текущая норма, состоящая из набора приложений, для интеграции которых требуются дополнительные усилия. когда необходимо.

Конечно, для выполнения этой работы требуются технологии, но «изучение» или покупка этой технологии бессмысленно, если вы не (пере)организуете свою ИТ таким образом.

Я думаю, что основная идея SOA верна и никуда не денется (хотя она может оказаться полезной не в каждом контексте).С другой стороны, SOA как технология — это модное слово, которое умрет.

Лично я бы сказал, что это прихоть.Облако в настоящее время широко распространено, как и мейнфреймы, но затем появились настольные компьютеры и взяли верх.Теперь мы возвращаемся к большому железу...

Я работаю в компании по производству медицинского оборудования и программного обеспечения, и SOA здесь не прихоть, а необходимость.Прогресс на этом фронте идет медленно из-за устаревших систем и стоимости создания такой достаточно открытой системы.

Другой аспект этой дискуссии: планирует ли ваша компания создать набор продуктов или только один продукт.

Не существует такой вещи, как причуда с точки зрения концепций или идей, если кто-то подумал об этом и что-то оказалось хорошим решением, то это не причуда.Хотя если купить Феррари и ездить на ней по грунтовой дороге с включенным ручным тормозом, то это, конечно, прихоть.Слабая связь сегодня жизненно важна, любой опытный консультант или программист, работавший напрямую с заказчиком, скажет вам, что все постоянно меняется, ничто не вечно, как это обсуждалось во время первого анализа, по моему опыту принципы SOA доказали свою ценность.100% моих клиентов, которые раньше работали с другими программистами, рассказали мне, что в какой-то момент другой парень решил начать все сначала или заявил, что определенный запрос невозможно реализовать.SOA — лучшее решение для сложных клиентов, а большинство клиентов трудны, однако вам нужно сохранять чувство меры.ESB — это хорошо, если у вас 100 филиалов в 30 странах и вы планируете быстро расти.Так называемые современные консультанты по программному обеспечению и продавцы программного обеспечения, на мой взгляд, - это ребята, которые никогда в жизни не писали ни строчки кода, они никогда не видели сами процесс анализа, разработки, доставки, управления запросами на изменения и все циклы и пни на пути, поэтому в глазах настоящих людей, занимающихся программным обеспечением, они кажутся фальшивыми.Конечно, они говорят фальшивку, но это потому, что они не знают, о чем говорят, а не потому, что то, о чем они говорят, — фальшивка.С течением времени веб-приложения и облачные вычисления захватывают все больше и больше SOA будет становиться все сильнее и сильнее, поскольку альтернативы межсистемному общению нет, учитывая множество платформ, операционных систем, языков программирования и, конечно же, программисты.Не позволяйте себе вводить себя в заблуждение из-за суеты, создаваемой невежеством других, которым это нравится только потому, что им нравится это слово.

Что касается проблемы с медлительностью, то дам совет:Попробуйте общение через JSON, вы не поверите своим глазам ;).

Если вы имеете в виду «сервисно-ориентированную архитектуру», то существуют приложения, для которых она полезна, но она будет приходить и уходить, как и любая другая причуда.Как и на любом рынке такого типа, здесь есть окно, где возникает нехватка квалифицированных кадров.Если вы приедете в нужное время, вы сможете неплохо из этого выйти.К тому времени, когда это будет разрекламировано в основных средствах массовой информации, вы, вероятно, уже опоздаете, поскольку все остальные Том, Дик и Гарри будут использовать любые рыночные возможности.

Если вы работаете в области, где SOA актуальна, обязательно разберитесь в этом.

Во многом это те же концепции, что и распределенные приложения, которые входили и выходили из моды на протяжении нескольких поколений технологий (SNA, Sun RPC, DCE, CORBA, EJB, DCOM и теперь веб-службы).

Другими словами, системы оркестровки можно рассматривать как средство интеграции компонентов в целое приложение.Если у вас есть ряд компонентов, которые предоставляют полезные сервисы, вы можете создать красивую и гибкую архитектуру приложения.

Как только пыль уляжется, очевидные убийственные приложения SOA станут именно такими же очевидными.Я бы сказал, что окно, в котором можно взимать непропорциональную плату за консультации за знание написания SOA, вероятно, сейчас закрывается.Изучите его, если вы хотите использовать его для чего-то или увидеть полезную синергию с другими навыками или опытом, в которых он может объединиться, чтобы сделать что-то продаваемое.В противном случае получите общее представление и копайте глубже, когда вам нужно.

Если «причуда» — это «мода, которая воспринимается с большим энтузиазмом в течение короткого периода времени;модное увлечение.» то SOA — это не прихоть.SOA существует уже некоторое время – с тех пор, как RPC на основе SOAP (т.Веб-службы XML).С тех пор прошло немало лет, и вместо того, чтобы вымереть, SOA только процветает в своем воплощении WCF.Так что я бы сказал, что SOA — это далеко не прихоть.

Я не думаю, что это действительно прихоть.Просто создать открытые системы, способные взаимодействовать с другими системами, сложнее, чем создать закрытые системы.Я думаю, что это всегда будет правдой.

Также всегда существует снижение производительности, если вы передаете данные с помощью стандартизированных «протоколов», таких как XML Soap.

SOA — неплохая технология, на самом деле я думаю, что ее обычно неправильно реализуют и неправильно интерпретируют.Есть сценарии, которые SOA действительно подходит лучше всего.

Но есть места, где следует избегать SOA.К вашему сведению, одним из недостатков SOA является то, что он обычно медленный.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top