суббота, 22 декабря 2012 г.

Проектирование контракта сервиса

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

Контракт сервиса должен однозначно описывать его интерфейс и семантику. В идеальном случае контракт должен быть самодокументируемым, т.е. по контракту должно быть понятно что это за сервис, какие у него есть методы, какие параметры принимают данные методы и какие результаты они возвращают. Если контракт по настоящему самодокументируемый, то по нему возможна автоматическая генерация кода. Другим преимуществом самодокументируемого контракта является возможность автоматической валидации запросов к сервису. Причем помимо валидации синтаксиса запроса (пример - валидация XML-документа по XSchema) возможна валидация семантики запроса (пример - использование Schematron). В настоящее время стандартом для представления контрактов сервисов является язык Web Services Description Language (WSDL). В данной заметке мы рассмотрим основные решения, которые должен принять архитектор при разработке WSDL-описания контракта сервиса, а так же приведем некоторые практические советы.

среда, 19 декабря 2012 г.

Варианты запуска WebLogic Server'а с использованием WLST

Существует несколько способов запуска серверов участников домена сервера приложений WebLogic. Один из них - это использовать скрипты DOMAIN_HOME/bin/startWebLogic.sh для AdminServer'а и DOMAIN_HOME/bin/startManagedWebLogic.sh для управляемых серверов. Другой - использовать утилиту WebLogic Scripting Tool (WLST). В данной заметке мы подробно рассмотрим второй способ.

вторник, 4 декабря 2012 г.

Пример использования Spring Framework совместно с SCA-контейнером Oracle WebLogic

В одной из предыдущих заметок я привел теоретическое описание компонентной архитектуры сервисов (SCA). Однако любая теория требует практического подкрепления, поэтому в данной заметке мы рассмотрим использование SCA-контейнера сервера приложений Oracle WebLogic и Spring Framework для реализации некоторых из довольно часто используемых паттернов интеграции корпоративных приложений (EIP) - Обогатитель данных (Data Enricher) и основанный на нем паттерн Квитанция (Claim Check).

Паттерн Обогатитель данных



Если есть две интегрируемые системы, одна из которых возвращает меньше данных, нежели нужно другой, то такие данные требуется обогащать - добавлять недостающие, получая их из некоторого хранилища. Например, по почтовому индексу, передаваемому системой-источником, можно получить во внешнем хранилище, например в БД КЛАДР, населенный пункт абонента и передать его в систему-приемник. В данном случае Обогатитель данных выступает специальным трансформатором преобразующим сообщение с неполным набором данных в итоговое сообщение. Важным компонентом данного паттерна является внешнее хранилище данных, которое может представлять собой СУБД, некоторое предустановленное корпоративное приложение или публичную службу.

Паттерн Квитанция




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

вторник, 20 ноября 2012 г.

Асинхронный веб-сервис на Oracle Service Bus

Обеспечить асинхронное взаимодействие с веб-сервисом по протоколу HTTP можно не только с помощью Oracle SOA Suite, но и с помощью Oracle Service Bus. Основная сложность при этом заключается в том, что Oracle Service Bus не содержит встроенных средств сохранения состояния, поэтому необходимо будет каким-то образом сохранить во внешней памяти URL сервиса обратного вызова и идентификатор сообщения, на которое мы отвечаем. Так же нам нужно будет самостоятельно сформировать заголовок ответного SOAP-сообщения, соответствующий спецификации WS-Addressing. Давайте посмотрим как это можно сделать.

воскресенье, 11 ноября 2012 г.

Модель потоков Oracle Service Bus

Чтобы разрабатывать эффективные с точки зрения производительности сервисы на Oracle Service Bus, необходимо понимать как данная шина использует потоки.

Общая модель потоков


Общая модель потоков OSB, т.е. модель потоков при использовании маршрутизации, следующая: ветвь обработки запроса выполняется в одном потоке, потоке для WorkManager'а прокси-сервиса, ветвь обработки ответа - в другом потоке - потоке для WorkManager'а бизнес-сервиса. После отправки запроса вызываемому сервису поток прокси-сервиса возвращается в пул потоков. Существует специальный мультиплексор, muxer, который используется для ожидания ответа от вызванного сервиса. После получения ответа тот передает его на обработку новому потоку, который используется для исполнения ветви обработки ответа (Response Pipeline). Данная архитектура подразумевает, что пока осуществляется ожидание ответа от бизнес-сервиса, никакие потоки не используются, что существенно улучшает масштабируемость в терминах использования потоков.

