Сервисы и сложные системы

При подготовке этой статьи мне удалось побеседовать с известным популяризатором технологий Microsoft Дэвидом Чаппеллом. Дэвид — специалист широкого профиля, но в последнее время он специализируется на пропаганде инициативы S+S, являющейся фирменной альтернативой, которую корпорация предлагает по отношению к SaaS. Сервисный подход, лежащий в основе S+S и других схожих начинаний, Чапппелл назвал «подлинной сервисной революцией».

Действительно, термин «сервис» сегодня применяется в самых разных контекстах. Как следствие, возникает многозначность трактовки, но если оставить термин без обсуждения и использовать его «по умолчанию», то уже сложившаяся неразбериха только усилится. К примеру, тому же Чаппеллу принадлежит следующее утверждение: «Если SOA ограничена корпоративными границами, то ее следует трактовать как составную часть S+S, а если SOA выходит за них, то понятия S+S и SOA тождественны».

С такой трактовкой сервисов согласиться невозможно, в ней есть что-то от поговорки про приусадебный участок близкого родственника из столицы Украины. И в технологиях SaaS, и в инициативе S+S сервисы рассматриваются очень узко, всего лишь как способ доставки программного обеспечения (точнее, функционала программного обеспечения). В таком случае перед нами — обычная услуга, попадающая в категорию «по требованию».

А вот в контексте SOA роль сервисов совершенно иная. Здесь речь идет об сервисной архитектуре; следовательно, сервисы следует рассматривать как объекты, из которых строятся сложные системы, называемые сервисными; таким образом, в SOA функции сервисов выходят за рамки услуги.

О сервисах как таковых

На этом терминологические казусы, связанные с сервисами, не заканчиваются. На примере широко распространенного термина «Web-сервисы» можно убедиться в том, что не вполне точная интерпретация названия может со временем привести к существенным заблуждениям. Об этом написал Грэм Гласс, один из тех, кто первым предложил сервисные решения и стал их активным проповедником. Он утверждает, что трактовать название «Web-сервисы» как «сервисы, предоставляемые через WWW», ошибочно. На самом деле данное название ведет свою родословную вовсе не от Всемирной паутины, а от Web of services, то есть «паутины сервисов».

Глассу можно поверить, в недалеком прошлом он был основателем MindElectric, одной из наиболее успешных Internet-компаний первого поколения. Затем вплоть до весны 2007 года он оставался в должности директора по технологиям в webMethods, еще одной заметной для истории сервисов компании, купленной теперь компанией SAG. Именно webMethods еще в 1998 году предложила сервисные технологии. Там же в 2001 году был разработан язык Web Interface Definition Language, предшественник WSDL.

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

По существу, сервисная идея известна давно. В зародышевом виде программные сервисы появились вместе с языками программирования Фортран и Кобол, а затем получили развитие в функциях Си, в объектах Java и хранимых процедурах языка запросов SQL. Но до появления сервисов в том качестве, в котором мы их понимаем сегодня, они оставались привязанными к какому-то конкретному языку или к определенной платформе. Такие сервисы не могли распространяться по сети, из них невозможно было собрать путем «оркестровки» нужное приложение. Пересмотр роли сервисов начался вместе с созданием языка XML, когда открылась возможность распространять приложения; теперь приложение, находящееся на одном компьютере, может стать доступным по всему земному шару.

