Ноябрьский номер журнала в этом году посвящен сервис-ориентированному подходу («Service Orientation»). К соответствующему тематическому разделу относятся пять больших статей и вводная заметка приглашенного редактора, которым на этот раз является Тициана Маргария (Tiziana Margaria, Potsdam University, Germany). Ее заметка называется «Сервис в глазах наблюдателя» («Service Is in the Eyes of the Beholder»).

Сервис-ориентированность (СО) не является технологией; скорее, это широкомасштабная философия или парадигма. Это понятие относится как к техническим серверным службам (службам печати, передачи и приема факсов, хранения данных и т.д.) и телекоммуникационным службам, так и к высокоуровневым службам поддержки бизнес-процессов и повседневно используемым Web-сервисам.

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

Этот разрыв между концепцией и уровнем зрелости технологии ведет к классической модели эволюции – от творчества к инженерии. В компьютерной науке переход от творчества (уникальных, творчески, вручную изготовленных артефактов) к инженерии (индустриальным, развитым методам) является повсеместным. В последние 20-30 лет такой переход наблюдался в областях конструирования компиляторов, инженерии программного обеспечения, проектирования аппаратуры компьютеров и т.д. Всегда сначала появляются концепция, некоторые иллюстративные убедительные примеры, которые демонстрируют потребность в некоторой новой службе. Это сопровождается громадным разрывом между обещаниями и реальным состоянием дел. Эволюция приводит к тому, что в конце концов оказывается возможным говорить про возникновение «решения». Такой переход наблюдался в области Всемирной Паутины, а сегодня подобный разрыв между концепцией и реальностью существует в области Web-сервисов.

Мы находимся на ранней стадии эпохи сервисов, стадии концепций и обещаний. Сообщество все еще пытается понять, в чем состоят суть и основные характеристики сервис-ориентированного подхода. Эта ситуация не является чрезмерно удивительной, поскольку понимание сервисов зависит от их восприятия пользователями, ожидания которых полностью зависят от контекста применения сервисов. Хотя допустимы задержки и периоды выжидания (например, при реализации служб оперативного обнаружения сервисов), во время которых пользователи отыскивают и собирают информацию, такие задержки неприемлемы при наличии более жестких условий: бронирование билетов должно производиться, банковские переводы должны поступать на правильные счета и т.д. В таких ситуациях естественно ожидать качества сервисов, свойственного области телекоммуникаций: правильной работы всегда и везде.

Несмотря на все различия в разных областях применения, у сервис-ориентированного подхода имеется одно общепризнанное свойство – участие пользователей. У пользователей должна иметься возможность непосредственно влиять на сервисы, управлять ими и приспосабливать их к своим потребностям. По крайней мере, в типичных повседневных ситуациях такое участие должно быть возможно без специальной IT-подготовки. Таким образом, сервис-ориентированный подход потенциально оказывает разрушительное воздействие на существующие структуры. Его эффект можно сравнить с эффектом перевода Библии на общепринятые языки, что устранило потребность в изучении латыни или древнегреческого языков и обеспечило доступ к текстам Священного Писания широкой публике.

С технической точки зрения к сервис-ориентированному подходу можно относиться, как к подходу 80/20 к управлению процессами, который следует принципу «для многих просто, для некоторых сложно». Больше всего усилий затрачивается на разработку внешних компонентов технологии: полную виртуализацию всех технических деталей, не существенных на уровне сервисов; слабое связывание сервисов, обеспечивающее максимальную свободу выбора, оркестровки и эволюции сервисов; учет особенностей прикладных областей, позволяющий сообществу пользователей каждой прикладной области напрямую пользоваться готовыми сервисами. Эта работа, дополняемая последующей стандартизацией, непосредственно способствует повышению производительности труда пользователей. В краткой статье Иоханеса Хельбига и Александра Щердина, опубликованной в этом же номере журнала, суть сервис-ориентированной точки зрения выражается в следующей формуле: семантическая интеграция + слабое связывание + управляемая эволюция.

