Подключение при помощи адаптеров WebSphere Integration Developer: Часть 1. Введение.

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

Уровень сложности: средний

Джон Грин , штатный консультант, IBM Toronto Lab
Грег Адамс, инженер, IBM
Рэнди Гиффен, консультант по разработке ПО, IBM
Ричард Грегори, штатный разработчик ПО, IBM

12.03.2008

В серии статей "Экскурсия по WebSphere® Integration Developer" мы рассмотрели основы создания сервис-ориентированного приложения при помощи WebSphere Integration Developer. В данной серии статей мы исследуем вопросы интеграции приложения в корпоративные информационные системы, системы обмена почтовыми сообщениями и системы управления базами данных, рассматривая их как повторно применяемые сервисы, использующие адаптеры ресурсов. В данной статье рассказывается, что такое адаптеры ресурсов, как они могут решать обычные бизнес-проблемы и как их использовать в приложениях. В последующих статьях вы узнаете о специфических адаптерах и создадите ваши собственные приложения, их использующие.

От IBM WebSphere Developer Technical Journal.

Введение: корпоративные информационные системы как реализации сервисов

В серии статей "Экскурсия по WebSphere Integration Developer" мы познакомили вас с концепциями создания приложения с сервис-ориентированной архитектурой (service-oriented architecture - SOA), использующего WebSphere Integration Developer. Мы продемонстрировали каждый из типов компонентов, который можно использовать для реализации приложения. Компоненты являются черными ящиками, которые подключаются для формирования приложения. Термин "черный ящик" означает, что каждый компонент ничего не знает о внутренней работе другого компонента. Компоненты можно реализовать с использованием машин бизнес-состояний (business state machines), бизнес-процессов, пользовательских задач, бизнес-правил и многого другого.

Возможно, у вас появилось странное ощущение, что все является компонентом. Вы абсолютно правы. В мире SOA все является сервисом, а в WebSphere Integration Developer сервисы реализованы при помощи компонентов. Применив это золотое правило к корпоративной информационной системе (enterprise information system - EIS), мы обнаружим, что хотим рассматривать нашу EIS тоже в виде черного ящика. Другими словами, мы хотим обращаться к нашей информационной системе как к любому другому компоненту, так чтобы не иметь дела с деталями логики EIS. В конечном счете, мы хотели бы, чтобы наша бизнес-логика пребывала в счастливом неведении относительно тайн EIS.

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

EIS-компонент выполняет кодирование, используя специализированный адаптер, позволяющий компоненту общаться с конкретной EIS. Адаптеры бывают самых разных видов и размеров (но не цветов); некоторые работают с базами данных, некоторые с однородными файлами (flat files) файловой системы, а некоторые с функциями EIS.

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

Подключение к EIS не представляет трудности: выбирается адаптер для конкретной EIS, которому сообщается, к какой системе нужно обратиться. Затем WebSphere Integration Developer в пошаговом режиме создаст EIS-компонент, который будет представлен в модуле в виде компонентов import или export, использующих этот адаптер. WebSphere Integration Developer даже создаст бизнес-объект, соответствующий данным, с которыми вы работаете в EIS.

Вы, наверное, помните по серии статей "Экскурсия по WebSphere Integration Developer", что, поскольку EIS-компонент не реализуется в вашем модуле (адаптер ресурсов реализует EIS-компонент), обращение к нему производится через компоненты import или export. import - это компонент, реализуемый вне модуля. Он использует процедуру связывания (binding), например, связывание с Web-сервисом для подключения к Web-сервису или SCA-связывание для подключения к другим модулям. export - это часть модуля, которая делает компонент видимым для остальных модулей или приложений.

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

На рисунке 1 изображены фундаментальные концепции адаптеров. Предположим, что интегрируется специализированная информация, часть которой предоставляется в XML-файлах (однородные файлы в отличие от структурированной базы данных), и эта же информация есть в базе данных. Данная информация должна синхронизироваться в обеих системах. Теперь предположим, что возникает событие, когда однородный файл обновляется новой пользовательской информацией. Адаптер ресурсов использует компонент export модуля для активизации операции в компоненте SyncCustomerData, являющейся запросом входящего сервиса к модулю.