среда, 7 ноября 2012 г.

Интеграция Spring Framework и консоли администрирования сервера приложений WebLogic

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

пятница, 26 октября 2012 г.

Знакомимся: Компонентная архитектура сервисов - Service Component Architecture (SCA)

Компонентная архитектура сервисов (SCA) - это множество спецификаций, описывающих модель построения приложений и систем с использованием сервис-ориентированной архитектуры (SOA). SCA расширяет и дополняет предыдущие методы реализации сервисов и основывается на открытых стандартах, таких как веб-сервисы.

По-сути, SCA обеспечивает программную модель для реализации SOA.


Спецификация состоит из двух основных частей, описывающих методы

  1. Реализации компонентов, предоставляющих одни и использующих другие сервисы.

  2. Объединения множества компонентов для построения бизнес-приложений путем связывания сервисов и сервисных ссылок (service references).


Разработчиком спецификации является консорциум Open SOA Collaboration (www.osoa.org). Текущая версия спецификации - 1.0 от 21 марта 2007 г. Некоторые части спецификации приняты позднее, например SCA Assembly Extensions for Event Processing and Pub/Sub V1.00 - 30 апреля 2009 г. Существует черновик версии 1.1, выпущенный 31 мая 2011. Несмотря на то, что это - черновик, он уже поддерживается Oracle.

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

четверг, 18 октября 2012 г.

Библиотеки, необходимые для сборки и развертывания OSB и SOA Suite проектов

Одной из популярных сегодня техник создания программного обеспечения является непрерывная интеграция. При внедрении данного процесса при разработке сервисной шины предприятия, основанной на Oracle Service Bus (OSB) или Oracle SOA Suite, требуется решить две задачи:

  • обеспечить сборку проектов OSB и SCA-композитов SOA Suite;

  • обеспечить развертывание собранных компонентов на сервере приложений Oracle WebLogic.

В сети представлено много материалов, описывающих автоматизацию этих задач. Рекомендую статью Станислава Девятова Непрерывная интеграция для Oracle SOA Suite 11g. В данной же заметке хочется рассмотреть вопрос минимизации количества необходимых библиотек.

вторник, 2 октября 2012 г.

Несколько слов в защиту шаблона "Анемичная модель предметной области" (Anemic Domain Model)

Мартином Фаулером в его классическом труде "Шаблоны корпоративных приложений" (Patterns of enterprise application architecture) выделено несколько подходов к организации бизнес-логики.

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

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

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

    Выделяют два варианта данного подхода:

    • Насыщенная модель предметной области - данные и поведение инкапсулируются внутри объектов предметной области.

    • Анемичная модель предметной области - в объектах предметной области инкапсулируются только данные, поведение же выносится в слой сервисов, расположенный поверх слоя предметной области.


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

вторник, 11 сентября 2012 г.

Создание кластера серверов приложений WebLogic с помощью WLST и утилит pack/unpack

В заметке полуторагодичной давности Создаем кластер серверов приложений WebLogic: балансировка нагрузки, обнаружение ошибок, репликация сессий Суровый расказывал о том, как создать домен с помощью Configuration Wizard. Однако у данного способа есть недостаток - он трудоемок для администратора. Посудите сами: администратор, каждый раз создавая домен, вынужден проходить по двум десяткам окон мастера, внося одни и те же изменения. А т.к. классический процесс разработки и внедрения предполагает наличие как минимум трех сред: разработки, интеграционного тестирования и промышленной эксплуатации, то придется создать как минимум три домена. При этом грамотно настроеная среда промышленной эксплуатации подразумевает кластеризацию и соответствующее увеличение экземпляров домена. К счастью, процесс создания домена можно автоматизировать с помощью утилиты WebLogic Scripting Tool (WLST).