Вопросы «В чем состоит простота сервис-ориентированного подхода?» и «Кто те ‘некоторые’, которые сталкиваются со сложностями?» приводят к сложной схеме разделения труда, которая находит свое отражение во многих поддисциплинах, таких как СО-архитектуры, СО-компьютинг, СО-программирование и СО-инженерия, развивающихся по мере того, как сообщество «некоторых» старается облегчить работу сообщества «многих». Эти вопросы решаются, в частности, в области интеллектуальных сетевых служб (Intelligent Network services, IN), в которой обеспечиваются первые систематическое определение и эксплуатационное внедрение сервис-ориентированного подхода в индустрию. В архитектурном стеке IN-сервисов четко определяется несколько уровней служб с разными ответственностями и ролями. Каждый уровень разрабатывался соответствующей группой экспертов, действовавших на основе нормативных руководств, которые зафиксированы в семействе стандартов IN (серия ITU-T Q.1200). Эти стандарты сопровождаются опубликованными описаниями интерфейсов и абстрактного поведения, которые можно реализовать способом, зависящим от поставщика, но с гарантируемой и сертифицируемой интероперабельностью.

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

Это определение является крупномодульным, и в качестве модулей выступают сервисы-компоненты, обеспечивающие общую функциональность и поддержку процессов процессы на стороне каждого участника. Определение абстрагируется от деталей местоположения и коммуникаций, учитывается лишь то, что предоставляют укрупненные сервисы, и как они оркестрованы в согласованное единое целое. Предназначение сервис-ориентированного подхода состоит в том, чтобы дать возможность экспертам в данной области бизнеса (многим) управлять сервисами этого уровня в своей повседневной работе без потребности в поддержке со стороны IT-специалистов.

Деление на «некоторых» и «многих» может показаться надуманным, поскольку численность групп IT-поддержки часто превышает численность групп бизнес-менеджеров, бизнес-разработчиков и бизнес-аналитиков. Однако эта ситуация возникла по историческим причинам и представляет собой недоразумение: слишком много людей безостановочно повторно изобретает колесо. Парадигма сервисной ориентации поможет устранить это недоразумение.

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

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

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

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

В результате образуется новый, ориентированный на будущее вид специалистов, имеющих дело как прикладными областями, так и с IT. Эти специалисты накапливают и анализируют требования архитекторов бизнес-процессов и прикладных инженеров и создают многоуровневую архитектуру, возможно, в соответствии с согласованными моделями.

Первую статью тематической подборки «Сервис-ориентированный компьютинг: современный уровень и исследовательские проблемы » («Service-Oriented Computing: State of the Art and Research Challenges») представили Михаэль Папацоглы, Паоло Траверсо, Шахрам Дустдар и Франк Лейман (Michael P. Papazoglou, Tilburg University, Tilburg, Netherlands, Paolo Traverso, Ricerca Scientifica e Tecnologica, FBK-IRST, Trento, Italy, Schahram Dustdar, Vienna Internet Technologies Advanced Research Lab, Frank Leymann, University of Stuttgart, Stuttgart, Germany).

В парадигме сервис-ориентированного компьютинга (service-oriented computing, SOC) сервисы используются для поддержки разработки быстродействующих, малозатратных, интероперабельных, эволюционизирующих и массивно распределенных приложений. Сервисы являются автономными, платформенно-независимыми сущностями, которые можно описывать, публиковать, обнаруживать и слабо связывать на основе использования новых методов. Сервисы выполняют широкий диапазон функций от ответов на простые вопросы до выполнения сложных бизнес-процессов, для которых требуются сквозные взаимосвязи между разными уровнями потребителей и поставщиков сервисов. Любая часть кода и любой компонент приложения, входящие в систему, могут быть повторно использованы и преобразованы в сервис, доступный в сети.