Эволюционный путь к полноценному пониманию сервисов начался с операционной системы Unix и со встроенного в нее стека протоколов TCP/IP, для которых был предложен метод удаленного вызова процедур Remote Procedure Call (RPC), позволяющий осуществлять удаленный вызов функций, написанных на Си, Фортране или ином языке программирования. В основе этого решения лежит протокол eXternal Data Representation (XDR), он позволяет представить передаваемые данные в формате, не зависящем от языка. С появлением LISP и объектно-ориентированных языков, подобных C++ и Java, удалось еще выше поднять уровень абстракции и открыть разработчикам возможность для создания объектов, в большей степени адекватных их структурам, существующим в реальном мире. Протоколы, появившиеся позднее, позволили осуществлять удаленный вызов процедур еще более естественно, чем RPC. Из них наибольшую популярность приобрели два подхода — CORBA (Common Object Request Broker Architecture), поддерживаемый консорциумом компаний во главе с IBM, Oracle и Sun Microsystems, а также DCOM (Distributed Common Object Model), предложенный Microsoft. Недостатком этих подходов является их замкнутость, гомогенность и несовместимость между собой.

На дальнейшую судьбу сервисов радикальным образом повлияло широкое распространение транспортного протокола HTTP, который изменил мышление ИТ-специалистов, он открыл возможность для обмена данными между машинами и при этом понятен человеку. Но не хватало средства для обмена сервисами и данными через Internet. Именно эту нишу и заполнил язык XML, позволяющий создавать документы с самоописанием, которые легко преобразовывать, с которыми легко работать. Чтобы картина оказалась законченной, оставалось разработать стек протоколов SOAP (Service-Oriented Architecture Protocol), WSDL (Web Services Description Language) и UDDI (Universal Description, Discovery, Integration). Построенные поверх HTTP и XML, эти протоколы позволяют публиковать, обнаруживать и вызывать сервисы независимо от языков, платформ и географического местоположения.

Именно вследствие описанных событий в начале текущего десятилетия компьютерный лексикон обогатился словечком «сервис». Первыми представителями новой волны терминов оказались Web-сервисы, за ними последовала «сервис-ориентированная архитектура» (Service-Oriented Architecture, SOA), еще позже — «программы как сервис» (Software as a Service, SaaS) и даже «информация как сервис» (Information as a Service, IaaS). В конечном итоге сервисная идея приобрела самостоятельность в чистом виде, независимо от ее частной реализации. Ориентацию на сервисы стали рассматривать как один из новых принципов системного проектирования. Но почему именно «сервис» и почему именно «сервисная ориентация» оказались в центре нашего внимания? Попробуем разобраться.

Сервисы и SOA

У подавляющего большинства специалистов ориентация на сервисы ассоциируется исключительно с SOA. Сегодня это действительно одна из самых популярных в мире ИТ трехбуквенных аббревиатур. Однако происходящее порой выглядит как многолетнее топтание на месте. Одна из причин застоя заключается в том, что адепты альтернативных распределенных решений упорно не хотят принимать SOA. В этом отношении показательна статья «Путь SOA, туда-сюда» (From here to there, the SOA way), опубликованная в августовском номере журнала Queue.сom с характерным подзаголовком «SOA не в большей степени серебряная пуля, чем предшествующие подходы».

Попытка обобщить рассуждения о том, что же такое ориентация на сервисы, правда не выходя за границы SOA, предпринята в статье. На уровне SOA сервисная ориентация рассматривается как реализация идеи разделения ответственности или разделения сфер влияния между компонентами. Там же рассмотрены сервисные принципы Томаса Эрла, определяющие свойства сервисов в рамках SOA. Однако сферой SOA область действия сервисов не ограничивается, поэтому любопытно посмотреть на проблему шире. К этому побуждает появление концепций SaaS, SOE (Service Oriented Enterprise) и даже Human Service Bus (буквально «шина человеческих сервисов»), видимо по аналогии с ESB. Следовательно, есть какая-то сила, побуждающая именно сейчас, на нынешнем этапе развития информационных технологий обращаться к сервисам. Но какая?

Сервисы и сложность