понедельник, 27 августа 2012 г.

SOA Governance: создаем домен с OSB, SOA Suite, Oracle Enterprise Repository и Oracle Service Registry

Корпорация Oracle предлагает следующее программное обеспечение для построения процесса управления сервисно-ориентированной архитектурой предприятия (SOA Governance):

  • Oracle Enterprise Repository - репозиторий предприятия, предназначеный для хранения схем, описаний сервисов, самих сервисов, процессов, методологических документов, и прочего имущества (assets) предприятия. Позволяет гибко настраивать таксономию ресурсов и отслеживать взаимосвязи между ними. Опционально можно настроить политики, например стандарты качества, и отслеживать соответствие ресурсов данным стандартам.

  • Oracle Service Registry - UDDI v3-совместимый реестр сервисов. Интегрируется как с Oracle SOA Suite, так и с Oracle Service Bus, а так же позволяет публиковать и искать сервисы с помощью Eclipse и JDeveloper.

  • Oracle Enterprise Gateway - средство защиты сервисно-ориентированной архитектуры. Как видно из названия, реализует паттерн Gateway в противовес паттерну Agent, реализуемому Oracle Web Services Manager'ом.

  • Oracle Enterprise Manager SOA Management Pack Enterprise Edition - средство управления сервисно-ориентированной архитектурой предприятия во время исполнения.

  • Oracle SOA Suite - средство реализации сервисов. Содержит такие компоненты как Mediator, BPEL, Business Rules, Human Task, а так же поддерживает интеграцию со Spring Framework. В состав SOA Suite входит Oracle Web Services Manager - средство, используемое для обеспечения работы политик WS-Policy.


вторник, 31 июля 2012 г.

Многоуровневая SOA

В заметке рассмотрена многоуровневая сервисно-ориентированная архитектура и ее отображение на технологическую платформу Oracle SOA Suite.

В типичной сервисно-ориентированной архитектуре на предприятии можно выделить пять основных слоев:

  1. Пользовательский интерфейс (User Interface).

  2. Бизнес-процессы (Business Processes).

  3. Бизнес-сервисы (Business Services).

  4. Виртуальные сервисы (Virtual Services).

  5. Сервисы приложений (Application Services).


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

  1. Пользовательский интерфейс (User Interface).

  2. [Виртуальные сервисы].

  3. Бизнес-процессы (Business Processes).

  4. Бизнес-сервисы (Business Services).

  5. Виртуальные сервисы (Virtual Services).

  6. Сервисы приложений (Application Services).

Рассмотрим данные слои подробнее, снизу-вверх.

четверг, 26 июля 2012 г.

Интеграция: Oracle Service Bus vs Oracle SOA Suite

Несмотря на то, что лицензионно Oracle Service Bus входит в состав Oracle SOA Suite, фактически это - два пакета, соответственно инсталлировать и использовать можно как каждый из них в отдельности, так и оба вместе. В данной заметке мы разберемся для каких задач, решаемых при интеграции приложений, следует использовать Oracle Service Bus, а для каких - композитные приложения, реализуемые с помощью Service-Component Architecture(SCA)-контейнера Oracle SOA Suite.

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

вторник, 24 июля 2012 г.

1Z0-451 Oracle SOA Foundation Practitioner успешно сдан

Сегодня Суровый сдал экзамен Oracle SOA Foundation Practitioner. Сдал на 95 баллов. Меня данный результат очень обрадовал. Лучше в своей жизни я сдавал только ЕГЭ по физике в далеком 2003-м году: 97 баллов.

Не имею права рассказывать об экзамене и вопросах, расскажу лишь о том, как готовился.

Время, прошедшее между решением "буду сдавать" и получением отчета с заветной строчкой Pass, составило одну неделю. Конечно, здесь можно заметить, что помимо этой недели у меня есть два года опыта практического использования Oracle SOA Suite, но во время работы приходится использовать не все возможности продукта, поэтому подучиться и что называется "подтянуть хвосты" все же пришлось. Собственно, это и есть основное предназначение сертификации - дать цель устранить пробелы в знаниях и получить полный обзор возможностей продукта.

