Фриланс Старт Фриланс Работа Интернет Бизнес в Интернете Бизнес Коммерция Заработок Доход Автоматизация блогов Атоматизация Блог Киберсантинг - виды Создание игр Жулики Копирайтинг Интернет магазин Маркетинг товара Образование Продажа программ Реклама товаров и услуг Создание сайтов Написание программ Разработка дизайна Софт для создания сайтов Сайтостроительство Dreamweaver Язык PHP Homesite Frontpage Studio MX Citrix MetaFrame |
|
Создание сайтов - статьи
Единица работы
WSCI использует элемент транзакции (В примере, связанном с продажей или покупкой акций, онлайновая торговая компания вступает во взаимодействие с различными Web-сервисами, которые предоставляют сторонние организации (например, Web-сервис кредитных карт). Если возникает исключительная ситуация или Web-сервис не может выполнить транзакцию ни с каким из сторонних провайдеров, то он должен вернуться к предыдущему состоянию. Это достигается с помощью использования элементов транзакции и компенсации (
Как WSC может помочь
WSC помогает справиться со всеми вышеназванными сложностями, возникающими при интеграции процессов, путем использования WSDL как базовой основы и расширяя его функциональные возможности (рис. 3). В следующих разделах объясняется, как WSCI справляется с этими недостатками.Рис. 3. Торговля акциями с помощью WSC
Контекст
При агрегировании нескольких сервисов для создания составного бизнес-сервиса они должны иметь общий контекст. Элемент контекста (Определение контекста имеет локальные свойства и определения локальных процессов. Локальные свойства доступны только для действий, выполняемых в рамках этого контекста. Определения локальных процессов указывают именно те процессы, которые могут быть инициированы в рамках данного контекста. Для того чтобы вызвать внутренний процесс или осуществить его генерацию, он должен находиться в рамках такого контекста, где видимы определения локальных процессов.
В листинге 1, приведенном ниже, определение локального процесса имеет различные контексты для продажи и покупки акций. Если в процессе покупки акций случается ошибка, то она не выходит за рамки этого процесса. А, например, если контексты не определены, то ошибка в процессе продажи может прервать доступ пользователя к Web-сервису вместо того, чтобы перенаправить это состояние в состояние продажи (placeSellOrder). Ниже приведен фрагмент определения WSCI:
Пример элемента контекста
Пример элемента последовательности
Пример элемента взаимодействия
Пример элемента транзакции
Транзакция может быть вызвана в элементе компенсации в том случае, когда возникает исключительная ситуация:
Пример исключения и элемента превышения лимита ожидания
reference="tns:ReserveSeats@end">
Об авторе
Джером Джозефрай (Jerome Josephraj) живет в Эссексе (графство Англии). Его статья "Struts и Web-сервисы" (Struts and Web Services) была опубликована на сайте IBM. Он также является официальным рецензентом "Справочного руководства по Jakarta Struts" (Jakarta Struts Cookbook) и готовящейся книги "Web-сервисы, сейчас" (Web Service, Now). С ним можно связаться по адресу: .Обработка исключений
В интеграции бизнес-процессов обработка исключений и выбор соответствующего пути важны так же, как и обработка стандартных вариантов. Для этого WSCI использует элементы исключений (WSCI может сгенерировать исключение на основе сообщения о сбое из WSDL, содержания сообщения или какого-либо события (например, превышения лимита ожидания). Появление такого исключения вызывает отмену текущего контекста после выполнения действий, связанных с этим исключением. Таким образом, WSCI поддерживает концепцию "восстанавливаемых исключений" (recoverable exceptions), которые не вызывают отмены всей хореографии (что похоже на концепцию throw/catch в JavaTM). Но появление сбоя, для которого не определено никакого исключительного поведения, вызывает отмену контекста и появления сбоя в родительском контексте. Более абстрактно, исключение, связанное с обработкой поведения, определенного в родительском контексте, может работать как поведение по умолчанию для всех своих потомков, и наоборот: исключение, связанное с обработкой поведения, определенного в дочернем контексте, может замещать исключение, связанное с обработкой поведения, определенного в своем родителе.
Как показано в листинге 5, если подтверждение заказа занимает более минуты, приложение выдает сообщение о превышении лимита ожидания. В WSC это осуществляется с помощью операции о превышении этого лимита. Элемент превышения лимита ожидания (
Онлайновая компания, использующая Web-сервисы
Необходимость и роль WSC лучше всего можно увидеть на простом примере торговли акциями. Для краткости автор предлагает рассмотреть основные действия, из которых состоит этот процесс. Все шаги покупки и продажи акций не будут рассматриваться, т.к. это выходит за рамки статьи. Вместо этого предлагается простой пример приложения для торговли акциями. На рис. 1 показаны все шаги бизнес-процесса, необходимого для того, чтобы продавать и покупать акции, используя онлайновое Web-приложение.
Рис. 1. Бизнес-процесс торговли акциями
Определение последовательности процессов
Для того чтобы элементарные бизнес-процессы вызывались в определенной последовательности и были сгруппированы в рамках более глобального бизнес-процесса, WSC использует последовательность элементов интерфейса. Как видно из названия, это действие обеспечивает вызов системой процессов в определенной последовательности. Когда пользователь сервиса хочет купить акции, элемент интерфейса вызывает операцию перевода денег раньше, чем собственно процесс покупки. Это достигается определением всех операций, вызываемых последовательно, в рамках элемента последовательности (Практическая хореография Web-сервисов
Джером Джозефрай (Jerome Josephraj)Перевод:
Оригинал: Web services choreography in practice
В статье рассказывается, как можно использовать интерфейс хореографии Web-сервисов для объединения различных Web-сервисов в реальный бизнес-процесс. На примере онлайновой компании, торгующей акциями, автор рассматривает сложности, возникающие при использования языка WSDL для интеграции бизнес-процессов, и объясняет, как можно применять хореографию для решения этих сложностей.
Пример использования
Онлайновое приложение для торговли акциями получает информацию об акциях от стороннего Web-сервиса, например, xmethods.net, и предоставляет ее пользователю. Пользователь может выбрать те акции, которые его заинтересовали, и запросить более детальную информацию. Онлайновая торговая компания использует один из сторонних Web-сервисов для получения этой информации.После того, как пользователь выбрал акции для покупки, он делает заказ. Онлайновое приложение использует один из своих внутренних процессов для покупки акций на рынке. Затем онлайновое приложение для торговли акциями просит пользователя подтвердить заказ на покупку и устанавливает определенный период, в течение которого пользователь должен подтвердить свой заказ. Если этого не будет сделано в течение минуты, то пользователь получает уведомление о том, что время истекло.
После подтверждения заказа онлайновое приложение для торговли акциями снимает необходимую сумму со счета пользователя. Для этого оно использует один из существующих сторонних Web-сервисов. Оно использует один Web-сервис для проверки кредитной карты, а другой - для снятия денег. Оба этих шага должны быть обработаны как логическая единица всей работы; сбой одного из сервисов приведет к тому, что пользователь получит сообщение о невозможности выполнить операцию. Если кредитная карта успешно проходит проверку, а средства без проблем списываются со счета пользователя, онлайновое приложение осуществляет покупку требуемого числа акций на рынке. Пользователь может размещать более одного заказа; каждый из них будет обрабатываться как отдельная логическая единица.
Заказ на продажу включает такие же шаги, как и заказ на покупку. Пользователь размещает заказ и подтверждает его, когда это необходимо. После этого онлайновое приложение размещает заказ на продажу и переводит деньги на счет пользователя после проверки счета покупателя.
Для того чтобы увеличить число бизнес-каналов и иметь возможность сотрудничать с другими системами, онлайновая торговая компания может представить приложение Купить/Продать (Buy/Sell) как Web-сервис. В случае простого Web-сервиса шаги, перечисленные выше, могут быть преобразованы ("мэппированы") в операции в WSDL-файле. Используя программное обеспечение для Web-сервисов, например, редактор Microsoft VBA или внешнее приложение, вызывающее Web-сервис, пользователь может вызывать эти операции, описанные на WSDL, для того, чтобы разместить заказ на продажу или покупку. Пример того, как выполнить эту задачу с помощью VBA, можно найти по следующей ссылке: http://www.microsoft.com/office/previous/xp/webservices/toolkit.asp. На рис. 1 показаны операции, описанные на WSDL, и мэппирование между бизнес-процессами.
Проблемы WSDL
Хорошо разработанный Web-сервис для покупки и продажи акций работает нормально, если все процессы являются атомарными или, другими словами, у них нет общих состояний. Но в этом случае выполнение ряда ключевых требований к интеграции бизнес-процессов обеспечивает только посредством WSDL (рис. 2). Ниже перечислены эти основные требования:Рис. 2. Торговля акциями с помощью WSDL
Клиент сервиса, использующий Web-сервис купить/продать, может вызывать операции в любой последовательности. Например, клиент может обратиться к операции перевода денег до вызова операций размещения заказов на продажу или покупку (placeBuyOrder или placeSellOrder). WSDL не препятствует вызову операций в любом порядке. Приложение Web-сервиса, использующее WSDL, должно удовлетворять этому путем определенной логики, описанной выше.
Взаимосвязь - это простая идея, которая состоит в том, что при обмене сообщениями (т.е. при отправке письма кому-либо и получении позднее ответа на него) используется некоторый общий элемент данных в возвращаемом экземпляре сообщения для его связи с экземпляром исходного сообщения. При взаимодействии бизнес-процессов очень важно понимать и описывать взаимосвязь между экземплярами сообщений. У WSDL нет возможностей для задания взаимосвязи между экземплярами сообщений. Другими словами, WSDL не поддерживает состояние между операциями. При обычной интеграции бизнес-процессов для обеспечения совместного процесса процессы обычно используют одно состояние. Все операции, описанные с помощью WSDL, не не имеют состояния.
В приведенном выше примере, когда пользователь в качестве следующего шага размещает заказ на покупку, приложение Web-сервиса требует подтверждения заказа. Пользователь может захотеть изменить количество акций или дату покупки. Если заказ изменился, его необходимо размещать снова. Такой обмен сообщениями может происходить несколько раз, и пользователь может разместить несколько заказов на покупку, или, другими словами, осуществить несколько диалогов с приложением Web-сервиса.
Но Web-сервис, использующий только WSDL, не обладает возможностью задания взаимосвязи между экземплярами сообщений.
Для того чтобы Web-сервис мог быть частью длительного обмена сообщениями, важно иметь возможность четко устанавливать время реального начала обмена сообщениями и его прекращения, а также определять, какая часть этого обмена может рассматриваться как транзакция.
В этом примере операции размещения заказа на покупку (placeBuyOrder) и его подтверждения (confirmBuyOrder), а также процесс снятия денег (debit money) должны осуществляться как одна единица работы. Web-сервис должен успешно выполнить все три операции; в противном случае пользователю придется восстанавливать операции до состояния, соответствующего началу их выполнения. Эти операции не могут быть использованы для распределенных транзакций, выраженных с помощью WSDL. В WSDL рамки транзакции ограничены отдельными операциями и не могут охватывать более одной операции.
Хотя WSDL использует код ошибки для генерации любого исключения, он не работает с модельными признаками, такими как проверка определенного сообщения, объявление об истечении времени ожидания исключения или объявление исключения только для некоторого набора операций, а не для всего Web-сервиса.
Для взаимодействия процессов необходимо иметь соответствующий модельный признак для исключения. В приведенном выше примере, если пользователь не подтверждает заказ на покупку или продажу в течение минуты, Web-сервис генерирует исключение о превышении времени ожидания.
При взаимодействии бизнес-процессов важно, чтобы у них был общий контекст для обмена информацией. Эта информация может быть набором деклараций, исключительных событий или свойств транзакций. У WSDL нет никаких возможностей для того, чтобы процессы работали в рамках контекста.
Прочие особенности WSCI
В таблице 1 перечислен ряд других полезных возможностей WSCI. Полный список доступен в документации по WSCI.Таблица 1. Элементы WSCI
| Название элемента | Краткое описание | Пример | |
| Выбор (selector) | Элемент выбирает значение свойства из сообщения. Он полезен для преобразования сложного сообщения в набор свойств. | Элемент выбора может быть использован для получения общего числа акций из сообщения обо всех акциях (getAllStocksResponse): xpath = "count (./StockList)" /> |
|
| Вызов (call) | Элемент вызывает произвольную операцию (например, вызов стороннего Web-сервиса) в процессе выполнения действия. Это атомарный элемент, и действие не может быть выполнено, если не выполняется вызываемый процесс. | Если приложение должно записать все транзакции для операций аудита и согласования, то для этого может быть вызван произвольный процесс: role = "tns:trader" operation = "tns:debitMoney"> | |
| Все действия (all activity) | Этот элемент похож на элемент последовательности. Все операции, определенные в элементе последовательности, выполняются, но операции, определенные в этом элементе, могут быть выполнены непоследовательно. | В этом примере заказ на покупку и снятие денег могут быть выполнены в любом порядке: |
|
| Для каждого (foreach) | Элемент выполняет действия в условном цикле. Он похож на элемент цикла в языке Java. | Элемент выполняет операцию размещения заказа на продажу (PlaceSellOrder) для каждого набора акций в общем списке (arrayOfStocks): | |
| Переход (switch) | Элемент осуществляет условный выбор действия из списка действий. Порядок условий очень важен; первым выполняется условие, значение которого истинно. Элемент похож на условный элемент языка Java (case statement). | Элемент выполняет соответствующее действие, когда значение условия истинно. Если условие не выполняется, элемент осуществляет операцию отказа. role = "tns:trader" operation = "tns:reverseBuyOrder"/> operation = "tns:confirmBuyOrder"/> | |
| До того, как (until) | Элемент выполняет все действия на основе значения оператора Boolean. Он выполняет эти действия как минимум один раз. Элемент похож на элемент языка Java "делай пока" (do while). | role = "tns:trader" operation = "tns:debitMoney"> | |
| Пока (while) | Элемент выполняет все действия на основе значения оператора Boolean. При этом они могут быть выполнены как один или более раз, так и ни одного. Элемент похож на элемент языка Java "пока" (while). | role = "tns:trader" operation = "tns:debitMoney"> | |
| Задержка (delay) | Элемент выполняет действие с определенным периодом задержки. Если в процессе выполнения этого действия возникает исключительная ситуация, то оно может быть завершено раньше указанного времени. | type = "duration" reference="tns:delayBuyingStock"> | |
| Вызов (call) | Элемент инициирует процесс и ждет окончания его выполнения. Он полезен для вызова внутренних процессов. | ||
| Генерирование (spawn) | Элемент инициирует процесс, но не ждет его окончания. | ||
| Объединение (join) | Элемент ждет окончания выполнения генерированного процесса. Если нет никаких экземпляров или все они уже выполнены, действие завершается. |
Ресурсы
До сегодняшнего дня не существовало
До сегодняшнего дня не существовало стандартного способа описать поток сообщений, который проходит через Web-сервис, участвующий в хореографическом взаимодействии с другими сервисами. BEA Systems, Intalio, SAP AG и Sun Microsystems создали WSCI для решения этой проблемы. В статье на простом примере были описаны некоторые основные функции WSCI. Но это только небольшая часть информации. Для того чтобы лучше понять WSCI, нужно ознакомиться с его спецификацией и попробовать написать простое приложение.Взаимосвязь сообщений
В WSC можно неявно создавать экземпляры при поступлении сообщений за сервисом. Экземпляры, созданные в WSC, идентифицируются с помощью ключевых полей внутри сообщений с данными. В рассматриваемом примере важно установить взаимосвязь между процессами подтверждения заказа на покупку (confirmBuyOrder) и его размещения (placeBuyOrder), поскольку каждый из них может произойти раньше другого. Когда запрос на подтверждение заказа посылается пользователю сервиса, то клиент может изменить свой заказ (например, поменять количество акций из-за изменения цены) и разместить заказ на покупку еще раз. Такой обмен сообщениями между клиентом и Web-сервисом может происходить неоднократно.Клиент сервиса может разместить несколько заказов на покупку, что, в свою очередь, будет сопровождаться несколькими сериями обмена сообщениями. Каждая такая серия должна быть идентифицирована. Для этого используется операция идентификации заказа (placeOrderID). При наличии такого механизма пользователь сервиса может разместить сколько угодно заказов на покупку, и каждый из них будет участвовать в своей серии обмена сообщениями. Для каждой серии создается свой placeOrderID.
Для этого определяется элемент взаимодействия (
ESB и XML
Было бы несправедливо, если бы мы не подчеркнули особую роль XML - XML является основанием для интеграции. Если принять тот факт, что XML скорее "алфавит", чем просто язык, становится понятным, что для полной реализации интеграции требуется "дирижировать" бизнес-процессами, управлять преобразованием XML, а также проверять и пересылать сообщения XML по организации. Все эти функциональные возможности составляют основу корпоративной сервисной шины.XML может обеспечить исчерпывающее представление набора данных. Популярность этого языка можно объяснить его высокой гибкостью и расширяемостью. Действительно, синтаксис XML позволяет модернизировать и разрабатывать специализированные XML-схемы для обработки различных данных.
Вместе с тем стремительный рост объемов данных, подлежащих передаче, создает серьезные сложности для функционирования корпоративной информационной структуры. Так, первые интеграционные проекты, в которых использовались возможности XML, явились "живым" доказательством перспективности этого языка, однако сейчас наблюдается определенные проблемы при увеличения количества, размера и сложности XML-документов. Ниже перечислены основные причины существующих сложностей (недостаточной масштабируемости):
Для решения проблемы недостаточной масштабируемости рекомендуется использовать архитектуру обработки, которая поддерживает следующие функции:
обеспечивается низкое время ожидания. Этот подход позволяет обрабатывать большие сообщения также продуктивно, как и небольшие.
Приведенные выше функции могут быть реализованы с помощью корпоративной сервисной шины - причем без специального кодирования и конфигурирования. В результате, можно разрешить проблему неудовлетворительной производительности.
Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
Подготовлено: по материалам зарубежных сайтовПеревод:
Продолжая знакомить читателя с , мы решили остановиться на относительно новой и весьма привлекательной технологии - корпоративной сервисной шине (Enterprise Service Bus, сокр. ESB).
Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.
Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня (middleware), который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция). Многие корпоративные сервисные шины также поддерживают другие стили обмена информацией, включая гарантированную доставку и "публикацию и подписку" (publish and subscribe). Сервисы, предоставляемые этими шинами, обладают "добавленной стоимостью", которой не располагают межплатформенное обеспечение, предназначенное для упрощенного обмена сообщениями, - они обеспечивают проверку сообщений, трансформацию, маршрутизацию на основе содержания, безопасность, обнаружение сервисов для сервис-ориентированной архитектуры, балансирование нагрузки и регистрацию. Некоторые сервисы встроены в основание шины, другие - исполняются в модулях расширения (plug-in). Кроме того, шины поддерживают язык XML и другие форматы сообщений.
Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, "бюджетные", решения.
Действительно, сегодня наблюдается усиления спроса на интеграционные технологии. И если раньше развертывание продуктов EAI было связано с достижением стратегических целей и, следовательно, окупалось в долгосрочной перспективе, задачи, с которыми в настоящий момент приходится сталкиваться компаниям, носят тактический характер и требуют новых подходов. "Современные бизнес-реалии" привлекли внимание к областям, где поставщики EAI традиционно слабы - к трансформации, программной обработке, ориентированной на разработчиков (например, на Java) и интеграции к внешним технологиям. Все это и "подготовило благоприятную почву" для появления новой категории продуктов - ESB.
Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): "Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB".
Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как "бюджетные" интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа - это продукты, предназначенные для рынка Web-сервисов, наконец последние - это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.
Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру.
Например, в IBM корпоративную сервисную шину считают "архитектурной моделью" (architectural pattern).
Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов:
На данный момент на обозначенные вопросы нет окончательных ответов.
Вместе с тем стоит подчеркнуть, что несмотря на отсутствие ясности в отношении корпоративной сервисной шины, совершенно очевидно, что благодаря тому, что ESB опирается на открытые стандарты, она позволяет существенно сократить затраты на покупку и реализацию.
Заметим, что слово "сервисная" в термине "корпоративная сервисная шина" является центральным. Так, аналитики Forrester Research рассматривают ESB как "слой промежуточного программного обеспечения, с помощью которого можно получить доступ к набору основных (многократно используемым) бизнес-сервисам". SOA позволяет представить большую часть функциональности как "сервис" в корпоративной сервисной шине, которая переправляет, преобразовывает и проверяет входные и выходные данные в формате XML, получаемые из этих сервисов.
Публикации
и оценкам аналитиков ведущих исследовательских
Судя по публикациям в зарубежных Интернет-изданиях и оценкам аналитиков ведущих исследовательских компаний, корпоративная сервисная шина уже больше не является просто новой технологией с большим потенциалом. Действительно, по прогнозу Gartner, в 2005 году большинство крупных компаний будут использовать ESB. В IDC же полагают, что корпоративная сервисная шина должна "революционизировать" информационные технологии и сделать возможным гибкую и масштабируемую распределенную обработку данных.Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), "ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты".
И все же неопределенность с многозначностью термина "корпоративная сервисная шина" пока сохраняется. Сегодня ESB означает любую технологию, необходимую для реализации SOA. Именно такой точки зрения придерживаются в компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированная архитектуры. В этой связи аналитики ZapThink предупреждают, что если в 2005 году не будет выработано реального и конкретного определения корпоративной сервисной шины, термин ESB "навсегда уйдет из лексикона SOA". Что касается же самой SOA, то о ней речь пойдет в .
Быстродействие
Для тестирования быстродействия вызова веб-сервиса был включен код, отвечающий за вычисление времени, потраченного на создание proxy-сборки, на подключение к серверу и время выполнения; кроме того, для того чтобы получить более корректные результаты в ходе тестирования при повторных вызовах, был добавлен цикл while(). Этот подход позволяет исключить погрешность, обусловленную первоначальной загрузкой и инициализацией библиотек. Такой же код был включен в собранный ранее клиент C#.Для клиента, реализованного с использованием C#, время, потраченное на вызовы, составило чуть более 2010 мс. В то время как для клиента на Java — около 2460 мс. Я не нашел логичного объяснения столь большому времени отклика, на некоторых машинах это время было меньшим на порядок и составляло около 250 мс. Но на большинстве машин, где проводилось тестирование, порядок цифр, тем не менее, оставался прежним — 2000 мс. Java-клиент, запущенный под управлением RH9 Linux, показал намного лучший результат. Время отклика в этом случае составило примерно 300 мс.
Данные приведены для Athlon 2000+ c 400 Мб RAM. Внизу представлен рисунок, демонстрирующий работу Java-клиента на Linux-системе.
Рис. 9. Результаты работы Java-клиента, запущенного под управлением RH9 Linux
Даже 0,25 с может быть многовато для некоторых критичных приложений реального времени. 2460 мс — эта величина может оказаться неприемлемой даже для очень нетребовательных приложений. На КП-диске также приведен пример простого XML-RPC-сервера и клиента с той же функциональностью, что и в первом примере. В отличие от первого примера, эта связка показала примерно одинаковые результаты — независимо от места тестирования. Время отклика в этом случае составило около 110 мс для Windows 2000, что более чем вдвое превышает показатели даже для наиболее оптимального для SOAP-сервиса случая.
Достоинства
Первое достоинство такого рода служб (которое, собственно, и является определяющим) — это простота создания. Что можно объяснить, прежде всего, существованием всякого рода кодогенераторов и визардов.Еще одним фактором, давшим толчок данной технологии, было то, что привыкшие к графическому интерфейсу пользователи приложений уровня предприятия не слишком радостно встретили такую инициативу разработчиков, как повсеместный переход на веб-интерфейс. Оптимизм по поводу таких приложений очень быстро сменился скепсисом, прежде всего по двум причинам. Во-первых, создание сложного удобного графического интерфейса посредством DHTML не такое уж простое и тривиальное дело. Во-вторых, избыточность трафика в этом случае просто огромная. По сети передается не только информационная часть, но и всевозможная информация относительно форматирования документа. И если для интернет-приложений это еще приемлемо, то для приложений уровня предприятия — избыточно.
Если нам необходимо оперативно изменить какую-то цифру в табличном представлении, мы должны перегрузить всю HTML-страницу или фрейм; браузер, в свою очередь, должен потратить некоторое время на рендеринг нового представления. Примером такого рода приложений могут служить всякого рода форексподобные сайты и веб-чаты. Если же принять во внимание разницу в диалектах DHTML-скриптов и в поведении фреймов для разных браузеров, то картина и подавно становится нерадостной.
Несколько спасало положение то, что в местах, где информация должна передаваться достаточно оперативно, разработчики использовали Java Applets (в этом случае в качестве протокола можно также использовать веб-сервисы). Но в последнее время, в результате выяснения отношений с Sun, Microsoft удалила Java-машину из последних версий своих браузеров, что привело к некоторым неудобствам на стороне пользователя, который теперь вынужден загружать Java-машину отдельно. То же самое касается Flash- и SVG-технологий.
Такой букет проблем подтолкнул разработчиков к выводу о том, что необходимо использовать решения в виде настольных и комбинированных приложений. Поскольку основным транспортным протоколом в технологии веб-сервисов является HTTP, то и все проблемы, связанные с дополнительными настройками брандмауэров и роутеров отпадают автоматически. Приложение может без проблем работать не только в Intranet-, но и в Internet-сетях. Кроме того, эта технология не привязана к какой-либо одной платформе, что открывает возможность создания распределенных приложений в гетерогенных средах. Отличная интеграция этой технологии с DOT.NET является, пожалуй, единственной известной уступкой Microsoft мировому сообществу разработчиков за последнее время.
Недостатки
Хотелось бы сразу отметить, где можно использовать подобные приложения и где их использование не желательно.Прежде всего, если вы создаете приложение реального времени, то вам, вероятно, придется отказаться от применения этой технологии в пользу сокетов, DCOM, Remouting, RMI или других протоколов-оберток для создания распределенных приложений. Это объясняется достаточно большим временем отклика и некоторой избыточностью пересылаемой информации, что при больших нагрузках может привести к перегруженности сетевого трафика. Если же у вас нет критических требований к времени отклика (а таких приложений в реальном мире где то 90%), то смело можете брать эту технологию на вооружение.
Еще один недостаток этой технологии заключается в отсутствии возможности асинхронной связи. Программистам, работавшим с DCOM, хорошо знакома такая сущность, как события,— в случае с веб-сервисами такая возможность отсутствует.
Определение
Наиболее корректным, на мой взгляд, является определение веб-сервиса как пары строк, в которых представлены структуры данных посредством формата XML или какого-то другого. Клиент формирует строку запроса и отсылает ее серверу. После получения строки сервер преобразует ее в вызов функции. Полученные структуры данных, в свою очередь, преобразуются в строку, которая и передается клиенту. Общение происходит посредством какого-либо сетевого протокола. Такой сетевой протокол принято называть транспортным. На практике это HTTP. Хотя теоретически может быть использован любой другой транспортный протокол. Далее клиент, получивший строку, разбирает ее и восстанавливает структуры данных.Протоколы уровня представления — это XML-RPC и SOAP. Они определяют, каким образом в строке представлены структуры данных.
Идея представить структуры данных в виде строки возникла задолго до появления протоколов представления XML-RPC и SOAP. И именно существование великого множества доморощенных протоколов послужило толчком для создания этих стандартов. Оба протокола построены на основе XML.
Протоколы уровня представления
Протоколами уровня представления информации (wire protocols) сейчас являются два стандарта — SOAP и XML-RPC.SOAP является основным стандартом, принятым многими фирмами разработчиками. В том числе и Microsoft. Собственно SOAP родился в результате сотрудничества между тремя фирмами UserLand, DevelopMentor и, конечно же, Microsoft. Позже протокол был переработан и дополнен W3C.
Протокол XML-RPC менее известен, однако используется не менее широко. Его реализации тоже существуют для большинства сред и языков. Основное достоинство этого протокола — меньшая избыточность и, как следствие, легковесность. Естественно, за все надо платить — и в результате XML-RPC не сможет похвастаться той гибкостью, какую предоставляет SOAP. Но при этом, у него есть серьезное одно достоинство: этот протокол более безопасен. В отличие от SOAP, не предусмотрена возможность просмотра экспонируемых методов посредством discovery- и description-сервисов.
Существенный недостаток этого протокола — отсутствие интеграции в средах разработки. Как следствие: вам придется самостоятельно выбрать реализацию библиотеки и загрузить ее с сайта разработчика. Исчерпывающую информацию по этому протоколу вы можете найти на .
Фактически, прототипом для XML-RPC явился один из черновиков протокола SOAP. Поэтому, если посмотреть на фрагменты строк, взятых из двух протоколов, становится ясно, что у них достаточно много общего. В текущем состоянии SOAP поддерживает XML-схемы, перечисления, странные гибриды структур и массивов, а также определяемые пользователем типы — в то время как у XML-RPC более скромный набор. В то же время, некоторые аспекты SOAP не документированы и поэтому оставлены на усмотрение разработчика. Поэтому фактически окончательным стандартом SOAP можно считать его реализацию предоставленную Microsoft.
Вот как выглядит строка-запрос в XML-RPC-протоколе:
Этот фрагмент дает возможность оценить, насколько проще и нагляднее выглядит XML-RPC по сравнению с SOAP. Именно этим обусловлено меньшее время отклика в реализациях протокола XML-RPC.
Справедливости ради стоит отметить, что Microsoft в качестве альтернативы предлагает использовать классические HTTP-GET и HTTP-POST методы передачи параметров, результат при этом возвращается в виде очень простой XML-строки. Время отклика в этом случае будет еще меньшим, чем у XML-RPC. Но эти альтернативные методы не могут работать со сложными типами данных, так что рассматривать их в качестве кандидатов для использования в реальных приложениях не имеет смысла.
Веб-сервисы в гетерогенных средах
Олег Ремизов,Данная статья посвящена рассмотрению некоторых практических аспектов технологии web-services на платформах DOT.NET и Java. Такой метод обмена информацией, хотя не является наиболее оптимальным, тем не менее, имеет много преимуществ по сравнению с другими современными технологиями создания распределенных приложений.
Благодаря поддержке таких гигантов рынка как Microsoft, IBM, Sun эта технология быстро набирает вес и становится стандартом де-факто для создания распределенных приложений. Использование данной технологии в последнее время является наиболее актуальным конкурентным преимуществом при продвижении на рынок нового поколения распределенных приложений.
Возможности интеграции со средами разработки
В качестве демонстрации того, насколько просто создать такое приложение с использованием современных средств разработки, приведем пример, в котором создадим веб-сервис в среде DOT.NET и Java-клиент, вызывающий этот веб-сервис (для демонстрации гетерогенных возможностей технологии).На практике подобная задача встречается довольно часто. Так что рассмотрим ситуацию из реальной жизни. Система учета супермаркета использовала в качестве базы данных MSSQL-сервер. Таким образом, серверная сторона была привязана к Win2k. Дабы сэкономить на лицензиях Win2k, для торговых терминалов решено было создать рабочее место оператора с использованием UNIX-машин. Для реализации проекта был создан свой протокол с использованием Berkley Sockets. Его создание и отладка отняла значительную часть то общего времени реализации проекта, которое в результате составило примерно полгода! Если бы разработчики использовали веб-сервисы, время разработки значительно сократилось бы.
Приступим непосредственно к созданию нашего примера. В начале создадим проект сервиса. Для этой цели я использовал VS7.1. Запускаем его и создаем новый проект C# на основе шаблона Web Service. При этом в IIS будет создан виртуальный каталог (на диске в соответствие ему ставится реальный каталог), в котором будут размещены файлы проекта.
Рис. 1. Создаем Web Service в среде разработки Visual Studio 7.1
Интерес для нас представляют три файла:
Переименуйте файл сервиса и класс службы, для того чтобы они несли определенную смысловую нагрузку. Для тестового приложения я выбрал имя файла AccountState.asmx, а для класса службы — AccountState, поскольку наше тестовое приложение будет отображать состояние некоего счета в банке.
Существует распространенное заблуждение, что веб-сервис представляет сущность без состояния. Это не совсем так, мы вполне можем хранить промежуточные данные в статических переменных класса или в переменных приложения. Эти данные будут оставаться живыми вплоть до перегрузки веб-сервера. Верно то, что при каждом новом запросе создается новый экземпляр класса веб-службы. После закрытия клиентом соединения с сервером экземпляр класса будет разрушен — при этом все нестатические члены класса должны быть сохранены в базу данных или посредством serializing. Точно так же они должны быть загружены при новом запросе. Если мы хотим оптимизировать работу сервера, избежав многочисленных обращений к диску или базе данных, оптимальным решением будет сохранение результатов в статической коллекции объектов и сохранение той в хранилище данных через некоторые промежутки времени. Из кода, сгенерированного wizard, несложно догадаться, что место для инициализации — это конструктор класса. Когда нам надо освободить ресурсы, то делать мы следует в методе Dispose().
Код методов нашего веб-сервиса выглядит так:
[WebMethod]
public string GetBankName()
{
return "Baby Bank";
}
[WebMethod]
public void Deposit(int ammount)
{
state += ammount;
}
[WebMethod]
public int GetState()
{
return state;
}
[WebMethod]
public int Withdraw(int ammount)
{
state -= ammount;
if (state < 0)
{
state = 0;
return state;
}
else
{
return ammount;
}
}
Не забудьте определить переменную state как static (полный код этого примера вы сможете найти на КП-диске).
При вызове сервиса в Internet Explorer мы сможем прочитать пару "запрос-ответ" в формате SOAP. Для примера приведем текст запроса и ответа для функции int GetState() будет выглядеть следующим образом:
Если сравнить формат SOAP с ранее приведенным фрагментом в формате XML-RPC, сразу видно, что при наличии большого количества сложных объектов размер строки XML-RPC будет гораздо меньшим.
Возможность тестировать методы прямо из Internet Explorer делает разработку сервисов еще более простым занятием. Внизу приведены рисунки, отображающие некоторые экраны в процессе тестирования.
Рис. 2. Мы можем просмотреть все методы web службы прямо в Internet Explorer
Рис. 3. Есть возможность вызвать любой метод web службы
Рис. 4. Результат вызова службы в Internet Explorer представлен виде XML
Протестировав наш сервис в Internet Explorer, напишем небольшой консольный клиент, проверяющий его работу.
Код простейшего клиента будет выглядеть так:
[STAThread]
static voidMain(string[] args)
{
try
{
AccountClient.AccountState.AccountState ac
= new AccountClient.AccountState.AccountState();
Console.WriteLine("Try to invoke service from URL : " + ac.Url);
Console.WriteLine("Bank name : " + ac.GetBankName());
Console.WriteLine("Accaunt initial state : " + ac.GetState());
ac.Deposit(10);
ac.Withdraw(5);
Console.WriteLine("After Operations accaunt state : " + ac.GetState());
ac.Dispose();
Console.WriteLine("Press key 'Enter' to complete program execution");
Console.ReadLine();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
При этом необходимо создать в проекте веб-ссылку, для того чтобы Visual Studio мог сгенерировать промежуточную proxy-сборку. Таким образом, среда разработки берет всю черновую работу на себя, нам остается только создать экземпляр класса и вызвать его методы.
Чтобы создать веб-ссылку, щелкните по контекстному меню на дереве проекта нашего клиента и выберите пункт add web reference. Появится интуитивный дружественный wizard. На рисунке показано его финальное диалоговое окно, где название ссылки изменено с localhost на AccountState.
Рис. 5. Окно визарда, создающего proxy-сборку
Если заглянуть внутрь папки проекта [имя проекта]\Web References, мы обнаружим исходный код нашего proxy-класса. Благодаря применению атрибутов он достаточно компактен. Стартуйте клиент на выполнение и убедитесь, что все работает.
Рис. 6. Клиент DOT.NET, опрашивающий веб-службу
Если вы запустите его несколько раз, то обнаружите, что данные, хранящиеся в статической переменной state, не будут уничтожены. Но если пересобрать проект, что приведет к перезагрузке приложения в IIS, эти данные все же исчезнут. Поэтому вам в любом случае необходимо позаботиться об их сохранении. Глобальные данные можно сохранять при помощи класса Application.
Первая часть проекта завершена, создадим теперь аналогичный консольный проект Java при помощи среды разработки JBuilder X. Создайте проект, после чего добавьте объект Web Services Designer из меню New. На следующей вкладке визарда установите параметры, как это показано на рисунке 7.
Рис. 7. Настраиваем объект Web Services Designer в среде разработки JBuilder X
После этого в дереве проекта выберите Web Services Designer > Import WSDL > From URL. Из контекстного меню выберите пункт Add. Будет добавлен новый сервис. Вставьте URL нашего сервиса с постфиксом ?WSDL. Все остальное визард сделает сам — по удобству и интуитивности он ничем не уступает своему аналогу из Visual Studio.
На рисунке ниже показано окно визарда с URL.
Рис. 8. Окно Web Services Designer с импортированным объектом веб-сервиса в среде разработки JBuilder X
Все установки на вкладках оставьте по умолчанию (я изменил только имя пакета для proxy-классов и имя самого сервиса). Соберите проект, в пакете со введенным вами именем возникнут сгенерированные классы. Добавьте новый класс с методом main() и вставьте туда следующий код:
try
{
// here we will invoke our soup method :
long time1 = System.currentTimeMillis();
AccountStateSoapStub proxy = (org.tempuri.AccountStateSoapStub)
new org.tempuri.AccountStateLocator().getAccountStateSoap(new URL(" /Account/AccountState.asmx"));
if (proxy != null)
{
proxy.setTimeout(60000);
// operations:
proxy.getBankName();
System.out.println("Bank name : " + proxy.getBankName());
System.out.println("Accaunt initial state : " + proxy.getState());
proxy.deposit(10);
proxy.withdraw(5);
System.out.println("After Operations accaunt state : " + proxy.getState());
System.out.println("Name : " + proxy.getName());
proxy.setName("Oleg");
System.out.println("Name : " + proxy.getName());
long time2 = System.currentTimeMillis();
long delta = time2 - time1;
System.out.println("Request take : " + Long.toString(delta) + " millisecond");
System.out.println("Press key 'Enter' to complete program execution");
System.in.read();
}
}
catch (Exception ex)
{
ex.printStackTrace();
}
Следует отметить, что JBuilder использует Apache Axis — самый известный пакет для работы с SOAP. Существуют другие реализации этого протокола — как платные, так и free. Не исключено, они более оптимальны — но если вы остановитесь на одной из них, то почти наверняка потеряете интеграцию с вашей средой разработки. А это означает снижение производительности вашего труда.
В ходе тестирования были обнаружены
В ходе тестирования были обнаружены странные флуктуации производительности веб-сервисов, использующих SOAP. Если быстродействие приложения, использующего веб-сервисы, вас не устраивает, то возможным вариантом его оптимизации может стать отказ от протокола SOAP в пользу более легковесного XML-RPC.На разных задачах DOT.NET-машина перегоняет JVM в полтора-два раза. Именно такого результата следовало ожидать в этом случае. В этом тесте не было замечено значительной разницы в производительности на стороне клиента.
Если принять во внимание тот факт, что объемы передаваемых данных в наших примерах просто смехотворны, а эксперимент проводился на одной машине (без реального сетевого взаимодействия), следует еще раз задуматься о целесообразности использования веб-сервисов вообще для приложений с повышенными требованиями к быстродействию (особенно в гетерогенных средах). Для сравнения: та же последовательность вызовов посредством RMI занимает всего 20…30 мс. К счастью, большинство реальных приложений таковыми не являются.
BPEL (Business Process Execution Language – язык выполнения бизнес-процессов) – это язык сервисов.
Немногие, если таковые вообще удастся найти, бизнес-приложения сегодняшних дней работают в изоляции. С того самого момента, когда коммерческий представитель находит клиента, и до момента, когда будет оплачен счет и выполнен заказ, многочисленные гетерогенные приложения и сервисы, скрытые от посторонних глаз, работают для создания бизнес-процессов. Интегрирование сегодняшних гетерогенных приложений, действий, событий и сервисов в эти сквозные бизнес-процессы является большой проблемой.Ключом для решения проблемы интеграции является обеспечение общеупотребительного стандарта. Фокусирование такого стандарта на транзакционные бизнес-процессы требует описания, как именно происходят транзакции, и в каком порядке.
Язык выполнения бизнес-процессов (Business Process Execution Language – BPEL) предлагает общеупотребительный язык для бизнес-приложений и сервисов. BPEL является новым стандартом для интеграции гетерогенных приложений и сервисов в транзакционные бизнес-процессы.
"BPEL – это язык потоков технологических процессов и данных (workflow and process flow language). Поэтому если имеется несколько стадий, которые нужно объединить в единое целое для формирования бизнес-процесса, то BPEL – это тот язык, который вы будете использовать для описания, как и в какой последовательности должны происходить события, – объясняет Дейв Шаффер (Dave Shaffer), бизнес-консультант и эксперт по BPEL корпорации Oracle. – Есть одно неправильное представление, которое необходимо рассеять: для того, чтобы BPEL был полезен, вовсе обязательно всюду иметь Web-сервисы. BPEL позволяет связываться со многими различными видами выполняющихся на сервере систем через родные для них (native) протоколы".
До BPEL
"До появления BPEL существовали различные технологии интеграции прикладных систем уровня предприятия (Enterprise Application Integration – EAI) и составляющих чью-то собственность (proprietary -проприетарный) технологий управления бизнес-процессами (Business Process Management – BPM), – объясняет Шаффер. – Люди имели возможность строить связанные приложения, но они были дорогими, сложными и проприетарными".В декабре 2000 года корпорация Microsoft опубликовала XLANG – язык бизнес-процессов на базе XML, используемый в Microsoft BizTalk Server для управления приложениями и Web-сервисами XML. Три месяца спустя корпорация IBM опубликовала язык потоков данных Web-сервисов (Web Services Flow Language – WSFL), язык XML для описания Web-сервисов как части определения бизнес-процесса. IBM разработала WSFL как часть инфраструктуры технологии Web-сервисов, опираясь на спецификации таких существующих стандартов как SOAP, UDDI, WSDL и XMLP.
В августе 2002 года IBM, Microsoft и BEA выпустили первый общедоступный проект спецификации языка выполнения бизнес-процессов для Web-сервисов (Business Process Execution Language for Web Services -- BPEL4WS), в которой они скомбинировали идеи спецификаций XLANG и WSFL. В апреле 2003 года OASIS (Organization for the Advancement of Structured Information Standards – организация по усовершенствованию стандартов структурированной информации) пригласила всех желающих принять участие в работе технического комитета BPEL. В мае 2003 года о своей поддержке BPEL объявили Sun и Oracle.
Характеристики BPEL
BPEL определяет поведение бизнес-процессов, базирующихся на Web-сервисах. BPEL реализует функциональность экспорта и импорта, используя исключительно интерфейсы Web-сервисов. BPEL вписывается в архитектуру основных Web-сервисов, построенную поверх UDDI, WSDL, XML и XML Schema."BPEL – это упрощенный стандартный язык, который облегчает гармоническое сочетание различных Web-сервисов, – говорит Шаффер. – Он образует слой поверх Web-сервисов и XML, а также стандартных блоков различных компонентов. Большинство людей уже работает в среде SOAP, WSDL, XML и XML Schema, и большинство компаний уже двигается в направлении интеграции на основе XML. Так что BPEL – это правильный путь для разработчиков".
Императив интеграции (Integration Imperative)
(Rich Schwerin), старший редактор издательства Oracle Publishing.Источник: журнал Oracle Magazine, no.6, 2004, раздел "ТЕХНОЛОГИЯ", рубрика "Промышленный стандарт", http://www.oracle.com/technology/oramag/oracle/04-nov/o64industry.html
Перевод: Oracle Magazine RE
Oracle BPEL Process Manager
Oracle BPEL Process Manager является масштабируемым сервером оркестровки на основе BPEL с поддержкой моделирования, объединения, развертывания и управления процессами BPEL; он предлагается и как автономный продукт, и как опция сервера приложений Oracle 10g Enterprise Edition. Помимо BPEL сервер приложений Oracle 10g поддерживает SOAP, WSDL, WS-Coordination, WS-Transaction и XML, каждый из которых позволяет приложениям гибко находить друг друга и прозрачно взаимодействовать в рамках независимой от платформы модели."Основная бизнес-проблема с BPEL – это интеграция, – объясняет Роб Ченг, директор, управляющий выпуском продукта Сервер Приложений Oracle 10g. – Цель BPEL состоит в том, чтобы найти более простые, более гибкие и более легкие способы разрешения проблем интеграции – не только для подключения унаследованных приложений, но также и для того, чтобы в будущем строить приложения с более высоким уровнем модульности".
"BPEL определяет совместную оркестровку и хореографию (orchestrated and choreographed) сервисов и способен компоновать сущности воедино в потоки процессов и потоки приложений в рамках гетерогенной архитектуры – независимо от используемого оборудования, языка программирования или операционной системы – то есть, именно там, где сервер BPEL от Oracle превосходит другие системы, – говорит Ченг. – У нас есть единственный промышленный механизм BPEL, который обрабатывает BPEL естественным образом, так что он богаче, быстрее, работе с ним проще научиться и он более расширяем, чем проприетарные альтернативы".
От сервисов к процессам
BPEL определяет конструкции, необходимые для составления набора сервисов для бизнес-процессов, связанных с совместной деятельностью и сделками. "BPEL определяет, как посылать XML-сообщения отдаленным сервисам, как управлять структурами данных XML и асинхронно получать XML-сообщения от отдаленных сервисов, – замечает Шаффер. – Он также позволяет вам управлять событиями и исключительными ситуациями, определять параллельные последовательности выполнения, и отменять части процессов, когда происходят исключительные ситуации".С помощью BPEL типичные бизнес-процессы могут быть описаны как выполнимые бизнес-процессы, моделирующие фактическое поведение участника бизнес-взаимодействия, и как бизнес-протоколы, использующие описания процесса, которые определяют обоюдно видимое поведение обмена сообщениями каждой из сторон, участвующих в протоколе, не раскрывая их внутреннего поведения. Описания бизнес-протоколов называются абстрактными процессами. BPEL моделирует поведение как исполняемых, так и абстрактных процессов.
Поддержка обслуживания BPEL
Технический комитет OASIS по проблеме языка Web Services Business Process Execution Language (WSBPEL), работает над развитием BPEL. В него входят фирмы BEA Systems, Commerce One, EDS, IBM, Microsoft, NEC, Novell, Oracle, SAP, Siebel Systems, Sybase, Tibco и Vignette.Текущая спецификация BPEL, рассмотрением которой в настоящее время занимается OASIS, имеет номер версии 1.1. Планируется, что ее рассмотрение будет завершено к концу 2004 года. Тем временем, продукты BPEL для серверов типа Oracle BPEL Process Manager поставляются уже сегодня.
После BPEL
Есть некоторые вещи, которые BPEL разрешить не может, в том числе, сложные преобразования, конвертирование данных, соглашения с торговыми партнерами, ручные (выполняемые человеком) процессы и привязка к определенным выполняющимся на сервере системам, объясняет Шаффер и добавляет, что BPEL и не пытается “дать всем сестрам по серьгам”."BPEL не включает в себя сложные преобразования, но поддерживающие BPEL продукты поддерживают и некоторые XQueries, так что вы можете связать все вместе, как сервис, – объясняет Шаффер. – В BPEL имеются некоторые простые преобразования, но без помощи XQuery или XSLT для сложных преобразований вы должны были бы выполнить их отдельно, а затем интегрировать их".
Шаффер добавляет, что в BPEL отсутствует концепция ручного процесса, но он имеет ключевую поддержку асинхронных сервисов и ручных задач; а ручные задачи легко поддерживаются как сервисы.
Три ключа к BPEL
Основу BPEL составляют три ключевые свойства: асинхронность, координация потоков и управление исключительными ситуациями. Все они связаны с проблемами, с которыми сталкиваются разработчики, занимающиеся управлением интеграцией.Asynchrony (Асинхронность) Асинхронность имеет дело с асинхронными взаимодействиями, корреляцией сообщений и надежностью. Поддержка асинхронности необходима для разрешения Web-сервисов в сценариях интеграции и является обязательной для оптимального использования рабочего времени (для лучшего распределения обработки она позволяет пользователям вмешиваться в течение бизнес-потока или задержанной пакетной обработки). За счет разделения запросов на обслуживание и соответствующих им откликов асинхронность повышает масштабируемость и помогает избежать узких мест при выполнении приложения. Кроме того, она допускает непрерываемое выполнение, когда сервисы временно недоступны и когда клиенты работают в автономном режиме или отключены.
Flow coordination. (Координация потоков) Координация потоков включает параллельный поток выполнения, образцы соединений и динамические потоки. В реальных приложениях бизнес-потоки могли бы включать образцы сложных взаимодействий, и с синхронными, и с асинхронными сервисами. Координация потока включает интерфейс с WSDL, действия потока, переменные XML и отвечает за компенсацию. BPEL использует WSDL для обращения к обмениваемым сообщениям, вызванным операциям и типам портов. Действия с потоком используют общие переменные XML, так что компенсационные обработчики (compensation handlers) должны сохранять снимки данных, которые могут быть использованы обработчиком. Компенсационные обработчики могут отменить шаги, которые были уже завершены.
BPEL includes basic and structured activities. (В BPEL включены основные и структурированные действия). Основные действия состоят из индивидуальных шагов для взаимодействия с сервисом, манипулирования обмениваемыми данными или обработки исключительных состояний, с которыми сталкиваются в течение выполнения. Структурированные действия определяют последовательность выполнения и описывают создание процесса, транслируя выполняемые ими действия в структуры; в состав этих структур включены поток данных, шаблоны управления, обработка внешних событий, обработка ошибок и координация сообщений.
Exception management. (Управление исключительными ситуациями). Управление исключительными ситуациями имеет дело с синхронными ошибками, асинхронным управлением исключительными ситуациями и компенсацией бизнес-транзакций. Для того чтобы автоматизировать бизнес-процессы, большие усилия сосредоточены на управлении исключительными ситуациями, и BPEL упрощает управление исключительными ситуациями для Web-сервисов. При возникновении исключительных ситуаций вызываются локальные обработчики ошибки, связанные с Web-сервисами, и асинхронные сервисы уведомляются об этих исключительных ситуациях.
Порталы и жизненные циклы
21.02.2002Portal Lifecycle Management
Поначалу порталы представлялись довольно простой коллекцией статического контента, и это представление несколько задержалось в умах, отсюда следует всеобщая недооценка сложности и стоимости задач, которые предстоит решать в процессе эксплуатации, на протяжении всего жизненного цикла портала. На самом деле возникает необходимость управлять жизненным циклом. Действительно, управление статической информацией не требует значительных затрат, но современные порталы имеют дело с онлайновыми приложениями, их логическая сложность сопоставима со сложностью самого предприятия. С появлением новых технологий складывается впечатление, что современные системы для управления бизнесом, обретают все большее сходство с классическими системами автоматического регулирования, которые уже много десятилетий используются в технологическом управлении. А в теории автоматического управления, на которой строятся последние, есть такое утверждение: сложность регулятора не может быть меньше, чем регулируемого им объекта.
Портал обязан соответствовать предприятию на всем протяжении жизненного цикла, быть синхронным ему, но в отличие от других объектов, например, технических систем, бизнес-система находится в состоянии постоянной эволюции, и, следовательно, корпоративный портал никогда не может быть закончен как некоторый продукт и окончательно сдан в эксплуатацию, а живет и развивается вместе с предприятием.
Идеологию, пригодную для построения динамической схемы жизненного цикла портала, можно найти в [12]. В отчете, подготовленном аналитическом Delphi Group использованы материалы компании Mongoose Technology, предлагающей средства для разработки и эксплуатации порталов. Автор отчета представляет цикл жизни портала как замкнутый и повторяющийся, что противопоставляется обычному отношению к приложениям, которые иронически называются: «целься, пли, готово». Ударным трудом с фиксированной датой окончания порталы не строятся, это не продукт, имеющий окончательные потребительские качества, следовательно, требуется долговременные и методичные усилия по развитию и совершенствованию, через последовательность итераций.
В [13] приводится еще одно интересное наблюдение, вывод из которого имеет большое практическое значение. Обычно в процессе проектирования портала большинство участников составляют заинтересованные представители менеджмента компании, а ИТ-персонал — меньшинство. После того, как портал внедрен, пропорция радикально меняется, менеджерам он остается нужным в качестве инструмента, и они теряют к нему интерес, а большинство переходит к ИТ-специалистам, далеким от понимания функциональности. Отход менеджеров от выполнения миссии по совершенствованию опасен деградацией портала.
Каждый из витков жизненного цикла портала состоит из четырех периодов.
 |
Рис. 2. Жизненный цикл портала |
Одна из самых сложных проблем заключается в достижении взаимопонимания соучастников процесса, например, прикладными программистами, с одной стороны, и дизайнерами и художниками, ни те, ни другие не должны доминировать. Критически важным является подчинение технических проблем задачам бизнеса. В конечном счете, очень важно, сохранить целостность и контроль организации над порталом, а не наоборот.
Сегодня предложение средств для менеджмента порталов на рынке программного обеспечения еще невелико. Одно из наиболее известных — пакет PortalStudio Interactive Development Environment от компании Mongoose Technology, который представляет собой среду, позволяющую архитекторам порталов применить интегрированный подход к PLM. В состав пакета входит визуальная среда, библиотека компонентов, набор различных портальных заготовок. Пакет может быть использован в процессе создания и поддержки порталов на всем их жизненном цикле. В октябре 2001 года Mongoose Technology выпустила PortalStudio Enterprise Edition 2.0. Технология, предлагаемая компанией, соответствует стандартам J2EE, что обеспечивает ей нейтральность по отношению к вендорам портальных платформ. Существует возможность работы Mongoose PortalStudio совместно с BEA WebLogic, Oracle9i AS, Orion, Macromedia Jrun и IBM WebSphere.
Портал как средство для создания виртуальных сообществ
Работы, которые ведутся в Mongoose, не ограничены чисто технологическими аспектами, остающимися пока наиболее привычными для ИТ-специалистов. В PortalStudio 2.0 включен компонент RealCommunities, относящийся к новому поколению средств для групповой работы, так называемых коллаборационных приложений, основанных на использовании Web-служб для организации межличностного общения. Обращение к изучению этой категории коллективов и созданию средств их создания вызвано довольно простой мыслью. Эволюции человека в физическом пространстве проходила в процессе создания разного рода объединений, от стада до демократического государства, вся индустриальная история — это, в конечном итоге, история производственных коллективов.
Выйдя в виртуальное пространство, человечество с неизбежностью повторит этот опыт, поэтому и Web проходит три этапа.
Сообщества в электронном бизнесе могут играть возможно большую роль, чем в обычном бизнесе. Самый очевидный пример эффективности сообществ представляют собой системы CRM, основная идея которых выражается формулой:
P = ({[(Ri - Ci) х Li] - Si},
где
P — суммарная прибыль; Ri — доход от одного клиента; Ci — затраты на одного клиента; Li — время жизни одного клиента;
Si — затраты на получение одного клиента.
В этой формуле самым значимым параметром оказывается время вхождения клиента в сообщество потребителей. Если максимизация других параметров зависит от ряда других обстоятельств, время, пока потребитель остается верен поставщику, напрямую зависит от качества организации сообщества. Совершенно аналогичные рассуждения можно приложить к системам категорий SCM, CVM и другим. Понимая это, в Mongoose предлагают пакет RealCommunities, который позволяет объединить инфраструктуру и прикладные службы для построения Web-сообществ и взаимодействие каждого с каждым (peer-to-peer) внутри корпоративного портала. Схема работы RealCommunities удивительным образом напоминает каноническое представление о функционировании Web-служб, но в качестве объектов в ней выступают не приложения, а реальные люди. RealCommunities включает в свой состав модули:
RealCommunities обеспечивает управляемое взаимодействие между сотрудниками, партнерами и клиентами. Используемые при этом Web-службы усиливают процесс образования групп, коллаборацию между группами и внутри них, обмен знаниями между теми же тремя категориями — сотрудники, партнеры и клиенты. К числу достоинств RealCommunities с корпоративной точки зрения можно отнести возможность его средствами отчуждать сохранять интеллектуальный капитал, уменьшать текучесть рабочей силы, повысить продуктивность команд сотрудников и повышать лояльность клиентов.
Литература
Аналитические сервисы
Oracle Business Intelligence 10g - это интегрированное решение, предоставляющее бизнес-пользователю полную картину состояния дел на уровне организации. Это решение обеспечивает возможность быстрее принимать правильные решения, позволяет большему количеству служащих иметь доступ к информации, в которой они нуждаются, удаляет шум и обеспечивает качественную информацию. Кроме того, Oracle Business Intelligence использует пакетную обработку и возможности очистки данных Oracle Warehouse Builder для предоставления единого источника правды для важных информационных активов.Cервисы безопасности в Grid
В Oracle Application Server 10g Release 2 включен полный набор инструментальных средств и инфраструктура, необходимая для обеспечения безопасности на всех уровнях разработки и развертывания приложений. К их числу относятся визард-управляемые инструментальные средства разработки,безопасные интерфейсы приложений и поддержка стандартов, наряду с администрированием и форсированием инфраструктуры во время выполнения.Компоненты безопасности Oracle Application Server 10g включают:
Делегируемые административные
В Oracle Application Server 10g Release 2 включена служба Oracle Delegated Administration Services (Oracle DAS), предлагающая централизованные сервисы для управления пользователями и делегированного администрирования. Кроме того, Oracle DAS предлагает всеобъемлющее форсирование политики паролей, правила композиции, управление потерянными паролями и форсированные возможности повторной установки. В число новых возможностей DAS Oracle входит:
Инструментарий разработчика безопасности в Oracle
В Oracle Application Server 10g Release 2 появились комплекты Java-инструментарий разработчика безопасности, обеспечивающий стандартные криптографические возможности для основных задач, например, обмен защищенными сообщениями, а для более сложных проектов - реализация защищенной SOA. В инструментальные средства разработчика безопасности Oracle (Oracle Security Developer Tools) включены следующие возможности:
Интеграция и оркестровка сервисов – новые характеристики
Полная бизнес-интеграция может улучшить способность организации предсказывать рыночную динамику и отвечать на нее, увеличить продуктивность организации и радикально упростить среду информационной технологии, давая, в то же самое время, возможность эксплуатировать ранее сделанные инвестиции. Решение интеграции Oracle предлагает полную, продуктивную, открытую, расширяемую и стратегически важную платформу интеграции, которая является лучшей в классе по критериям ценности и функциональных возможностей.простой и удобный в работе продукт и нтеграции данных, который обеспечивает полные функциональные возможности шинной организации служб предприятия (Enterprise Service Bus – ESB) для быстрого развертывания интеграционных решений на всем предприятии.
продукт для управления бизнес-процессом (Business Process Management – BPM), позволяющий разрабатывать, компоновать и отлаживать сквозные бизнес-процессы, включающие людей, партнеров и приложения.
полное решение B2B, поддерживающее ведущие отраслевые протоколы для комплексной и быстрой интеграции партнеров.
управляемая событиями платформа для агрегирования, корреляции и представления событий на предприятии в пределах контекста, понимаемого бизнесом.
Он органично взаимодействуетс корпоративными порталами Oracle с целью создания сложных приложений, в которые вовлечены бизнес-процессы предприятия и данные. Кроме того, он обеспечивает комплексный мониторинг и управление, используя для этого Oracle Enterprise Manager.
Качество обслуживания – масштабируемость
В Oracle Application Server 10gRelease 2 вводится новый администратор динамических ресурсов (Dynamic Resource Manager), который облегчает повышение или снижение масштабов приложения, используя вычислительные ресурсы оптимально. Администратор динамических ресурсов состоит из трех взаимодействующих компонентов: (i) сервис динамического мониторинга (Dynamic Monitoring Service – DMS) используется для мониторинга производительности системы и потребления ресурсов индивидуальными приложениями. (ii) Oracle Enterprise Manager используется для сбора информации мониторинга из DMS и установки порогов производительности и политики распределения ресурсов для конкретных приложений. Например, можно сделать так, чтобы приложение для ввода заказов (Order Entry) получало 30% времени центрального процессора, в то время как программа ведения главной книги (General Ledger) получала 70% времени центрального процессора. (iii) Администратор динамических ресурсов интерпретирует определенную политику управления ресурсами и направляет запросы в соответствии с этой политикой. Если у приложения возникает нехватка ресурсов, администратор динамических ресурсов может завершить неактивные процессы; снять некоторую часть ресурсов с других приложений, которые в данный момент не нуждаются в них; запустить новые экземпляры сервера приложений или добавить (по требованию) вычислительную мощность. Следовательно, администратор динамических ресурсов обеспечивает оптимальное использование ресурсов; сокращает размер потраченных впустую вычислительных мощностей и освобождает администраторов приложений от выполнения утомительных задач по настройке производительности и балансировке ресурсов.Качество обслуживания – производительность
Oracle Application Server 10g Release 2 продолжает обеспечивать пользователям лучшую в отрасли производительность, оптимизируя каждый аспект сервера приложений и используя усовершенствования технологии аппаратных средств. В него заложено множество усовершенствований производительности:Oracle Application Server 10g является доказанным победителем во всех категориях эталонного тестирования SpecJ, типа: общее отношение цена/производительность, полная производительность, также в категориях c двумя и с многими узлами.
В следующих разделах мы обсудим некоторые из этих возможностей подробно.
Web-кэш Oracle
В OracleWeb Cache 10g (9.0.4) введены значительные усовершенствования в кэшировании и потоковых алгоритмах. В этом выпуске в потоковых алгоритмах сделаны дальнейшие усовершенствования, позволившие включить возможность сжатия. Кроме того, в Web-кэш были еще более усилены возможности выравнивания нагрузки IP. Управление Web-кэшем Oracle стало более простым за счет применения Oracle Enterprise Manager 10gApplication Server Control (10.1.2). Вот некоторые из усовершенствований Application Server Control для Web-кэша: возможность активировать/блокировать правила кэширования, настраиваемые имена для правил кэширования и автоматизированное конфигурирование порта прослушивания HTTP.
Oracle Containers для J2EE
В Oracle Containers для J2EE 10g (10.1.3) введено много усовершенствований производительности, которые дают приложениям возможность удовлетворить соответствующие соглашения об уровне обслуживания.
Вот только некоторые из этих характеристик:
Oracle Integration
Усовершенствования производительности для Oracle Integration 10g (10.1.2) заметны во всех ее компонентах. В диспетчере процессов Oracle BPEL появилось много характеристик, увеличивающих производительность, включая определенные усовершенствования для не фиксирующего своего состояния BPEL и более быстрые преобразования. Был значительно улучшен механизм Oracle Integration B2B, получивший более быструю хореографию. Интеграция данных много выиграла от усовершенствований, сделанных в JDBC, XSD и метаданных, и результаты показывают, что теперь она стала на 22% быстрее, чем в предыдущем выпуске. Кроме того, в большинство адаптеров были добавлены конкретные, зависящие от объекта характеристики усовершенствований производительности. Например, адаптер AQ стал в этом выпуске на 30% быстрее из-за усовершенствований, сделанных в способе копирования памяти, а также благодаря изменениям на уровне JDBC.
Качество обслуживания – высокая доступность
По мере роста числа стратегически важных приложений, развернутых в Интернете и интранете, пользователи становятся все более требовательными к качеству обслуживания и высокой доступности разворачиваемых систем. Из-за постоянного увеличения количества систем, используемых служащими и партнерами, высокая доступность перешла из разряда стратегически важных требований в разряд общих требований, которые затрагивают все типы развертывания.В Oracle Application Server 10g Release 2 были расширены возможности высокой доступности предыдущих выпусков, чтобы сократить время как планового, так и незапланированного простоя. Поскольку именно он является главной ценностью для всех заказчиков, которые используют сервер базы данных Oracle, Oracle Application Server 10g Release 2 был интегрирован с последними возможностями высокой доступности Oracle Database 10g. Теперь Oracle Application Server 10g Release 2 предлагает самые передовые механизмы выравнивания нагрузки и автоматического преодоления последствий сбоя между промежуточным уровнем и базой данных приложения.
Незапланированный простой из-за сбоя системы
Время незапланированного простоя из-за сбоев системы может быть уменьшено или полностью устранено за счет применения хороших решений для высокой доступности. При сбое системы имеются три основных проблемы, которые должны быть разрешены этими высокодоступными решениями.
Избыточность: Oracle Application Server Release 2 позволяет на всех его подуровнях выбирать между активно-активными или активно-пассивными моделями избыточности. Решение Oracle Cold Failover Cluster (кластер холодного автоматического преодоления последствий сбоя) теперь расширено и работает не только для инфраструктуры, но и для промежуточного уровня и компонентов web-уровня.
Используя новые функциональные возможности Server Failover (автоматическое преодоление последствий сбоя сервера), стало возможно создать единый набор сервисов, мониторинг и управление которыми будут проводиться сервером диспетчера процессов и уведомлений Oracle (OPMN).
Эти возможности расширяют возможности “обнаружения смерти” (выхода системы из строя) и авто-рестарта, представленные в предыдущих выпусках Oracle Application Server для многоузловых сред, и делают OPMN самым продвинутым самовосстанавливающимся механизмом для платформ сервера приложений на рынке.
Время внепланового простоя из-за сбоя данных
Защита от сбоев данных должна принимать во внимание три основных типа требований:
Резервное копирование и восстановление: Термин “резервное копирование и восстановление” относится к различным стратегиям и процедурам, задействованным в защите от отказов аппаратных средств и потери данных, а также к способности восстанавливать конфигурацию данных и экземпляра в тех случаях, если такая потеря произошла. Единое интегрированное инструментальное средство для резервного копирования и восстановления, поставляемое с Oracle Application Server, облегчает создание таких контрольных точек и последующее восстановление с них в случае необходимости. Инструмент Oracle Application Server 10g Release 2 Backup and Restore Tool может поддерживать резервное копирование и восстановление всей среды приложения. Этот инструмент интегрирован с Grid Control и Application Server Control и может выполнять все намеченное и инкрементальное резервное копирование с записью результатов на ленту или на диск. Инструмент полностью интегрирован с Oracle RMAN и обеспечивает создание снэпшотов на заданные моменты времени.
Flashback: В Oracle Application Server 10g Release 2 включена возможность автоматизированной архивации конфигурации и системных файлов, которые могут затем, в случае необходимости, быть использованы для выполнения “перемотки” на заданный момент времени.
Эта характеристика может быть скоординирована с опцией Flashback сервера базы данных Oracle для сквозной защиты от пользовательских ошибок.
Восстановление в случае чрезвычайных ситуаций: В состав Oracle Application Server 10g Release 2 включено новое решение для восстановления в случае чрезвычайных ситуаций (Disaster Recovery). Продукт Oracle Application Server Guard (ASG) построен на базе инструмента для резервного копирования и восстановления, а также ведущей в отрасли технологии Oracle Data Guard, которые обеспечивают полную защиту экосистемы сервера приложений от чрезвычайных ситуаций. Этот инструмент автоматизирует следующие операции:
Запланированные простои – скользящие обновления
В Oracle Application Server 10g Release 2 вводятся новые возможности для минимизации воздействия передислокации на различных уровнях:
Концентраторы данных Oracle (Oracle Data Hubs)
Продукты Oracle Data Hubs позволяют вам синхронизировать информацию ото всех систем на вашем предприятии в едином центральном местоположении, чтобы получить точное, непротиворечивое представление с полным обзором (на все 360 градусов) данных компании. Эта интеграция еще более упрощается за счет использования Oracle Integration Interconnect – эталонной реализации Customer Data Hub – и предлагает конкретные коннекторы с ведущими пакетами программ и технологиями, обеспечивающие широкую функциональную совместимость с имеющимися у вас информационными активами предприятия.Контейнеры Oracle Application Server для J2EE
Oracle Containers for J2EE (OC4J – контейнеры Oracle для J2EE) – являются ядром во время выполнения J2EE и Web-сервисов на Oracle Application Server. OC4J 10g (10.1.3) сертифицирован как полностью совместимый с J2EE 1.4 сервер с поддержкой JCA 1.5, JMS 1.1, JTA 1.0, JNDI 1.2, EJB 2.1, Servlet 2.4 и JSP 2.0.Поддержка новой инфраструктуры управления и развертывания
OC4J обеспечивает реализацию J2EE Management 1.0 (JSR 77), базирующуюся на Java Management Extensions (JMX), которая содержит ряд предварительно подготовленных компонент управления (Management Beans – MBeans) для администрирования и мониторинга самого сервера, приложения J2EE и Web-сервисов и средства поддержки. Используя эту инфраструктуру, разработчики могут также разрабатывать заказные MBeans для администрирования и мониторинга заказных приложений. В стандартизированных операциях развертывания и планах предусмотрена полная поддержка J2EE Deployment 1.1 (JSR 88).
В комплект поставки OC4J входит новая компонента Oracle Enterprise Manager на базе браузера – Application Server Control (управление сервером приложений), базирующаяся на инфраструктуре JMX, которая используется для управления, развертывания и мониторинга приложений J2EE и Web Service. В дополнение к ориентированным на задачи экранам администрирования, предлагается полный браузер JMX MBean.
Кластеризация приложений
Контейнер OC4J вводит новую модель кластеризации на уровне приложений, которая позволяет экземплярам OC4J одновременно принимать (быть хостом) как кластеризованные, таки и некластеризованные приложения. Для репликации состояний могут использоваться многие протоколы, включая многоабонентский (multi-cast) протокол, протокол взаимодействия равноправных (peer to peer) систем и протокол с поддержкой базы данных. Эта новая модель кластера предлагает более гибкий контроль, большую простоту использования и увеличенную производительность.
Web-сервисы
В дополнение к выполнению требований платформы J2EE 1.4 для поддержки JAX-RPC и Web-сервиса EJB, в OC4J вводится обширная структура управления Web-сервисами, дающий пользователям возможность вести аудит сообщений SOAP, регистрацию на основе контента, надежное получение сообщений и организацию безопасности.
Обеспечивается полная поддержка WS-Reliability и WS-Security ( каждый из которых является отраслевым стандартом организации по усовершенствованию стандартов структурированной информации – OASIS). Эта структура управления может быть сконфигурирован через консоль управления OC4J – Application Server Control – для системных администраторов, и через Oracle JDeveloper – для разработчиков.
Для разработчиков и администраторов в этом выпуске также вводятся задачи Ant (Ant tasks) для развертывания и свертывания приложений с использованием базовой инфраструктуры JMX. Кроме того, предлагается обширный набор задач для создания пакетирования Web-сервисов, сгенерированных из Java, EJB, JMS, CORBA и средства идентификации базы данных.
Архитектура коннекторов JCA
Обеспечивая для интеграторов приложений, работающих с информационными системами предприятия (EIS), существенный шаг вперед, OC4J 10.1.3 предлагает полную реализацию версии 1.5 J2EE Connector Architecture. Сюда входит полная поддержка контрактов уровня качества обслуживания системы, включая управление жизненным циклом, управление защитой, управление рабочими периодами, а также входные потоки сообщений и транзакций. Новинкой в J2CA 1.5 стал стандартизированный подход для входящих и исходящих коммуникаций, дающий возможность внешним EIS инициировать потоки в контейнер, и, как и ранее, получать потоки из контейнера.
JMS
Основным функциональным элементом реализации OC4J J2CA является готовый к употреблению сразу после установки адаптер родовых ресурсов JMS, который дает возможность провайдерам JMS от третьих фирм полностью включиться в инфраструктуру OC4J. Используя этот адаптер, Oracle Application Server 10g сертифицирует интеграцию с серверами JMS от третьих фирм, например, с WebSphereMQ, JMS Tibco и SonicMQ. Помимо поддержки провайдера JMS от третьих фирм, родовой адаптер ресурса JMS предусматривает MDB, которые автоматически приспосабливаются к изменяющейся нагрузке от сообщений, оптимизированной глобальной поддержке транзакций и созданию пулов подключений JMS.
Маршрутизатор JMS
Маршрутизатор JMS – это приложение J2EE, упакованное в OC4J, который предлагает надежное соединение посредством сообщений между любыми поддерживаемыми провайдерами JMS, например: OracleAS JMS, OJMS (AQ/JMS), WebSphereMQ, Tibco JMS и ли SonicMQ. Маршрутизатор JMS также поддерживает фильтрацию сообщений для маршрутизации сообщений.
Бизнес-правила
Бизнес-правила Oracle позволяют разработчикам приложений добавлять в свои приложения потрясающие маневренность и прозрачность. Это достигается за счет того, что бизнес-аналитикам разрешается самостоятельно, без какой-либо зависимости от программистов, вносить в приложения изменения, отражающие новую политику ведения бизнеса. Бизнес-правила Oracle особенно подходят для развертывания, в частности, как приложений BPEL, так и приложений SOA вообще, а также приложений других архитектур, где маневренность, особенно за низкую цену, является важным свойством.
Краткий обзор
Предприятия всех размеров были в состоянии до некоторой степени использовать Web-сервисы и сетевые вычисления, чтобы выстраивать подвижные взаимодействия между своими разноплановыми приложениями и ИТ-ресурсами. И хотя организации могли снизить стоимость стандартизации бывших когда-то различными ИТ-систем и ресурсов, в то же самое время они смогли понять ограничения, накладываемые развертыванием на их предприятиях точечных решений . Поэтому потребность и далее повышать полный ROI (коэффициент окупаемости инвестиций) вынудили организации провести переоценку точечных стратегий в пользу решений, которые обеспечили бы лучшую полную ценность и допускали бы повторное использование на всем растущем предприятии.В Oracle Application Server 10g Release 2 объединены продвинутые возможности Service Oriented Architecture (SOA – корпоративная сетевая архитектура на базе сервисов) для стратегически важных приложений, позволяющие предложить наиболее сплоченные и всеобъемлющие заказные решения в отрасли для масштабирования, обеспечения безопасности и управления Web-сервисами и сетью, подходящие для любых сред ИТ.
Эта статья сфокусирована на новых характеристиках, появление которых заплан ировано в Oracle Application Server 10gRelease 2: инновации в SOA, новые инфраструктуры разработки решений, Portal, Business Intelligence, Identity Management и сетевые вычисления. Эти характеристики являются основными для получения решений, которые, будучи один раз включены, остаются затем всегда доступными для управления ими и дальнейшего улучшения возврата инвестиций в бизнес, базирующегося на ИТ-модели наилучшего полного спектра возможностей.
Обеспечение идентификации (Oracle Identity Provisioning)
Возможности Oracle Identity Provisioning:
Oracle Application Server 10g Release 2. Краткий обзор новых характеристик
Источник: Белая книга Oracle (An Oracle White Paper)Перевод: Oracle Magazine/RE
Oracle BAM: Полностью новая архитектура реального времени
Oracle BAM довел до нового уровня возможности аналитики, реализуя информационное и отчетностное решение в целом по предприятию. В отличие от традиционного решения, когда данные находятся в хранилище и к ним осуществляется доступ по запросам, Oracle BAM уникально базируется на активной, основанной на сообщениях и управлении событиями архитектуре, в которой при помощи сообщений (messaging) промышленная информация передается моментально и доходит до графического отображения за 2-10 секунд после события на предприятии. Oracle BAM позволяет внедрять новые и только еще развивающиеся технологии, которые радикально меняют основную бизнес-деятельность, улучшают эффективность эксплуатации и производительность. В числе таких технологий можно назвать:При задействовании этих ключевых технологий Oracle BAM оптимизирует бизнес-производительность посредством эффективного воздействия всех уполномоченных лиц, как внутри, так и вне организации. Эти лица, которые принимают решения (ЛПР), совершают действия, которые положительно или отрицательно воздействуют на бизнес- производительность в целом. При использовании Oracle BAM ЛПР могут сделать правильные решения, поскольку они всегда имеют необходимую информацию, в удобном для них формате, и именно тогда, когда они в ней нуждаются. Oracle BAM уникально обеспечивает:
Своевременность... Постоянно изменяющаяся информация
Чтобы предпринимать эффективные действия и повышать производительность, непосредственно в момент решения ЛПР нуждаются в информации в реальном времени,. Oracle BAM обеспечивает сигналы тревоги в реальном времени и доступ к актуальным данным, которые представляют собой сию секундные сведения, чтобы решение было проактивным, упреждающим, а не запоздалым, реактивным.
Поточная доставка данных гарантирует, что сообщения в реальном времени автоматически и непрерывно модернизируются, коль скоро изменения происходят в основных данных.
Досягаемость... Все для лиц, принимающих решения
В отличие от традиционных запросных решений Oracle BAM объединяет информацию из многомерных и реляционных источников данных, web-сервисов, данных от приложений предприятия, и представляет их в интуитивном пользовательском браузер-интерфейсе на на любом устройстве, обеспечивая готовность всей информации предприятия в реальном времени.
Релевантность... Только нужная информация
В Oracle BAM информация персонифицирована, так что каждый пользователь получает только нужную ему информацию в точном, удобном формате в точное время. Отчеты Oracle BAM в реальном времени обеспечивают групповое сотрудничество и принятие решения с обратной связью, что позволяет немедленное непосредственное обсуждение проблемы и ее решение.
Применимость... Эффективно, эффектно, удобно в работе
Oracle BAM построен для равномерной, гладкой работы с существующими информационными инфраструктурами. Он поддерживает практически любые коммерческие базы данных и системы управления сообщениями. Oracle BAM применим и может быть полностью настроен и персонифицирован по ролям, обязанностям и навыкам каждого пользователя. И искущенные, и бизнес- пользователи приходят к выводу, что отчеты столь же легко проектировать, распределять и изучать, как слайды PowerPoint.
Oracle BPEL Process Manager
Язык выполнения бизнес-процессов (Business Process Execution Language – BPEL) появился как четкий стандарт для объединения нескольких синхронных и аси нхронных сервисов в совместные и связанные со сделкой потоки процесса. К усовершенствованиям Oracle BPEL Process Manager относятся всеобъемлющее и удобное решение на базе стандартов для создания, развертывания и управления бизнес-процессами, в которых участвуют несколько при ложений. В этих бизнес-процессах могут иметься как автоматизированные, так и “человеческие” шаги технологического процесса, в результате чего становится возможным создание истинной корпоративной архитектуры на базе сервисов. Реализованная в нем "родная" поддержка стандартов типа XML (1.0), XSLT (2.0), XPATH (2.0), JMS (1.0.2), JCA (1.5) и Web-сервисов делает его идеальным решением для создания интегрированных бизнес-процессов, которые будут переносимыми между платформами.BPEL Designer
BPEL Designer (проектировщик процессов) предлагает графический и дружественный к пользователю способ построения процессов BPEL, используя BPEL как свой собственный ("родной") формат. Это означает, что процессы, построенные с помощью Designer, являются на 100% переносимыми, и, кроме того, он дает возможность разработчикам просматривать и изменять исходный код BPEL, не уменьшая полезности инструмента. Обеспечивающ ий пользователям унифицированную среду времени проектирования Designer является частью JDeveloper.
Консоль Oracle BPEL Process Manager (интеграционная панель)
Консоль BPEL обеспечивает дружественный к пользователю Web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживается информация трассировки аудита и статистические данные/данные отчетности процесса; она доступна и через BPEL-консоль, и через API Java. Списки задач технологического процесса и статистические отчеты анализа процесса также и нтегрированы в ту же самую консоль.
Встроенные сервисы интеграции
Встроенные сервисы интеграции дают разработчикам возможность без труда использовать из стандартных процессов BPEL расширенные технологические процессы, возможности функциональной совместимости и преобразования.
К числу этих возможностей относятся поддержка преобразований XSLT и XQuery, а также связывание с сотнями унаследованных систем через адаптеры JCA и "родные" протоколы. Сервисы технологических процессов с участием человека, типа управления задачами, управления уведомлениями и управления идентификационным и параметрами личности, обеспечиваются как встроенные сервисы BPEL, чтобы обеспечить и нтеграцию в потоки BPEL людей и ручных задач. Расширяемая структура связывания WSDL делает возможной функциональную совместимость со многими протоколами и форматами сообщения, помимо SOAP. Связывания доступны для JMS, электронной почты, JCA, HTTP GET и POST, а также для многих других протоколов, разрешающих простую функциональную совместимость с сотнями серверных систем. Вот только некоторые готовые к употреблению сразу же после установки адаптеры, которые делают возможной работу сервисов интеграции:
SAP, PeopleSoft, Siebel, J.D. Edwards
CICS, IMS DB, IMS TM, DB2, VSAM
RosettaNet, EDI
HTTP, SMTP, FTP, JMS, Database, Advanced Queuing, Web-сервисы
Сервер Oracle BPEL Process Manager
Oracle BPEL Process Manager выполняет стандартные процессы BPEL и обеспечивает возможность "дистилляции" (dehydration), так чтобы состояние потоков, выполняющихся длительное время, автоматически поддерживалось в базе данных, что делает возможной кластеризацию как в целях автоматического преодоления последствий сбоев, так и для достижения масштабируемости. Некоторые расширенные возможности Oracle BPEL Process Manager включают:
Oracle Business Intelligence Discoverer
С помощью Oracle Business Intelligence Discoverer (OracleBI Discoverer) бизнес-пользователи на всех уровнях организации могут более быстро принимать бизнес-решения на основе более широкой и полной информации. Используя любой стандартный web-браузер, пользователи получают защищенный и немедленный доступ к своим данным. Discoverer предлагает бизнес-представления, скрывающие сложность лежащих в их основе структур данных, тем самым, давая пользователям возможность сосредоточиться на решении деловых проблем.
Прямой доступ OLAP
Этот выпуск Discoverer поддерживает в базе данных опцию OLAP, обеспечивающую многомерные представления данных из реляционных таблиц и аналитических рабочих пространств. База данных Oracle интегрировала OLAP и реляционную аналитику в единый механизм. Вам больше не требуется для анализа извлекать, переносить и преобразовывать данные в отдельный многомерный механизм. Используя новый прямой доступ OLAP, пользователи могут выполнить свой собственный многомерный анализ, создавать отчеты и обеспечивать их совместное использование, чтобы принимать лучшие решения.
Oracle Identity Management Control
В Oracle Identity Management Control предлагается центральная консоль для мониторинга распределенных компонентов управления идентификацией на всем предприятии. Интегрированное с Grid Control решение является частью комплексного решения, обеспечивающего контроль, мониторинг и создание отчетов о состоянии среды корпоративных приложений.К числу возможностей Oracle Identity Management Control относятся:
Oracle Integration B2B
Oracle Integration B2B является единственным инструментом, требующимся для определения, конфигурирования, управления и мониторинга электронного обмена информацией между двумя или большим числом предприятий. В сочетании с Oracle Integration InterConnect, BPEL Process Manager и соответствующими технологиями – адаптерами Application и Legacy – Oracle обеспечивает полное сквозное решение для интеграции на вашем предприятии и за его пределами. К числу новых возможностей, включенных в этот выпуск, относятся:Широкая поддержка протоколов
Oracle Integration B2B предлагает широкую поддержку протоколов, делающую возможной развертывание признанных отраслью стандартов: RosettaNet, электронного обмена данными (Electronic Data Interchange – EDI), Applicability Statement 2 (AS2) и заказных конфигураций. Эта поддержка включает:
Комплексное соглашение с торговым партнером
В Oracle Integration B2B предлагается удобный интерфей с пользователя (UI) на базе мастера, чтобы провести его через шаги определения возможностей каж дого торгового партнера. Затем, используя эти возможности, можно определить электронное соглашение, которое обеспечивает принудительное исполнение правил взаимодействия торговых партнеров в рамках определенного бизнес-процесса.
Oracle Integration Interconnect
Используя обширные возможности шинной организации служб предприятия Oracle Integration InterConnect, можно значительно сократить время, требующееся для развертывания решения для интеграции данных. К числу ключевых возможностей относятся:Oracle интегрирует BAM
Oracle BAM является полностью новой, построенной на сообщениях, управляющей событиями, резидентной в памяти архитектурой, разработанной специально под потребности аналитики и управления в реальном времени отчетами приложений. Oracle BAM является первым и единственным решением, которое обеспечивает наблюдаемость в реальном времени деятельности предприятия, которое дает бизнес-пользователям подробную аналитическую информацию, какие нужно улучшить процессы, какие сократить затраты, - как только в бизнесе происходят случаются некоторые события. Архитектура Oracle BAM использует управление сообщениями (messaging), интеграцию данных, усовершенствованное кеширование данных, аналитический мониторинг, тревожную сигнализацию (alerting) и технологическую отчетность, чтобы предоставить за несколько секунд требуемую важную информацию о событиях или изменениях состояния (статуса). Поскольку первичный источник данных - сообщения, Oracle BAM способен корректировать отчеты и генерировать тревожные сигналы со скоростью, которую просто не могут обеспечить традиционные аналитические архитектуры. Oracle BAM может принять десятки тысяч корректировок в секунду в постоянно находящийся в памяти кеш, который служит центром архитектуры Oracle BAM.Архитектура Oracle BAM включает три главных логических элемента:
Oracle Internet Directory – служба каталогов LDAP
В Oracle Internet Directory включены следующие новые возможности:Oracle JDeveloper
Oracle JDeveloper 10g – это среда разработки J2EE со сквозной поддержкой моделирования, разработки, отладки и развертывания приложений и Web-сервисов.
Основная IDE
В Oracle JDeveloper 10g Release 2 (10.1.3) введены совершенно новые принципы построения пользовательского интерфейса, базирующиеся на JGoodies. Усовершенствования удобства и простоты использования относительно к управлению окнами включают обратную связь по "перетаскиванию", возможности быстрой максимизации и восстановления, области заголовка в виде закладок и двойной щелчок для разделения окна редактора. Кроме того, в JDeveloper 10g введены усовершенствования, типа возможностей создавать динамические проекты, рабочие наборы, общие и локальные для пользователей свойства и управление библи отеками, чтобы устранить все препятствия в работе с проектами в среде групповых разработок.
Кодирование Java и рефакторинг
Новая структура рефакторинга позволяет вести более мощный и более быстрый рефакторинг и добавляет более 20 новых действий рефакторинга. Эта новая структура позволяет вести дополнительный поиск в файлах, написанных не на Java, а также в комментариях и строках исходных файлов Java. Новые правила навигации по коду Java включают возможность перемещений с использованием меток Find Usages, Hierarchy Browser, Implemented and Overridden margin, а также облегчают навигацию между членами.
Поддержка J2SE 5.0
Помимо этого, JDeveloper 10g предлагает полную поддержку J2SE 5.0. Мало того, что новая версия J2SE может использоваться для компилирования, выполнения, отладки и профилирования проектов Java – IDE предлагает также инструментальные средства для помощи с новыми конструкциями кодирования, введенными в J2SE 5.0. Например, все опции Structure Pane, Code Insight и Code Editor были обновлены для работы с аннотациями метаданных, родовыми величинами, автоматическим созданием окон (auto-boxing), переменными параметрами (varargs) и многими другими. Такие возможности IDE, как программные шаблоны и рефакторинг, были усилены, чтобы можно было воспользоваться преимуществами новых особенностей J2SE.
Интеграция с открытыми программными технологиями
Теперь Oracle JDeveloper 10g (10.1.3) стал более дружественным к открытым источникам и предоставляет более простую интеграцию с Ant, Junit, CVS, Struts и Xdoclet. Как ожидают, Oracle JDeveloper, предложит эталонную реализацию JSR-198, как только эта спецификация будет завершена, делая, таким образом, возможной интеграцию с любым и инструментальными средствами, поддерживающими эту спецификацию.
Этот новый выпуск JDeveloper поддерживает Web-сервисы, соответствующие техническим требованиям J2EE 1.4, с возможностью создать клиентов и сервисы JAX-RPC. В него также включены новые Мастера для WS-Security, WS-Reliability и WS-Management, позволяющие пользователям устанавливать свойства защиты, качества обслуживания и регистрации для Web-сервиса перед его развертыванием.
Oracle Portal
В Oracle Application Server 10g Release 2 (10.1.2.0.1) появился Instant Portal, который становится доступным сразу же после установки. Кроме того, Oracle Portal продолжает обеспечивать усовершенствования во всех своих сервисах, включая среду проектирования на базе браузера, публикацию и управление контентом методом самообслуживания, сообщества пользователей, многоканальный доступ и встроенные системы анализа бизнес-информации.
Instant Portal
Oracle Instant Portal – это готовое сразу же после установки решение портала для совместного использования и передачи информации. Не требуется никаких предварительных разработок, поскольку Instant Portals генерируются “с одного щелчка”. В каждый портал включается ряд предварительно сконфигурированных страниц для публикации и организации контента по отделам или функциям. Первый Instant Portal генерируется автоматически при инсталляции Oracle Application Server Standard Edition One. Запускающийся с одного щелчка мастер облегчит создание дополнительных порталов.
Непосредственно в Instant Portal могут быть созданы или удалены пользователи; там же им могут быть предоставлены привилегии.
Упрощенная модель защиты подразделяет пользователей каждой из основных портальных страниц на просматривающих, вкладчиков или менеджеров.
Дизайн и разработка страницы
К числу сделанных в этом выпуске усовершенствований относятся: Мастер для создания и редактирования страниц, упорядочение страниц и управление ими, а также настройка страниц и портлетов.
Управление контентом в режиме самообслуживания
В этот выпуск включены следующие усовершенствования: Мастер для публикации контентов, увеличение числа типов элементов контента, возможность расширить список атрибутов и поведение контента, новые политики, разрешающие администраторам порталов более точную группировку контента и управление им, и расширенные возможности групповой разработки контента.
Поддержка стандартов
В Oracle Portal по-прежнему поддерживается разработанный OASIS стандарт Web-сервисов для удаленных портлетов (Web services for Remote Portlets – WSRP), который делает возможной функциональную совместимость портлетов на различных платформах порталов.
Oracle Sensor Edge Server
Oracle Sensor Edge Server – новый компонент Oracle Application Server 10gRelease 2 – действует подобно мосту между миром сенсорных устройств и остальной частью программной инфраструктуры. Его главная функция – обеспечить механизм управления и расширения для соединения с физическими аппаратными средствами и легко объединить их возможности с имеющимися или новыми приложениями. Sensor Edge Server спроектирован для того, чтобы справляться с быстро изменяющимися стандартами и возможностями сенсорных технологий, и в то же время оградить разработчиков приложений от изменений протоколов и аппаратных средств и разновидностей различных устройства.Инфраструктура драйвера
Инфраструктура драйвера Oracle Sensor Edge Server подключает к бизнес-приложениям аппаратные средства RFID, устраняя тем самым потребность в том, чтобы приложения знали о специфике аппаратных средств, используемых в том или ином проекте. Он нормализует поток событий между аппаратными средствами и приложением в общеупотребительный формат и протокол и управляет взаимодействием с самим аппаратным устройством. Следовательно, этот драйвер облегчает разработку приложений на основе RFID, которые могут работать почти со 100 различными устройствами RFID, не требуя от разработчиков приложений, чтобы они понимали их специфику или могли реализовать свои приложения в соответствии с характеристиками каждого устройства.
Фильтры, группы и управление
В Oracle Sensor Edge Server предлагается каркас фильтра, обеспечивающий фильтрацию на уровне групп и фильтрацию на уровне устройств. В результате сокращается низкоуровневая обработка, которая должна проводиться корпоративными приложениями. Возможность группирования позволяет сгруппировать несколько физических считывающих устройств в единый логический объект, позволяя приложению игнорировать базовую реализацию и рассматривать его (этот объект) как единое считывающее устройство.
Диспетчеризация событий
Каркас Dispatcher (диспетчера) предлагает несколько готовых диспетчеров, позволяя посылать данные от сенсорных датчиков через Web-сервис или другие стандартные интерфейсы непосредственно приложению, или в технологию накопления и диспетчирования событий типа Oracle Streams, ставшие доступными в Oracle Database 10g. Во внутренней очереди перед диспетчером кэшируются все поступающие от датчиков события, чтобы обеспечить страхование на тот случай, если выйдет из строя соединение между Sensor Edge Server и приложением.
Edge Extensions
При проектировании Oracle Sensor Edge Server было учтено, что сенсорные технологии изменяются очень быстро. Sensor Edge Server обеспечивает расширяемый интерфейс для укрепления возможностей сервера по трем ключевым моментам: Driver Extensions, Filter Extensions и Dispatcher Extensions.
Oracle TopLink
Разработка в среде J2EE упрощается благодаря применению Oracle TopLink, предлагающего ряд сервисов данных, которые позволяют приложениям обращаться к данным практически из любого источника данных. Сервисы данных используют общий дизайн и инфраструктуру времени выполнения и включают объектно-реляционное отображение, доступ к данным бизнес-процесса и отображение объект-XML с реализацией JAX-B.
Oracle TopLink 10g (10.1.3) более тесно интегрирован с Oracle Application Server и поддерживает CMP EJB, соответствующие техническим требованиям CTS 1.4, структуру управления на базе JMX, структуру стандартной регистрации и политику защиты. Он использует базу данных Oracle с поддержкой Virtual Private Database, типа XDB-XML, опции Flashback и хранимые функции. В Oracle TopLink также включены существенные усовершенствования в област и Object-XML, Mapping Workbench, Cashing, Clustering и Transaction.
Oracle Wireless
Oracle Wireless предлагает комплексную платформу для расширения радиуса действия ваших корпоративных приложений. Приложения обмена сообщениями (однонаправленные и двунаправленные, SMS/MMS/IM/Email/Voice Alerts), сервисы, связанные с местоположением заказчиков (мобильное позиционирование, работа с картами, выбор маршрута), интерактивный голосовой доступ (VoiceXML), и мобильные приложения с браузером (WML, XHTML MP) – все это можно разработать и развернуть, а также управлять этим с помощью Oracle Application Server Wireless, обеспечивая одну консолидированную платформу сервера приложений для всех ваших беспроводных потребностей.
Каналы обмена сообщениями
Архитектура обмена сообщениями Oracle Application Server Wireless является расширяемой и позволяет добавлять новые каналы. Поддерживаются следующие каналы, готовые к употреблению сразу же после установки: SMS, EMS, SmartMessages (vCard, vCal, Ringtones, Icons, логотипы Оператора), MMS, электронная почта, факс, голосовые уведомления, пейджеры и мгновенный обмен сообщениями.
Поддержка шлюзов и протоколов
Была расширена поддержка различных шлюзов и протоколов, как это описано ниже.
Отчетность
В OracleBI Discoverer 10g (10.1.2) имеется много новых усовершенствований отчетности, включая генерацию высококачественных PDF, экспорт в формат PDF, предварительный просмотр выводимой на печать информации, макет страницы и опции печати. Используя Discoverer Viewer, пользователи будут теперь в состоянии, как вложение, послать по электронной почте содержание своих рабочих листов в любом из форматов экспорта, включая Excel, PDF, HTML, текст, CSV и другие. Для пользователей, которым более удобно работать с рабочими листами Excel, Discoverer не только экспортирует данные, но и экспортирует их как сводные (pivoting) таблицы Excel.
Простота использования
В этом выпуске стала теперь доступна прямая манипуляция для выполнения большинства задач, а также и возможность простого прохода по данным многими способами, типа погружения в данные для их детализации и укрупнения (агрегации) данных. Поддержка "перетаскивания", улучшенное погружение в данные, возможность доводить периодическую информацию до большого числа пользователей, предоставление доступа к результатам запланированной рабочей книги, и улучшенные возможности управления рабочей книгой повышает квалификацию пользователей.
Портал
В OracleBI Discoverer 10g (10.1.2) теперь можно интегрировать с Oracle Portal заказные портлеты Business Intelligence, делая тем самым возможным своевременный корпоративный доступ к качественной информации. Он вводит портлеты для подведения итогов, позволяющие создавать мгновенные снимки (снэпшоты) информации. Кроме того, заказчики могут теперь персонифицировать свои представления портлетов Business Integration для опубликованного рабочего листа, изменяя значения параметров, форматы, макет страницы, типы графического представления и так далее.
Reports
Oracle Reports 10g (10.1.2) делает возможной межплатформенную среду разработки, в которой можно разрабатывать отчеты на одной платформе и разворачивать их на любой другой. Кроме того, в Reports проведено много изменений инфраструктуры, типа миграции от Visibroker к ORB Sun, позволивших увеличить производительность и масштабируемость. В Oracle Reports введено много усовершенствований форматирования для PDF, Postscript, HTMLCSS, электронных таблиц и RTF. К числу усовершенствований интеграции управления Oracle Reports относятся расширение содержимого страницы состояния Reports и появление новой страницы All Metrics.
Рисунок 1: Oracle Application Server
Рисунок 1Рисунок 1: Oracle Application Server 10g Release 2
Рисунок 2: Поддержка полного цикла
Рисунок 2Рисунок 2: Поддержка полного цикла жизни
Рисунок 4: Разработка структуры приложений
Рисунок 4Рисунок 4: Разработка структуры приложений Oracle.
Рисунок 6: Oracle Sensor Edge
Рисунок 6Рисунок 6: Oracle Sensor Edge Server
Рисунок 7: Непрерывная высокая доступность
Рисунок 7Рисунок 7: Непрерывная высокая доступность в сети
Рисунок 8: Управление полным циклом
Рисунок 8Рисунок 8: Управление полным циклом жизни в сети
Платформа интеграции каталога
Вот новые возможности, включенные в эту платформу:
A “Сводка возможностей”
В Oracle Application Server 10g Release 2 и Release 3 имеется много новых возможностей. Чтобы определить, в котором именно выпуске стала доступной (или будет доступна) та или иная возможность, в приводящихся ниже таблицах предлагается привязка новых возможностей к номерам выпусков. Таблицы организованы по следующим категориям:B “Что стоит прочесть еще”
Ниже приводится список источников, из которых можно получить более глубокую информацию о новых возможностях различных решений в Oracle Application Server.Разработка структуры приложений Oracle
Разработка структуры приложений Oracle (Oracle Application Development Framework – ADF) упрощает разработку J2EE за счет минимизации потребности написания программного кода, реализующего шаблоны проектирования и инфраструктуру приложения. Признавая, что недостаточно иметь набор сервисов времени выполнения, Oracle ADF сосредотачивается на опыте разработки, обеспечивающем визуальный и декларативный подходы к разработке в среде J2EE.Разработка в среде JavaServer Faces
В Oracle JDeveloper предлагается визуальная среда разработки JavaServer Faces (JSF), а также обширная библиотека компонентов JSF – Oracle ADF Faces. В дополнение к поддержке “перетаскивания” компонент пользовательского интерфейса и навигации по лицам (faces navigation), разработчики постоянно имеют доступ к исходному тексту JSF. Это дает им возможность быстро создавать макет (прототип) пользовательского интерфейса, взаимодействовать с пользователями для получения обратной связи, а затем итерационно усовершенствовать его без ограничений.
В своем визуальном редакторе Oracle ADF обеспечивает прямую визуализацию компонентов JSF, предлагаемых эталонной реализацией JSF (Reference Implementation—RI), а также визуализацию заказных компонентов типа ADF Faces, MyFaces и других компонентов JSF третьих фирм.
Развервертывание сервисов в grid
В Oracle Application Server 10g Release 2 имеется множество новых возможностей, которые были спроектированы, чтобы предоставить бизнес-приложениям превосходную производительность, масштабируемость и высокую доступность на кластерах, собранных на базе дешевых процессоров и памяти. Эти возможности понижают стоимость аппаратных средств и памяти; уменьшают расходуемые впустую вычислительные мощности; позволяют добавлять вычислительные мощности маленькими, модульными блоками и обеспечивают лучшее качество обслуживания бизнес-приложений.В Oracle Application Server 10gRelease 2 включены усовершенствования, которые были спроектированы, как обеспечивающие множество преимуществ:
Oracle Application Server 10g предлагает защищенную платформу для корпоративных приложений. Он понижает стоимость администрирования защиты и дает возможность централизованно управлять идентификационными параметрами пользователей и их привилегиями контроля доступом через комплексные возможности управления идентификационными параметрами личности, заложенные в Oracle Application Server 10g.
Решения для построения сервисов – новые возможности
В Oracle Application Server 10g поддерживается новая модель для разработки и интеграции корпоративных приложений – сервис-ориентированная архитектура (SOA). С появлением SOA наметился сдвиг от монолитных приложений к формированию сложных приложений, которые собраны из многократно используемых бизнес-компонент и сервисов. Любое новое или существующее приложение может быть опубликовано как сервис. Если они раскрыты с использованием стандартных интерфейсов типа WSDL, эти сервисы называют Web-сервисами, которые облегчают функциональную совместимость между платформами.в Grid, многие отделы информационных
В связи с движением приложений в сторону сервис-ориентированной модели, разворачиваемой в Grid, многие отделы информационных технологий продолжают экспериментировать, тестировать и развертывать сервисные приложения и архитектуры, используя фрагментированные частичные решения. Хотя уже первые преимущества и выигрыш в стоимости выглядят перспективными, становится все более и более ясно, что для получения хороших результатов по окупаемости долгосрочных инвестиций потребуются более проработанные решения. Oracle Application Server 10g Release 2 и Release 3 влился в эту струю с инновационным решением, хорошо проработанным для обеспечения расширяемости, простоты, удобства сопровождения и полного управления циклом жизни нового поколения сервис-ориентированных корпоративных приложений (Service Oriented Enterprise Applications), которые должны обеспечить своим организациям реальные инвестиционные результаты.
Oracle Application Server 10g предлагает много технологических решений, базирующихся на модели сервис-ориентированных вычислений. Он предлагает простую для инсталляции SOA- инфраструктуру; организации могут теперь, используя единую среду разработки, быстро разработать и развернуть приложения на J2EE-платформе. Он делает возможным применение непрерывных бизнес-транзакций в реальном времени и неразрывную работу систем анализа бизнес-информации в Grid, делая эти системы доступными в любое время и из любого места. Более того, он обеспечивает ключевые возможности масштабирования постоянно использующихся корпоративных приложений на более дешевых аппаратных средствах, гарантируя их более высокую производительность и простоту управления, а также обеспечивает безопасность бизнеса и идентификацию партнеров со значительно меньшими административными накладными расходами.
Oracle Application Server 10g Release 2, на разработку которого было затрачено более 8 миллионов часов технических специалистов, обеспечивает наиболее полный набор возможностей и может быть настроен для предприятий любого размера.
Сертифицированная авторизация Oracle (Oracle Certificate Authority)
В Oracle Application Server 10g Release 2 включена возможность определить расширение Subject Alt Name (альтернативное имя субъекта) в сертификатах, выпускаемых Oracle Certificate Authority.Кроме того, Oracle Certificate Authority обеспечивает возможность защиты корневого ключа CA в аппаратном модуле защиты. Эта возможность обеспечивает безопасность развертывания PKI, предлагая более высокий уровень защиты и гарантии защиты идентификационных параметров Certificate Authority.
Сервисы доступа и связанная информация
В состав Oracle Application Server включено полное и интегрированное решение для формирования, развертывания и поддержки корпоративных порталов мирового класса, которое допускает доступ к информации из любого места, в любое время и через любое устройство.
Управление безопасностью и идентификацией (Oracle Security and Identity Management)
Oracle Identity Management состоит из следующих компонентов:
Однократная подпись – управление доступом через Web
В Oracle Application Server Single Sign-On включены следующие новые возможности:
Безопасная федеративность в Oracle (Oracle Secure Federation)
Oracle Application Server 10g Release 2 предлагает основанные на открытых стандартах технологии для организации безопасной федерации в гетерогенной среде.
Эти опции включают:
Управление циклом срока службы в Grid
Oracle Application Server 10g Release 2 наряду с Oracle Enterprise Manager10g Application Control и Grid Control Release 2 добавляют усовершенствования в следующих категориях:Подготовка программного обеспечения к работе и его конфигурирование
В Oracle Application Server 10g Release 2 было добавлено много усовершенствований, делающих возможным более быструю подготовку к работе программного обеспечения. Эти усовершенствования включают:
Поддержка скользящих обновлений с более широкими комбинациями совместимости.
Централизованное управление системами
Oracle Enterprise Manager 10gApplication Server Control и Grid Control Release 2 обеспечивают полное управление экосистемой всего приложения, включаяOracle Application Server 10g. К числу новых ключевых возможностей относятся:
Полное управление Oracle Application Server Suite
Oracle Application Server Control 10g теперь управляет всеми службами набора: Web-кэшем, Identity Management, Discoverer, Forms, Reports и диспетчером процессов BPEL. С домашней страницы Oracle Application Server администраторы могут выполнять погружения в данные для выполнения стандартных административных действий, типа следующих:
Управление на базе топологии
Визуальное представление всей среды сервера приложений является необходимым для администраторов, чтобы понять отношения компонент. Для удовлетворения этому требованию Enterprise Manager использует Topology Viewer (средство просмотра топологии), доступное из Application Server Control 10g. Средство просмотра топологии предлагает два типа представлений:
Из средства просмотра топологии администратор может выполнить различные общие задачи, типа:
Мониторинг усовершенствований
В дополнение к родовому средству просмотра состояния Application Server Control 10g предлагает метрики сеанса, применяемые DMS в пределах экземпляра сервера приложений. Затем эти показатели могут быть подсуммированы (rolled up) в Grid Control и использованы для анализа статистических тенденций и прогнозирования, для анализа производительности в зависимости от времени, диагностирования прошедших проблем, по мере того, как они происходили, и создания отчетов о статистической производительности и доступности.
Инструментальные средства консоли Grid Control Application Service Level Management (ASLM), представляют существенный сдвиг в системной диагностике и контроле Web-приложений.
К числу других усовершенствований в Application Server Control и Grid Control относятся: применение байт-кода JVM, мониторинг и управление центральным портом и средство просмотра диагностических журналов.
Усовершенствованное управление высокой доступностью
Управление кластерами Oracle Application Server на основе файла: Application Server Control 10g может теперь управлять кластерами OracleAS, принадлежащими ферме OracleAS, на основе файла.
Резервное копирование и восстановление: Enterprise Manager упрощает и автоматизирует задачу резервного копирования и восстановления Oracle Application Server 10g. Используя Enterprise Manager, администратор может всего несколькими щелчками восстановить систему после того, как произошел сбой.
Управление конфигурацией: Enterprise Manager собирает конфигурационную информацию для всех назначенных хостов, так же, как и для их операционных систем, и информацию об установленном на всем предприятии администратора программном обеспечении Oracle. В Grid Control Release 2 консоль предлагает инструментальные средства для сравнения систем в рамках всего предприятия, позволяя администратору быстро и легко с большой точностью находить различия в ключевых системах. Это может помочь при определении, почему два экземпляра сервера приложений, которые администратор считает одинаковыми, работают по-разному, а также делает возможным превентивный контроль и обновление систем еще до того, как такие проблемы могут возникнуть.
Планируемые задания в группах: С помощью Grid Control администраторы могут организовать из распределенных экземпляров сервера приложений в сети единственный логический объект, который называется группой. Выполняя соответствие “многие к одному”, администратор может, к примеру, выполнить мониторинг фермы сервера приложений как один логический сервис.
Лучшие методы управление
С появлением Oracle Application Server 10g Release 2 административные операции для АБД и системных администраторов становятся даже более простыми, обеспечивая детализированный документированный набор лучших методов, решающих различные аспекты конфигурирования и администрирования систем. Эти лучшие методы могут быть разделены на три категории:
Сюда относятся: (i) консолидация системы – например, консолидация нескольких каталогов LDAP в единственный каталог LDAP; (ii) увеличение размеров системы путем добавления вычислительных мощностей – например, перенос серверов базы данных на новый хост; (iii) реконфигурирование сети – например, миграция сервера приложений из одной подсети в другую; (iv) перенос систем из одной среды в другую – например, миграция системы из промежуточной среды в промышленную среду; и (v) конфигурирование системы для обеспечения высокой доступности – например, создание автоматизированного средства восстановления в случае чрезвычайных ситуаций для серверов приложений.
Новая консоль управления J2EE
В Oracle Application Server 10gRelease 2 (10.1.3) появилась построенная со 100% соблюдением стандартов консоль управления, поддерживающая JMX. Эта новая консоль использует стандарты типа JMX, JSR77 и JSR88, чтобы обеспечить базирующиеся на стандартах возможности управления сервером приложений Oracle. Она выполняется в составе процесса самого Oracle Application Server – агент при этом не требуется. Консоль, помимо многих других новых возможностей, обеспечивает родовые возможности быстрого просмотра MBean, поддерживает приложение (определяемый пользователем MBeans), уведомления JMX и родовой редактор планов развертывания JSR-88.
Этот новый Application Server Control также обеспечивает комплексные возможности управления Web-сервисами, включая способность конфигурировать параметры настройки аудита, регистрации, надежности и управления защитой Web-сервисов.
WS-Security
Открытым стандартом защиты Web-сервисов является спецификация консорциума OASIS, называющаяся WS-Security. Эта спецификация предлагает три основных механизма защиты для обеспечения безопасности Web-сервисов: аутентификация сообщений, целостность сообщений и конфиденциальность сообщений. Поддержка WS-Security 1.0 состоит в следующем:
Бизнес-процессы и XML
Подготовлено: по материалам зарубежных сайтовПеревод:
Предлагаемый вниманию читателя материал завершает рассмотрение вопросов, поднятых в статьях "" и "". Напомним, речь шла о новом интеграционном подходе - корпоративной сервисной шине (ESB) - реализация которого неразрывно связана с концепцией сервис-ориентированной архитектуры (SOA). ESB - это слой промежуточного программного обеспечения, предназначенного для передачи данных между приложениями и системами через шинную архитектуру. Для описания систем и приложений на уровне бизнес-процессов разработано несколько спецификаций, особое место среди которых занимает язык BPEL4WS. Именно об этом языке и рассказывается в данной статье.
Язык BPEL: основные понятия
В самом общем виде BPEL можно определить как язык, предназначенный для определения поведения бизнес-процессов с помощью Web-сервисов.Действительно, с помощью языка WSDL можно осуществлять интеграцию в рамках лишь двух моделей - синхронного взаимодействия без сохранения состояния обмена и асинхронных взаимодействий с обменом некоррелированными сообщениями. Язык BPEL позволяет использовать Web-сервисы при последовательном одноранговом (peer-to-peer) обмене сообщениями - как синхронных, так и асинхронных, причем с сохранением состояния процесса, который может иметь большую продолжительность по времени и затрагивать более двух участников. В результате, эта спецификация значительно расширяет возможности использования Web-сервисов для интеграции систем, приложений, систем B2B.
Язык BPEL объединяет возможности языка WSFL (Web services flow language, Язык организации потоков Web-сервисов), разработанного компанией IBM, и языка XLANG, используемого в Microsoft BizTalk Server 2002. BPEL включает WSFL для поддержки графоориентированных процессов, а XLANG - для поддержки структурных конструкций для процессов. Таким образом, BPEL предназначен для поддержки реализации бизнес-процессов любой сложности, а также для описания интерфейсов бизнес-процессов. Надо отметить, что язык BPEL "неразрывно связан" со спецификациями WS-Coordination ("Координация Web-сервисов") и WS-Transaction ("Транзакции Web-сервисов"), которые были определены для совместного использования с BPEL и разработаны для координации транзакций и процессов. Так, в спецификации WS-Coordination описываются стандартные механизмы создания и регистрации протоколов транзакций, которые координируют выполнение распределенных операций в среде Web-сервисов. С помощью спецификации WS-Transaction можно отслеживать успех или неудачу каждого отдельного скоординированного действия в бизнес-процессе, задавать гибкую модель транзакций, которая обеспечивает целостность и надежность операций в распределенной среде Web-сервисов и позволяет бизнес-процессам обрабатывать сбои в ходе выполнения.
BPEL можно рассматривать как некий язык программирования, который "находится посередине" между декларативным и процедурным программированием. Как и в любом языке программирования, в BPEL определены зарезервированные слова, которые перечислены ниже:
Поскольку BPEL - это фактически диалект языка XML, скрипт BPEL можно создавать "вручную", либо, что, вероятно, более предпочтительно, воспользоваться одним из существующих программных инструментов для генерации скриптов.
Скрипт BPEL - это документ XML, который соответствует схеме BPEL. Он интерпретируется во время исполнения процессором BPEL, который выявляет ключевые слова и выполняет соответствующую обработку.
Приведенные выше команды BPEL также известны как процессы (activity). Возможны две разновидности описания процессов:
BPEL можно использовать для моделирования и абстрактного, и исполняемого процессов, т.е.либо для описания бизнес-процесса с целью моделирования или представления (абстрактный процесс), либо для создания исполняемого бизнес-процесса.
Наконец, корректная и полная реализация стандарта BPEL должна поддерживать следующий набор стандартов Web-сервисов:
Немного истории
В августе 2002 года, осознав сложность обращения к Web-сервисам в синхронной и асинхронной средах, корпорации BEA, IBM, Microsoft, SAP и Siebel в результате совместных усилий разработали язык реализации бизнес-процессов для Web-сервисов (Business Process Execution Language for Web Services, сокр. BPEL4WS или просто BPEL). В апреле 2003 на рассмотрение международной организации OASIS была передана спецификация следующей версии этого языка - BPEL4WS 1.1. В настоящий момент спецификация BPEL опубликована на сайте IBM и OASIS. Стоит отметить, что различия между редакциями 1.0 и 1.1 не носят принципиального характера.и сотрудники исследовательской компании Gartner,
Ряд аналитиков, в том числе и сотрудники исследовательской компании Gartner, полагают, что язык BPEL является явным лидером среди спецификаций в области управления Web-сервисами. Так, другие стандарты - как, например, BPML (Business Process Modeling Language, Язык моделирования бизнес-процессов), WSCI (Web Service Choreography Interface, Интерфейс взаимодействия Web-сервисов), XPDL (XML Process Definition Language, Язык описания процессов) и BTP (Business Transaction Protocol, Протокол бизнес-транзакций) - обладают техническими достоинствами, однако, не поддерживаются большинством поставщиков и не признаны авторитетными органами стандартизации. В связи с этим в Gartner считают, что в 2005 году окончательная редакция спецификации BPEL станет основным отраслевым стандартом для организации потоков Web-сервисов (с вероятностью 0.7).Архитектура и компоненты портала
При организации общих служб многие реализации порталов используют схожие архитектурные концепции, в том числе портлеты, платформы серверов порталов и интеграция портала с удаленными портлетами.Портлеты и контейнеры портлетов
Информационное наполнение часто предоставляется пользователям в форме так называемых портлетов — своеобразных контейнеров, которые, по существу, являются пользовательским представлением соответствующего им персонифицированного информационного наполнения. С технической же точки зрения, портлет — это фрагмент кода, который исполняется на сервере порталов и позволяет встраивать информационное наполнение в страницы портала.
В данной статье речь о портлетах и контейнерах портлетов ведется в терминах J2EE, поскольку данная платформа поддерживает и структуру портлетов, и взаимодействие портлетов со средой времени исполнения. Кроме того, большинство реализаций серверов порталов — это Web-приложения на базе J2EE.
J2EE — одна из самых известных серверных компонентных моделей. В J2EE серверные компоненты размещаются в специальных контейнерах. Контейнер представляет собой среду времени исполнения для серверного компонента; он вызывает компонент и предоставляет специфические для компонента службы (например, информация о пользователе и сохранение состояния объекта между сеансами).
Точно так же портлеты размещаются в контейнерах портлетов. API портлетов определяет интерфейс между портлетом и контейнером портлетов.
 | |
Рис. 2. Простой портлет. Здесь приведена реализация портлета, подготовленная для среды Apache Jetspeed |
На рис. 2 показана простая реализация портлета. Как и сервлет, портлет существует в единственном экземпляре, который создается один раз в контейнере портлетов, а затем может многократно использоваться в различных нитях управления. В состав API портлетов входят следующие элементы:
Портлеты существуют в нескольких режимах. Пользователи могут видеть представленное информационное наполнение, запускать службу помощи для конкретного представления или редактировать представление таким образом, чтобы настроить его в соответствии со своими предпочтениями, а администраторы могут конфигурировать портал для предоставления настроенных служб. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Кроме того, представление может находиться в одном из нескольких состояний, в том числе normal («нормальное»), maximized («максимизированное»), minimized («минимизированное»), closed («закрытое») и т.д. Как и дескрипторы размещения сервлетов, дескрипторы портлетов содержат свойства, существенные для размещения конкретного портлета.
В дополнение к контейнеру портлетов сервер порталов должен предоставлять службу получения информационного наполнения и службу сохранения состояния между сеансами, которые позволяют портлетам хранить информацию в специальном буфере. Однако самая важная служба портлета — это служба пользовательской информации, которая дает портлетам доступ к информации, касающейся пользователей, в том числе предпочтения, данные о настройке и т.д.
 |
Рис. 3. Строительные блоки сервера порталов. |
Удаленные портлеты
Порталы получают информацию и информационное наполнение из многих источников, в том числе из внутренних систем и от провайдеров приложений и информационного наполнения на базе Internet.
Чтобы интегрировать новый источник, владелец портал должен адаптировать информационное наполнение к формату, который воспринимается порталом, что может оказаться весьма длительным и трудоемким процессом.
Процесс интеграции можно упростить одним из двух способов. При первом подходе внешние провайдеры услуг поставляют информационное наполнение в формате, который непосредственно воспринимается клиппирующим портлетом (как правило, HTML или WML). Однако этот подход ограничивает возможности портала готовить информационное наполнение в соответствии с особенностями конкретного канала взаимодействия с пользователем. При втором подходе владелец портала устанавливает портлет на сервере порталов внешнего провайдера услуг. Затем портлет получает информационное наполнение в своем особом формате для вывода его как части общей страницы портала. Однако размещение кода независимого поставщика на сервере может оказаться небезопасным как с точки зрения стабильности, так и с точки зрения защиты информации. Например, портал для сотрудников может предоставить доступ к размещаемой в Internet информации о погоде и приложению управления кадрами в системе планирования ресурсов предприятия. Чтобы предоставить такой доступ, администратор запускает портлеты локально, как показано на рис. 4.
 |
Рис. 4. Портлеты работают на локальном сервере порталов. В этом случае кадровый портал предоставляет пользователям доступ к Internet-службе погоды и кадровым приложениям из внутренней ERP-системы |
Модуль исполнения портлетов обладает функциональностью, достаточной для того, чтобы дать возможность удаленному портлету реагировать на вызовы посредника портлета. Таким образом, посредник портлета не нуждается в таких службах, как объединение и настройка. Модуль исполнения портлетов может также быть реализован в другой технологии (например,.Net), если она поддерживает протокол удаленного вызова портлетов, поддерживаемый посредником портлета.
Чтобы обеспечить интероперабельность между различными серверами порталов и поставщиками информационного наполнения, необходима стандартизованная модель взаимодействий для посредника портлета и удаленного портлета. В настоящее время над стандартом на Web-службы для удаленных портлетов работает организация Organization for the Advancement of Structured Information Standards (OASIS).
Web-службы для удаленных порталов
Web-службы для удаленных порталов (Web services for remote portals, WSRP) представляют собой визуальные, настроенные на пользователя компоненты Web-служб, которые подключаются визуально, методом буксировки к порталам или другим промежуточным Web-приложениям, объединяющим информационное наполнение из различных источников. Поставщики информационного наполнения и приложений реализуют свою службу как Web-службу удаленного портала и публикуют ее в общедоступном каталоге (например, в реестре Universal Description, Discovery, and Integration). Этот каталог позволяет владельцам порталов легко находить необходимые службы. Элементы каталога, опубликованные в формате Web Services Description Languag, кратно описывают компонент WSRP и предоставляют детальную информацию о службах. Посредник портлета связывается с компонентом WSRP через SOAP, а протокол удаленного вызова портлета (remote portlet invocation, RPI) гарантирует корректное взаимодействие между обеими сторонами. На рис. 5 показан пример того, как портал находит и интегрирует удаленный портлет.
 |
Рис. 5. Размещение удаленных портлетов. Сервер портлетов находит удаленные портлеты путем поиска в реестре UDDI и вызывает портлеты, которые используют посредников портлетов |
Попытки стандартизации серверов порталов
Попытки стандартизации предпринимаются в двух важных областях: API-интерфейсы портлетов и Web-службы для удаленных порталов.API-интерфейсы портлетов
Эксперты Java Community Process работают над расширением стандарта J2EE с целью унифицировать свободно распространяемое программное обеспечение и коммерческие продукты различных производителей. Помимо унификации необходимо гарантировать, что API-интерфейсы портлетов будут основаны на открытых стандартах.
Эта спецификация будет состоять из самих портлетов, API-интерфейсов портлетов и формата дескриптора развертывания. Сегодня, однако, не существует открытой для публики предварительной спецификации; нет эталонной реализации.
Учитывая, что в работе этой группы участвуют разработчики Apache, их проект Jetspeed, вероятно, будет выбран в качестве эталонной реализации. Однако ряд производителей порталов, также принимающих участие в разработке спецификации, намерены опираться на стандарты, а не на свободно распространяемую реализацию.
Web-службы для удаленных порталов
Технический комитет организации Organization for the Advancement of Structured Information Standards сейчас разрабатывает стандарт на Web-службы для удаленных порталов. Данный стандарт, WSRP, позволит организовать взаимодействие ориентированных на пользователей Web-служб с порталами и другими Web-приложениями промежуточного слоя. Это также даст возможность реализовывать удаленные портлеты на любой платформе, будь то J2EE, .NET или некоторая служба, поддерживающая SOAP.
Службы и использование порталов
Типы порталов варьируются в зависимости от пользователей, которым они адресованы, и служб, которые они предлагают.Названные типы порталов предполагают различные сценарии работы, однако все они обладают некоторыми общими характеристиками. Технология сервера порталов, для которой пока не существует соответствующего стандарта (см. врезку ), предусматривает реализацию порталов с общим набором служб.
Самая распространенная операция - "клиппировать" (вырезать) информацию с существующих Web-сайтов, скопировав ее в формате HTML на портал. Портал для сотрудников, к примеру, может вырезать ее из внутрикорпоративной интранет-сети.
Технология сервера порталов
Кристиан Веже19.09.2002
Открытые системы, #09/2002
Разработчики сайтов все чаще сталкиваются с задачей интеграции существующего информационного наполнения с новой информацией и размещаемыми на сервере приложениями, а также с Web-службами. Постепенно даже самые нехитрые сайты становятся все более похожи на традиционные порталы, представляющие собой единую, интегрированную точку доступа к информации и приложениям и единую точку контакта с пользователями. Порталы объединяют различные каналы коммуникаций в одной точке, предоставляя развернутый контекст и общее представление всей информации.
Порталы, в основном, базируются на существующей технологии Web-приложений, такой как Web-серверы и Java 2 Platform Enterprise Edition (J2EE). В статье предлагается обзор типов порталов и их служб, а также более детальный анализ архитектур и компонентов, предназначенных для построения порталов.
 | |
Рис. 1. Страница с портала Yahoo. На ней содержится информация, ориентированная на конкретного пользователя и сформированная с помощью специальных компонентов настройки |
и потому фрагментарная область, но
Технология серверов порталов — еще довольно новая и потому фрагментарная область, но сейчас уже разрабатываются необходимые стандарты. Тем не менее, на рынке уже есть несколько достаточно зрелых продуктов, которые определяют состояние дел в этой области.Большинство современных серверов порталов базируются на Java. Компании Epicentric и Plumtree, пожалуй, первыми предложили серверы порталов как отдельные продукты. С приобретением компании TopTier корпорация SAP смогла присоединиться к ним имеющемуся в ее системе уровню интеграции приложений iViews. Корпорация IBM предлагает WebSphere Portal Server, который базируется на технологиях свободно распространяемой портальной платформы Jetspeed, реализованной в рамках проекта Apache. Со своей стороны, Apache принимает участие в разработке спецификаций для API портлетов в стандарте J2EE, благодаря чему Jetspeed стал серьезным кандидатом на роль эталонной реализации нового стандарта. Еще одна свободно распространяемая портальная платформа Zope реализована компанией Python. Помимо функций портала Zope предлагает некоторые возможности управления информационным наполнением и общие службы Web-приложений. (Этот список, конечно, не полон.)
В ближайшем будущем мы станем свидетелями стабилизации и более надежной интероперабельности между серверами порталов различных производителей по мере того, как они будут реализовывать ориентированные на порталы стандарты. Включение в состав спецификации J2EE интерфейса API портлетов также будет способствовать значительному расширению использования технологии портальных серверов, учитывая известность спецификации J2EE.Что касается других элементов спецификации J2EE, популярность свободно распространяемых реализаций будет расти, вынуждая к тому производителей, стремящихся сохранить свои конкурентные преимущества. В ближайшем будущем скорость внедрения технологии будет определять жизнеспособность рынка служб портлетов. Наконец, в перспективе, технология серверов порталов может распространяться на новые области. Представьте, к примеру, принтер, который предлагает свой пользовательский интерфейс управления как Web-службу удаленного портлета в рамках портала системного управления, обратиться к которому можно по телефону.
Крстиан Веже () — аспирант университета Тюбингена (Германия) и разработчик приложений корпорации DaimlerChrysler. К области его научных интересов относятся архитектура программного обеспечения и взаимозависимость между эволюцией программного обеспечения и эволюцией методологии.
Christian Wege, Portal Server Technology. IEEE Internet Computing, May-June 2002. All rights reserved, 2002, IEEE Computer Society. Translated and reprinted with permission.
Перспективы
Совершенно очевидно, что SOA "набирает обороты". По крайней мере, около года назад сотрудники Gartner уверенно заявили о том, что к 2008 году преобладающей практикой проектирования и разработки компьютерных программ станет сервис-ориентированная архитектура (с вероятностью 0,7). Таким образом, SOA положит конец господствовавшей последние 40 лет архитектуре монолитного программного обеспечения.Аналитики компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированно1 архитектуры, выяснили, что в 2004 году компании переходили от пилотных проектов к реальным внедрениям в рамках своих отделов. Так, целый ряд организаций из различных сегментов экономики, включая финансовые услуги, страхование, аэрокосмическую отрасль, здравоохранение, фармацевтику, розничную торговлю, государственный сектор и промышленность, "подняли" Web-сервисы до уровня SOA. В настоящий момент эти организации рассматривают возможность расширения рамок этих проектов - они собираются внедрить их не только на уровне различных отделов и подразделений, но и во всей компаний.
В ZapThink справедливо замечают, что до недавних пор реальную пользу - в денежном эквиваленте - от SOA в основном получали аналитики, журналисты и консультанты. Однако, сегодня появился рынок как для продуктов SOA, так и услуг по внедрению сервис-ориентированной архитектуры. Так, в ZapThink говорят об одной интересной тенденции - некоторым организациям, предоставляющим профессиональные услуги, удалось не только выйти на точку безубыточности, но заключить многомиллионные контракты. В этой связи аналитики полагают, что в 2005 году доходы таких организаций могут превысить - и даже весьма ощутимо - поступления всех поставщиков, предлагающих продукты, реализующие SOA.
Сотрудники ZapThink прогнозируют, что 2005 год станет "годом SOA". Причем количество перейдет в качество: увеличится число внедрений сервис-ориентированной архитектуры и, как следствие, развертывание SOA будет рассматриваться как стратегическая задача, а не как тактическое решение, рамки которого пока ограничиваются одним подразделением. Таким образом, SOA станет обязательным подходом для большинства крупных компаний, а не перспективным направлением для немногих дальновидных организаций.
Преимущества использования SOA
Прежде чем, перечислить преимущества использования SOA, будет уместным напомнить, что преимущества бывают разные: стратегические и тактические. SOA обладает рядом достоинств как стратегических, так и тактических.Стратегическая ценность SOA:
Известно, что реализация традиционных решений для интеграции прикладных программ - непростая задача, требующая существенных капиталовложений. Кроме того, часто при внедрение необходимо написание программного кода. SOA предусматривает размещение сервисов в сети в режиме исполнения, т.е. позволяет автоматизировать эти ресурсоемкие процессы, благодаря чему существенно сокращаются все расходы на интеграцию.
Тактические преимущества SOA:
Публикации
Сервис-ориентированная архитектура: основные понятия
Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией . Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных 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 (подробнее см. "").
Сервис-ориентированная архитектура
Подготовлено: по материалам зарубежных сайтовПеревод:
Сегодня наблюдается устойчивый рост интереса к концепции сервис-ориентированной архитектуры (service-oriented architecture, сокр. SOA). Свидетельство тому - оценки аналитических компаний и усилия крупных поставщиков программного обеспечения по продвижению этого подхода.
Значение SOA
По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники (information engineering), до появления концепции SOA при разработке систем в качестве отправного момента для программирования бизнес-логики использовались диаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программы тщательно тестировались, после чего внедрялись. Сегодня ситуация изменилась коренным образом: современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестировании. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами.По мнению Клива Финкельштейна, такая технология управления бизнес-процессами является большим шагом вперед с точки зрения повышения эффективности разработки систем; по значимости ее можно сравнить с созданием в конце 50-х годов компиляторов языка высокого уровня. Действительно, данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил. Кроме того, при изменении этих правил, корректируется соответствующая логика в диаграммах: диаграммы автоматически генерируются заново. Таким образом, закладываются предпосылки для перехода от медленного ручного кодирования, используемого сейчас при создании систем, к автоматизированному. Благодаря этому компании смогут реализовывать изменение бизнес-правил за минуты или часы, а не за месяцы или годы.
Axis и поддержка WSDL
На момент написания этой статьи Axis поддерживает только SOAP 1.1, хотя реализует в ограниченном виде GET. Используя его унифицированный локатор ресурса и указав параметр method и другие параметры, можно активизировать любой запрос.Предположим, например, что автор статьи реализовал по адресу (с унифицированным локатором ресурса) http://joker.psol.com/axis/order/Status.jws сервис, предназначенный для сообщения статуса заказа. У этого сервиса два метода - track и detailTrack, которые принимают номер заказа (number) в качестве параметра. Этот сервис может быть активизирован через http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322.
Язык WSDL 2.0 (разработкой которого в настоящий момент занимается консорциум W3C) добавляет атрибут pattern в определение операций. Этот атрибут указывает, какую модель SOAP MEP поддерживает сервис (WSDL вызывает модели MEP, поэтому между SOAP и WSDL нет путаницы). Пример сервиса отслеживания приведен в Листинге 1.
Беглый взгляд на модели ответа MEP
Новые возможности, появившиеся в SOAP 1.2, позволяют более тесно связать Web-сервисы и структуру Интернет. Так, одно из нововведений – это метод GET. Этот метод имеет огромное значение, поскольку с его помощью можно выполнять разнообразную оптимизацию. Значимость GET подтверждает сам Web – достаточно вспомнить, настолько широко в нем используется данный запрос. Эта статья посвящена методу GET.Одним из недостатков первой версии спецификации SOAP (SOAP 1.0) считалась ее зависимость от метода HTTP POST. Хотя в SOAP и использовался популярный протокол (HTTP), архитектура, на основании которой был построен протокол SOAP, вызвала достаточно нареканий.
Этот момент был учтен в новой редакции SOAP, которая была разработана под эгидой W3C. Консорциум вложил немало усилий в абстрагирование многих черт этого протокола, что должно упростить его применение среди различных технологий. В результате, в SOAP 1.2 появилась поддержка SMTP (помимо HTTP), в спецификации также улучшено использование HTTP.
Фрагмент WSDL
О методе GET
Чем же плох POST? Если попытаться объяснить в двух словах, то HTTP определяет различные методы для взаимодействия с сервером, основными из которых являются GET и POST. На практике GET используется для большинства запросов, тогда как POST предназначен для форм, которые обновляют сайт. Согласно спецификации HTTP, предназначение GET - извлечения информации, этот метод должен быть безопасным и идемпотентным.В данном контексте безопасный означает, что эта операция предназначены для извлечения, а не модификации информации. Другими словами, у запроса GET обычно не должно быть побочного действия. Идемпотентный означает, что несколько запросов к одному и тому же унифицированному локатору (URL) ресурса должны выдавать одинаковый результат. Приведенные определения менее строгие, чем они могут показаться. По существу, их смысл состоит в том, что если пользователь обращается по ссылке, он должен быть уверен, что с его точки зрения он не изменяет ресурс.
Рассмотрим, например, новостной сайт, информация на главной странице которого постоянно обновляется. И хотя второй запрос вернет изменившийся блок новостей, данная операция по-прежнему считается безопасной и идемпотентной, поскольку всегда предоставляет текущие новости.
В отношении запроса POST такое упрошенное рассмотрение будет некорректным. POST идентифицирует запросы, которые могут модифицировать ресурсы на сервере. В случае примера с новостным сайтом, комментарии читателя о статье должны быть реализованы с помощью запроса POST, поскольку сайт изменяется после их публикации (если, например, новое замечание располагается внизу статьи).
Различие между GET и POST не всегда столь жёсткое, а некоторые их аспекты довольно непрозрачны. Многие сайты инкапсулируют извлечение информации в запросе POST, возможно, из-за того, что разработчики считали, что такой подход более простой.
Несмотря на то, что это обсуждение методов HTTP может показаться излишне абстрактным и теоретизированным, это далеко не так. Обеспечение оптимальной производительности браузеров и промежуточного программного обеспечения (прокси, брандмауэров и решений по доставке контента а-ля Akamai) зависит от возможности различать запросы (см. ).
Объединение SOAP и GET
Первоначально SOAP поддерживал только запросы POST. Однако, Web-сервисы могут предоставлять услуги, которые безопасны согласно приведенному выше определению. Например, сервис, который запрашивает о выполнении заказа, является и безопасным, и идемпотентным. В соответствии со спецификацией HTTP, он мог бы быть реализован как запрос GET. А согласно спецификации SOAP 1.0, он должен быть POST.В спецификации SOAP 1.2 появились модели MEP (Message Exchange Patterns, модели обмена сообщениями) и новое связывание HTTP, комбинируя которые можно реализовать Web-сервисы, которые могут отвечать на запросы GET. Модели MEP регистрируют модели взаимодействия клиента и сервера. Модель SOAP Request-Response MEP (модель запрос-ответ SOAP) – это типичное взаимодействие Web-сервиса: клиент посылает запрос на сервер, а сервер отвечает.
В этой статье подробно рассматривается модель SOAP Response MEP (модель ответа SOAP). Эта модель определяет только ответ, без запроса. На практике, это означает, что отправленный запрос не является запросом SOAP – только ответ является сообщением SOAP. При комбинировании с этим новым связыванием HTTP модель Response MEP допускает запросы GET. Ниже описано, как работает эта модель:
Используя заголовок Accept, сервер отличает запросы SOAP от обычных запросов HTTP. Чтобы указать свои предпочтения, клиент может воспользоваться свойством q, задавая различный контент/тип в заголовке Accept.
В зависимости от своих задач клиент может включить параметры в унифицированный локатор ресурса, используя обычные методы кодирования унифицированного указателя ресурса (обычно после символа ?). Например, сервису, который сообщает статус группы серверов, возможно, и не требуются никакие параметры. По умолчанию он возвращает статус текущего сервера. И, наоборот, сервис, который сообщает о наличие продукта и его цене, должен принимать идентификатор продукта (или имя) в качестве параметра.
Разумеется, поскольку запрос не является частью SOAP, может возникнуть вопрос о том, каким образом клиент узнает, какой унифицированный локатор вызвать и какие параметры передавать. Ответ на этот вопрос прост: сервер SOAP должен делать то, что делают обычные Web-серверы, и включать этот унифицированный локатор ресурса в предыдущее взаимодействие SOAP. Ничто не мешает соединять и сочетать GET и POST.
В качестве примера представим себе, что сервис используется для обрабатывания заказов офисных принадлежностей (ручек, бумаги, ножниц и т.п.). Этот сервис принимает такой заказ с помощью SOAP; очевидно, что подобный запрос не может считаться ни безопасным, ни идемпотентным, поэтому он отправляется как POST. Ответ с сервера может включать унифицированный локатор ресурса, предназначенный для отслеживания выполнения этого заказа. Это отслеживание безопасно и идемпотентно, следовательно, его лучше реализовывать как GET.
Ресурсы
в основу Web, уже доказали
Простые принципы, положенные в основу Web, уже доказали свою масштабируемость и надежность. Поэтому можно только приветствовать то, что SOAP, один из главных стандартов, являющихся основой Web-сервисов, развивается в направлении, которое будет более тесно привязано к этой несомненно успешной архитектуре.Автор рекомендует читателям, ожидающим того момента, когда в их любимых инструментальных средствах появится поддержка SOAP 1.2 и WSDL 2.0, пересмотреть свои Web-сервисы и выявить безопасные операции, являющиеся основными кандидатами на переход к связыванию GET.
Ответ «традиционалистов»
По мнению специалистов из WSAWG, позиция оппонентов из лагеря REST не учитывает возможности более широкого взгляда на явления. Они считают, что использование Web-технологий является конкретной и частной реализацией Архитектуры, ориентированной на сервисы, и, следовательно, определенным ограничением на общую архитектуру SOA. Это ограничение заключается в том, что агенты SOA обращаются к объектам, которые в World Wide Web принято считать ресурсами, и которые идентифицируются при помощи URI. С другой стороны, Web-приложения в стиле REST строятся в предположении еще больших ограничений, которые заключаются в использовании унифицированной семантики и унифицированных средств манипулирования ресурсами. В WSAWG различают два типа сервисов.Иначе говоря, «прямые» сервисы используют известные Web-серверы для манипуляций с данными, а «посредничающие» сервисы исполняются средствами внешних кодов, которые вызываются сообщениями и с помощью Web-серверов. Однако оба класса могут идентифицировать ресурсы общими средствами URI, использовать протоколы Web и форматы XML для обмена сообщениями.
Пути развития прикладных протоколов
Количественное и качественное развитие всевозможных Internet-приложений формирует потребность в новых прикладных протоколах. В их совершенствовании видится три возможных пути.Традиционный подход к протоколам. Этот подход и соответствующая категория протоколов названы традиционными, потому что они появились раньше других и изначально были основаны на первичных протоколах Internet, а именно TCP и UDP. Недостаток этого подхода заключается в невозможности совместного использования ими инфраструктуры. Скажем, протокол RosettaNet существенно отличается от протокола ebXML а тот, в свою очередь, — от протокла Jabber. И хотя сейчас они сближаются поскольку стали использовать XML, реальная совместимость еще не достигнута. Опасность традиционного пути состоит в том, что при появлении новых требований всякий раз возникает потребность в создании новых протоколов.
Структурный, или рамочный подход. Структурный подход родился из понимания неизбежности постоянного обновления прикладных протоколов. Как следствие, возникла мысль о рамочной конструкции (framework). Пример такого протокола являют собой SOAP,WSDL, а также менее известные протоколы BEEP/BXXP (Block Extensible Exchange Protocol). Рамочная конструкция предполагает несколько общих характеристик: тип системы; язык описания сервисов; адресную модель; связь с транспортными протоколами нижних уровней (binding); решения по безопасности; разбиение сообщений на компоненты (framing).
По сравнению с традиционной, эта стратегия позволяет создавать общую инфраструктуру. К слабостям рамочного подхода можно отнести то, что по своей логике он продолжает технологии DCOM и CORBA. Не полностью решается проблема безопасности, маршрутизации и асинхронных двунаправленных коммуникаций. Кроме того, не оправдались первые надежды на XML как на средство, которое обеспечит совместимость приложений, как только будет выбрана основная группа стандартов, например, SOAP/WSDL/UDDI. Со временем стала очевидной необходимость в дополнительных протоколах.
Начали появляться WS-Security, WS-Routing, WS-Inspect и т.д. Неопределенность всей картины в целом сильно сдерживает широкое распространение Web-сервисов и стимулирует многих занимать выжидательную позицию в надежде на W3C и другие организации, которые обеспечили бы взаимодействие.
REST и горизонтальный подход. Стратегия, опирающаяся на горизонтальный подход к протоколам, наиболее радикальна. Слово «горизонтальный» означает в данном случае сохранение существующего уровня, без выстраивания уровней поверх него. Предполагается отказаться от разработки новых протоколов, а использовать несколько хорошо проверенных, считая, что для работы с объектами вполне достаточно уметь выполнять четыре типа действий: создание (Creation), восстановление (Retrieval), изменение (Update) и уничтожение (Destruction). Из этих действий получается так называемый «шаблон проектирования» CRUD. Протокол Hypertext Transfer Protocol определяет методы GET/PUT/POST/DELETE, которые и реализуют шаблон CRUD.
Апологеты REST относят сервисы, построенные в этом стиле, ко второму поколению. Остальные Web-сервисы они объявляют сервисами первого поколения, подчеркивая при этом, что SOAP есть ни что иное, как DCOM или CORBA, но работающие через Internet. Действительно, первоначально технологии, подобные SOAP, называли Web-брокерами или объектными брокерами, построенными в Web. Как указывает Прескод [3], используемая в них модель RPC предназначена для замкнутого мира, где вы знаете каждого пользователя, где данные можно перераспределять между ними, где возможны прямые коммуникации. Для успешной работы в Web необходимо поддерживать сложный механизм, обеспечивающий взаимодействие на случай внесения системных изменений.
Требования со стороны защитников REST-сервисов выглядят иногда слишком экстремистскими. Так, Марк Бэйкер считает, что:
Разумеется, никто и никогда не выполнит подобные ультимативные условия, и потому подобная агрессивная тактика только мешает восприятию рациональных решений, существующих в REST-сервисах.
REST + SOAP
Если обратиться к истории, то надо вспомнить, что на уровне языка ассемблера данные, и программы адресовались одинаково. Но уже тогда возникла проблема: как построить вызов к подпрограмме — подкомпилировать ее в тело кода, выполнив специальную макрокоманду, или же использовать вызов с передачей параметров. Сегодня стоит по сути дела та же самая проблема, но на другом уровне. В 70-е годы появилось структурное программирование, был предан анафеме оператор безусловного перехода goto, точнее обозначилось деление на данные и программы. В дальнейшем развитие оборудования хранения данных привело к созданию реляционных СУБД и языка SQL. Для работы с данными оказалось достаточным операторов insert, select, update и delete. В 90-е годы сети стали соединяться Internet-протоколами, подпрограммы с параметрами трансформировались в объекты с сообщениями, а хранимые процедуры стали нормой для операций, модифицирующих реляционные СУБД.Конфликт «REST vs. SOAP» стоит рассматривать как диалектическое противоречие. Так или иначе оно будет разрешено, позволив более четко представить соотношение между кодами и данными на уровне архитектур SOA откроет путь к более продуктивному использованию Web-сервисов.
Литература
Рой Филдинг и архитектурный стиль REST
Собственное видение проблем программного обеспечения Сети Филдинг описал в докторской диссертации «Архитектурные стили и проектирование архитектур сетевого программного обеспечение» [1]. Работа представляет собой не только фундаментальное исследование на означенную тему, но одновременно и прекрасный учебник.В настоящее время Филдинг работает в должности научного руководителя компании Day Software, но миру профессионалов он гораздо лучше известен своими прежними достижениями и общественной деятельностью. Стоит вспомнить участие в разработке инфраструктуры World Wide Web, где именно он был главным архитектором Hypertext Transfer Protocol (HTTP/1.1), а также соавтором стандартов для HTTP и URI. Кроме того, Филдинг был в числе инициаторов нескольких проектов известных программных систем с открытым кодом (один из них — проект Apache HTTP Server, который, как признано, является основой более 60% Internet-сайтов). В сферу научных интересов Филдинга входят также архитектура программного обеспечения для сетевых приложений, сетевые протоколы прикладного уровня, средства совместной разработки программного обеспечения. За свои научные успехи, в частности, за проект Apache, в 1999 году он был удостоен ACM Software System Award. В том же году Филдинг был включен в почетный список Top100 молодых исследователей, который составляется журналом MIT Technology Review.
Стиль REST методично раскрыт в диссертации Филдинга, первые четыре главы которой посвящены определению понятия «архитектурный стиль» вообще и принципам построения сетевого программного обеспечения. В пятой главе изложены начала REST. В более сжатом виде идеи стиля REST изложены в [2]; прочтение этой статьи можно считать обязательным для того, кто хочет понять, что такое WWW и REST. В данном случае вполне можно ограничиться самым грубым приближением и сказать, что REST задуман как основа масштабируемого прикладного протокола, обеспечивающего доступ к информационным ресурсам. Подчеркнем, именно к ресурсам. Противопоставление REST остальному миру сервисов можно, в какой-то мере, сравнить с противопоставлением процессорной архитектуры RISC архитектуре CISC. В обоих случаях используется ограниченный набор операций; в случае доступа к ресурсам в стиле REST их всего четыре: GET, PUT, POST и DELETE. Этих четырех операций оказывается достаточно для оптимальных манипуляций с сетевыми ресурсами; главное, что они позволяют, — отделить размещение ресурсов на сервере от восприятия этой информации клиентом и потоковую передачу информации. Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC).
SOAP и REST, вместе или порознь?
18.09.2003На протяжении последних двух лет в среде разработчиков стандартов для Web-сервисов развернулась активная дискуссия на тему: «SOAP против REST». С этими двумя аббревиатурами ассоциируются два почти диаметрально противоположных подхода к организации Web-сервисов. SOAP (Simple Object Access Protocol) — хорошо известный нижний уровень в стеке протоколов. REST (Representational State Transfer) — менее известное явление, называемое его авторами «архитектурным стилем». В творческом споре против основной массы сторонников SOAP выступает небольшая, никак формально не организованная, группа инакомыслящих, которые поддерживают REST. Скорее всего, победителя в этом противостоянии не будет; как обычно бывает, большинство учтет мнение меньшинства, и вместо противопоставляющего лозунга «SOAP против REST» появится конструктивный «SOAP + REST».
Утверждение, что будущее — за сетевыми архитектурами, превратилось в банальность, сейчас только и разговоров, что Grid да SOA (Service-Oriented Architecture). Но, как говорят англичане, «ободрать кошку можно по-разному», какими именно станут в будущем сетевые архитектуры, сказать сложно, однако наступила пора выбора. Есть взгляды, которых придерживается большинство; их разделяют и крупные компании. Но есть и мнения оппонирующих им «диссидентов».
Во всех нынешних начинаниях, связанных с сетями, так или иначе, присутствует World Wide Web. Первопроходец Всемирной паутины Тим Бернерс-Ли дал своему детищу гениальное по лаконичности определение: «Web — это просто пространство (буквально, «вселенная», universe — Л.Ч.) глобальной информации с сетевым доступом». Идеи, которые заложила возглавляемая им группа энтузиастов из CERN в фундамент архитектуры Web, были настолько продуктивными, что спустя несколько лет оказались востребованными в компьютерной индустрии.
На наших глазах почти в точности повторяется история заимствования корпоративными intranet-сетями технологий из Internet, которая имела место лет пять-семь назад. Однако есть и отличия, вполне очевидно, что архитектура WWW осмыслена адаптаторами в гораздо меньшей мере, чем в свое время архитектура Internet.
В той трактовке Web, которая получила распространение и усиленно эксплуатируется (особенно, когда речь идет о Web-сервисах), все сводится к представлению Web исключительно в качестве коммуникационной среды, что явно противоречит приведенному определению. Web-cервисы, построенные на основе протокола SOAP, не используют возможности Web в полной мере — в том числе, и возможности механизма адресации информационных ресурсов, основанного на универсальных идентификаторах ресурсов (URI).
Не удивительно, что в академической среде и в близком к ней инженерном сообществе, глубже понимающем идеи WWW, возникло альтернативное направление, которое, по мнению его приверженцев, полноценно, по-настоящему использует это великолепное изобретение. Такие альтернативные сервисы называют сервисами на основе REST.
За фасадом победного шествия архитектур, ориентированных на сервисы, и Web-сервисов, вне сферы внимания коммерческой прессы идет невидимое миру противоборство приверженцев различных точек зрения на устройство Web-сервисов. С одной стороны выступает вся индустрия, возглавляемая такими могучими компаниями, как IBM, Microsoft, Sun Microsystems, которые продвигают идеи Web-сервисов на основе «святой троицы» протоколов SOAP/WSDL/UDDI, с другой — крошечная группа энтузиастов идеологии Web в чистом виде. И это не просто борьба технических идей, а скорее отчаянное сопротивление «пуристов», сопротивление, как им кажется, искажению и коммерциализации принципов Всемирной паутины. Острие их нападок направлено на группы Technical Architecture Group (TAG) и особенно Web Services Architecture Working Group (WSAWG), которые действуют в составе основного координирующего органа Web, консорциума W3C. По их мнению, наиболее полно выраженному Марком Бэйкером, в конце 2004 года коммерческие подходы к Web-сервисам ожидает серьезный кризис. В TAG, напротив, считают проповедуемые альтернативные сервисы на основе архитектурного стиля REST частным случаем использования HTTP и не видят за ними серьезного будущего.Наиболее выдержанные специалисты, например, Дэвид Орчард (David Orchard), директор по технологиям компании BEA Systems, являются выразителями более умеренных взглядов.
Консолидированная точка зрения большинства на Web-сервисы представлена в статье «SOA — шаг за горизонт», публикуемой в этом номере журнала. Но двумя лицами дело не ограничивается; может быть и третье, и четвертое. В этой же статье представлена точка зрения меньшинства; знакомство с ней будет полезно хотя бы потому, что позволит лучше понять, почему название «Web-сервисы» используется в основном не вполне корректно. Название неудачное: троица протоколов не имеет по сути своей никакого отношения к Web, кроме использования механизма адресации. Однако название уже прижилось, как говорится, «термин занят». В данной статье, чтобы различить два подхода, будем временно использовать термин «SOAP-сервисы» для обозначения сервисов, построенных на основе SOAP/WSDL/UDDI, и «REST-сервисы» для альтернативного подхода.
Постановка проблемы
Существовавшая до 2002 года практика разработки программ для доступа к информации в Управлении информационного обеспечения ФГУП "Воткинский завод" предусматривала прямое чтение программами информации из таблиц баз данных. Недостатками такого подхода являются:необходимость детального знания разработчиками аналитических программ всех, читаемых разрабатываемыми программами, таблиц;
практическая невозможность реорганизации структур хранения данных из-за наличия гигантского количества, подлежащих в этих случаях корректировке, ранее разработанных аналитических программ.
Решение проблемы
Попыткой как выхода из создавшейся ситуации, так и способом заложить фундамент для будущего развития Информационной системы предприятия является совокупность прорабатываемых в настоящее время специалистами Управления т.н. Web-сервисов, перекрывающих основные структуры хранения данных.Предполагается, что именно Web-сервисы станут той информационной инфраструктурой, которая как позволит с незначительными издержками перерабатывать имеющиеся структуры хранения данных без изменения эксплуатирующихся программ, так и избавит предметных программистов от необходимости в получении исчерпывающих знаний о структуре хранимых данных.
Решено считать, что, с учётом присутствующих тенденций развития информационных технологий, для ситуации наличия значительного количества независимых баз данных, путь создания и развития Web-сервисов является более предпочтительным, чем, широко описанный в литературе и ныне считаемый традиционным, путь перехода к централизованным базам данных. Планируемый состав основных Web-сервисов приведён на Рис.1. Состав некоторых других предполагаемых Web-сервисов приведён на Рис.2. Пунктирными линиями выделены предполагаемые к созданию Web-сервисы и базы данных.
Рис.1. Предполагаемый состав основных Web-сервисов
Предполагается, что каждый из Web-сервисов будет иметь две группы методов. Первая группа методов будет сообщать о факте наличия/отсутствия информации о конкретной детали или сборочной единице (ДСЕ) и, при наличии информации, возвращать структуру, содержащую имеющуюся информацию о ДСЕ. Вторая группа методов должна сообщать о перечне ДСЕ, информацию о которых можно предоставить. Эта группа методов содержит методы: сообщения количества ДСЕ, соответствующих критерию; выдачи перечня возможных символов, следующих в обозначении ДСЕ за некоторой переданной строкой; и непосредственно выдачи перечня ДСЕ в количестве, не превышающем указанного.
Рис.2. Web-сервисы, относящиеся к материальному планированию
Веб-сервисы как вариант основы информационной инфраструктуры предприятия
, ,ФГУП Воткинский завод,, Ижевский Государственный Технический Университет
у разработчиков аналитических программ не
Ожидается, что при использовании Web-сервисов предлагаемой структуры у разработчиков аналитических программ не будет необходимости в непосредственном обращении к таблицам баз данных, что повысит степень независимости разрабатываемых программ от структуры хранящихся данных и снизит требования к уровню знаний предметной области разработчиками. Другим ожидаемым положительным моментом будет являться возможность неограниченной переработки структур хранения данных при контролируемом уровне доработки Web-сервисов.Business Process Execution Language
В предыдущих статьях я рассматривал Web-сервисы, как одиночные Web-сервисы. Я показал, как создать Web-сервисы, используя JAX-RPC – интерфейс прикладного программирования (API) в среде J2EE (J2EE Web services API), и привел примеры того, как некоторое решение из управления Web-сервисов может естественным образом работать с этими Web-сервисами. Понятно, что для бизнеса полезны даже отдельные Web-сервисы, но настоящую ценность для большинства представляет возможность интеграции множества Web-сервисов в более крупные приложения, часто называемые композитными приложениями или бизнес-процессами.В следующих статьях я рассмотрю соединение нескольких Web-сервисов в бизнес-процесс. Я буду использовать стандарт, называемый Business Process Execution Language (BPEL). BPEL – это стандарт на основе XML, который Oracle, BEA, IBM, Microsoft и другие поставщики интенсивно разрабатывают как механизм для "оркестрирования" "сквозных" (end-to-end) бизнес-процессов, построенных на базе Web-сервисов. Хотя этот стандарт все еще находится в процессе разработки в комитете OASIS, его спецификация уже достаточно продвинута и появились продукты, поддерживающие ее, от ряда поставщиков, включая Oracle.
Почему BPEL?
Часто первая реакция разработчиков, услышавших о BPEL, такова: "Зачем мне нужен этот стандарт для решения задачи, которую можно сделать обычным программированием?" Разумеется, ничто не принуждает разработчика использовать BPEL. Он может создать простенький бизнес-процесс, который сначала вызывает один Web-сервис, затем принимает его результат и вызывает другой Web-сервис. Но проблема становится намного более интригующей, когда вы попытаетесь разобраться с анатомией типичного долгоживущего бизнес-процесса. Сразу встает ряд непростых вопросов:Этот список можно продолжить. И, что интересно, не только разработчики (на индивидуальном уровне) много раз пытались решить эти проблемы ранее, для этого предлагалось множество "частных" процессных механизмов, которые в той или иной степени решали эти проблемы. Но неизбежно каждый из них решал их по-своему и каждый из них вынуждал организации привязываться к конкретным поставщикам и нестандартным языкам программирования.
BPEL предназначен для решения и этой проблемы. При его развитии учитывается не только история процессных языков и исследований по механизмам широкого круга компаний, но и происходит разрыв с прошлым, благодаря применению фундамента из стандартов Web-сервисов. C этим фундаментом на основе переносимости, прагматизма предыдущих попыток и академического происхождения многие, включая Oracle, полагают, что BPEL будет основой реализаций сервисно-ориентированной архитектуры.
Пример "Заем [денег]"
Давайте разберем детали на примере. Я постараюсь на простеньком бизнес-процессе показать, как определяется процентная ставка (interest rate) возможного заемщика (loan customer), когда услуги по заемам нескольких банков запрашиваются в соответствии с требованиями его заема.На рисунке 1 представлены первые шаги, необходимые для составления процесса получения заема (loan process). Я сначала проведу вас по схеме процесса (process flow), особо обращая внимание на некоторые ключевые конструкции языка BPEL, а затем рассмотрим фрагменты кода реального процессного языка. (Рассматриваемый пример скачан с OTN.) При изучении течения процесса акцент будет сделан на синтаксисе процессного языка, взаимодействию процесса с конечным пользователем будет уделено меньше внимания.
Рисунок 1: Начальные шаги для получения заема
Первое, запрос для оценки заявки на заем (loan assessment) – это вызов Web-сервиса, полученый через действие . Далее, данные о клиенте выбираются и приводятся к формату, совместимому с сервисом каждого банка, через действие. Сервисы The United Loan Service и the American Loan Service вызываются параллельно из действия , содержащего два действия . По завершению оценки, сервис каждого банка возвращает управление бизнес-процессу получения заема со своей оценкой. Этот входящий (inbound) запрос представлен действием .
Далее, эти результаты сравниваются друг с другом, чтобы определить наилучшую ставку, благодаря использованию действий и , аналогичных конструкции if-then-else в языках программирования. В рамках действия выбирается наилучшая ставка и ее значение присваивается переменной для возврата , благодаря использованию действия . Наконец, результат обоих этих вызовов посылается обратно источнику вызова, благодаря другому действию .
Рассмотрим детали реализации
Процесс, определенный в BPEL, как правило, состоит из двух больших секций: секции деклараций и секции процессных действий, окруженных внешним элементом, который называется и идентифицирует имя/название процесса.
Глобальные декларации. Как правило, первая секция процесса содержит глобальные декларации, в том числе те, которые определяют используемые Web-сервисы и называются , а также те, которые определяют используемые переменные и называются .
На приведены листинги деклараций United Loan и American Loan, а также декларации , ожидаемые этими Web-сервисами. Эти конструкции создаются в Oracle BPEL Designer в начале этапа проектирования до того, как сам процесс написан.
Другие высокоуровневые конструкции, такие, как обработчики глобальных ошибок (global error handlers), называемые , обработчики ошибок глобальных транзакций (global transaction failure handlers), называемые , также декларируются в этой первой секции.
Определение процесса. Вторая часть BPEL-процесса содержит логику процесса — шаги, которые будут предприняты, и Web-сервисы, которые будут использованы для выполнения полезной работы. Попросту говоря, есть два типа действий:
На приведен код, обеспечивающий вызов the United Loan Service и American Loan Service. Для вызова каждого банка и включены в некоторую последовательность (sequence), тем самым вынуждая их исполняться один за другим. Но оба действия сами включены в действие , тем самым вынуждая обе подпоследовательности для каждого сервиса (бизнес-процесса получения заема) исполняться параллельно.
Соединяя Web-сервисы (Weaving Web Services Together)
(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE.Источник: журнал "Oracle Magazine", no.4, 2004,
http://www.oracle.com/technology/oramag/oracle/04-jul/o44dev_web.html
Перевод:
Не нужно много времени для
Не нужно много времени для уяснения эффективности стандартизованного способа создания бизнес-процессов на базе Web-сервисов. И не только потому, что основную процессную функциональность можно немедленно использовать в любой сервисно-ориентированной архитектуре, но и потому, что она построена на базе стандартов, которые получили беспрецедентное признание в отрасли.Эта ситуация аналогична ситуациям с SQL и J2EE — стандартами, которые, будучи приняты отраслью, создала целые рынки для серверов, инструментальных средств и услуг. Поставщики технологий отныне не пытались решать базисные проблемы доступа к данным и построения бизнес-логики; вместо этого они сосредоточились на новаторских решениях на базе этих стандартов.
BPEL находится в такой же ситуации раскрытия тех же самых возможностей для интеграции бизнес-процессов. В следующих статьях будут рассмотрены построение, управление и выполнение BPEL-процессов.
Следующие шаги:
Узнайте больше о BPEL
СКАЧАЙТЕ примеры к этой статье
Web-сервисы == или != распределенные объекты?
Дэвид Орчард (David Orchard)Оригинал
Перевод:
За последние несколько лет тема Web-а, Web-сервисов и распределенных объектов не раз приковывала внимание автора этой статьи: я провел немало времени, размышляя о том, чем они отличаются друг от друга и что необходимо для их успешного применения. На этот счет высказываются самые разные соображения, включая, на мой взгляд, откровенную рекламную чушь: «Web-сервисы – это то, что надо, потому что это нечто новое и совершенное. Для вас они могут даже окраситься в красный цвет!»
Однако, чем же на самом деле отличаются друг от друга Web, Web-сервисы и распределенные объекты? В чем состоят конкретные архитектурные различия? Задавая этот вопрос, я не хотел бы услышать двусмысленный ответ в духе: «Web-сервисы – это крупно структурированные объекты, а распределенные объекты – мелко структурированные».
По моему мнению, одно из различий между Web-ом, Web-сервисами, с одной стороны, и распределенными объектами, с другой, состоит в том, что первые позволяют человеку читать и понимать передаваемый формат данных (HTML, XML,..), объектные ссылки (URIs), протокольные сообщения и описание[1]. Хотя, возможно, язык WSDL далеко не самый удобочитаемый. Распределенные объекты же позволяют читать и понимать описание (IDL – язык описания интерфейса), а формат передачи, объектные ссылки и протокольные сообщения делают бинарным. Так что, возможно, этого вполне достаточно. Хотя существует множество других различий, например, позднее связывание (late binding of the information content to the user), возможность получения высокой производительности благодаря использованию протокола HTTP и URI для установления эквивалентности и т.п.
Вместе с тем, на мой взгляд, существует еще один важный и незатронутый ранее аспект: расширяемость. Если сравнивать Web с распределенными объектами, необходимо отметить, что механизмы вызовов весьма различены. В случае распределенных объектов можно написать что-нибудь вроде: public interface PO { getMyPo( in int poId, out PO purchaseOrder); }
тогда как HTTP мог бы быть смоделирован следующим образом: public interface HTTP { get (in URI address, out MIME body ); }
Давайте очень кратко остановимся на «HTML-ой версии» этого примера, поскольку именно с HTML связано большинство вызовов. Поэтому немного изменим интерфейс: public interface HTTP { get (in URI address, out HTML body ); }
У каждого из этих интерфейсов имеется две весьма различные конфигурации. Интерфейс PO может быть расширен новыми и произвольными методами - как и класс PO. Они оба произвольно расширяемые – то есть определяются интерфейсом – в отличие от обобщенных или унифицированных. HTTP, SQL и т.п. называются унифицированными, поскольку разработчик приложения не может изменять методы. Чтобы расширить команды HTTP, потребуется выполнить колоссальную работу, поскольку в этом процессе оказываются задействованными стандарты. Сказанное справедливо и в отношении официального HTML.
Поэтому может показаться, что благодаря произвольной расширяемости интерфейса в стиле dist-obj (распределенные объекты), эта конфигурация должна была бы иметь огромный успех. Однако существует нечто чрезвычайно важное, что не выражается в этом интерфейсе. Возможно, именно поэтому в выигрыше оказываются системы, которые основываются на соглашениях, а не на интерфейсах прикладного программирования (API). Хотя интерфейс HTTP и ограничен определенным набором команд, содержимое может быть расширено. В него можно поместить XML, MIME
Возвращаясь к HTML, стоит отметить, что в спецификации присутствует важная часть информации. Это – правило "Необходимо пропускать" ("Must Ignore"). Другими словами, и для HTML, и для заголовков HTTP, и даже для значительной части спецификации URI существует правило, согласно которому любое неизвестное должно быть пропущено. Если какое-либо содержимое появляется в произвольном месте, и получатель об этом не знает, его можно проверить на допустимость, как если бы это неизвестное содержание было бы «выброшено» из экземпляра. Хотя данное правило указано в спецификации HTML, оно не выражено в схеме/dtd.
По мнению автора, если бы HTML не имел возможности выразить правило "Необходимо пропускать" вне схемы, HTML, вероятно, не допускал бы столь широкую расширяемость.
В результате, стало возможным развитие HTML, которое, однако, не повлияло на интерфейс прикладного программирования HTTP, поскольку они ортогональны. Эти форматы и команды развиваются отдельно друг от друга.
Системы распределенных объектов навязали решение о том, что для расширения любого вида необходимо, чтобы обе стороны понимали расширенный интерфейс. Это – ошибка «единственного администратора». На устранение недостатков систем распределенных объектов была потрачена масса усилий, и, по убеждению автора, отсутствие «локальной» расширяемости ("touchless" extensibility) явилось основной причиной недостаточного понимания и успеха Web-а.
Давайте представим, что для распределенных объектов и Web-а применяются обратные правила. Тогда в случае систем распределенных объектов можно было бы поместить в класс PO желаемое содержание любого вида и, если оно неизвестно получателю, он просто пропустил бы его. В результате, системы распределенных объектов оказались бы гораздо более эластичными. И содержали бы меньше интерфейсов с астрономическим числом различных методов. По мнению автора, технология распределенных объектов была бы более притягательный, если бы для поддержания расширяемости параметров, и возможно даже расширяемости методов, не требовалось бы синхронного изменения обеих сторон.
Сейчас сложно представить, что HTML развивался бы столь быстро и успешно, не будь правило "Необходимо пропускать" встроенным, и поэтому HTML и не смог развиться вне рамок комитета по стандартизации. Изображения, формы, каскадные таблицы стилей и т.п. были разработаны после появления первой версии HTML.
А что с Web-сервисами? Похоже, что большинство разработчиков Web-сервисов при проектировании своих интерфейсов принимают такое же решение, как и в случае распределенных объектов. Они заново создают метод распределенного объекта "getPO" в сообщении SOAP, не допуская расширяемость в PO.
Всякий раз, когда им необходимо расширить PO, они вынуждены расширять схему и выпускать новую версию. Хотя они могли бы расширить PO, используя механизм расширяемости XML-схемы.
XML-схема навязала решение, что любые расширения, которые необходимо проверить на допустимость, должны потребовать корректировки схемы на обеих сторонах. Более того, все понятия, согласующиеся с расширяемостью, выражаются на языке схемы. Это чрезвычайно близко к решениям распределяемых объектов.
Однако, эти решения не совсем такие. Так, XML-схема предоставляет элемент wildcard, который делает возможным присутствие в экземпляре элементов ограниченных пространств имен. Если схема PO обеспечивает групповые символы, разработчики PO могут воспользоваться групповыми символами для расширяемости. Они не получат произвольную расширяемость, присущую HTML – по мнению автора, это весьма проблематично. Существует общая модель, допускающая элементы из пространств имен, отличных от целевого пространства имен. Это обеспечивает по крайней мере какую-то расширяемость, хотя эта модель не исключает некоторых сложностей, которые детально рассмотрены в статье Examining wildcards for versioning. В статье Versioning XML Languages (Управление версиями XML-словарей), опубликованной на xml.com, показано, как их можно использовать для получения «локальной» расширяемости с полной проверкой допустимости; отмечу, однако, что в этом случае разработчик должен по-прежнему активно определять точки расширения.
Существует еще одно существенное различие между технологией расширяемости Web-а и XML-схемы - отличие активной спецификации расширяемости от пассивной. Так, XML-схема требует от разработчика активно вставлять что-нибудь в документ схемы, чтобы предугадать, где нужно обеспечить расширяемость для локального изменения, а большинство технологии Web уже располагает расширяемостью, по умолчанию пассивно встроенной в систему. Что, возможно, оказалось бы идеальным решением, если бы нам удалось добиться пассивного объединения правила "Must Ignore" c логикой проверки на допустимость.
В этом случае мы могли добавить всю функциональность это правила в инфраструктуру, и не требовать, чтобы каждый формат данных и соответствующий код определял, где пропускаемые элементы допустимы, а где нет. И с учетом «уроков HTML» механизм определения правила "Must Ignore", возможно, следует выражать вне языка схемы.
Однако, высказывается мнение, что отсутствие команд с ограничениями (это мнение так называемых «рестафарианов» [RESTafarian]) свидетельствует о «недолгом веке» Web-сервисов. Автор полагает, что хотя сложность в обеспечении «локальной» расширяемости ухудшает возможность развертывания вободно связанных приложений, имеется достаточно способов, с помощью которых можно построить свободно связанные Web-сервисы. Но для этого потребуется явные действия от разработчика интерфейса. Именно поэтому, на мой взгляд, должна появиться более легкая модель, предназначенная для создания и проверки допустимости расширяемых XML-языков.
Имеется в виду язык WSDL (Web Services Description Language - язык описания Web сервисов) [прим. перев.]
Использование новой инфраструктуры в Oracle Application Server
В номере Oracle Magazine за май/июнь 2004 года опубликована моя статья "Управление web-сервисами" ("Managing Web Services"), в которой я представил несколько концепций, применяемых в зарождающейся области управления Web-сервисами, включая такие классические, как мониторинг, аудит и безопасность, а также более специфические для Web-сервисов, такие как обеспечение (provisioning), виртуализация (virtualization) и маршрутизация (routing). Я также указал, что в основе управления Web-сервисами лежат модель передачи сообщений протокола Simple Object Access Protocol (SOAP) и публичный контракт Web Services Description Language (WSDL), описывающий ее расширения.В этой статье я представлю новые возможности управления Web-сервисами в Oracle Application Server 10g Release 10.1.3. В отличие от моего первого "программистского" вхождения в эту область, когда я написал несколько обработчиков (handlers) для интерфейса JAX-RPC, чтобы реализовать простейшие функции управления, на этот раз я воспользуюсь тем, что предоставляет сервер приложений, и, как разработчик, я смогу сфокусироваться на бизнес-функциях, а не на ручном кодировании поддерживающей инфраструктуры.
Я продолжу использовать мой пример Web-сервиса для предметной области "Кадры" (human recources), HRService - с операцией getEmpSalary - как базовый пример, и в этой статье подробно рассмотю специфические аспекты возможностей управления Web-сервисами, включая аудит, журнализацию, надежность и безопасность.
Конфигурирование политик
Политики для Web-сервисов устанавливаются в иерархии, соответствующей структуре WSDL. Сервисы, как правило, содержат один или несколько портов, которые содержат связи (bindings) к одной или более операциям. Чтобы соответствовать такой структуре, политики управления могут быть установлены на уровне порта или операции.Чтобы получить представление об этих политиках, давайте изучим a snippet файла wsmgmt.xml для Web-сервиса "Кадры": 1
Прежде всего, заметим на строке 5, что политики могут быть включены (enabled) или выключены (disabled). В этом примере политики безопасности и аудита включены, в тоже время политика надежности, заданная в строках 15-22 отключена только тем, что она не упомянута как атрибут, включенный для этапа выполнения.
Далее, в строках 6-14 устанавливается политика безопасности для всех операций порта EmpInterfacePort сервиса HRService — политика, которая требует, чтобы для каждой операции был заданы provided with a username and password authentication token.
И наконец, в строках 26-28 приведен пример политики на уровне операции для аудита, showing that requests and faults are audited on the getEmpSalary operation but responses are not. Политики безопасности также могут установлены на уровне операции.
Понимание "движущихся частей"
Чтобы понять как использовать эти возможности, я прежде всего должен дать обзор "движущихся частей" (moving parts) в среде управления Release 10.1.3. Рисунок 2 показывает три основных компонента этого продукта, которые и составляют решение: компонент этапа проектирования (the design time) с Oracle JDeveloper, компонент этапа выполнения (the runtime) с Release 10.1.3 и среда управления с Oracle Application Server Control.
Рисунок 2: Конфигурирование управления в перспективе
Обратите внимание, что на этом рисунке между консолями компонент этапов проектирования и выполнения находится файл wsmgmt.xml. Это файл конфигурирования политик к Web-сервисам (Web services policy configuration file) для Oracle Application Server, позволяющий администраторам-пользователям Application Server Control устанавливать политики аудита, журнализации, надежности и безопасности.
Способ, характерный для разработчика, конфигурирования этого файла политик заключается в декларировании политик управления в файле oracle-webservices .xml. Этот файл oracle-webservices.xml является специфичным для сервера приложений соединением (binding) к инфраструктуре Oracle. Этот файл дополняется стандартным для JAX-RPC файлом webservices.xml, который определяет платформно-независимое поведение Web-сервисов.
Изучение рисунка 2 слева направо показывает, как разработчик должен использовать такой инструмент, как Oracle Jdeveloper или его аналог с интерфейсом типа командная строка Web Services Assembler, чтобы сформировать (to package up) файл типа архив предприятия (enterprise archive (EAR), содержащий политики из oracle-webservices.xml. Затем, после развертывания в инфраструктуре Oracle Application Server 10g Release 10.1.3, эти политики будут автоматически зарегистрированы в файле политик этапа выполнения wsmgmt.xml.
В дополнение к конфигурированию политик на стороне сервера часто также необходимо такое же конфигурирование на стороне клиента. Oracle предоставляет опцию для администраторов, чтобы они могли бы получить свои конфигурации политик на стороне сервера в синтаксисе WSDL, чтобы соответствующие средства на стороне клиента могли использовать это публично доступный контракт и автоматически создать в соответствии с этими политиками клиент.
Разделение проблем
Из вышеприведенного рассмотрения ясно, что подход к управлению Web-сервисами с применением средств Oracle Application Server вышел за рамки программистского подхода к более административному, декларативному, на основе политик подходу. Это не означает, что в данном случае навыки программирования разработчику не нужны, они необходимы для разработки "крюков" (hooks) для обработчиков стандарта JAX-RPC. Но подход на основе политик обеспечивает логическое и физическое разделение проблем для тех организаций, которые хотят воспользоваться его преимуществами. Он дает возможность разработчикам сфокусироваться на построении бизнес-функциональности Web-сервисов и администраторам на определении операционной политики к Web-сервисам. Мы рассмотрим подробно эти новые возможности управления Web-сервисами в следующих нескольких статьях и научимся определять, где такое разделение очевидно и где находятся естественные точки соприкосновения. Чтобы на практике оценить сказанное в этой статье, скачайте Oracle Application Server 10g Release 10.1.3 Developer Preview из сети OTN, установите пример Web-сервиса "Кадры" с интерфейсом JAX-RPC, и затем проверьте новые возможности управления Web-сервисами в Oracle Application Server Control.Скачать
Управление Web-сервисами уже здесь! (Web Services Management Arrives)
(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE.Источник: журнал "Oracle magazine", no.6, 2004,
http://www.oracle.com/technology/oramag/oracle/04-nov/o64dev_web.html Перевод:
Возможности управления Web-сервисами
Основные возможности управления Web-сервисами, которые можно конфигурировать в Oracle Application Server 10g Release 10.1.3, таковы:Они дополняются средой мониторинга для действий, связанных с Web-сервисами: запросов (requests), ответов (responses) и сообщений об ошибочных ситуациях (faults). Эти возможности полностью конфигурируемы в среде управления Oracle Application Server Control. Разработчики смогут также декларативно сконфигурировать их до размещения в Oracle JDeveloper. Рисунок 1 показывает административную, входную страницу управления Web-сервисами в среде Oracle Application Server Control. Эта среда (Application Server Control) в Oracle Application Server 10g Release 10.1.3 может быть типовым образом вызвана заданием URL http:// :1810/ascontrol.
()
Рис. 1: Конфигурирование управления Web-сервисами в Oracle Application Server Control
Использование преимуществ SOAP
Если вы полагаете, что термин Web services определяется не строго, поищите четкое определение термину управление Web-сервисами (Web services management). Некоторые думают, что он просто означает конфигурирование, мониторинг, аудит и журнализацию Web-сервисов (Web service configuration, monitoring, auditing, and logging). Другие определяют его более абстрактно, используя такие термины, как визуализация, уведомление, взаимодействие с протоколами и предоставление сервисов (service virtualization, notifications, protocol mediation, and provisioning).Давайте разберемся с этой проблемой, которая часто возникает, как только вы переходите от работы с полудюжиной Web-сервисов к полновесным бизнес-сценариям, в рамках которых десятки Web-сервисов связываются в бизнес-процесс или сложное приложение.
Особенности SOAP
Хотя управление Web-сервисом, как компонентом, необходимо предлолагает начало деятельности Web-сервиса, необходимо подчеркнуть тот ключевой аспект, который отличает большинство Web-сервисов от протоколов передачи двоичных данных в моделях программирования таких, как CORBA и DCOM: Web-сервисы – это технология работы с сообщениями, в которой и передача сообщений основана на XML (Simple Object Access Protocol [SOAP]), и они сами описываются на XML (Web Services Description Language [WSDL]).В моей предыдущей статье я объяснил, как написать хендлер JAX-RPC для аудита и журнализации контента на основе SOAP. Сила такого подхода заключается в возможности манипулировать, перехватить и запросить “сырое” XML-сообщение по дороге к его пункту назначения.
С этим подходом связано несколько проблем, несмотря на очевидную привлекательность полного доступа к передаваемому сообщению. Например, для относительно типичной утилиты журнализации или аудита, этот подход не является слишком уж простым и декларативным —хендлер должен быть написан вручную (custom-written) и сконфигурирован для каждого Web-сервиса. Хотя хендлеры делают возможными сложные вещи, они не позволяют легко делать вещи простые.
Если вы отступите дальше и представите работу с Web-сервисами в разнородной среде, а это, скорей всего, наиболее типичное использование Web-сервисов, поскольку они по сути – технология интеграции, то применение хендлеров становится еще более проблематичным, так как они привязаны к JAX-RPC и не работают, если конечная точка (endpoint) вашего Web-сервиса реализована на C, Visual BASIC или Perl.
Таблица 1: Пример того, как может измениться входное сообщение
| Тело оригинального входящего SOAP-сообщения | SOAP-сообщение с новым параметром |
| ... |
... |
Стандарты, стандарты, стандарты
Уже реализуется скоординированное движение к обеспечению управлению Web-сервисами как ресурсом. Стандарт, к которому стремятся большинство поставщиков, - это Web Services for Distributed Management (WSDM), разрабатываемый OASIS, который сделает для Web-сервисов то, что Java Management Extensions (JMX) сделали для приложений среды J2EE: предоставить независимый от поставщиков и реализаций способ для трактовки разнородных Web-сервисов как управляемых ресурсов (manageable resources).Во что это стандарт практически должен воплотиться – это набор Web-сервисов и операций, которые должна будет обеспечивать каждая реализация Web-сервиса — операции для конфигурирования, мониторинга и других задач управления. Если этот набор будет реализован согласно данному стандарту, любой Web-сервис будет управляем любой инфраструктурой управления, совместимой с WSDM.
Технический комитет OASIS по WSDM начал свою работу над таким стандартом в феврале 2003 года продолжает работать над версией 1.0 стандарта, которая должна завершиться в середине 2004 года.
И будьте уверены, в каждой большой версии Oracle Application Server управлению Web-сервисами будет уделяться все нарастающее внимание.
Следующие шаги:
СКАЧАЙТЕ
Посмотрите к этой статье
Прочитайте об
Управление компонентами Web-сервисов
На самом нижнем уровне Web-сервис – это просто еще одна программа, выполняющаяся в недрах вашей вычислительной инфраструктуры. С точки зрения управления, существует некоторое множество основных (ключевых) функций, которые применяются для управления Web-сервисами. В их числе - развертывание, конфигурирование и обеспечение безопасности (deployment, configuration, and security support), они комбинируюттся с некоторыми основными возможностями мониторинга и диагностики.Эти ключевые функции реализованы в Oracle Application Server Control, консоли управления сервера приложений Oracle Application Server 10g, как показано на . Используя эту консоль, с которой можно работать через Web-браузер, вы можете легко управлять любым Web-сервисом в среде Java (J2EE Web service).
По мере перехода отрасли на платформу J2EE 1.4, эта консоль будет развиваться, чтобы обеспечить разработчиков средствами конфигурирования и мониторинга всех новых артефактов стандарта JAX-RPC, включая конфигурирование согласно спецификации JSR 109 (JSR 109 configuration), хендлеры JAX-RPC и затем обеспечение надежности, транзакций и безопасности Web-сервисов (Web services reliability, transactions, and security). Эта интегрированная консоль управления имеет особое значение в стандартизации JAX-RPC как части J2EE—инфраструктуры управления, которую ваш J2EE-сервер предлагает, чтобы в равной степени использоваться как с Web-сервисами, так и с классическими J2EE-компонентами.
В версии Oracle Application Server Containers for J2EE 10g (OC4J) Developer Preview 10.0.3, когда я создавал примеры JAX-RPC (см. врезку “Следующие шаги”), инфраструктура управления, лежащая в основе Application Server Control, была расширена для включения Java Management Extensions (JMX). В данном случае эти ранее реализованные возможности по-прежнему доступны, но новая консоль управления будет предоставлять возможности конфигурирования и мониторинга Web-сервисами через стандартные модули (beans - “бобы”) JMX MBeans. Чтобы взглянуть на эти “бобы” (Web service Mbeans) через JMX-браузер прямо, перейдите на страницу http://127.0.0.1:8888/adminoc4j вашей OC4J 10.0.3 Developer Preview и запросите Web service MBeans.
Управляя сообщением
Более общий подход заключается в том, что ввести “посредника” между потребителем сервиса и и его провайдером. Перехват сообщения на уровне трафика для его обработки - не новая идея. Она уже используется в Web-мире на уровне как оборудования, так и софтвера для балансирования загрузки, ускорения, маршрутизации и кеширования (load balancing, acceleration, routing, and caching).Как только вы поймете, что вы можете не только инспектировать и манипулировать контентом SOAP-сообщения, но и применяя WSDL, получить полное представление о формате этого сообщения, его операторов и конечных точек, возможности этого подхода становятся весьма интересными.
Например, рассмотрим простой случай использования сервиса с таблицей Employee salary из моей предыдущей статьи. Этот сервис на основе номера служащего (employee number) возвращает соответствующую информацию о зарплате. Представьте, что после нескольких месяцев применения, этот сервис начинает использоваться несколькими крупными подразделениями в компании, и многие люди просят, чтобы сервис предоставлял и информацию о комиссионных. Разработчики решают просить пользователей этого сервиса изменить входящее сообщение, которое ранее содержало только номер служащего, чтобы оно включало дополнительный параметр,
В идеальном мире, и провайдер, и пользователи этого Web-сервиса должны изменить свои среды одновременно, чтобы поддержать новый параметр, и вычислительная система должна быть модернизирована. В мире Web-сервисов, в котором у провайдеров и потребителей часто различные приоритеты, несвязанные расписания модернизаций и нередко трудно изменяемые инфраструктуры, такая (одновременная) реализация этих модернизаций часто затруднительна.
Решение? Есть немало возможностей на уровне управления, с которыми можно “понять” передаваемое сообщение. Одна из них заключается в том, чтобы “ловить” передаваемые сообщения со старой подписью и маршрутизировать их к старой реализации (old implementation) — простое решение на основе версий.
Другой подход заключается в том, чтобы преобразовать сообщения старого формата (old-style messages) без параметра
Результат этого подхода – провайдер сервиса может выполнять модернизацию по расписанию, независимому от потребителей сервиса. Еще лучше то, что процесс управления происходит на “лету” независимо от реализации, можно проводить модернизацию, даже если ваша внутренняя (back-end) среда состоит из разнородных реализаций Web-сервисов. Соответственно, потребители сервисов могут выбирать модернизацию или воспользоваться преимуществом новых функций по своему собственному расписанию.
Для такой инфраструктуры можно указать немало случаев применения. Что, если ваши клиенты требуют использования SOAP-сообщений, но вы не можете модернизировать вашу внутреннюю инфраструктуру для обработки двоичных данных? Вы можете использовать это подход для “посредничества” между протоколом входящего SOAP и двоичным протоколом в вашей внутренней инфраструктуре. Либо вы могли бы маршрутизировать сообщение к другим машинам на основе таких факторов, как тип клиента, посылающего сообщение, или необходимость учитывать расписания модернизаций этих машин.
И этот продуманный процесс, и появляющиеся прототипы реализаций вызвали ажиотаж в управлении Web-сервисами. Эта область является естественным дополнением для других появляющихся стандартов для Web-сервисов в областях надежности, безопасности, транзакций, grid-вычислений и даже управления бизнес-процессами. Но важно не забывать, что она не волшебная; эта область просто пользуется преимуществами и новациями характеристик присущих Web-сервисами.
Управляя Web-сервисами (Managing Web Services)
(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE. Источник: Oracle Magazine, no.3, 2004,http://www.oracle.com/technology/oramag/oracle/04-may/o34dev_web.html Перевод:
Недопустимость генерации WSDL
Ответим на вопрос: предназначен ли WSDL 1.1 для восприятия человеком. Типичный совет - генерировать WSDL, а не писать вручную. Автор по этому вопросу придерживается следующего мнения. Возможно, это и верно, если таким образом разрабатывается простой, демонстрационный сервис, но данный подход обречен на провал, когда он применяется к крупным системам. Даже программист, работающий самостоятельно, быстро утратит общее представление о проблеме; ситуация усложняется если разработку совместно ведут различные, территориально разнесенные группы специалистов. Большие распределенные системы требуют проектирования; ожидание того, что после объединения они будут совместно работать, приведет к катастрофе.Если распределенные компоненты могут разрабатываться на различных языках программирования, то для того, чтобы указать, как должны быть задействованы сервисы, необходим Язык описания интерфейсов (Interface Definition Language, IDL), нейтральный по отношению к языку программирования. У CORBA (Общая архитектура посредника запросов к объектам, Common Object Request Broker Architecture), как и у DCOM (Распределенная модель компонентных объектов, Distributed Component Object Model), такой язык есть. IDL - это контракт между инициатором на обслуживание и поставщиком, но он только собирает синтаксис. Семантика остается неосвещенной: IDL оставляет открытым вопрос о том, что делает сервис.
WSDL - это IDL Web-сервисов. Он описывает, как вызывать Web-сервисы. Он также определяет ответы, которые могут быть получены как при успешном вызове, так и нет. Спецификация WSDL жестко регламентирует формат сообщений, используемые протоколы и адрес, по которому находятся сервисы. К сожалению, даже четкое и строгое описании на WSDL не гарантирует высокое качество проектирования. Подобно всем языкам IDL, WSDL силен в синтаксисе и слаб в семантике. Однако, не стоит им пренебрегать - в конечном счете важна именно семантика, синтаксис же используется просто, чтобы ее раскрывать.
Непрозрачность сети
Сеть не является прозрачной - вызов локального сервиса и его удаленный вызов существенно отличаются друг от друга. В качестве "памятки разработчику" можно порекомендовать тезисы Питера Дойча (Peter Deutsh) "Восемь заблуждений о распределенной обработке данных" ().Неверная семантика различна для сетевого окружения и локальной реализации: при неудачном вызове не всегда известно, исполнился сервис или нет.
WSDL 1.1 описывает следующие виды вызовов: односторонний (one-way), запрос-ответ (request-response), ответ на требование (solicit-response) и уведомление (notification). Однако, связывания WSDL поддерживают только односторонний вызов и вызов вида запрос-ответ. Также следует понимать, что реально, а что - нет. Другими словами, сегодня невозможно реализовать ситуацию, когда клиент ожидает с сервера асинхронное получение практического, "промышленного качества" и согласованного со стандартами результата. Это следует расценивать как досадное обстоятельство, поскольку это именно тот механизм, который является наиболее гибким в ситуации частичного сбоя.
WSDL позволяет перемешивать и согласовывать виды вызова и транспорт (transport). На этом этапе важно прибегнуть к здравому смыслу. Первое требование - а это не всегда очевидно - необходимо четко представить, как стек протоколов предлагаемого Web-сервиса будет себя вести. В качестве примера рассмотрим, что случится если асинхронно вызвать Web-сервис поверх механизма синхронного транспорта. Предположим, что SOAP-сообщение пересылается в одну сторону по HTTP: бизнес логика на клиенте формирует SOAP сообщение, чтобы вызвать удаленный сервис. В результате запрос HTTP посылается на сервер. Когда сервер получает запрос, он должен немедленно возвратить ответ HTTP, не обслуживая этот запрос. Бизнес логика на сервере должна отрабатывать после того, как этот ответ был возвращен. Этот ответ не должен содержать SOAP-сообщение. Ответ HTTP с кодом состояния 200 или 202 не означает, что сервис успешно отработал.
Код сбоя, с другой стороны, должен гарантировать, что вызов сервиса не исполнился. Слой SOAP на клиенте не формирует новых сообщений до тех пор, пока он не получит ответ, или пока не истечет время ожидания.
Таким образом, односторонний вызов не "устраняет" задержки или неисправности в сети. Самое большее - он помогает избежать задержки с бизнес логикой на сервере. Автор употребил "самое большее", подразумевая, что эту функциональность стоит протестировать на инструментальной цепочке сервера, прежде чем полагаться на нее -корректная реализация является нетривиальной задачей для любого поставщика.
Используя HTTP в в качестве транспортного протокола, клиент может быть уверен, что его запрос был доставлен. Стоит заметить, однако, что если клиент не получил ответ, это не значит, что сервер не получил и не обработал корректно этот запрос. Например, сеть может "упасть" во время отправки ответа. Другими словами, реализовать вызов просто, правильно завершенный вызов - нет.
Определение ограниченных интерфейсов
Следует внимательно изучить то, что предлагается: и на уровне данных, и на уровне кодирования данных. Необходимо помнить, что придется продолжить поддерживать поставляемый интерфейс. Чем ограниченнее интерфейс, тем легче его реализация. WSDL же спроектирован для гибкости.. Из-за этой гибкости легко ошибиться в спецификации Web-сервисов и оставить многие опции реализации неохваченными . Следует избегать этого - клиенты и серверы должны уметь обрабатывать все сообщения, которые допустимы по контракту.Типичная ошибка, совершаемая при реализации серверных систем, - установление соединения с базой данных при каждом запросе к этой базе. Автор совершил такую ошибку - выяснилось, что установление соединения с базой данных занимает больше времени, чем все остальное, вместе взятое. Чтобы минимизировать это падение производительности, можно прибегнуть к одному из двух приемов: воспользоваться пулом соединений (connection pool) или хранимой процедурой.
При использовании Web-сервисов стоимость установки соединения также высока. Опять-таки дополнительные затраты на вызов могут быть уменьшены повторным использованием существующего соединения. С другой стороны, необходимо учитывать, что поддержание открытого соединения требует ресурсов. Однако, важно помнить, что расходы, связанные с вызовами Web-сервиса, гораздо более высокие по сравнению с вызовом локальной функции и, следовательно, их следует реже использовать.
Здесь уместно провести аналогию с хранимыми процедурами. Вместо отправки данных и обработки их на клиенте, только чтобы выяснить, что требуются еще данные, хранимые процедуры оперируют с данными в адресном пространстве базы данных. Применение хранимых процедур в приложениях баз данных является спорным моментом - по крайней мере, по двум причинам. Во-первых, язык написания хранимых процедур не стандартизирован, и поэтому их использование ведет к зависимости от поставщика БД. Во-вторых, бизнес логика должна находиться в отдельном слое, а не в базе данных.
Тем не менее, хранимые процедуры решают реальную проблему, и их недостатки должны быть соотнесены с достоинствами в каждом отдельном случае. Аналогично, в области Web-сервисов, клиенту предоставляется контроль над логикой за счет множества мелко структурных вызовов. Крупно структурные сервисы более напоминают хранимые процедуры. Они не только улучшат производительность, но и упросят процесс реализации, внедрения и управления всей системой.
Итак, практическая рекомендация - проектировать Web-сервисы под ограниченные, но крупно структурные интерфейсы. Ограниченность позволяет показывать как можно меньше, крупность структуры - выполнять как можно больше для одного вызова.
Отличие Web-сервисов от распределенных объектов
Объекты характеризуются состоянием. Следует избегать состояния, поскольку оно связывает ресурсы и ослабляет масштабируемость. Слабосвязанная архитектура разрешает отдельным компонентам изменяться, не разрушая систему. Весьма вероятно, что в будущем потребуется расширять Web-сервис. Как же при этом сохранить обратную совместимость?Несмотря на то, что достоинство удаленного вызова процедуры (RPC) в легкости реализации, он не очень хорошо уживается со слабой связанностью: необходимо передавать фиксированный список параметров при каждом вызове Web-сервиса. Эту проблему можно в некоторой степени сделать менее острой, разрешив некоторым параметрам "не иметь значения". Оставим без рассмотрения возникающие в этом случае проблемы, связанные с обеспечением возможности взаимодействия, - более фундаментальное ограничение заключается в том, что этот прием позволяет исключать параметры, а не добавлять их. Вызовы в стиле документа проявляют себя лучше, когда части документа могут быть определены как необязательные. Они также могут быть спроектированы для расширяемости.
Проектирование интерфейсов
Прежде чем приступить к написанию WSDL, необходимо оговорить с заказчиками то, что Web-сервис должен делать. Следует записать случаи использования, четко определив, как этот сервис взаимодействует со своей средой. Предположим, что программа-агент (actor) с какой-либо целью вызывает Web-сервис. В этом случае, нужно создать не только сценарий "солнечного дня", который реализует поставленную задачу, но сценарий "дождливого дня", когда результат отрицательный. Какие гарантии может предложить система, что цель успешно достигнута? А когда нет? Где находится граница ответственности клиентской части и сервера?Трудно переоценить важность четкого определения требований. На этом этапа стоит задуматься о цели проекта. В чем конкретно она заключается? Какие данные необходимо получать от клиента, и что должен поставлять сервер? Совершение ошибки на этом шаге чревато большими затратами.
Например, рассмотрим Web-сервис, который в качестве параметров принимает список установленных программ и величину свободного места на диске. Затем этот сервис должен вернуть список приложений, подлежащих обновлению. В случае если места достаточно, проблем не возникает. Однако, как быть, если его недостаточно? Как выбрать продукты, для которых необходимо установить новые версии? Предполагается ли, что клиент сам удаляет старые редакции программ, чтобы освободить место для новых? Это непростые вопросы, для решения которых потребуется разрабатывать сложные алгоритмы, при реализация которых не исключены ошибки. Разумеется, ни одну систему не следует определять подобным образом. Сервер должен предоставлять список приложений, зависимости между ними и требования, которые они предъявляют к ресурсам. Решение же о том, какой пакет установить, является задачей клиента. Поэтому поручив серверу это задание, клиент ничего не выиграет, он только повысит затраты на разработку серверной части.
Таким образом, необходимо проводить анализ затрат на начальном этапе. При этом можно проигнорировать технические детали - сервис можно рассматривать как черный ящик.
Но нельзя пренебрегать деталями, касающимися взаимодействия между этим сервисом и его средой.
Следующий шаг - проанализировать, как можно реализовать случаи использования. Будет ли единственный интерфейс (portType в WSDL версии 1.1), обеспечивающий всю функциональность? Или несколько интерфейсов? Каждый интерфейс может быть предложен в нескольких конечных точках, но, как правило, он должен быть неделимым. То есть конечная точка должна предоставлять либо всю функциональность, либо ничего. Аналогично, интерфейс должен быть семантически последовательным. Сказанное носит рекомендательный характер и опирается на здравый смысл, хотя ничто в спецификации WSDL не препятствует иной интерпретации.
Требуются ли какие-нибудь поддерживающие интерфейсы? Как и когда они должны вызываться? Какова природа этой зависимости? Пока нет стандартов, а только рекомендации о том, как обращаться с "хореографией сервисов" (service choreographies), как разрешать сервисам выполнять гиперссылки к другим сервисам. Другими словами, это неисследованная проблемная область.
Возвращает ли разрабатываемый сервис результат клиенту? Должен ли клиент располагать информацией о том, что сервис успешно отработал? Должен ли клиент вызывать сервис синхронно? Или асинхронно? Или же сервис будет поддерживать оба типа вызова?
Проектирование Web-сервисов
Употребляемый автором термин Web-сервисов относится исключительно к тому виду технологии, которая состредоточена на взаимодействии (interoperability). Это означает, что эта технология стандартизирована: гетерогенные системы работают только при наличии отрытых стандартов. В этом случае уместен вопрос: будут ли Web-сервисы решением вашей проблемы? Сегодня одного слова Web-сервисы уже недостаточно, чтобы говорить о солидности компании, их использующей, поэтому будет лучше, если имеются иные веские основания для их использования. Если вы контролируете оба конца канала, не исключено, что существуют более подходящие технологии. Сейчас - только заря эры открытых стандартов распределенной обработки данных. Поэтому цена поддержки Web-сервисов на этом еще несформировавшемся рынке остается высокой - это и снижение производительности, и увеличение затрат на разработку, и ухудшение защищенности.Тезис о том, что Web-сервисы являются "дружественными по отношению к брандмауэру" ("firewall friendly"), обманчив. Действительно, обычные брандмауэры оберегают корпоративные ценности от "злоумышленников", которые используют слабые места в прикладном программном обеспечении, появившиеся в результате открытия портов, на которых исполняются защищённые сервисы. С другой стороны, Web-сервисы через этих порты "выставляют" прикладное программное обеспечение. Другими словами, они ослабляют безопасность, предоставляя посторонним лицам доступ к приложениям - именно то, чему сетевой брандмауэр должен был бы воспрепятствовать. Поэтому необходимо новое поколение брандмауэров. На рынке уже появилось несколько новых игроков, предлагающих такие продукты. Поставщики обычных брандмауэров также начинают обращать внимание на эту проблему. Но это только начало, и такая технология должна еще оправдать себя.
Даже если предполагается применять Web-сервисы, необходимо помнить, что необязательно использовать SOAP. Например, автор статьи видел формы, передаваемые как аргумент запроса на удаленный вызов процедуры SOAP (SOAP-RPC). Ему также попадались формы, которые возвращались как часть ответа удаленного вызова процедуры SOAP. Он так и не смог найти дополнительную пользу от применения SOAP. Разве не был бы проще обыкновенный XML или HTML через HTTP?
Разделение проектирования и реализации
В идеале при проектировании Web-сервисов следует оставить вопросы реализации в стороне. Суть проектирования -посмотреть на систему на высоком уровне абстракции, не обращая внимания на проблемы реализации. Однако, можно выбрать такой, казалось бы подходящий по всем параметрам дизайн проекта, который окажется бесполезным, если инструментальные цепочки, которые предполагается использовать, не поддерживают конструкции в разработанном WSDL. Автор настойчиво рекомендует создание макета по техническим спецификациям для проверки реальности осуществления проекта. Пока этот момент еще не проработан.Разнесение бизнес логики и политики
Не следует реализовывать аутентификацию и авторизацию в бизнес логике. Безопасность транспортного уровня может быть как удовлетворительной, так и нет. В разделе приведены ссылки на статьи, в которых рассматривается этот вопрос. Даже если безопасность транспортного уровня и не урезается, все равно пока нет стандартов - они только разрабатываются, и из них стоит отметить создаваемые Техническим комитетом OASIS "Защищенность Web-сервисов" (). Предлагаемые подходы действительно способствуют разделению бизнес логики и политики (policy): заголовки SOAP вставляются в сервис, чтобы обеспечить характеристики безовасности, а информативная часть сообщения сохраняется для бизнес логики.Но как же без ложки дегтя - предлагаемый стандарт применим только к Web-сервисам, использующим SOAP. Еще одна неприятность - отсутствие стандартизированного способа указать Качество защиты (Quality of Protection, QoP) сервиса в документе WSDL. Microsoft, BEA, SAP и IBM опубликовали спецификацию для "Приложений политики Web-сервисов" (), в которой рассматривается этот вопрос. Насколько известно автору, этот документ еще не был передан ни в один орган стандартизации.
Ресурсы
"Мыльная опера" на тему защищенность Web-сервисов будет продолжаться еще долго. Ниже приведено "содержание первых серий":В статье "IDL, которого нет" () Мартина Гуджина (Martin Gudgin) и Тимоти Иуолда (Timothy Ewald) приводится более глубокий анализ WSDL с позиций IDL.
В белой бумаге "Кто пишет контракты Ваших Web-сервисов" () корпорации Karniak рассказывается о том, как точное описание упрощает процесс разработки Web-сервиса.
WSDL: взгляд изнутри, часть I
Автор: Джоан Питерз (Johan Peeters)Перевод:
Недавно автору статьи довелось использовать язык WSDL (Web Services Description Language, Язык описания Web-сервисов) для нескольких существующих Web-сервисов - на одном клиенте работал сервер и клиентская реализация. У этого клиента и специалистов по обслуживание сервера уже сложились тесные рабочие отношения, но наступил момент, когда возникла необходимость в еще одной клиентской реализации, которую должна была выполнить группа разработчиков, находящихся в противоположенной точке земного шара. В связи с этим потребовалась четкая спецификация, описывающая такие сервисы, а именно для этого и предназначен WSDL. Поэтому автор вознамерился основательно изучить то, что ранее не было достаточно освещено. В результате, он приобрел ценный опыт - ему удалось вспомнить старую и добрую практику проектирования программного обеспечения и обнаружить ряд проблем, характерных для Web-сервисов, WSDL и XML Schema.
В самом начале, на этапе проектирования, было допущено несколько ошибок, которые изначально трудно заметить. Вероятно, эти недочеты не были бы допущены, если бы проектировщики дали формальное определение для своих сервисов на WSDL. Так что, вот основная мысль этих двух статей: пишите WSDL заранее, не генерируйте его потом, как это часто советуют поставщики.
При всем внимании, которым были одарены Web-сервисы, часто сложно отделить желаемое от действительного. В предлагаемом цикле статей акцент будет сделан на реальном, а не на потенциальном. В них читатель не найдет краткого обзора WSDL, кроме того предполагается, что он знаком с W3C XML Schema. В первой статье рассказывается, чем могут быть полезны при проектировании Web-сервисов практика проектирования программного обеспечения и опыт в области распределенной обработки данных. В ней рассматриваются некоторые решения, которые должен принимать проектировщик Web-сервисов, приводятся необходимые советы и рекомендации. В остальных статьях будет описан процесс проектирования: во второй статье будут перечислены некоторые "темные стороны" спецификации WSDL 1.1. В нее не войдут определения типов данных - темы третьей статьи, в которой будет представлена W3C XML Schema с позиции того, кто использует ее для определения данных, передаваемых через интерфейсы Web-сервисов.
Что можно ожидать
Как уже отмечалось, WSDL 1.1 не имеет статуса стандарта. И все же эта спецификация широко используется, часто не оправдывая надежд на возможность взаимодействия. Именно это и является причиной появления Организации по развитию возможности взаимодействия Web-сервисов (WS-I) - не получить право собственности на стандарт WSDL, а определить очертания, "состоящие из набора некоммерческих спецификаций Web-сервисов наряду с уточнениями и поправками к тем спецификациям, которые способствуют возможности взаимодействия".Конечно, наличие еще одной организации стандартизации вызывает раздражение. Несмотря на заявленные цели, автор не может отделаться от ощущения, что деятельность организаций, схожих с WS-I, может привести к появлению взаимоисключающих стандартов. Тем не менее, он посоветовал бы ознакомиться с разделом 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), в котором содержатся отличное разъяснение некоторых "дыр" WSDL 1.1. И все же автор не одобряет то, что организация уделяет максимум внимания SOAP.
В предыдущей статье также говорилось о Техническим комитете OASIS "Защищенность Web-сервисов" (OASIS WSS TC), который, кажется, становится лидером в области определения стандартов защищенности Web-сервисов. Это еще одна организация, которая решает часть поставленной выше задачи. Но смогут ли подойти друг к другу эти части, и кто собирается их объединять?
Право собственности на будущие версии WSDL, похоже, однозначно остается у консорциума W3C, где Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занята написанием WSDL 1.2. Согласно ее уставу, выход этой версии запланирован на май 2003 года. Эта срок, очевидно, будет сорван. Тем не менее, группа время от времени публикует рабочие проекты будущей редакции. Так, что же будет со "слабыми сторонами" WSDL , о которых шла речь выше?
Если судить по проекту, доступному на момент написания этой статьи, похоже, подтверждается интерпретация того, что происходит в целевом пространстве имен описания Web-сервисов. В нем говорится, что "информационная единица атрибута targetNamespace определяет присоединение пространства имен для компонентов верхнего уровня, определенных в этой информационной единице элемента definitions. Сообщения, типы порта, связывания и сервисы являются компонентами верхнего уровня". Будет ли WSDL 1.2 поддерживать реализацию нескольких интерфейсов является предметом жарких дебатов. В проекте WSDL 1.2 явно указано, что для используемых пространств имен с импортированными документами применяются те же правила как и в XML Schema. С другой стороны, альтернативный подход по разделению описаний на модули обеспечивается посредством элемента include, моделируемого по элементу include XML Schema, который не допускает совместного использования пространств имен.
Document/literal против rpc/encoded
Здравый смысл предписывает использовать текстовый формат передачи при вызове документа и кодированный при использовании RPC (Remote Procedure Call, Удаленный вызов процедуры). Однако, фундаментальных причин, почему необходимо следовать этому правилу, нет - это скорее исторически сложившиеся стечение обстоятельств, что инструменты, как правило, поддерживают эти комбинации.Выбор осуществляется между сложностью модели программирования и сложностью маршалинга (marshalling) сообщений. RPC предлагает удобную модель программирования. Она не без изъянов, как отмечалось в предыдущей статье. Однако, также важно знать об обязательствах, которые форматы передачи, используемые с RPC, накладывают на маршалеров: различие между literal и encoded - это различие между составителем и читателем. Это означает, что у второго формата передачи может быть множество различных представлений для семантически эквивалентных сообщений.
Классический пример - поддержка кодирования SOAP для независимых и встроенных элементов. Понимать все представления - дело получателя. В предыдущем разделе уже говорилось о важности максимально точного определения формата сообщения. Причина тому - высокая стоимость принятия правильного решения читателем. Это, возможно, не имеет значения в средах, в которых доступны сложные инструменты генерации клиентской заглушки (client stub), но при работе на гетерогенных платформах это не всегда так.
Инструменты
Перед тем, как вдаваться в подробности, давайте рассмотрим инструмены, которые могут помочь. Во-первых, при написании WSDL можно воспользоваться XML-редактором, желательно с возможностью проверки валидности WSDL-документа. Модифицируя WSDL для существующих Web-сервисов, автор обнаружил, что очень полезно уметь генерировать, посылать и получать сообщения из редактора; XML Spy от Altova выполняет это для Web-сервисов, использующих SOAP и HTTP. Благодаря этому интерактивные разработка, тестирование и отладка WSDL получают практический смысл. К сожалению, XML Spy не предоставляет такую возможность для других протоколов. Важная функциональность, которое, похоже, отсутствует в сегодняшних инструментах - это возможность проверять ответ сервера на допустимость согласно описанию Web-сервиса.Модульные описания Web-сервиса
Применяя ключевое слово import, можно разделить WSDL на документы-модули. Пример, приведенный в Примечании консорциума W3C состоит из трех документов, которые содержат, соответственно, определения типов данных, абстрактные определения и специфические связывания сервиса. Эти специфичные или конкретные определения сервисов зависят от абстрактных определений сервиса, которые в свою очередь зависят от определений типов данных.Помимо улучшения читабельности этот подход может также повысить возможность расширения и повторного использования некоторых типов: одни и те же определения типов данных могут быть использованы во многих абстрактных сервисах, а одни и те же абстрактные сервисы могут быть использованы во многих различных связываниях по многим адресам.
Вначале множество Web-сервисов может быть представлено в виде набора из трех документов. Однако, по мере того, как сервис развивается, это может вылиться в дерево документов, у которого в корне находятся определениями типов данных, а его ветви расходятся к нескольким документам абстрактных сервисов и далее к конкретным сервисам.
Элемент portTypes - это набор семантически связанных операций, во многом подобный интерфейсу в языке программировании. Элемент binding не обязан охватывать все элементы operation данного portType. Например, определенные в одном portType элементы operation могут использовать различные транспортные протоколы. Поскольку service - это набор элементов port, а port ссылается на отдельный binding, можно определять сервисы, которые не предлагают все operation, определенные в portType. Однако, наличие таких сервисов является признаком плохо разделенных элементов portType.
Отдельный сервис может быть составлен из множества интерфейсов, каждый из которых представляет отдельный аспект этого сервиса. Например, у сервиса может быть порт для своей бизнес логики и еще один порт для доступа к функциям управления.
Обработка ошибок
Возможно, единственно наиболее важное отличие между демо- и готовым сервисом заключается в качестве обработки ошибок. Тем не менее, в литературе этому вопросу удаляется мало внимания.Определение отдельных сообщений с целью установления различных сбойных ситуаций может быть удобно - структура таких сообщений может меняться согласно возникшей сбойной ситуации. В Листинге определен Web-сервис, который приведет в бешенство системных администраторов: он запускает двоичный код (binary), по запросу вызывающей программой. Читатель, возможно, будет разочарован, не обнаружив примеров использования пространств имен и разделения на модули - этот пример не рассматривает эти особенности. Он иллюстрирует обработку ошибок - при проектировании была предусмотрена возможность появления двух ошибок: первая - если недостаточно памяти, в этом случае возвращается область выделенной динамической памяти и количество используемой памяти; вторая - если программа попытается разыменовывать нулевой указатель, в этой случае возвращается запись стека.
Типы сообщения о сбоях получены из абстрактного типа. Причина использования абстрактных типов может быть объяснена желанием провести аналогию с отображением ошибочных действий в иерархию наследования во многих языках программирования. Поэтому исправленный Листинг - это более компактное описание Web-сервиса. Разница между наборами сообщений о сбоях, которые допустимы согласно соответствующим документам, незначительны.
Замысел, однако, намного яснее в первом документе. Разработчики клиентской реализации, работая со вторым документом вероятно смогут предположить, что может быть возвращено и сообщение OutOfMemoryException. Но из спецификации неясно, имеет ли это значение. Также они не могут быть уверенными, что код клиентской реализации охватывает все сбойные ситуации, поскольку абстрактный класс tException может быть расширен типами, отличными от перечисленных во втором документе.
Автор сталкивался с гибридным подходом, при котором сложный тип не объявлен абстрактным. В этом случае сообщения о сбоях могут быть определены в описании Web-сервиса как производный тип, иногда определяется сложный тип. В результате, возникает еще большая неопределенность относительно точного формата, который получит клиент - автор не рекомендует этот подход.
Пространства имен
Описания Web-сервиса, как только они согласованы, должны быть зафиксированы. WSDL 1.1 предусматривает необязательное использование целевого пространства имен. Однако, удобно назначать пространство имен для недвусмысленной идентификации сервисов и их версий - как принято делать в случае спецификаций стандартов. Сложность состоит в том, что WSDL 1.1 не очень четок относительно того, что подразумевается под целевым пространством имен. Другими словами, что точно вкладывается в это понятие? По мнению автора, под ним понималось те же правила, что и в W3C XML Schema.Напомним кратко эти правила: то, что помещается в целевое пространство имен регулируется атрибутом form в элементах element и attribute. При отсутствии такого атрибута управление передается набору значений по умолчанию в атрибутах elementFormDefault и attributeFormDefault, находящихся в корневом элементе schema. При отсутствии явного задания значений по умолчанию в силу вступают неявные значения по умолчанию: к пространству имен относятся только элементы, определенные глобально.
В каком виде эти правила W3C XML Schema нашли свое отражение в WSDL 1.1? Во-первых, в WSDL не задействованы элементы element и attribute. Во-вторых, элементами верхнего уровня в WSDL являются messages, portTypes, bindings и services, являющиеся сущностями (entity), которые должны быть помещены в целевое пространство. Очевидно, в данном случае type не релевантны. В-третьих, несмотря на то, что теоретически атрибут form мог бы использоваться с любыми элементами, определенными в WSDL, это не является принятой практикой. В-четвертых, аналогично сказанному, атрибуты elementFormDefault и attributeFormDefault могли бы использоваться в элементе definitions, но автор с этим не сталкивался.
Таким образом, можно утверждать, что все message, portType, binding и service оказываются в целевом пространстве имен, а их потомки - нет.
Удобно ли это правило? А имеет ли это значение? Это имеет смысл, когда сообщения зашифрованы так, что - за исключением этого правила - пространство описания Web-сервиса могло бы "просочиться" в сообщение.
Действительно, автор потратил достаточно времени, чтобы выяснить, что пространства имен, которые находились в зашифрованном SOAP-сообщениях, не были в пространстве имен WSDL из-за того, что, согласно принятой, но обескураживающей практике, то же самое пространство имен используется в качестве входного для шифрования SOAP. Непосредственным результатом указанного правила пространства имен является отсутствие элементов и атрибутов сообщения в пространстве имен описания Web-сервиса, если только они не помещены туда пространством имен шифрования SOAP.
Если описание Web-сервиса разложено на модули, согласно приведенной выше рекомендации, каждому документу должно быть назначено пространство имен. Описания Web-сервиса не должны импортировать (import) определения с одинаковым пространством имен. Спецификация WSDL не формулирует это правило явно, но опять-таки, по мнению автора, наличие элемента import в W3C XML Schema явился причиной появление одноименного элемента в WSDL и расширения тех же правил. Schema не разрешает импортирующей и импортируемой схеме совместно использовать пространство имен. По оценке автора, это очень удобное правило, поскольку сложно рассуждать о пространстве имен, если нет уверенности, что определение полное.
Ресурсы
Ценную информацию о WSDL можно почерпнуть из следующих материалов:Крепким духом и не только стоит прочитать "Примечание WSDL 1.1" консорциума W3C (WSDL 1.1). Обратите внимание на раздел 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), поскольку в нем поясняются многие положения WSDL 1.1. Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занимается написанием спецификации WSDL 1.2. Время от времени группа публикует редакции рабочего проекта.
Оригинальный текст статьи можно посмотреть здесь:
WSDL Tales From The Trenches, Part 2
WSDL: взгляд изнутри, часть II
Дата: 24-06-2003Автор: Джоан Питерз (Johan Peeters)
Перевод: Intersoft Lab
В ("WSDL: взгляд изнутри, часть I") автор привел общее описание процесса проектирования Web-сервисов. В ней отмечалось, что Язык описания Web-сервисов (Web Services Description Language, WSDL) только определяет синтаксис того, как Web-сервис может быть вызван; он не говорит ничего о его семантике. В этой статье этот вопрос получит дальнейшее рассмотрение.
В настоящий момент наиболее широко используется версия WSDL 1.1, опубликованная в качестве Примечания консорциума W3C (W3C Note). Она не является официальным стандартом. WSDL 1.1 предлагает широкие возможности для вызова Web-сервисов. При этом поддержка инструментов осуществляется посредством "патчей". Эта версия WSDL была встречена недоброжелательно, поскольку явила собой компромисс между выразительностью и гибкостью, с одной стороны, и многословностью и сложностью, с другой. Прежде чем продолжить, автор вынужден признаться, что он не представляет, как написать действительно четкий, точный WSDL.
Корпоративные сайты и порталы
Андрей Беляев,
,
Подготовлено: по материалам зарубежных сайтов
Перевод:
Авторские права:
Кристиан Веже,
Михаил Евдокимов, КомпьютерПресс 6'2001
Изо дня в день работая над обновлением содержимого своего Web-сайта, насыщая его интересными материалами, вы, вероятно, задумываетесь о том, что ежедневно создаются сотни новых Web-сайтов, которые также ежедневно пополняются сотнями новых документов. Как создаются все эти новые массивы страниц и каким образом они так быстро обновляются? Все это не так сложно, как кажется на первый взгляд, поскольку здесь используется концепция динамических Web-страниц.
Андрей Щербина, Открытые системы, #04/2003
П. В. Федосеев
Статья посвящена Microsoft Commerce Server, продукту, предназначенному для быстрого создания комплексных программных решений для электронной коммерции. Commerce Server содержит комплекс средств для построения business-to-customer (B2C) и business-to-business (B2B) систем.
, Открытые системы, #06/2003
, Открытые системы
Алексей Рындин (Главный инженер проектов), http://www.jetinfo.ru/
Web-сервисы
Александр Симаков, alexander-simakov.blogspot.com
Александр Симаков, alexander-simakov.blogspot.com
, ведущий консультант-разработчик IBS Borlas
Источник:
An Oracle White Paper, перевод
Oracle Magazine/RE
Джером Джозефрай (Jerome Josephraj)
Перевод:
Мнение аналитиков IDC
по материалам зарубежных сайтов ,
по материалам зарубежных сайтов ,
по материалам зарубежных сайтов ,
, старший редактор издательства Oracle Publishing.
Перевод Oracle Magazine RE
, главный менеджер по продукту Oracle Application Server Containers for J2EE.
Перевод Oracle Magazine RE
, главный менеджер по продукту Oracle Application Server Containers for J2EE.
Перевод Oracle Magazine RE
, главный менеджер по продукту Oracle Application Server Containers for J2EE.
Перевод Oracle Magazine RE
Олег Ремизов,
Евгений Веселов, Михаил Голованов,
Дэвид Орчард,
, перевод:
, ,ФГУП Воткинский завод,
, Ижевский Государственный Технический Университет
,
Джоан Питерз (перевод )
Джоан Питерз (перевод )
Билал Сиддикуи (перевод )
,
Подготовлено по материалам зарубежных сайтов
Подготовлено по материалам зарубежных сайтов
Дэн Эверет (перевод )
Шейн Куркуру (Shane Curcuru) (Перевод: )
Web-сервисы: растущие опасения
"Информация для размышления": изолированная структура (silo) - модное техническое словечко, обозначающее любые неэффективные и дорогие элементы в несовместимом программном обеспечении. Изолированные структуры являются "мишенью" для Web-сервисов. Можно сказать, одно из предназначений Web-сервисов - разрешение проблемы изолированных структур. Так почему же за последние три года Web-сервисам так и не удалось реализовать эту задачу? Именно таким вопросом задались аналитики исследовательской компании IDC. В своей работе "Web-сервисы: растущие опасения" они предлагают свое видение проблемы, высказывают предположения о дальнейшей судьбе Web-сервисов. Однако, прежде чем познакомить читателя с их точкой зрения, будет нелишним привести "краткую историческую справку". Напомним, что практически три года назад Web-сервисы рассматривались как новое и перспективное направление информационных технологий. Тогда с ними были связаны большие надежды. Так, еще в марте 2002 года Журнал клуба знатоков DWH, OLAP, XML () рассказывал о прогнозах консалтинговой компании The Stencil Group (более подробно см. "Рынок Web-служб: прогнозы The Stencil Group"). Ее сотрудники прогнозировали, что на рубеже 2004-2005 годов должна начаться третья и последняя фаза развития Web-сервисов - этап их активного использования. Однако, сегодня можно констатировать, что развитие Web-сервисов происходят с явной задержкой. Аналитики IDC полагают, что существует достаточно много причин, почему ожидания в отношении Web-сервисов не оправдались, начиная от ограниченного практического опыта и заканчивая непроработанными технологиями и стандартами. Однако, главная причина, почему переход к архитектуре Web-сервисов так и не состоялся, заключается в высоких сопутствующих рисках и отсутствии убедительного обоснования оправданности затрат.Как ни печально, но, по оценке IDC, организации по-прежнему находятся на самой ранней стадии признания и освоения Web-сервисов. Тем не менее, несмотря на затянувшийся старт, исследователи ожидают значительное повышение темпов роста на рынке программного обеспечения и услуг, относящихся к Web-сервисам, в период до 2008 года.
Рост произойдет в первую очередь в более крупных организациях, затем на рынке среднего и более мелкого бизнеса. В частности, выяснилось, что организации, занимающиеся предоставлением финансовых услуг, и государственные учреждения, в которых установленные устаревшие программные продукты создают дополнительные интеграционные сложности, имеют больший опыт в области внедрения Web-сервисов по сравнению со своими коллегами из других вертикальных отраслей.
В настоящий момент компании, которые начали развертывание Web-сервисов, заняты простой интеграцией на уровне "приложение - приложение". Однако, со стратегической точки зрения более незначительная группа организаций рассматривает возможность применения композитных приложений. Дело в том, что использование Web-сервисов позволяет композитным приложениям динамически адаптироваться к изменяющимся бизнес-процессам и поэтому является очень привлекательным, однако широкому применению препятствует отсутствие инструментов, технологий и стандартов, которые только начинают появляться.
Как отмечают в IDC, при рассмотрении рисков при переходе на новую технологию, в частности на Web-сервисы, необходимо учитывать факторы, анализ которых, несмотря на то, что организации не могут на них повлиять, необходим, поскольку позволяет оценить их потенциальное воздействие. Ниже перечислены основные тенденции, учет которых может быть полезен компаниям, планирующим развертывание Web-сервисов.
В IDC практически убеждены, что законы рынка потребуют объединения стандартов. Однако, в результате, появятся победители и проигравшие: победители будут разрабатывать стандарты с учетом своих сильных сторон, проигравшие - будут вынуждены сдать свои позиции и довольствоваться второстепенными ролями. Что касается сотрудников IT-отделов компаний, то им придется либо подождать, пока число сторонников любого стандарта не достигнет критической массы, либо иметь очень веские причины не дожидаться широкого признания стандарта (например, если его предполагается использовать внутри компании) и рискнуть внедрить стандарт на свой страх и риск.
REST ( который также может использовать XML, но применяет команды HTTP GET, POST, PUT и DELETE вместо SOAP) становится все более популярным, поскольку обещает вернуть изначальную простоту Web-а.
Как замечают в IDC, в области информационных технологий переход от одной технологии, архитектуры, процесса или подхода к другому, как правило, начинается медленно - чтобы избежать чрезмерного риска.Как только "ранним последователям" удается разрешить сложности и познакомить широкую аудиторию с новшеством, может произойти его массовое признание и освоение. Что же касается Web-сервисов, то в IDC полагают, что этот цикл повториться несколько раз - по мере того как будет расширяться функциональность Web-сервисов. Поэтому изолированные структуры будут сокращаться гораздо медленнее, чем изначально предполагалось, а опасения в отношении стандартов и технологии, даже для основной интеграции по уровне "приложение - приложение", по-прежнему сохранятся.