Это довольно простой пример. В других сценариях может присутствовать большее количество компонентов в модуле, используемых компонентом бизнес-процесса для выполнения своей работы, и интерфейсная карта (interface map) для выполнения всех преобразований данных, необходимых для различных систем хранения данных. Наконец, после завершения своей работы процесс вызывает операцию CustomerEISImport. Компонент import использует адаптер ресурсов для записи обновленной информации в базу данных, что является запросом исходящего сервиса из модуля.

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

В начало

Что такое адаптер ресурсов

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

Адаптеры ресурсов приносят пользу в следующих случаях:

• Во-первых, если вы сами создаете бизнес-приложение, адаптер ресурсов автоматически определяет, что доступно в системе хранения данных, и отображает это как сервисы и бизнес-объекты. Адаптер ресурсов определяет общий интерфейс, который WebSphere Integration Developer использует для общения с системой хранения данных и обнаружения сервисов и бизнес-объектов.
• Во-вторых, во время исполнения созданный WebSphere Integration Developer компонент (с использованием функциональности обнаружения) делает всю сложную работу по сохранению (извлечению) бизнес-данных в (из) EIS.

Без адаптеров каждая EIS или сервер приложений должны были бы предоставлять свои собственные инструменты для подключения, или еще хуже, разработчики должны были бы писать специализированные программы подключения для каждой EIS и сервера приложений. Кроме того, такие инструменты как WebSphere Integration Developer должны были бы создавать код обнаружения, совместимый с огромным числом EIS. К счастью у нас есть адаптеры! При внедрении новой системы хранения данных можно быстро начать ее использование, если для нее имеется адаптер. Используя этот адаптер, WebSphere Integration Developer может обнаружить сервисы и создать компоненты import или export для них, а приложение сможет общаться с этой системой как с любым другим компонентом.

А теперь несколько слов от автора стандартов

Для того чтобы адаптер был полезен на различных платформах, он должен придерживаться общей спецификации. Адаптеры ресурсов WebSphere соответствуют спецификации J2EE Connector Architecture (JCA) 1.5. Эта спецификация определяет набор соглашений как для сервера приложений, так и для EIS. Таким образом, адаптер ресурсов SAP, соответствующий спецификации JCA 1.5, можно использовать на WebSphere Process Server или любом другом J2EE-совместимом сервере. Это действительно важно, поскольку поставщик системы может предоставить один единственный адаптер для своей системы, и его смогут использовать программы различных авторов и различные J2EE-совместимые сервера.

Постойте! Не бегите! Нет необходимости изучать спецификацию JCA. Как прикладному программисту или специалисту по интеграции вам не обязательно знать спецификацию; нужно знать только о том, как общаться с адаптером ресурсов из приложения. Как говорилось выше, это просто означает подключение вашего компонента (например, бизнес-процесса BPEL) к компоненту import, настроенному на использование адаптера.

В начало

Адаптеры, поставляемые с WebSphere Integration Developer

Теперь давайте кратко рассмотрим, какие адаптеры поставляются с WebSphere Integration Developer, а затем обсудим способы их использования.

Предыдущие версии WebSphere Integration Developer содержали только адаптеры ресурсов CICS® и IMS™, но WebSphere Integration Developer версии 6.0.2 предоставляет множество адаптеров ресурсов, поэтому можно подключаться к разнообразным популярным EIS и к большому количеству информационных систем, например, к текстовым файлам. В WebSphere Integration Developer включены и поддерживаются приведенные ниже адаптеры ресурсов IBM® WebSphere. Все адаптеры из этого списка соответствуют спецификации J2EE Connector Architecture 1.5. Несколько первых адаптеров поддерживают только исходящий сервис; все остальные поддерживают как входящий, так и исходящий сервис.