В сервисах отражается подход «сервис-ориентированности» к программированию, который основывается на идее компоновки приложений путем обнаружения и вызова сервисов, доступных в сети, для выполнения некоторой задачи. Этот подход не зависит от конкретных языков программирования и операционных систем. Он позволяет организациям раскрыть свою ключевую компетенцию в виде программных компонентов, доступных в Internet или разнообразных локальных сетях, с использованием стандартных языков и протоколов, основанных на XML, и самоописывающего интерфейса.

В настоящее время наиболее перспективной технологией, основанной на использовании парадигмы SOC, являются Web-сервисы. В этой технологии Internet используется как коммуникационная среда, для передачи данных применяется протокол SOAP (Simple Object Access Protocol), для определения сервисов – язык WSDL (Web Services Description Language), и для их оркестровки – язык BPEL4WS (Business Process Execution Language for Web Services).

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

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

Ключом к пониманию этой концепции является сервис-ориентированная архитектура (service-oriented architecture, SOA). SOA является логическим средством разработки программных систем для обеспечения сервисов приложениям, ориентированным на конечных пользователей, или другим сервисам, распределенным в сети, путем публикации и обнаружения интерфейсов. Правильно построенная, основанная на стандартах SOA может обеспечить организации гибкой инфраструктурой и средой обработки за счет поддержки в виде сервисов независимых, повторно используемых прикладных функций и предоставления надежной основы для использования этих сервисов.

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

Для обеспечения средств консолидации и рационализации исследований, проводимых в области SOC в настоящее время, авторы проводят анализ ряда текущих проектов в контексте плана перспективных исследований, включающего четыре основных взаимосвязанных темы: основы сервисов, построение сервисов, управление сервисам и их мониторинг, сервис-ориентированная инженерия. Приводится обширный обзор текущего состояния дел в каждом из этих направлений, отмечаются имеющиеся проблемы и трудности.

Томас Магеданц, Никлас Блюм и Симон Дутковски (Thomas Magedanz, Niklas Blum, Simon Dutkowski, Fraunhofer Institute FOKUS / Technical University of Berlin) являются авторами статьи «Эволюция понятий SOA в области телеккомуникаций» («Evolution of SOA Concepts in Telecommunications»).

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

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

Сегодня платформы предоставления телекоммуникационных услуг основываются на SOA. Сегодняшие платформы, базирующиеся на технологии Web-сервисов, появились в результате эволюции подходов интеллектуальных сетей (Intelligent Network, IN) и объектно-ориентированных программных интерфейсов. Для реализации открытого набора сервисных компонентов используется большая часть современных информационных технологий. Дополнительное давление на телекоммуникационные компании по созданию открытого рынка сервисов, основанного на открытом наборе доступных сервисов и компонентов, оказывает развитие Web 2.0.

В тематической подборке выделена подтема «Сервис-ориентированность на предприятии» («Service Orientation in the Enterprise»), которой посвящены три небольшие статьи. Ян Босх (Jan Bosch, Intuit) написал статью «Навстречу мобильным сервисам: три подхода» («Toward Mobile Services:Three Approaches»).

Обстановка, в которой софтверные компании внедряют свои продукты, быстро изменяется. Десять лет тому назад было достаточно разработать вариант продукта для десктопа, чтобы на него обратило внимание большинство заказчиков. Более важно то, что такой продукт отвечал их ожиданиям. По мере повышения скорости и уровня доступности Internet популярными стали продукты и сервисы, основанные на Web, которые стали не менее распространенными, чем чисто настольные приложения.

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

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

Эти тенденции ставят перед софтверными компаниями проблемы обеспечения единообразного и интегрированного доступа пользователей к программным продуктам через декстопы, Web и мобильные платформы. Естественной архитектурной целью является максимизация числа программным компонентов, общих для этих трех разновидностей платформ, при минимизации объема кода, специфичного для конкретного вида платформ. Кроме того, интерфейс между общей и платформенно-зависимой частями систем должен быть предельно прост и стабилен. SOA является отличным техническим решением для достижения этой цели.