Для подготовки нужны две вещи: материалы и технология. В качестве материалов рекомендую использовать две следующие книги:

  • Oracle SOA Suite 11g Handbook by Lucas Jellema - книга довольно затянута и местами нудная, но некоторые главы, особенно касающиеся Oracle Service Bus, написаны очень хорошо.

  • Oracle SOA Suite 11g R1 Developer's Guide by Antony Reynolds and Matt Wright - на мой взгляд данная книга читается легче предыдущей, но некоторые моменты в ней описаны недостаточно полно. Не совсем понравилось, что информация об Oracle Service Bus размазана по всей книге, хотя это является следствием просто другого подхода к компоновке материала.

Помимо книг обязательна если не к прочтению, то хотя бы к беглому ознакомлению официальная документация. Прежде всего, это - Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1.

Стоит отметить, что по дополнительным компонентам, например Oracle B2B информации в книгах или нет или крайне мало, поэтому рекомендуются к ознакомлению User Guide'ы по следующим технологиям: Technology Adapters, Applications Adapters, Business Rules, B2B, CEP и BAM.

По Oracle Service Bus рекомендуется к прочтению документ под названием Concepts and Architecture. Он не слишком объемный, но полезный. Если же его читать лень, то обратите внимание на 13-ю главу книги Lucas Jellema.

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

Как всегда рад ответить на ваши вопросы в комментариях.

Понравилось сообщение - подпишитесь на блог и Twitter

воскресенье, 8 июля 2012 г.

Ищу разработчика ESB

UPD 27.07.2012: Вакансия закрыта, спасибо всем откликнувшимся.

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

Мне нужен человек, который знает и понимает, что такое SOA, умеет программировать на Java, желательно, знакомый с языком BPEL. Умение разрабатывать веб-сервисы и рассказать на собеседовании о структуре WSDL-описания будет большим плюсом. Знакомство с СУБД Oracle тоже приветствуется.

Самое главное: мы используем продуктовый стек Oracle Fusion Middleware: WebLogic Server, SOA Suite и Service Bus. Если вы знакомы с данным стеком, то это очень хорошо, если нет - не беда, готов обучить. В свою очередь ожидаю от кандидата способность и желание учиться.

Что мы предлагаем:
- Белую заработную плату, оформление по ТК;
- Оплату мобильной связи;
- Соцпкет (ДМС, обучение, фитнес);
- Сурового руководителя группы.

Наш офис находится на ст. м. Савеловская, м. Марьина Роща.

Если заинтересовались, то присылайте резюме на hr@at-consulting.ru, ну или мне - psamolysov@at-consulting.ru.

Важно: к сожалению, у нас не принято публиковать вилки зарплат. Готовы выслушать ваши пожелания.

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

Понравилось сообщение - подпишитесь на блог и Twitter

четверг, 5 июля 2012 г.

Потоки в управляемой среде. WorkManager

Вся мощь серверов приложений проявляется в том, что они обеспечивают управляемую среду исполнения программ. С одной стороны это обозначает, что сервер приложений предоставляет некий набор API, например JSR-316 - Java EE 6, а с другой - сервер приложений предоставляет средства, обеспечивающие управление жизненным циклом программы, транзакциями, доступом к ресурсам и другим системам, а так же потоками.

Пул потоков


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

Администратор сервера приложений может настроить следующие параметры пула:

  • Приоритет потоков - параметр позволяет ранжировать потоки, создаваемые разными пулами, по приоритету. Таким образом можно настроить поведение при котором запрос пользователя к критичному для бизнеса приложению приостанавливает другие потоки в системе.

  • Количество потоков в пуле - параметр позволяет задать минимальное и максимальное количество потоков, находящихся в пуле. При этом современные сервера приложений, например Oracle WebLogic, позволяют не ограничивать максимальное значение потоков в пуле константой, а указать источник данных (пул соединений с базой данных), на основе которого данное значение будет вычисляться. Таким образом обеспечивается полное однозначное соответствие - одно соединение с базой данных на один поток.


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

среда, 4 июля 2012 г.

Почему я не участвую в спорах Spring vs JavaEE