• IBM CICS ECI Resource Adapter Version 6.0.2: CICS (Customer Information Control System) - это система обработки транзакций, используемая в критичных бизнес-системах, таких как ATM (банкоматы) и системы резервирования авиабилетов. Данный адаптер поддерживает только исходящий режим.
• IBM IMS Connector for Java™ Version 9.1.0.2.2a: IMS (Information Management System) - это система управления транзакциями и иерархическими базами данных, десятилетиями используемая на мэйнфреймах. Данный адаптер поддерживает только исходящий режим.
• IBM WebSphere Adapter for JD Edwards EnterpriseOne Version 6.0.2: JD Edwards EnterpriseOne (в настоящее время принадлежит корпорации Oracle) - это набор бизнес-приложений для взаимодействия с клиентами, менеджмента, управления поставками и управления финансами для малых и средних предприятий. Данный адаптер поддерживает только исходящий режим.
• IBM WebSphere Adapter for Oracle® E-Business Suite Version 6.0.2: Oracle E-Business Suite - это набор приложений для управления ресурсами предприятия (enterprise resource planning - ERP), использующихся в таких областях как управление финансами, закупки, производство, логистика, управление кадрами и продажи.
• IBM WebSphere Adapter for PeopleSoft Version 6.0.0.1: Продукты компании PeopleSoft (в настоящее время принадлежит корпорации Oracle) - еще один набор ERP-приложений, который может быть настроен под конкретные бизнес-требования.
• IBM WebSphere Adapter for SAP® Software Version 6.0.2: SAP - еще один поставщик ERP-приложений (но не принадлежащий в настоящее время корпорации Oracle). Данный адаптер позволяет интегрировать различные SAP-интерфейсы с SAP Web Application Server.
• IBM WebSphere Adapter for Siebel Business Applications Version 6.0.2: Siebel Business Applications (тоже принадлежит корпорации Oracle) - это система планирования ресурсов клиентов. Данный адаптер подключается к приложениям Siebel путем вызова родных Siebel-интерфейсов для обмена бизнес-объектами с Siebel-приложением.
• IBM WebSphere Adapter for JDBC Version 6.0.2: EIS может быть также базой данных. Данный адаптер используется для обмена бизнес-объектами с любой базой данных, к которой можно подключиться при помощи JDBC.
• IBM WebSphere Adapter for Flat Files Version 6.0.2: Корпоративные информационные системы не обязательно являются монстрами, выполняющимися на мэйнфреймах. На малых предприятиях вполне можно обойтись хранением бизнес-данных в простых текстовых файлах. Для доступа к таким файлам используется адаптер ресурсов простых файлов, например, XML-формата или формата с разделением запятыми, точно так же, как и для доступа к другой EIS или базе данных.
• IBM WebSphere Adapter for E-mail Version 6.0.2: Как видно из названия, этот адаптер позволяет использовать электронную почту для обмена бизнес-объектами с различными приложениями, не предоставляющими программируемые или сервисные интерфейсы. Он проверяет почтовые ящики на серверах на наличие сообщений либо передает почтовые сообщения на почтовый сервер и выполняет преобразование между сообщениями и бизнес-объектами.
• IBM WebSphere Adapter for FTP Version 6.0.2: Аналогично адаптеру WebSphere Adapter for E-mail, адаптер FTP (File Transfer Protocol) помогает взаимодействовать с приложениями, использующими данные, которые не легко интегрировать. Он использует FTP-команды get и put для обмена бизнес-объектами с приложениями. Этот адаптер полезен при использовании текстовых файлов для хранения корпоративной информации, разбросанных по разным местам.

Помните о том, что адаптеры CICS, IMS, JD Edwards, Oracle, PeopleSoft, SAP и Siebel, поставляемые с WebSphere Integration Developer, лицензированы только для разработки. Это означает, что вы можете использовать их на вашем локальном тестовом сервере WebSphere Process Server. Однако перед использованием этих адаптеров на рабочем сервере, необходимо получить полную лицензию. Адаптеры JDBC, простых файлов, e-mail и FTP можно использовать как во время разработки, так и на рабочем сервере.