Однако в случае мобильных платформ приходится делать выбор между тремя подходами, у каждого из которых имеются свои достоинства и недостатки. Первый подход состоит в реализации традиционной клиент-серверной схемы с поддержкой в мобильном устройстве платформенно-зависимого клиентского программного обеспечения. При втором подходе применяется клиент-серверная архитектура, на мобильном устройстве поддерживается Java-клиент. Наконец, третий подход предполагает наличие в устройстве «тонкого» клиента, основанного на Web-браузере.

Вторая «подтематическая» статья называется «Новые парадигмы для проектов электронного правительства следующего поколения» («New Paradigms for Next-Generation E-Government Projects») и представлена Стефаном Фридрихсом и Стефаном Юнгом (Stefan Friedrichs, Stefan Jung, Public One).

В конце 1990-х гг. в секторе общественных услуг началась электронная революция, в особенности, в связи с упрощением громоздких административных процедур. На этой ранней стадии развития технологии электронного правительства была распространена точка зрения, что для поддержки требуемых преобразований и улучшения качества общественных услуг можно опираться только на технологию Internet. За счет непосредственной адресации услуг населению через Internet правительства рассчитывали добиться лучшей связи с народом и получить большее доверие.

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

Вызывают сомнения объемы финансирования неудачных IT-проектов в секторе общественных услуг. Хотя эти проекты продолжают инвестироваться миллионами налогоплательщиков, аналитики и государственные должностные лица становятся все более скептичными по поводу крупномасштабных инициатив в области электронного правительства. Центральной проблемой является чрезмерные и нереалистичные надежды многих администраторов на реформу, основанную на IT. В действительности, чем крупнее проект, тем более вероятен его провал. Лишь 40% крупных инициатив считается успешно реализованными, но и в этих случаях обещанные преимущества часто не обеспечиваются.

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

Хотя качество подготовки должностных лиц является важной составляющей успеха будущих проектов электронного правительства, имеются развивающихся тенденции в области IT, которые выдвигают новые правила для государственного сектора: переход от изолированных к интероперабельным приложениям, от изолированных функций – к интегрированным процессам. В проектах электронного правительства нового поколения основное внимание должно уделяться не созданию должной технологии, а более глубокому пониманию организационных преобразований и управления бизнес-процессами.

Последняя статья, посвященная подтеме, написана Иоханнесом Хельбигом и Александром Шердиным (Johannes Helbig, Alexander Scherdin, Deutsche Post) и называется «Создание ценности бизнеса за счет гибкой IT-инфраструктуры» («Creating Business Value through Flexible IT Architecture»).

Развитие глобализации и электронной коммерции приводит к быстрому росту и постоянному изменению рынка логистики. Современные цепочки поставки включают много звеньев поставщиков услуг и товаров, розничных торговцев и заказчиков. Сложность этих сетей возрастает по причине раздельного формирования цен в стоимостных цепочках. Поэтому дифференциация в логистике является вопросом не только стоимостных преимуществ. Ключевым фактором успеха является IT. Необходимым условием успешного использования IT является построение гибкой архитектуры.

При наличии 600000 служащих и годового оборота в 60 миллиардов долларов Deutsche Post World Net является крупнейшим в мире поставщиков логистических услуг. Восемь лет назад почтовое подразделение компании столкнулось с проблемами массовой конкуренции, отмены государственного регулирования и глобализации. IT-архитектура скорее препятствовала, чем способствовала изменениям. Тогда в компании было принято решение о создании новой архитектуры, направленной на достижение большей гибкости по отношению к бизнесу за счет применения более адаптивных IT-систем; повышение эффективности IT за счет возрастающего привлечения людей из мира бизнеса; обеспечение базиса для эффективного руководства IT; концентрация на издании специализированных функциональных средств при повторном использовании существующих бизнес-служб; разработка приложений в стиле «управляемой эволюции». Таким образом, в Deutsche Post программа применения SOA развивалась под влиянием требований бизнеса.