Появление сервисных архитектур — объективная необходимость. Сервисная ориентация есть не что иное, как неизбежная реакция на постоянно возрастающую сложность информационных систем. Развитие в соответствии с законом Мура ведет к бесконечному росту числа компонентов информационных систем, а потому — к росту их сложности. В сложности как таковой видят назревшую проблему, некий барьер, укрепился даже термин «проблема сложности». Проблема сложности неоднократно становилась предметом для обсуждения на различного рода конференциях, ей посвящено множество публикаций. Нередко при обсуждении проблемы сложности немедленно предлагается и средство для ее разрешения, обычно это какие-то практические интегрированные решения, скрывающие в себе сложность. Если же постановке задачи придан глобальный характер, как это было сделано в знаменитом меморандуме Пола Хорна, то предлагается не менее глобальное лекарство — переход к самоуправляемым, или автономным, компьютерным системам.

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

Скорее всего, вычленение сложности как проблемы есть не что иное, как признание того, что продукты информационных технологий стали сложными системами в полном смысле этого слова. Мы слишком часто и без должного уважения употребляли слово «система», прилагая его к достаточно простым устройствам, а настоящая система по определению является сложной. Мы создавали бесконечное множество разного рода систем, не обладая достаточным уровнем системного мышления, а когда эти системы перестали соответствовать нашим интуитивным представлениям, мы испугались и назвали их сложными. Вот так и возникла «проблема сложности».

Сложность

В XX веке системная сложность, как таковая, стала объектом исследования ученых. Основополагающие работы по сложности принадлежат американскому ученому Уоррену Уиверу. Отечественным специалистам Уивер известен тем, что обосновал возможность машинного перевода, однако круг его интересов гораздо шире. Он был выдающимся математиком, кибернетиком, философом и одновременно вполне успешным организатором науки, более двух десятилетий возглавлявшим Рокфеллеровский фонд. В историю науки он вошел, прежде всего как соавтор Клода Шеннона по книге «Математическая теория коммуникации». Принадлежащая перу Уивера часть книги посвящена философскому обоснованию информации; она особенно интересна и актуальна сегодня, когда фокус внимания смещается от данных к информации. Уивер, сотрудничавший и с Норбертом Винером, является автором ряда работ по кибернетике. Есть у него серьезные исследования и по теории вероятностей, и в области криптографии.

Еще одним признанным авторитетом по вопросам сложности является Герберт Саймон, профессор Университета Карнеги-Меллона, исследователь в области компьютерных наук, когнитивной психологии, социальных наук. Среди многочисленных научных наград Саймона есть премия Тьюринга (1975) и Нобелевская премия в области экономики (1978). Его основной труд, относящийся к сложности, называется «Организация сложных систем».

В современных условиях неожиданно актуальной стала, казалось бы, не самая важная статья Уивера «Наука и сложность» (Science and complexity), опубликованная в 1948 году в журнале American Scientist. Эту статью можно заслуженно поставить в один ряд с выдающимися научно-популярными публикациями Ванневара Буша, Дага Энгельбарта, Джозефа Ликлайдера, сделанными 40-60 лет назад; сегодня и она, и труды этих классиков продолжают жить, оставаясь философской основой современного компьютерного мира. Надо сказать, что после своего опубликования статья «Наука и сложность» была надолго забыта, интерес к ней возобновился в последние годы, когда в отрасли, в самых разных ее частях, вышла на первый план проблема сложности. За несколько лет эта неведомая прежде проблема распространилась в широком диапазоне от процессоров до корпоративных информационных систем. Сегодня нет такой конференции, где бы ее не упоминали, но, что не может не вызывать удивления, в такой обобщенной постановке, как это сделал Уивер, никто проблему сложности не ставит, ее постоянно привязывают к какой-то отдельно взятой предметной области.

Сложность по Уиверу

