Многоуровневая 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).

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

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

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

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

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

Ищу разработчика 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

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

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

Пул потоков

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

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

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

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

Почему я не участвую в спорах 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>

 

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

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

• Что?
  Что мы делаем: разрабатываем новое ПО с нуля, занимаемся офшорным программированием, внедряем готовую систему или всего понемножку.
  
  
• Кто?
  Состав команды, выполняющей проект. Например: бизнес-аналитик, системный аналитик, архитектор, разработчики, тестировщики, технический писатель.
  
  
• Как?
  Основные этапы и принципы организации процесса. Например, процесс итерационный, каждая итерация длится 2-4 недели и заканчивается поставкой новой версии заказчику. Итерация состоит из этапов анализа, проектирования, разработки, тестирования, внедрения.
  
  Стоит заметить, что некоторые методологии, например Oracle Unified Method, идут дальше и предлагают подробный состав работ. При этом в описании каждой работы приведен еще и шаблон документа, которым должно заканчиваться исполнение данной работы.
  
  
• Обряды
  В каком-то смысле это часть ответа на вопрос "Как?". Обряд - это важное для успеха проекта по мнению участников действие. Например, ежедневные пионерские линейки.
  
  
• Внутренние артефакты
  Внутренние артефакты - средства коммуникации внутри команды. Это может быть доска с диаграммой сгорания задач, техническое задание, спецификация информационных потоков и т.д.
  
  
• Внешние артефакты
  По-сути, это - то, чем команда будет отчитываться перед заказчиком. В российских реалиях это обычно следующие документы: технические требования, техническое задание, эскизный проект, технический проект, рабочий проект, программа и методика испытаний, протокол испытаний.
  

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

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

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

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

• Экстремальное программирование - реальность и мифы.
  
• Обзор методологии Scrum.
  
• Методология Oracle Unified Method.

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