В унаследованных приложениях Deutsche Post бизнес-логика была жестко запрограммирована, требовались избыточные данные. В почтовом подразделении была определена архитектура уровня логических сервисов, связывающая архитектуру процессного уровня и архитектуру прикладного уровня. Эта архитектура основывалась на прикладных областях бизнеса, бизнес-объектах и бизнес-сервисах, являясь ядром общей сервис-ориентированной архитектуры. За счет повторного использования бизнес-сервисов и сокрытия унаследованных приложений и инфраструктуры за фасадом бизнес-сервисов архитектура логических сервисов помогла уменьшить влияние изменений в областях бизнеса и IT, а также облегчить повторное использование IT-ресурсов.

При преобразовании архитектуры компания Deutsche Post следовала эволюционному подходу. Основная идея этой управляемой эволюции состояла в балансировании между краткосрочными целями повышения ценности бизнеса и долгосрочной целью поддержки согласованности IT. Был определен проект целевой архитектуры, включая портфель бизнес-сервисов. Согласованный набор реализованных и повторно используемых бизнес-сервисов способствовал повышению как ценности бизнеса, так и гибкости IT-архитектуры.

Следующая большая статья тематической подборки называется «Навстречу реализации управления предприятием, ориентированной на использование политик » («Toward the Realization of Policy-Oriented Enterprise Management»). Автор статьи – Матиас Кайзер (Matthias Kaiser, SAP Research Center in Palo Alto).

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

В состав системы R/3 компании SAP входят эти и многие другие модули. Система R/3 основана на трехзвенной архитектуре. В этой архитектуре серверы баз данных управляют документами, метаданными и основными данными; на сервере приложений выполняется прикладное программное обеспечение; бизнес-приложения обращаются к серверам приложений в качестве клиентов для обеспечения взаимодействия клиентов с системой.

Несмотря на широкое и успешное применение у модульного подхода имеется несколько серьезных проблем. Во-первых, у систем имеется тенденция становиться монолитными, и поэтому связями между модулями слишком сложно управлять. Обычно это называют проблемой декомпозиции систем (system decomposition problem).

Кроме того, сложные взаимозависимости и требования интероперабельности затрудняют реализацию таких систем. Поскольку системы используются разнотипными организациями, у систем имеется множество параметров. Настройка этих параметров в соответствии с потребностями организации занимает много времени, и для нее может потребоваться несколько итераций. Эту проблему часто называют проблемой взаимодействия с системными средствами (feature interaction problem).

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

Подход авторов к построению бизнес-процессов под управлением целями основывается на метафоре физики предприятия (enterprise physics metaphor). В этом подходе используются обобщенные, основанные на логике стратегии для порождения бизнес-процессов, пригодных для достижения поставленных бизнес-целей.

Статью «Поддержка полного жизненного цикла сквозных процессов» («Full Life-Cycle Support for End-to-End Processes») представили Бернхард Стеффен и Пракаш Нараян (Bernhard Steffen, University of Dortmund, Germany, Prakash Narayan, Sun Microsystems).

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

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

Эта потребность противоречит текущему состоянию дел, когда, по сути, для реализации любого процесса, определенного бизнес-разработчиками, требуется поддержка IT-специалистов; реализация на основе IT полностью отрывается от исходной модели даже в том случае, когда полуавтоматически по ней генерируется; изменения в модели не воздействуют автоматически на реализацию и наоборот.