Уивер начинает свою статью с обратной задачи, называя ее «проблемой простоты» (Problem of Simplicity). Он показывает, что практически все современные ему изобретения, такие как радио, автомобили, самолеты, кино, фотография, электроэнергетика, базируются на достаточно простых принципах, открытых физиками в XVIII–XIX веках. Суть проблемы простоты заключается в том, что, как показывает практика, удается сделать полезные и, казалось бы, сложные вещи, не прибегая при этом, каким-то особенно сложным решениям, но если оставлять решения простыми, то в будущем такой подход может обернуться неприятностями. Если в процессе дальнейшего развития сохранять верность простым решениям, то рано или поздно наступает критическая ситуация, и напротив, когда в основе лежат сложные решения, то идет равномерное развитие и критическая ситуация не возникает. Иллюстрацией этого может служить парадокс процессорной индустрии, свидетелями которого мы являемся. Сегодня понятно, что первые компьютеры были, по существу, очень незамысловатыми устройствами, построенными по схеме фон Неймана. За последующие пятьдесят лет ничего принципиально нового в области процессорных архитектур не было сделано: та же схема, но с небольшими усовершенствованиями, и это на фоне активнейшего развития полупроводниковых технологий. Это и есть проблема простоты; вот к чему может привести затянувшаяся привязанность к простым решениям.

Рассуждения Уивера о сложности строятся на опыте предшественников. Ученые впервые столкнулись проблемой сложности в начале XX века, она проявилась в известном кризисе физики и привела к созданию квантовой теории и другим теориям, изменившим представления о физической картине мира. Для компьютерных технологий физика важна как материальная основа, а с точки зрения идеологии гораздо ближе биология. Биологи, как и физики, намного раньше инженеров столкнулись с проблемами сложности; именно они заложили основные принципы системного мышления, и случилось это тоже в первые десятилетия XX века.

Чтобы дать представление о проблеме сложности, Уивер приводит наглядный пример. Поведение одного шара на бильярдном столе с успехом может быть исследовано с использованием методов классической механики. Если увеличить количество шаров до нескольких десятков, то их поведение тоже можно каким-то образом описать, прибегнув к достаточно несложным физическим и инженерным методам. Если же количество шаров возрастет до миллионов — представим, что такой бильярдный стол найдется, — то возникает проблема сложности в описании их поведения. Уивер назвал это «проблемой неорганизованной сложности» (Problem of Dizorganized Complexity). Данная проблема стала одной из основных в XX веке, она успешно решается статистическими методами, а с появлением компьютеров начали широко применяться методы моделирования. Современные суперкомпьютеры превратились в один из важнейших инструментов для решения сложных инженерных и научных задач. Для проблемы неорганизованной сложности характерно то, что отдельные элементы — те же шары или молекулы в газовых потоках или что-то еще — не связаны между собой, не образуют единую систему.

Намного сложнее, если так можно сказать, «проблема организованной сложности» (Problem of Organized Complexity). Для ее решения недостаточно использовать статистические методы или методы численного моделирования. С проблемой организованной сложности первыми столкнулись биологи и психологи; в живых системах биологических или социальных — поведение каждого элемента намного сложнее, и они могут быть объединены в системы связями самой различной природы.

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

Сложность и теория систем

Проблема организованной сложности является предметом общей теории систем, междисциплинарной области, включающей в себя сложные системы в природе и обществе. Объектом исследования данной теории может быть организм, социальная группа, электронное устройство или информационный артефакт. Подразделами теории являются общая теория систем, кибернетика, исследования сложных адаптивных систем, теория живых систем, организационная теория, социокибернетика, системные психология и инженерия. Основоположником теории систем был англичанин Герберт Спенсер. Еще до Второй мировой войны было опубликовано несколько серьезных исследований; среди их авторов прежде всего следует назвать Александра Богданова («Тектология») и Людвига фон Берталанфи («Общая теория систем»). После войны кибернетические работы Норберта Винера стимулировали появление новой школы, в ее состав вошли Росс Эшби, Берталанфи, Анатоль Раппорт; позже к исследованиям подключились Грегори Бэйтсон, Умберто Матурано и другие.

