- •Архитектурные шаблоны (oltp, olap – системы) в информационной архитектуре предприятия
- •Хранилища данных и Data Mining
- •Кис производственных предприятий. Классификация производственных систем (по подробнее у Белова)
- •Системы класса erp. Функциональность erp-систем.
- •Нормативно-справочная информация производственных предприятий. Ее состав и основные элементы нси.
- •Основные прикладные компоненты современных кис (scada, mes, erp,…). Краткая характеристика каждой компоненты.
- •Новые подходы к проектированию архитектуры информационных систем: сервис - ориентированная архитектура (soa)
- •Интеграционные платформы. Их структура и функциональность.
-
Новые подходы к проектированию архитектуры информационных систем: сервис - ориентированная архитектура (soa)
Из википедии
Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).
Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.
Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными.
Главное, что отличает SOA, это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005
SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.
Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований.
(Из Инета)
Сервис-ориентированная архитектура
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab
Сегодня наблюдается устойчивый рост интереса к концепции сервис-ориентированной архитектуры (service-oriented architecture, сокр. SOA). Свидетельство тому - оценки аналитических компаний и усилия крупных поставщиков программного обеспечения по продвижению этого подхода.
Значение SOA
По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники (information engineering), до появления концепции SOA при разработке систем в качестве отправного момента для программирования бизнес-логики использовались диаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программы тщательно тестировались, после чего внедрялись. Сегодня ситуация изменилась коренным образом: современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестировании. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами.
По мнению Клива Финкельштейна, такая технология управления бизнес-процессами является большим шагом вперед с точки зрения повышения эффективности разработки систем; по значимости ее можно сравнить с созданием в конце 50-х годов компиляторов языка высокого уровня. Действительно, данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил. Кроме того, при изменении этих правил, корректируется соответствующая логика в диаграммах: диаграммы автоматически генерируются заново. Таким образом, закладываются предпосылки для перехода от медленного ручного кодирования, используемого сейчас при создании систем, к автоматизированному. Благодаря этому компании смогут реализовывать изменение бизнес-правил за минуты или часы, а не за месяцы или годы.
Сервис-ориентированная архитектура: основные понятия
Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией федеративного Хранилища данных. Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:
SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.
SOA - это не технология, а способ проектирования и организации информационной архитектуры и бизнес-функциональности.
Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означает построения приложений в соответствии с принципами SOA.
Джерими Уэстерман дает следующее определение SOA: это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде. Применение этого подхода требует от разработчиков проектирования приложений как набора сервисов, даже если преимущества такого решения сразу неочевидны. Разработчики должны "выйти за границы" своих приложений и подумать, как воспользоваться уже существующими сервисами, или изучить, как их сервисы могут быть использованы их коллегами.
SOA "подталкивает" к использованию альтернативных технологий и подходов (таких как обмен сообщениями) для построения приложений посредством связывания сервисов, а не посредством написания нового программного кода. В этом случае, при надлежащем проектировании, применение сообщений позволяет компаниям своевременно реагировать на изменение рыночных условий - "настраивать" процесс обмена сообщениями, а не разрабатывать новые приложения.
Слова Джерими Уэстермана в определенной степени перекликаются с точкой зрения Клива Финкельштейна. "Родоначальник инфотехники" сетует, что до недавних пор термин "сервис-ориентированная архитектура" был синонимом "Web-сервис". Клив Финкельштейн определяет SOA следующим образом - вызов Web-сервисов с помощью средств и языков управления бизнес-процессами. Он считает, что SOA - это термин, который появился для описания исполняемых компонентов - таких как Web-сервисы - которые могут вызываться другими программами, выступающими в качестве клиентов или потребителей этих сервисов. Эти сервисы могут быть полностью современными - или даже устаревшими - прикладными программами, которые можно активизировать как черный ящик. От разработчика не требуется знать, как работает программа, необходимо лишь понимать, какие входные и выходные данных нужны, и как вызываются эти программы для исполнения.
В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.
Рис. 1. Общая схема SOA
Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.
Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA (см. рис. 1). Так, Джерими Уэстерман отмечает, что использование XML и Web-сервисов "поднимает SOA на более высокий уровень".
Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.
Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях. Особое место среди различных спецификаций, предназначенных для описания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS (подробнее см. "Бизнес-процессы и XML").
Преимущества использования SOA
Прежде чем, перечислить преимущества использования SOA, будет уместным напомнить, что преимущества бывают разные: стратегические и тактические. SOA обладает рядом достоинств как стратегических, так и тактических.
-
Стратегическая ценность SOA:
-
Сокращение времени реализации проектов, или "времени выхода на рынок".
-
Повышение производительности.
-
Более быстрая и менее дорогая интеграция приложений и интеграция B2B - остановимся более подробно на данном пункте.
Известно, что реализация традиционных решений для интеграции прикладных программ - непростая задача, требующая существенных капиталовложений. Кроме того, часто при внедрение необходимо написание программного кода. SOA предусматривает размещение сервисов в сети в режиме исполнения, т.е. позволяет автоматизировать эти ресурсоемкие процессы, благодаря чему существенно сокращаются все расходы на интеграцию.
Тактические преимущества SOA:
-
Более простые разработка и внедрение приложений.
-
Использование текущих инвестиций.
-
Уменьшение риска, связанного с внедрением проектов в области автоматизацией услуг и процессов.
-
Возможность непрерывного улучшения предоставляемой услуги.
-
Сокращение числа обращений за технической поддержкой.
-
Повышение показателя возврата инвестиций (ROI).
-
Перспективы
Совершенно очевидно, что SOA "набирает обороты". По крайней мере, около года назад сотрудники Gartner уверенно заявили о том, что к 2008 году преобладающей практикой проектирования и разработки компьютерных программ станет сервис-ориентированная архитектура (с вероятностью 0,7). Таким образом, SOA положит конец господствовавшей последние 40 лет архитектуре монолитного программного обеспечения.
Аналитики компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированно1 архитектуры, выяснили, что в 2004 году компании переходили от пилотных проектов к реальным внедрениям в рамках своих отделов. Так, целый ряд организаций из различных сегментов экономики, включая финансовые услуги, страхование, аэрокосмическую отрасль, здравоохранение, фармацевтику, розничную торговлю, государственный сектор и промышленность, "подняли" Web-сервисы до уровня SOA. В настоящий момент эти организации рассматривают возможность расширения рамок этих проектов - они собираются внедрить их не только на уровне различных отделов и подразделений, но и во всей компаний.
В ZapThink справедливо замечают, что до недавних пор реальную пользу - в денежном эквиваленте - от SOA в основном получали аналитики, журналисты и консультанты. Однако, сегодня появился рынок как для продуктов SOA, так и услуг по внедрению сервис-ориентированной архитектуры. Так, в ZapThink говорят об одной интересной тенденции - некоторым организациям, предоставляющим профессиональные услуги, удалось не только выйти на точку безубыточности, но заключить многомиллионные контракты. В этой связи аналитики полагают, что в 2005 году доходы таких организаций могут превысить - и даже весьма ощутимо - поступления всех поставщиков, предлагающих продукты, реализующие SOA.
Сотрудники ZapThink прогнозируют, что 2005 год станет "годом SOA". Причем количество перейдет в качество: увеличится число внедрений сервис-ориентированной архитектуры и, как следствие, развертывание SOA будет рассматриваться как стратегическая задача, а не как тактическое решение, рамки которого пока ограничиваются одним подразделением. Таким образом, SOA станет обязательным подходом для большинства крупных компаний, а не перспективным направлением для немногих дальновидных организаций.