Общая корпоративная шина (Enterprise Service Bus)

Оглавление

1.Общая корпоративная шина (Enterprise Service Bus) 3

2. Протокол WS-Routing (Web Services Routing Protocol) 8

3. Тип имеет значение: исследование фокусируемых на типе веб-сайтов 11

 

  

1.Общая корпоративная шина (Enterprise Service Bus)

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

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

Одним из наиболее эффективных  решений данной проблемы, на сегодняшний  день, является построение объединенной инфраструктуры бизнес-приложений, основанной на архитектуре Enterprise Service Bus (общая корпоративная шина, ESB).

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

Интеграционная шина, как  правило, предоставляет следующие  функции:

- Преобразование сообщений,  а также их передача, алгоритмическое  перенаправление, постановка в  очередь и отслеживание;

- Работа с сообщениями  в режимах: синхронном, асинхронном,  «точка-точка», «публикация-подписка»;

- Поддержка XML и SOAP сообщений;

- Возможность подключения  множества систем через готовые  адаптеры и API для написания  новых адаптеров;

- Оркестровка (автоматическое  размещение, координация и управление) служб.

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

Рисунок 1 Архитектура с  использованием интеграционной шины

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

• Внести данные клиента
• Проверить, существует ли запись о данном клиенте 
• Получить список счетов клиента
• Получить список сервисов, которыми пользовался клиент
• Получить агрегированные данные по истории выплат по кредитам
• Получить данные для отчета
• Получить баланс счета
• Рассчитать кредитный рейтинг
• Сформировать отчет для рассмотрения менеджером
• Обновить данные по счету
• Сформировать уведомление для клиента

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

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

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

Следующая иллюстрация показывает, как меняется взаимодействие IT систем банка после внедрения интеграционной шины.

Рисунок 2 ИТ-архитектура банка до и после внедрения шины

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

Рассмотрим внедрение  интеграционных шин в нескольких крупных международных банках.

Chinatrust Commercial Bank (Коммерческий банк Чайнатраст) использует интеграционную шину для поддержки своих продуктов и сервисов. Сервис-ориентированная архитектура на основе интеграционной шины объединяет более семидесяти систем на множестве платформ, таких как: автоматизированная банковская система, сетевой банкинг, ипотечная система, лотерейная система, система автоматизации рабочих процессов, интерактивное голосовое меню и т.д. В режиме реального времени стали доступны такие сервисы, как: агрегация данных, сводка по счету, входящие и исходящие переводы, трансферы, уведомления (задействован функционал событийно ориентированных коммуникаций) и другие. Расходы на интеграцию новых систем снизились в среднем на 30..40%.

В настоящее время интеграционная шина банка поддерживает 100 000 ежедневных транзакций в корпоративном секторе и 50 000 в ритейле. Количество транзакций онлайн банкинга возросло с 150 000 до 1 200 000 в сутки.

Сингапуро-малазийский банк OCBC недавно  поставил себе цель в пятилетний срок повысить эффективность работы на 25% и снизить затраты на разработку новых программных интерфейсов на 30%. Первый сервис на основе SOA был запущен в 2006 году. Через шесть месяцев работало 116 единичных сервисов, каждый из которых пригоден к использованию в составных сервисах. 50 единичных сервисов являлись частью нескольких составных. Для поддержки интеграционных процессов банк создал Центр Интеграционных Компетенций. В OCBC полагают, что для достижения заявленных целей SOA играет ключевую роль.

В Японии конкуренция в  области интернет-банкинга чрезвычайно  высока. Банк Sumishin Net Bank, Ltd. поставил целью предложить на рынок широкий набор продуктов за более короткий промежуток времени, чем прочие финансовые институты. Для достижения этой цели банку необходимо было соответствовать строгим техническим стандартам, накладываемым на японский банковский сектор и одновременно с этим развивать конкурентные преимущества.  Была разработана сервис-ориентированная архитектура с использованием десяти программных продуктов, в том числе интеграционной шины. Всего лишь в течение 18 месяцев после запуска новой линейки услуг в банк было вложено ориентировочно 600 млрд. йен (около $6 млрд.), открыто 400 000 счетов. Была достигнута невероятная гибкость в добавлении новых сервисов. Существенно снизилась стоимость их разработки.

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

2. Протокол WS-Routing (Web Services Routing Protocol)