Информацию о лицензировании можно найти в Software license agreements search; введите название любого адаптера из приведенного выше списка для поиска информации о лицензировании. Ссылки на дополнительную информацию об адаптерах IBM WebSphere приведены в справочном разделе в конце данной статьи.

В начало

Импорт и настройка адаптера ресурсов

Перед началом использования адаптера необходимо, прежде всего, импортировать его как проект в ваше приложение. Адаптеры ресурсов упакованы в файлы Resource Adapter Archive (RAR). RAR-файлы представляют собой тип ZIP-файла, содержащего адаптер и набор дополнительных файлов, помогающих WebSphere Integration Developer (либо любой другой программе) предоставить параметры для настройки адаптера. Например, если система, с которой общается адаптер, требует указания имени пользователя, информация в RAR-файле указывает системе WebSphere Integration Developer отображать поля для настройки имени пользователя (на самом деле об этих подробностях знать не обязательно, поскольку нужно только найти RAR-файл и импортировать его).

Для импорта адаптера:

1. Откройте мастер импорта адаптера ресурсов, выбрав Import - RAR file в меню Business Integration view. Не удивляйтесь, если увидите термин коннектор (connector). Термины адаптер и коннектор взаимозаменяемы, поскольку адаптер используется для подключения к системе хранения данных. На рисунке 2 изображен мастер Import.
   
   Рисунок 2. Импорт адаптера ресурсов
   
   
   
2. В мастере Import найдите соответствующий RAR-файл, нажав Browse. Адаптеры, поставляемые с WebSphere Integration Developer, можно найти в каталоге Resource Adapters, расположенном в корневом каталоге установленного у вас WID.

В каталоге Resource Adapters имеется каталог для каждого из адаптеров. В каждом из каталогов или в их подкаталогах deploy имеется .rar-файл. На рисунке 2 импортируется адаптер e-mail, поэтому в качестве файла коннектора выбирается файл CWYEM_EMail.rar. Префикс CW* обозначает компоненты WebSphere, а префикс CWY* обозначает компоненты адаптеров WebSphere.

При просмотре каталогов адаптеров можно заметить несколько дополнительных вариантов адаптеров, которые можно импортировать. CICS и IMS имеют две версии адаптеров ресурсов. Обычно выбирается версия в каталогах cics15 или ims15, содержащих JCA 1.5-совместимые адаптеры. Адаптеры, расположенные в каталогах cics и ims, не совместимы с JCA 1.5, поэтому они используются тогда, когда приложение будет запускаться на более ранних версиях WebSphere Process Server (не забывайте о том, что версии сервера до WebSphere Integration Developer version 6.0 не поддерживают SCA-модули). В каталоге SAP\deploy имеется два файла коннекторов: CWYAP_SAPAdapter.rar и CWYAP_SAPAdapter_Tx.rar. Если необходима поддержка двухфазного подтверждения транзакции, выбирайте версию CWYAP_SAPAdapter_Tx. Версия CWYAP_SAPAdapter подтверждает данные просто при их добавлении или изменении.

После импорта адаптера ресурсов, возможно, придется выполнить дополнительную настройку. Адаптеры SAP, Seibel, PeopleSoft, JD Edwards, JDBC и Oracle EBS требуют дополнительной настройки. Необходимую информацию по данному вопросу можно найти в документации по адаптеру, приведенной на http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp. Например, для PeopleSoft необходимо скопировать специальный для каждой версии .jar-файл в проект adapter. .jar-файл содержит интерфейсы для данных, к которым планируется обращение.

В начало

Использование мастера Enterprise Service Discovery

В данный момент вы потягиваете кофе и наслаждаетесь свежим импортированным адаптером. А сейчас начинается самое интересное. Следующим шагом по созданию сервисов из вашей EIS является использование мастера Enterprise Service Discovery. Вспомните, что мастер обнаружения использует адаптер для исследования информационной системы и обращается ко всем адаптерам, используя imports или exports и взаимодействуя общепринятым способом, определенным в спецификации Enterprise Metadata Discovery (EMD).