Период наибольшего увлечения теорией систем выпал на 60-е и 70-е годы XX века. Книги, журнальные публикации, академические конференции с участием перечисленных ученых и множества других выглядели чрезвычайно привлекательно и многообещающе. Казалось, что вот-вот будет создана общая теория, а дальше на ее основе можно будет строить светлое кибернетическое будущее. Но к середине 80-х — началу 90-х годов значимые исследования в области теории систем почти прекратились. Почему? На этот вопрос могут ответить те, кто профессионально занимался или еще занимается этими проблемами. Для нас важно, что следствием работ в области теории систем стал системный подход. Этот термин часто используют как фигуру речи, но следует понимать, что системный подход — вовсе не метафора, а кибернетическое, осознанное видение сложности какой-то проблемы. Значимость системного подхода состоит в том, что он является методологической основой для целого ряда отраслей, таких как системная психотерапия, экология и других. Сжатое, но достаточно полное представление общей теории систем можно найти в статье шведских авторов Ола Ларсеса и Яда Эль-хори «Взгляды на общую теорию систем».

В теории систем система представляется как множество объектов, связанных отношениями между собой и между атрибутами этих объектов; объекты можно рассматривать в качестве примитивов системного мышления.

Сервисный взгляд на системы великолепно согласуется с представлениями о том, что такое «система» в теории системы. Реальный мир, состоящий из больших и сложных систем, в значительной мере построен на принципах сервисов. Это относится к сферам производства, потребления, услуг, организации бизнеса и т.д.

Онтология сервисов

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

Сервисы, посредством которых осуществляется связь между системными компонентами, имеют между собой много общего — будь то сервисы, имеющие естественную природу, или, скажем, Web-сервисы. Они представляют собой объекты, находящиеся в определенных отношениях и обладающие вложенной в них функциональностью. Можно считать, что сервисы являются обладателями трех качеств:

• потребительское свойство сервиса (service value) — представление сервиса с позиции потребителя;
• сервис как предложение (service offering) — иерархическая система предложения сервисов в том виде, какой ее представляет поставщик;
• сервис как процесс (service process) — описание того, как из сервисов можно выстроить некоторый бизнес-процесс.

Вне зависимости от его физической природы, отдельный сервисный элемент можно представить в виде черного ящика с входными и выходными портами, в число его характеристик входят тип, выполняемая функция, производительность, внутренние ресурсы и т.д. Взаимосвязь между сервисными элементами (coupling) может быть «слабой» (loose) или «сильной» (tight); для современных компьютерных архитектур больший интерес представляет слабая связанность. Ее преимущества следуют из того, что отношения между модулями, осуществляющими сервисы, в большей мере определяются интерфейсами, а не внутренним устройством модулей. Такая организация обеспечивает принцип «скрытия информации» (information hiding), являющийся основой для разделения сфер влияния между компонентами. Если же система строится из жесткосвязанных сервисов, то изменения одного модуля могут повлечь за собой изменения другого, каждый из модулей сложно понять в изоляции от остальных, затруднено многократное использование и тестирование.

Уровень связанности между модулями находится в зависимости от их отношения к контенту, в котором они существуют. Наиболее жесткой является такая связь, когда модули находятся в общем контенте, то есть когда один модуль работает, «зная» все о своем партнере. На противоположном полюсе — связанность, обеспечиваемая посредством обмена сообщениями (message coupling). При таком подходе модули знают о партнерах только то, что они получают в сообщениях. Промежуточные места занимают common coupling, где модули работают с одним и тем же пространством данных, и control coupling, где модули связаны какими-то управляющими сигналами. Кроме того, существуют различные виды модификаций перечисленных способов взаимодействия.