На мой взгляд спор не имеет смысла - один и тот же POJO может замечательно жить и под управлением EJB-контейнера и под управлением Spring Framework. Аргументы в стиле "EJB плохо тестируются" так же не состоятельны: при тестировании можно использовать Spring.

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

Позволю себе продемонстрировать данное мнение кодом, думаю так будет максимально наглядно. Данную заметку так же можно использовать в качестве пособия по интеграции JPA и Spring Framework.

IService:

package name.samolisov.demo;



public interface IService {



    public void transaction();

}

 

Service:

package name.samolisov.demo;



import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;



import name.samolisov.transactions.entity.Entity;



public class Service implements IService {

   

    @PersistenceContext(unitName = "TransactionSA")

    private EntityManager em;

       

    public void transaction() {        

        em.persist(new Entity(Thread.currentThread().getName()));      

    }  

}

 

Entity:

package name.samolisov.transactions.entity;



import javax.persistence.GeneratedValue;

import javax.persistence.Id;

import javax.persistence.SequenceGenerator;



@javax.persistence.Entity

public class Entity {

   

    @Id

    @SequenceGenerator(name = "EntitySeqGen", sequenceName = "id_seq", allocationSize = 10)

    @GeneratedValue(generator = "EntitySeqGen")        

    private Long id;

   

    private String message;



    public Entity() {

       

    }

   

    public Entity(String message) {

        this.message = message;

    }

   

    public Entity(Long id, String message) {

        this.id = id;

        this.message = message;

    }

   

    public Long getId() {

        return id;

    }



    public void setId(Long id) {

        this.id = id;

    }



    public String getMessage() {

        return message;

    }



    public void setMessage(String message) {

        this.message = message;

    }  

}

 

persistence.xml:

<?xml version="1.0" encoding="UTF-8"?>

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

    <persistence-unit name="TransactionSA" transaction-type="JTA">

        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

        <jta-data-source>jdbc/xa/sa</jta-data-source>

        <class>name.samolisov.transactions.entity.Entity</class>

        <properties>

            <property name="eclipselink.target-server" value="WebLogic_10"/>

        </properties>

    </persistence-unit>

</persistence>

 

понедельник, 18 июня 2012 г.

Структура методологии разработки/внедрения программного обеспечения

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

  • Что?
    Что мы делаем: разрабатываем новое ПО с нуля, занимаемся офшорным программированием, внедряем готовую систему или всего понемножку.

  • Кто?
    Состав команды, выполняющей проект. Например: бизнес-аналитик, системный аналитик, архитектор, разработчики, тестировщики, технический писатель.

  • Как?
    Основные этапы и принципы организации процесса. Например, процесс итерационный, каждая итерация длится 2-4 недели и заканчивается поставкой новой версии заказчику. Итерация состоит из этапов анализа, проектирования, разработки, тестирования, внедрения.

    Стоит заметить, что некоторые методологии, например Oracle Unified Method, идут дальше и предлагают подробный состав работ. При этом в описании каждой работы приведен еще и шаблон документа, которым должно заканчиваться исполнение данной работы.

  • Обряды
    В каком-то смысле это часть ответа на вопрос "Как?". Обряд - это важное для успеха проекта по мнению участников действие. Например, ежедневные пионерские линейки.

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

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

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

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

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

P.S. Для затравки:

Понравилось сообщение - подпишитесь на блог и Twitter

суббота, 16 июня 2012 г.

Координация родительских и дочерних BPEL-процессов. Сигналы

Продолжаем серию уроков по BPEL. Сегодня мы рассмотрим специфическое для Oracle SOA Suite средство организации взаимодействия между экземплярами BPEL-процессов - сигналы.

Постановка задачи координации родительских и дочерних процессов


При моделировании бизнес-процессов иногда требуется вынести некоторую логику в отдельные подпроцессы. Данная необходимость может объясняться желанием повторно использовать данную логику или распараллелить выполнение подпроцессов с целью увеличения производительности. Основной процесс в терминологии Oracle называется "мастером" или "родительским", а подпроцесс - "детальным" или "дочерним" процессом.