Спецификация EMD определяет общий интерфейс, который адаптеры ресурсов могут применять для представления доступных EIS-сервисов и бизнес-объектов инструментальным средствам, использующим эти сервисы и бизнес-объекты в приложениях. Любая среда разработки бизнес-интеграции, совместимая со спецификацией, может обнаружить сервисы, используя адаптер ресурсов для любой EIS одним и тем же способом. WebSphere Integration Developer и WebSphere Adapters, перечисленные ранее, соответствуют этой спецификации, за исключением IBM CICS ECI Resource Adapter 6.0.1 и IBM IMS Connector for Java 9.1.0.2. Ссылка на эту спецификацию приведена в справочном разделе в конце данной статьи. Хотя опять же, нет необходимости детально знать спецификацию EMD для использования этих адаптеров.

Итак, согласно спецификации EMD, мастер Enterprise Service Discovery использует адаптер ресурсов для подключения к EIS и поиска потенциальных сервисов и бизнес-объектов. Для открытия мастера выберите File - New - Enterprise Service Discovery. На первой странице мастера предоставлена возможность выбора адаптера ресурсов, как было описано в предыдущем разделе. Однако перед подключением его к EIS на второй странице мастера запрашивается имя пользователя и пароль, как показано на рисунке 3. Эта страница мастера меняется в зависимости от типа EIS. Например, при использовании адаптера EnterpriseOne настройки соединения не имеют раздела miscellaneous, и полями для указания полномочий являются Environment и Role.

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

После подключения к EIS все готово для того, чтобы мастер мог найти потенциальные сервисы для использования в вашем приложении. Мастер просматривает метаданные вашей системы EIS и создает интерфейсы сервисов на основе этой информации. Например, на рисунке 4 показаны сервисы, имеющиеся на сервере PeopleSoft. Объекты, которые находит мастер, зависят от типа используемой EIS, а также от того, что имеется в вашей конкретной EIS. Адаптеры E-mail, FTP, Flat File, CICS и IMS работают с определениями локальных бизнес-объектов, а не создают их путем запроса к EIS.

На рисунке 5 показана следующая страница мастера Enterprise Service Discovery. Здесь можно указать тип создаваемого сервиса (входящий или исходящий), а также то, какие именно операции будут доступны для этого сервиса. Опять же, операции зависят от используемой EIS. К типичным доступным операциям относятся: добавление новых бизнес-данных в EIS, изменение данных и получение данных. Можно указать другие операции (например, existsFlatFile или createFlatFile) для проверки существования однородного файла или для его создания при использовании в основанных на простых файлах информационных системах.

На последней странице мастера указывается, в какой модуль интеграции поместить import или export, должен ли проект ресурса адаптера развертываться с вашим модулем (адаптер ресурсов также можно установить на сервере, используя консоль администратора), и различные свойства подключения к EIS, например, имя базы данных, идентификатор пользователя и пароль.

Для CICS и IMS мастер создает сервисы. Страницы мастера выглядят для них немного по-разному, поскольку они требуют специализированного метода обнаружения сервиса. Хотя концепция одинакова - мастер проводит вас в пошаговом режиме по процессу создания импорта EIS. Обнаружение корпоративного сервиса происходит путем указания мастеру файла на языке COBOL или C, содержащего определения бизнес-данных, которые ожидает CICS-программа или IMS-транзакция. На основе содержимого файла создается объект, который можно использовать в качестве входного или выходного параметра операции сервиса.

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

В начало

Использование EIS-сервисов

После завершения работы с мастером обнаружения сервисов вы получите компонент import или export, который можно использовать в вашем модуле для вызова нового EIS-сервиса аналогично вызову любого другого сервиса. В данном разделе мы покажем, как использовать компоненты import и export, созданные мастером.

Компоненты import и export