Протокол WS-Routing (Web Services Routing Protocol), разработанный корпорацией Microsoft в 2001 году предназначен для создания и отправки SOAP-посланий, не требующих ответа и подтверждения получения. Послание, отправленное по протоколу WS-Routing, может на своем пути пройти несколько промежуточных серверов (actors), которые могут сделать предварительную обработку послания (forward message path). Это делает и обычное SOAP-послание, но протокол WS-Routing, в отличие от протокола SOAP, определяет точный порядок прохождения промежуточных серверов. Это позволяет спланировать последовательность обработки послания промежуточными серверами. Хотя протокол не предназначен для двусторонней связи, он позволяет отследить обратный путь (reverse message path) для посылки ответного послания.

Послание, созданное по правилам протокола WS-Routing, можно отправить не только по протоколам HTTP или SMTP, но и прямо по протоколу TCP или UDP, причем промежуточные серверы могут по своему усмотрению менять транспортный протокол.

Итак, главная цель протокола WS-Routing — обеспечить точный маршрут прохождения SOAP-послания от отправителя до получателя. Дополнительно можно задать обратный маршрут. Для достижения этих целей в заголовок SOAP-послания <Header> вкладывается элемент <path>, в котором вложенным элементом <from> указывается адрес URI отправителя, элементом <to> — адрес URI получателя, а элементами <via> — адреса URI промежуточных серверов. Элементы <via> записываются внутри элемента <fwd> и показывают маршрут от отправителя к получателю. Порядок прохождения промежуточных пунктов соответствует порядку записи элементов <via>. Обратный маршрут, если он нужен, указывается элементами <via>, вложенными в элемент <rev>.

Простейшее послание не содержит промежуточных адресов и адреса отправителя. Оно выглядит примерно так:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header>

<m:path xmlns:m= "http: //schemas .xmlsoap.org/rp/">

<m:action>http://s ome.com/update</m:act ion> <m:to>soap://D.com/endpoint;up=udp</m:to>

<m: id>uuid: 09233523-345b-4351-b623-5dsf35sgs5d6</m: id> </m:path> </env:Header>

<env:Body>

< ! — Содержимое послания…  —>

</env:Body>

</env:Envelope>

В этом примере показаны еще два обязательных элемента SOAP-послания, составленного по протоколу WS-Routing.

Обязательный элемент <action> указывает строкой URI программу-обработчик послания. Обязательный элемент <id> содержит строку URI, однозначно идентифицирующую данное послание. Это полезно для связи друг с другом подряд идущих посланий или для ссылки ответного послания на послание, вызвавшее ответ. Если надо указать промежуточные серверы, например, В.com и C. com то к посланию добавляется элемент <fwd> и вложенные в него элементы <via>:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env: Header>

<m:path xmlns :m="http: //schemas. xmlsoap. org/rp/"> <m:action>http://some.com/update</m:action> <m:to>soap://D.com/endpoint</m: to> <m: fwd>

<m:via>soap://В.com</m:via> <m: viaosoap://C. conK/m: via> </m:fwd>

<m:id>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</m:id>

</m:paith> </env:Header>

<env:Body>

< ! — Содержимое послания…  —> </env^:Body>

</env:Envelope>

Наконец, если нужно указать  обратный путь, то добавляются элементы <from> и <rev>:

<env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header>

<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">

<m:action>http://www.notification.org/update</m:action> <m:to>soap://D.com/endpoint</m:to>

<m:fwd>

<m:via>soap://B.com</m:via> <m:via>soap://C.com</m:via>

</m:fwd>

<m:rev>

<m:via/> </m:rev>

<m:from>mailto:ivanov@some.com</m:from>

<m:id>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</m:id>

</m:path>

</env:Header>

<env:Body>

<!—Содержимое послания…  —> </env:Body>

</env: Envelope>

В этом примере пустой элемент <m:via/> указывает, что выбор обратного пути возлагается на транспортный протокол.

3. Тип имеет  значение: исследование фокусируемых на типе веб-сайтов

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

Почему структура сетки  и состав крайне важны для типографии?

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

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

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

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

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

У структуры  сетки данного примера есть шесть  столбцов, которые объединяют информацию в визуально удобные сегменты. Непротиворечивая типографская система  для заголовков контрастирует с  более легкими тонами. Используется более приятный и удобный для  чтения шрифт.

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

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

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