Взаимодействие с BPEL-процессами реализуется точно так же, как и с другими сервисами. При этом существует три основных паттерна взаимодействия родительского и дочерних процессов:
  1. Родительскому процессу интересен только факт запуска экземпляров дочерних процессов. Данный паттерн так же называется "Вызови и забудь" (fire and forget). Родительский процесс создает один или несколько экземпляров дочернего процесса, при этом его не интересует их последующее исполнение.
  2. Родительскому процессу интересна информация, возвращаемая дочерними. В таком случае родительскому процессу необходимо ожидать ответ от каждого из них. В случае синхронного взаимодействия ответ и так подразумевается, а в случае асинхронного - родительский процесс продолжает работу после получения ответа от дочернего, а для связывания запроса и ответа используется механизм корреляции или WS-Addressing.
  3. Родительскому процессу интересен факт завершения выполнения некоторых действий дочерним процессом, но не результаты этого выполнения. Т.е. родительский процесс нуждается не в сообщении от дочернего, а в некотором сигнале.

Действия Signal и Receive Signal - Oracle'овое расширение языка BPEL - позволяют реализовать третий паттерн взаимодействия процессов.

понедельник, 11 июня 2012 г.

Длительно выполняющиеся транзакции в BPEL. Механизм компенсаций

Язык Business Process Modeling and Execution Language (BPEL, читается «БИПЛЬ») предназначен для моделирования бизнес-процессов предприятия посредством оркестровки сервисов. При этом, как исполнение самих операции сервисов, так и принятие решения о том, какой именно сервис вызвать, могут занимать довольно длительное время: часы, дни, недели. Особо характерна большая длительность операций в том случае, если они выполняются пользователями.

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

воскресенье, 27 мая 2012 г.

Уровни сложности сервисов

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

суббота, 26 мая 2012 г.

Мониторинг производительности Oracle SOA Suite


Основным инструментом для мониторинга производительности Oracle SOA Suite является Oracle Enterprise Manager Fusion Middleware Control Console (в дальнейшем - EM). Предлагаю рассмотреть основные возможности данного инструмента.

четверг, 17 мая 2012 г.

Обеспечение гарантированного порядка обработки сообщений в кластерном окружении с помощью JCA-адаптеров Oracle SOA Suite

В данной заметке описано как настроить JCA-адаптеры Oracle SOA Suite для обеспечения гарантированного порядка обработки сообщений в кластерном окружении.

При интеграции информационных систем, особенно унаследованных, часто приходится обеспечивать взаимодействие с ними через базу данных. В состав Oracle SOA Suite входят адаптеры, реализованные с помощью технологии JCA, позволяющие считывать события из базы данных. Примерами таких адаптеров являются DB- и AQ-адаптеры.

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

среда, 9 мая 2012 г.

Асинхронные веб-сервисы

В данной статье описаны подходы к реализации асинхронного взаимодействия между информационными системами с помощью веб-сервисов. Подробно рассмотрен применяющийся в Oracle SOA Suite подход, основанный на использовании сервиса обратного вызова и стандарта WS-Addressing. Приведены примеры создания асинхронного веб-сервиса с помощью Oracle SOA Suite и генерации клиента к такому сервису с помощью интегрированной среды разработки Oracle JDeveloper.

Введение


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

В Oracle SOA Suite применяется второй подход: потребитель сервиса является одновременно поставщиком сервиса обратного вызова. В свою очередь поставщик сервиса после получения запроса от потребителя возвращает ему HTTP-ответ 202 Accepted, что обозначает успешное принятие запроса на обработку. В Oracle SOA Suite при этом создается новый экземпляр композита. После завершения обработки запроса, которая может занимать достаточно много времени, например недели, что особенно характерно, если в обработке запроса участвуют люди, поставщик сервиса осуществляет вызов сервиса обратного вызова, предоставляемого потребителем.

воскресенье, 11 марта 2012 г.

Три подхода к интеграции информационных систем


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