В мастере обнаружения корпоративных сервисов вы указали или создали модуль, который будет использовать EIS-сервис. Если вы откроете общую схему (assembly diagram) этого модуля, то увидите компонент import или export в зависимости от типа созданного сервиса - исходящего или входящего (см. рисунок 6).

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

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

Компонентам import и export необходим интерфейс, который является контрактом между бизнес-приложением и EIS-сервисом, вызываемым вашим модулем или вызывающим ваш модуль. После завершения своей работы мастер создает интерфейс для компонента import или export в зависимости от того, что он обнаружил в EIS. Например, вернемся к операциям, изображенным на рисунке 5. На рисунке 7 показан получаемый в результате интерфейс.

Как известно, операции interface нужны параметры, описывающие бизнес-данные, передаваемые или возвращаемые операции. Из предыдущих серий статей вам уже известно о бизнес-объектах, но адаптер ресурсов требует некоторой дополнительной информации при обмене данными с EIS. При внимательном рассмотрении рисунка 7 вы заметите, что каждый тип параметра заканчивается символами "BG". Параметр для каждой операции, создаваемой мастером, на самом деле является бизнес-графом (business graph - отсюда суффикс BG), который вы можете считать расширенным бизнес-объектом. Бизнес-граф представляет собой контейнер, содержащий стандартный бизнес-объект плюс команду (verb) и итоговую информацию об изменениях. Команда (например, create, update, или delete) указывает, как вы будете использовать данные в бизнес-объекте. Информация об изменениях представляет собой снимок изменений в бизнес-объекте, произошедших после извлечения его из информационной системы. На рисунке 8 показан пример бизнес-графа из интерфейса, изображенного на рисунке 7.

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

Если команда в бизнес-графе не указывается, адаптер ресурсов использует итоговую информацию об изменениях для изменения информационной системы. Эта информация содержит также команду, описывающую, что делать с измененными данными. Не все адаптеры ресурсов работают с итоговой информацией об изменениях; поэтому вы должны обратиться к документации по вашему адаптеру и найти данные о том, что ожидает этот адаптер. Итоговая информация об изменениях уменьшает накладные расходы, связанные с обработкой огромного объема информации, которая может содержаться в бизнес-объекте. Можно иметь, например, бизнес-объект, содержащий тысячи атрибутов, а обновлять, скажем, только телефонный номер клиента. Используя итоговую информацию об изменениях, адаптер ресурсов знает только то, что ему нужно для выполнения обновления атрибута телефонного номера клиента.

В начало

Эстакада Java Connector Architecture

Для тех, кого интересует архитектура JCA (Java Connector Architecture), мы приведем ее краткий обзор. Каждый тип корпоративной информационной системы использует свою собственную нестандартную зависящую от поставщика архитектуру для подключения к серверу приложений. Когда-то каждый сервер приложений должен был предоставлять свои собственные инструментальные средства и интегрированные среды, помогающие интегрировать EIS в уже развернутые на сервере приложения. Это означало, что приложения, использовавшие EIS, были непереносимы на другие серверы приложений.

В настоящее время JCA определяет стандартную архитектуру соединений между приложениями и каждым типом EIS. Если EIS имеет адаптер ресурсов, совместимый со спецификацией, любое приложение, развернутое на сервере J2EE-приложений, может подключаться к этой EIS. Спецификация позволяет предоставлять адаптер ресурсов для каждой EIS стандартным способом. Как показано на рисунке 9, адаптер ресурсов можно подключить затем к серверу приложений, используя стандартный системный контракт. Такая методология развязывает EIS и сервер, поскольку только адаптер ресурсов должен понимать интерфейс EIS и детали подключения. Поэтому приложения обращаются к различным EIS одинаковым способом, используя стандартный прикладной контракт. Хотя на рисунке 9 для простоты показан только один адаптер ресурсов, вы могли бы подключить дополнительные адаптеры ресурсов к серверу и использовать их в приложениях одним и тем же способом.

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