В организации Centre of Innovation for Service-Centered Continuous Engineering (www.scce.info) применяется целостный подход для ликвидации разрыва между требованиями к процессам со стороны бизнеса и реализацией процессов на основе IT. Обеспечивается бесшовный метод и соответствующий набор инструментальных средств, основанный на инфраструктуре Java Application Building Center (jABC, www. jabc.de), поддерживающие фазу бизнес-разработки процесса и переход к его реализации на основе IT. Среда NetBeans Integrated Development Environment (IDE, www.netbeans.org) поддерживает IT-разработку и внедрение. В этой среде поддерживается много языков, включая Java, C/C++, Ruby, JavaScript и т.д. В ней также поддерживается полный жизненный цикл разработки приложений от моделирования до отладки и профилирования.

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

Автором последней тематической статьи – «Контракты компонентов в сервис-ориентированной архитектуре» («Component Contracts in Service-Oriented Architectures») – является Франциско Курбера (Francisco Curbera, IBM’s T.J.Watson Research Center).

В основе сервис-ориентированных архитектур лежат распределенные программные компоненты, предоставляемые или используемые независимыми сторонами. Поскольку доступ к таким компонентам не ограничен рамками организаций, этот доступ должен поддерживаться явными контрактами компонентов и общеупотребительными стандартами. Хотя подобные контракты должны покрывать все технические или бизнес-аспекты взаимодействия с сервисами, в настоящее время в центре внимания находятся политики обеспечения качества услуг (quality-of-service, QoS). С точки зрения SOA необходимо учитывать два раздельных аспекта использования политик QoS: интероперабальность компонентов, являющуюся предметом стека спецификаций Web-сервисов, и компоновку, которая определяется моделями компоновки, такими как архитектура сервисных компонентов (service component architecture, SCA).

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

Для поддержки большинства базовых видов SOA-контрактов имеется широко распространенные стандарты и инфраструктура. Функциональные интерфейсы специфицируются с использованием языка WSDL, в котором также обеспечивается поддержка информации о политиках и семантике. В политиках выражаются свойства QoS, такие как безопасность, надежная доставка и транзакционное поведение. SOA-контракты, основанные на этих стандартах Web-сервисов, уже становятся привычными как в корпоративных, так и в научных SOA-системах.

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

Вне тематической подборки в ноябрьском номере опубликована статья Максима Петренко, Дениса Пошиванюка, Вацлава Райлиха и Йозефа Бухты (Maksym Petrenko, Denys Poshyvanyk, Václav Rajlich, Joseph Buchta, Wayne State University) «Обучение принципам развития программного обеспечения на основе Open Source» («Teaching Software Evolution in Open Source»).

Учебные курсы по инженерии программного обеспечения должны быть направлены на подготовку студентов к карьере в индустрии и должны опираться на опыт, близкий к мировой практике. Однако в большинстве курсов студенты разрабатывают с нуля программы, в которых из-за недостатка времени отсутствуют характеристики промышленного программного обеспечения: большой объем, сложная архитектура, высокое качество кода и т.д. Кроме того, в сегодняшних условиях, когда 65% расходов на программное обеспечение уходят на развитие существующих программ, фокусирование на разработке не является эффективным. Преподаватели знают об этом дефекте и рекомендуют включить в учебные планы тему эволюции программного обеспечения.

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

Курс «Современная инженерия программного обеспечения» в Wayne State University ежегодно проходят 15-20 студентов разных лет обучения. Раньше в рамках курса выполнялись традиционные проекты, включающие группы из трех-пяти студентов. Фазы проекта соответствовали фазам каскадной модели разработки. В конце 2004 г. курс была включена тема эволюции программного обеспечения, и от групп потребовалась реализация новых возможностей в свободно распространяемом программном обеспечении. Курс обучает студентов использованию инструментальных средств и обеспечивает их опытом развития программных систем существенного размера. Кроме того, студенты учатся работе в составе группы. Для координации работы каждой группы внедрена система управления версиями исходных текстов CVS. Журнальные файлы CVS позволяют отслеживать эффективность как каждого студента, так и групп в целом.