Итак:

  1. Интеграция на уровне данных. Суть данного подхода заключается в следующем: приложения работают независимо друг от друга, каждое использует свой набор данных. В случае необходимости осуществляется обмен данными между приложениями. При этом, если обмен данными осуществляется путем вызова сервисов или отправки/получения сообщений, то в качестве среды для обмена можно использовать сервисную шину предприятия - Enterprise Service Bus (ESB). Если же обмен данными производится в основном между базами данных, используемыми тем или иным приложением, то можно использовать решение класса Extract, Transform, Load (ETL). При этом некоторые реализации ETL, например Oracle Data Integration (ODI), могут использовать в качестве источников и приемников данных веб-сервисы и системы класса Message-oriented Middleware (MOM).

  2. Интеграция на уровне бизнес-процессов. Суть данного подхода заключается в следующем: приложения выставляют сервисы, являющиеся интерфейсами к бизнес-логике данных приложений. Взаимодействие между приложениями реализовано в рамках бизнес-процесса, на отдельных шагах которого осуществляется вызов того или иного сервиса. Реализуется данный подход с помощью сервисной шины предприятия (ESB), которая занимается виртуализацией сервисов, предоставляемых приложениями, и решений класса Business Process Management System (BPMS), как правило основанных на языках BPEL или BPMN, которые реализуют логику процесса.

  3. Интеграция на уровне композитных приложений. Бизнес-логика отдельного приложения строится путем вызова сервисов, предоставляемых как данным приложением, так и другими системами. Таким образом на одном шаге бизнес-процесса могут взаимодействовать несколько сервисов, в то время как при интеграции на уровне бизнес-процессов на одном шаге процесса вызывается один сервис. Реализация композитных приложений осуществляется с помощью использования технологий Java Business Integration (JBI, JSR 208) или Service Component Architecture (SCA). В качестве SCA-контейнеров можно использовать Oracle WebLogic, Oracle SOA Suite или Apache Tuscany.


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

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

Понравилось сообщение - подпишитесь на блог и Twitter

четверг, 23 февраля 2012 г.

Выпущен Oracle Fusion Middleware 11.1.1.6


Корпорация Oracle выпустила очередную версию платформы Oracle Fusion Middleware - 11.1.1.6 (коммерческий номер - 11gR1 PS5). Забавно то, что ссылки на скачивание в OTN пока размещены не на всех страницах компонентов платформы. Т.е. скачать Oracle SOA Suite 11.1.1.6 со страницы SOA Suite нельзя, а со страницы BPM Suite - можно. К сожалению, Oracle Service Bus пока недоступна на OTN, но доступна на Edelivery.

Будьте внимательны!

UPD 26.02.2011:


Понравилось сообщение - подпишитесь на блог и Twitter

суббота, 18 февраля 2012 г.

Разработка системы мониторинга на базе Oracle BAM


В заметке введение в Oracle Business Activity Monitoring (BAM) Суровый обещал привести пример использования данного инструмента. Пришло время исполнить данное обещание.

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

четверг, 16 февраля 2012 г.

Два подхода к построению интеграционной шины предприятия


На мой взгляд можно выделить два подхода к построению интеграционной шины предприятия:

  • "от интегрируемых систем";

  • "от реализуемых процессов".


Давайте рассмотрим данные подходы подробнее.

воскресенье, 5 февраля 2012 г.

Введение в Oracle Business Activity Monitoring (BAM)


Одной из важнейших задач при внедрении на предприятии сервисно-ориентированной архитектуры (SOA), архитектуры, управляемой событиями, (EDA) и сквозных бизнес-процессов (BPM) является задача мониторинга - наблюдение в реальном времени за изменением ключевых показателей (KPI), обеспечением SLA и принятие мер в случае их нарушения. В линейке продуктов Oracle Fusion Middleware присутствует компонент, предназначенный для решения данной задачи, - Oracle Business Activity Monitoring (BAM).

воскресенье, 29 января 2012 г.

О построении сервисно-ориентированной архитектуры на предприятии


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

Для решения данной задачи нужно обеспечить исполнение следующих условий:

1. Переход от интеграции по принципу точка-точка к интеграции через сервисную шину предприятия (ESB).

2. Обеспечение независимости интеграции от форматов передаваемых сообщений.

3. Документирование в достаточном объеме и качестве.

4. Наличие мониторинга процесса передачи и обработки сообщений.