В SOA для объединения слабосвязанных сервисов в систему используют технологии, получившие название Web Service Orchestration (WS-Orchestration) и Web Service Choreography (WS-Choreography), то есть оркестровка и хореография. И хотя еще несколько десятилетий назад Джон Бэкус предупреждал об опасности «антропологизации» компьютеров, оба этих термина прижились. Их нередко путают между собой, несмотря на то что в приложении к SOA они имеют совершенно разный смысл. Упрощая, оркестровку в музыке можно рассматривать как средство для того, чтобы собрать группу инструментов для исполнения одного произведения. А хореография в балете преследует своей целью обеспечение согласованных действий труппы на сцене. При всей размытости этих понятий некоторое различие уловить все же удается. В SOA ситуация проще, для оркестровки сервисов используется язык Business Process Execution Language (WS-BPEL), а для хореографии — язык Web Services Choreography Description Language (WS-CDL). Цель оркестровки сервисов заключается в создании исполняемого бизнес-процесса; цель хореографии — в обеспечении многостороннего взаимодействия. Оркестровка описывает то, как сервисы должны взаимодействовать между собой, используя для этого обмен сообщениями, включая бизнес-логику и последовательность действий. Оркестровка подчинена какому-то одному из участников бизнес-процесса, а хореография предусматривает коллективное действие. Таким образом, задача хореографии в обеспечении распределенного обмена сообщениями между множеством серверов.

Сервисы с человеческим лицом

Относительно недавно сервисные архитектуры попали в сферу внимания теории организации, комплексной дисциплины, относящейся к менеджменту и включающей в себя знания из экономики, социологии, политических наук, антропологии и психологии. В основании теории организации лежат труды Платона, Аристотеля, Николо Макиавелли и других великих. В приложении к производству реальные первые шаги сделал Фредерик Тейлор, который построил свою систему взглядов, получившую название «тейлоризм», взяв в качестве базиса представления о труде Адама Смита. Выросший из тейлоризма подход к административному и научному менеджменту («научная организация труда», или НОТ, столь любимая во времена социализма), по сути, является абсолютизацией бюрократической системы, а в переводе на системный язык — «системой с жесткими связями». Как любая заранее запрограммированная система, в идеале она может работать с точностью хорошо отлаженного механизма. Но в реальной жизни ей не хватает гибкости и реактивности (agility) и других свойств, требуемых современному предприятию.

В поисках компенсации недостатков жестко, связанных систем, построенных на принципах НОТ, в середине прошлого века пришли к идее менеджмента, построенного на человеческих отношениях (Human Relations Management), где внимание сфокусировано на создании команд, мотивации, на роли личности в организации. Особую роль в развитии этого направления сыграл патриарх менеджмента ХХ века Питер Друкер. Однако ни жесткий механистический подход, основанный на мотивации и межличностных взаимодействиях, не являются всеобъемлющими, очевидно, что таковым может быть системный подход, основанный на кибернетических началах. Он не может быть упрощенным. Чилийский эксперимент по созданию единой национальной системы управления Cybersyn, научное руководство которым осуществлял Стаффорд Бир, представляет собой классический пример упрощения социальных и экономических проблем.

Как показывают новейшие исследования теоретиков менеджмента, для создания системы менеджмента, сочетающей в себе лучшие качества двух указанных выше подходов, в наибольшей степени подходит сервисная архитектура, а предприятие, построенное на сервисных принципах, они называют Service-Oriented Enterprise (SOE). По аналогии с шиной корпоративных сервисов Enterprise Service Bus (ESB) они предлагают шину человеческих сервисов Human Service Bus (HSB), где описание деятельности каждого из участников производства переводится на язык сервисов. Аргументы, приводимые в пользу SOE, слово в слово повторяют аргументы в пользу SOA, за тем исключением, что элементами, реализующими сервис, могут быть не только программные сервисы, но и люди-исполнители. Слабая связанность позволяет «скрыть» сложность и информационную избыточность и получить желаемую реактивность предприятия. Средствами хореографии можно перестраивать структуру предприятия, используя готовые блоки, а оркестровкой — задавать бизнес-процессы.

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