Ссылки на дополнительную информацию по JCA приведены в справочном разделе в конце данной статьи.

В начало

Заключение

На этом завершим наше знакомство с адаптерами. Надеемся, вы поняли, что мир адаптеров, несмотря на странную терминологию, на самом деле не сложен, и что подключиться к корпоративной информационной системе, базе данных, однородным файлам и системам обмена электронными сообщениями можно легко и быстро. После нахождения правильного для данной системы адаптера, WebSphere Integration Developer использует его для определения того, что можно сделать с системой, а затем создает сервисы, операции и бизнес-объекты, которые может использовать ваша бизнес-логика. Это означает, что использовав пару мастеров, вы получаете сервисы, которые можно вызывать из вашей бизнес-логики точно так же, как и любой другой повторно используемый сервис. Код бизнес-логики не должен знать детали того, что делается за кулисами адаптера.

Ресурсы

• Оригинал статьи Getting connected with WebSphere Integration Developer adapters : Part 1, An introduction to connecting with adapters (EN).
  
  
• Спецификация J2EE Connector Architecture 1.5.(EN)
  
  
• Обзор всех адаптеров WebSphere.(EN)
  
  
• Документация по адаптерам.(EN)
  
  
• Enterprise Metadata Discovery (developerWorks, декабрь 2004). (EN)
  
  
• WebSphere Adapter Development Redbook .(EN)
  
  
• Экскурсия по WebSphere Integration Developer.(EN)
  
  
• Информация о WebSphere Integration Developer.(EN)
  
  
• developerWorks: WebSphere Process Server и ресурсы по WebSphere Integration Developer.(EN)
  
  
• developerWorks: раздел WebSphere Business Integration.(EN)
  
  
• developerWorks: раздел WebSphere development tools.(EN)
  
  
• Встреча с экспертами: WebSphere Integration Developer. (EN)
  
  

• Загрузите пробную версию WebSphere Business Modeler.(EN)
  
  
• Загрузите пробную версию Rational Application Developer.(EN)

• Примите участие в обсуждении материала на форуме.
  
  
• Форум WebSphere Integration Developer.(EN)
  
  
• Блоги developerWorks.(EN)
  
  

Об авторах

		Джон Грин (John Green) - штатный консультант и технический директор отдела разработки инструментальных средств WebSphere Integration Developer Adapter. Является экспертом по J2EE Connector Architecture, Enterprise Metadata Discovery Specification и Enterprise Information Systems. Джон пришел в IBM в 1987 и занимался несколькими проектами до работы с адаптерами в VisualAge for Java, WebSphere Studio Application Developer Integration Edition, Rational Application Developer и WebSphere Integration Developer. Получил степень бакалавра по информационной технике в Queen's University in Kingston в 1987.

		Грег Адамс (Greg Adams) был ведущим архитектором пользовательского интерфейса знаменитой платформы Eclipse, а позднее ведущим архитектором и разработчиком основных инструментов WebSphere Business Integration, в том числе WebSphere Studio Application Developer Integration Edition и WebSphere Integration Developer. Грег возглавил выпуск первых пакетов инструментов IBM, поддерживающих сервис-ориентированную архитектуру (SOA) и первых стандартов BPEL4WS, поддерживающих Business Process Editor. И те, и другие являются важнейшими компонентами поддержки стратегии IBM On Demand

		Рэнди Гиффен (Randy Giffen) - консультант по разработке программного обеспечения в лаборатории IBM в Оттаве в команде WebSphere Integration Developer. Он отвечал за инструменты машины бизнес-состояний WebSphere Integration Developer и редактор визуальных фрагментов. Ранее работал над пользовательским интерфейсом WebSphere Studio Application Developer Integration Edition, Eclipse и VisualAge для Java.

		Ричард Грегори (Richard Gregory) - разработчик программного обепечения WebSphere Integration Developer в лаборатории IBM в Торонто. Он отвечал за разработку и выпуск новых версий отладчиков для WebSphere Integration Developer.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало