Создание SOA-приложений с повторно используемыми ресурсами: Часть 3. Шаблон WS response template

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

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

Хе Лей, штатный инженер-программист, IBM
Сунь Ин Линь, инженер-программист, IBM
Тянь Чэнь, инженер-программист, IBM
Эоин Лэйн, главный инженер решений, IBM, Software Group

06.07.2009

В данной серии статей исследуются повторно используемые ресурсы, рецепты и шаблоны программ, а также то, как они могут способствовать разработке SOA-решений. В этой, третьей, статье серии демонстрируется реализация шаблона WS response template. Данный шаблон можно применить к UML-модели сервиса для обеспечения большей его гибкости. Мы рассматриваем этот шаблон в контексте рецепта SOA Implement and Optimize Services и соответствующего типового примера из первых двух статей данной серии. В следующих статьях мы расскажем, как применить другие SOA-шаблоны к типовому примеру для удовлетворения нефункциональных требований.

Введение

В предыдущих частях данной серии статей мы познакомились с рецептом SOA Implement and Optimize Services и обсудили типовой пример (reference example) возможного применения данного рецепта. В типовом примере используется подход управляемой моделями разработки (Model-Driven Development - MDD) и возможности моделирования продукта IBM Rational® Software Architect для разработки модели варианта использования, модели анализа, моделей дизайна и моделей сервисов. В данной статье демонстрируется, как изменить существующий сервис, что является ключевым шагом в рецепте SOA Implement and Optimize Services.

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

Мы используем рецепт SOA Implement and Optimize Services с типовым примером для демонстрации того, как шаблоны программирования помогают удовлетворить эти нефункциональные требования. Использование шаблонов программирования для удовлетворения нефункциональных требований помогает разработчику и проектировщику создавать архитектурно согласованные сервисы в соответствии с передовыми методиками и принципами разработки программного обеспечения.

Изменение существующего сервиса

1. Анализ модели сервиса.
2. Анализ нефункциональных требований к сервису.
3. Анализ модели существующего приложения.
4. Применение подходящих шаблонов на основе нефункциональных требований.

• Модель сервиса каталога и связанные представления сообщений доступны как ресурсы программы Rational Software Architect и могут быть импортированы в проект UML-модели.
• Файл управления требованиями Rational RequisitePro для нефункциональных требований варианта использования приложения учета доступен как RAS-ресурс (Reusable Asset Specification). Однако к этому файлу требований должен быть разрешен общий доступ по сети. На рисунке 3 показан Rational RequisitePro Requirement Explorer в программе Rational Software Architect после открытия файла управления требованиями Rational RequisitePro для типового примера.
• Модель дизайна приложения каталога доступна в виде RAS-ресурса и может быть импортирована в проект UML-модели Rational Software Architect.

Анализ модели сервиса

На рисунке 1 показана модель сервиса каталога. Эта модель имеет две операции:

• Операция getCatalog() принимает первичный ключ и возвращает каталог.
• Операция getCatalogs() принимает массив первичных ключей и возвращает массив каталогов.

На рисунке 2 показана модель сообщений каталога. Модель со всей очевидностью демонстрирует, что:

• Каждое сообщение Сatalog содержит несколько сообщений CatalogItem.
• Каждое сообщение CatalogItem содержит несколько сообщений FeatureValue.
• Каждое сообщение FeatureValue содержит одно сообщение Feature.

Анализ нефункциональных требований

Файл модели сервиса каталога был детально исследован во второй части данной серии статей (EN).

Rational RequisitePro отслеживает нефункциональные требования для данной модели каталога. Rational Software Architect предоставляет Rational RequisitePro Client, который показывает отображение между вариантами использования и функциональными и нефункциональными требованиями. Ниже перечислены нефункциональные требования для сервиса каталога:

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

Анализ модели дизайна существующего приложения каталога

На рисунке 4 показана UML-визуализация существующего приложения (сервиса) каталога. Приложение представляет собой Java-компонент и предоставляет Java-интерфейс. При исследовании этого интерфейса вы увидите, что операции getCatalog() и getCatalogs() являются очень объемными в том смысле, что возвращают соответственно весь каталог и список всех каталогов. Данная модель доступна также из рецепта SOA Implement and Optimize Services, но для целей статьи нам это не нужно.

Применение подходящих шаблонов

Реализации и спецификации шаблонов Когда мы говорим о шаблонах (в качестве примера давайте использовать книгу "Design Patterns" "банды четырех" (Влиссидес, Гамма, Хелм и Джонсон)), наибольший интерес представляют два аспекта. Один - это реальный текст, описывающий шаблон. Это именно то, что можно найти в книге, скажем, в главе о шаблоне Adapter. Другой аспект- это инструментальные элементы дизайна, которые реализуют данный шаблон. Например, в Rational Software Architect имеются UML-артефакты, реализующие различные шаблоны проектирования из книги Design Patterns. То есть, если вы хотите применить Adapter в одном из ваших проектов, необходимо выбрать этот элемент из палитры и выполнить определенные манипуляции в инструментальной программе, чтобы преобразовать ваш дизайн в соответствии с этим шаблоном. Мы называем первый элемент "спецификацией шаблона". Второй элемент мы называем "реализацией шаблона". Ссылка на спецификацию шаблона WS response template приведена в разделе "Ресурсы".

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

Для формирования сервиса каталога будут использоваться три следующих шаблона:

• Спецификация шаблона WS response template детализирует контекст, проблему и готовое к повторному использованию решение. Шаблон обеспечивает гибкость и удобство обслуживания интерфейса сервиса. Ссылка на спецификацию шаблона WS response template приведена в разделе "Ресурсы".
• Спецификация шаблона Requestor Side Caching Pattern улучшает производительность сервиса. Ссылка на спецификацию шаблона приведена в разделе "Ресурсы".
• Шаблон Logging обеспечивает отслеживаемость активизаций сервиса.

Перед подробным исследованием этих шаблонов полезно рассмотреть n-уровневую архитектуру, описанную ниже. Простая трехуровневая архитектура будет иметь уровень представления, бизнес-уровень и уровень персистентности. В SOA-среде мы можем разделить бизнес-уровень далее на уровень сервисов, уровень контроллера и уровень управления объектами (сущностями). Такое разбиение на уровни изображено на рисунке 5. Такие базовые шаблоны Enterprise JavaBeans™, как session facade (фасад сессии), message facade (фасад сообщения) и business delegate (бизнес-делегат), принадлежат уровню контроллера. На рисунке 5 показано, где применяются эти шаблоны в n-уровневой архитектуре.

В начало

Шаблон WS response template

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

Нефункциональные требования

Шаблон WS response template удовлетворяет следующим нефункциональным требованиям:

1. Сервис должен уметь взаимодействовать с другими сервисами.
2. Сервис должен обеспечивать тонко настраиваемый доступ к крупномодульным интерфейсам.
3. Интерфейс должен обеспечивать некоторую гибкость в определении интерфейса и позволять развитие объектов value.

Для удовлетворения этих нефункциональных требований мы используем шаблон WS response template. Ссылка на спецификацию шаблона WS response template приведена в разделе "Ресурсы". Для полноты картины ниже приведена диаграмма классов и диаграмма последовательности. Эти диаграммы имеют больший смысл в контексте спецификации шаблона. Обсуждение спецификаций и реализаций шаблонов приведено на боковой врезке. Спецификация шаблона WS response template детализирует контекст, проблему и готовое к повторному использованию решение, обеспечиваемые шаблоном.

Диаграмма классов

На рисунке 6 показана диаграмма классов шаблона WS response template.

Диаграмма последовательности

На рисунке 7 показана диаграмма последовательности для шаблона WS response template.

• Используя предоставляемый WSDL-файл, настроенный на шаблон WS response template, клиентское приложение активизирует сервис. Запрашивающая сторона активизирует реализацию шаблона WS response template при помощи ключа и шаблона запроса.
• Ключ уникально идентифицирует требуемый объект value.
• Шаблон запроса сообщает реализации сервиса, какое автономное подмножество информации нужно в ответе.
• Реализация сервиса запрашивает провайдер, используя ключ, и получает соответствующий объект value, ассоциированный с этим ключом.
• Теперь активизируется компонент времени исполнения (неподдерживаемая его реализация предоставляется как часть шаблона), называемый навигатором. Навигатор принимает шаблон запроса и объект value в качестве входных параметров и возвращает шаблон ответа.
• Шаблон ответа содержит типизированное подмножество графа информации объекта value, запрошенное пользователем в шаблоне запроса. Шаблон ответа возвращается запрашивающей стороне.

В начало

Применение шаблона WS response template

Реализация шаблона Web service response template может быть импортирована в Rational Software Architect при помощи рецепта. Сначала перейдите в раздел 'Apply patterns to a service implementation' рецепта и разверните раздел 'Applying the WS response template pattern'. Найдите нужный ресурс в этом шаге и выберите import (см. рисунок 8). С применением данного шаблона можно познакомиться по флэш-ролику, ссылка на который приведена в разделе "Загрузка".

При этом в Rational Software Architect установится реализация шаблона WS response template, а также профиль программных сервисов UML. После установки шаблон будет отображаться в pattern explorer, как показано на рисунке 9.

Вот как мы будем применять шаблон: откройте SOA Inventory Service Model. Эту модель сервиса можно получить из репозитория Rational Software Architect, а обращение к ней осуществляется из рецепта SOA Implement and Optimize Services. Модель содержит UML Service Model для Catalog Service и для Inventory Service. Убедитесь в том, что установлен плагин Rational Software Architect - UML Profile for Software Services (см. раздел "Ресурсы"). При установке шаблона WS response template плагин UML Profile for Software Services устанавливается автоматически.

На рисунках 11 и 12 показаны две перспективы, которые нам интересны: Service View и Message View.

Диаграмма CatalogItems Overview в окне Message показывает сообщения каталога. Выполните двойной щелчок левой кнопкой мыши на окне, чтобы открыть его.

В перспективе modeling переместите шаблон WS response template из палитры Pattern Explorer Pallet в модель Catalog Message Model. В перспективе modeling его можно найти при помощи пиктограммы fast view в правой верхней части Rational Software Architect. Если его там нет, найдите Pattern Explorer в Windows > Show View. На рисунке 13 показана схема модели сообщений после завершения этой процедуры.

Шаблон WS response template принимает четыре параметра:

• AnchorMessage: корневое (root) сообщение графа сообщений. В нашем случае это будет сообщение Catalog.
• ServiceSpecification: спецификация сервиса, к которой будет применен шаблон WS response template. В нашем случае это будет Catalog Service.
• FilterParameter: обычно это атрибут потомка композитного сообщения, который позволяет фильтровать дочерние элементы. В нашем случае это будет атрибут SKU, который позволяет выполнять фильтрацию элементов CatalogItems по складским номерам.
• WSRTOperations: идентифицирует операции Service Specification, которые должны дать возможность использовать WS Response Template. В нашем случае используется операция getCatalog().

На рисунке 14 показана модель после применения шаблона.

Результатом применения этого шаблона является emx-файл модели нового сгенерированного сервиса. На рисунке 15 показана внутренняя структура этой сгенерированной модели сервиса, который может использовать шаблон WS response template.

При исследовании этой сгенерированной модели сервиса обнаруживается следующее:

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

Сигнатуры метода в интерфейсе сервиса каталога также были изменены. Сигнатура операции getCatalog() теперь имеет следующий формат: getCatalog(primaryKey, requestTemplate):ResponseTemplate. Метод возвращает строго типизированный экземпляр шаблона ответа сервиса каталога. Кроме того, метод теперь принимает два параметра запроса:

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

Из этой новой модели сервиса можно сгенерировать WSDL и XSD, применяющие шаблон WS response template.

• Найдите CatalogComponent в окне service.
• Найдите пункт меню transformation в контекстном меню, вызываемом при помощи правой кнопки мыши. Используйте преобразование UML to WSRT.
• Диалоговое окно этого преобразования запросит пользователя о web-проекте, в который нужно сгенерировать WSDL и XSD, а также пространство имен для WSDL. В качестве пространства имен используйте http://catalog.retail.ibm.com/.

Для создания Java-реализации Web-сервиса каталога мы будем использовать генератор WSDL to Java:

• Переключитесь в перспективу J2EE.
• Щелкните правой кнопкой мыши на сгенерированном WSDL-файле. Должна быть включена функциональность Rational Software Architect Web Service. Для включения этой и других возможностей перейдите в меню Windows > Preferences > Workbench > Capabilities и включите Web Service Developer и XML Developer.
• Отметьте флажок Disable data binding for use of SOAPElement для Windows > Preferences > Workbench > Web Services > Code Generation > IBM WebSphere runtime (см. рисунок 17).
• В диалоговом окне WSDL- Java generation отметьте флажок Test the Web Service and the Monitor the Web Service.
• Для остальных параметров можно оставить значения по умолчанию.
• Примечание. Полезно запустить до этого шага тестовый сервер IBM WebSphere® 6.0.

На этом этапе хорошо протестировать эту пустую реализацию в Web service explorer. На рисунке 19 показан вызов 'Catalog B', когда все, что интересует клиента, - это название, описание и начальная дата каталога.

В SOAP-запросе вызова имеется два параметра:

• Первичный ключ, в данном случае каталог 'B'.
• Шаблон запроса, указывающий, что следует возвратить только название, описание и начальную дату.

Если во время генерирования WSDL to Java был отмечен флажок monitor Web service, в TCP/IP tunneller должен появиться SOAP-запрос вызова с пустым SOAP-ответом.

Теперь давайте расширим реализацию, чтобы она возвращала что-то реальное. В реализации getCatalog() выполните следующие действия:

1. Вызовите существующее приложение каталога, которое принимает каталог. Обычно будет использоваться сигнатура getCatalog(key):Catalog.
2. Вызовите навигатор. С данной статьей предоставляется неподдерживаемая базовая реализация навигатора (см. раздел "Загрузка"), которую необходимо включить в развертываемое приложение для преобразования шаблона запроса каталога и объекта value этого каталога (из существующего приложения каталога) в объект ответа каталога.
3. Полный листинг этой реализации на стороне сервера, сгенерированного скелетного интерфейса и реализации сервиса каталога приведен ниже.
4. wst.server (базовый код навигатора) и существующее приложение каталога (приложение, которое фактически получает каталог) нужно сделать доступными для разработки и для системы времени исполнения (см. раздел "Загрузка"). Для разработки убедитесь в том, что оба проекта включены в путь компоновки (build path). Для системы времени исполнения эти проекты необходимо сначала добавить в родительский EAR-файл, а затем сослаться на них в WAR-файле сервиса каталога как на зависимые JAR-файлы.

				
/**
 * IWSRTTireCatalog.java
 *
 * Этот файл был сгенерирован автоматически из WSDL
 * программой IBM Web services WSDL2Java emitter.
 * o0505.16 v2605125559
 */

package com.ibm.retail.catalog;

import com.ibm.awsdc.wst.core.InvokerException;
import com.ibm.awsdc.wst.core.WriterException;

public interface IWSRTTireCatalog extends java.rmi.Remote {
    public javax.xml.soap.SOAPElement getCatalog(javax.xml.soap.SOAPElement key, 
    javax.xml.soap.SOAPElement requestTemplate) throws java.rmi.RemoteException, 
    InvokerException, WriterException;
}

						
						/**
 * IWSRTCatalogSpecificationBindingImpl.java
 * 
 * Этот файл был сгенерирован автоматически из WSDL
 * программой IBM Web services WSDL2Java emitter.
 * emitter. o0526.04 v62905175048
 */

package com.ibm.retail.catalog;

import javax.xml.rpc.ServiceException;
import javax.xml.rpc.server.ServiceLifecycle;
import javax.xml.rpc.server.ServletEndpointContext;

import com.ibm.awsdc.wst.core.InvokerException;
import com.ibm.awsdc.wst.core.Navigator;
import com.ibm.awsdc.wst.core.WriterException;

public class IWSRTCatalogSpecificationBindingImpl implements
	  com.ibm.retail.catalog.IWSRTCatalogSpecification,ServiceLifecycle {
	private ServletEndpointContext context;

	public javax.xml.soap.SOAPElement getCatalog(
		  javax.xml.soap.SOAPElement key,
		  javax.xml.soap.SOAPElement requestTemplate)
		  throws InvokerException, WriterException {
		Object catalog = null;
		String keystr = ((javax.xml.soap.Node) key.getChildElements().next())
			.getValue();
		System.out.println(keystr);
		// Получить ссылку на существующее приложение каталога
		com.ibm.retail.entity.catalog.LegacyCatalogApp catalogImpl = 
		 new com.ibm.retail.entity.catalog.LegacyCatalogAppImpl();
		catalog = catalogImpl.getCatalog(keystr);
		// Выполнить навигацию по каталогу для возврата шаблона ответа
		return Navigator.navigate(requestTemplate, catalog, context);
	}

	/*
	 * (non-Javadoc)
	 * 
	 * @see javax.xml.rpc.server.ServiceLifecycle#init(java.lang.Object)
	 */
	public void init(Object arg0) throws ServiceException {
		context = (ServletEndpointContext) arg0;

	}

	/*
	 * (non-Javadoc)
	 * 
	 * @see javax.xml.rpc.server.ServiceLifecycle#destroy()
	 */
	public void destroy() {
		// Заглушка автоматически сгенерированного метода

	}
}

Протестируйте реализацию при помощи Web service explorer. На рисунке 20 показана вызов 'Catalog A', когда клиентское приложение интересует только название, описание и начальная дата каталога.

Здесь присутствует соответствующий SOAP-запрос вызова. Этот запрос имеет два параметра:

• Первичный ключ для каталога, в данном случае catalog 'A'.
• Шаблон запроса, указывающий, что нужно возвратить только название, описание и начальную дату.

Если при преобразовании WSDL в Java был отмечен флажок monitor Web Service, в TCP/IP tunneller должен появиться SOAP-запрос активизации с пустым SOAP-ответом (см. рисунок 21).

Ссылка на готовый проект Rational Software Architect, упакованный в файл Project Interchange, приведена в разделе "Загрузка". Для импортирования в Rational Software Architect выберите File > Import > Project Interchange.

В начало

Что мы сделали?

На рисунке 22 показана диаграмма последовательности шаблона WS response template, примененного к Catalog Service Model.

• Используя предоставляемый WSDL-файл, настроенный на шаблон WS response template, клиентское приложение активизирует сервис. Запрашивающая сторона активизирует реализацию шаблона WS response template, используя ключ и шаблон запроса.
• Ключ уникально идентифицирует возвращаемый объект value.
• Шаблон запроса сообщает реализации сервиса, какое несвязанное подмножество информации нужно в ответе.
• Реализация сервиса запрашивает провайдер, используя ключ, и получает соответствующий объект value, ассоциированный с этим ключом.
• Теперь активизируется компонент времени исполнения (неподдерживаемая реализация предоставляется как часть шаблона), называемый навигатором. Навигатор принимает шаблон запроса и объект value в качестве входных параметров и возвращает шаблон ответа.
• Шаблон ответа содержит типизированное подмножество графа информации объекта value, запрошенное пользователем в шаблоне запроса. Шаблон ответа возвращается запрашивающей стороне.

Итак, применив шаблон WS response template к сервису каталога, мы продемонстрировали, что основные усилия должны быть направлены на понимание проблемы, определение области ее действия и последующее обобщение, чтобы можно было повторно применить шаблон в будущем.

Мы также обнаружили, что фундаментальным является изменение сигнатуры метода с getCatalog(primaryKey):Catalog на getCatalog(primaryKey, catalogRequestTemplate):CatalogResponseTemplate.

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

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

В начало

Заключение

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

В начало

Загрузка

Описание	Имя	Размер	Метод загрузки
Готовый Interchange Project	wsrt-catapp.zip	10 КБ	HTTP
Исполняемый код WS Response Template (Nagivator)	wst.server.zip	50 КБ	HTTP
Существующее приложение каталога	LegacyCatalogApp.zip	50 КБ	HTTP
Флэш-ролик: применение шаблона WS Response Pattern	wsrt.swf	1681 КБ	HTTP

	Информация о методах загрузки

Ресурсы

• Оригинал статьи "Building SOA applications with reusable assets, Part 3: WS response template pattern" (EN).
  
  
• "Шаблон Web services response template: спецификация" (Эоин Лэйн (Eoin Lane), developerWorks, февраль 2006 г.) - спецификация шаблона WSRT и предлагаемые им решения для улучшения интерфейсов сервисов (EN).
  
  
• "Спецификация шаблона requester side caching: обзор" (developerWorks, октябрь 2005 г.) - подробная спецификация шаблона requester-side caching (EN).
  
  
• Дополнительная информация об OMG-стандарте спецификации Reusable Asset Specification, версия 2.2 (EN).
  
  
• Дополнительная информация о моделировании в Rational Software Architect и Rational Software Modeler в статье "Руководство по моделированию структуры в Rational Software Modeler и Rational Software Architect" (EN).
  
  
• В статье "UML 2.0 Profile for Software Services" приведена информация об UML-профиле для программных сервисов, профиле для UML 2.0, позволяющем моделировать сервисы для сервис-ориентированной архитектуры (SOA) и сервис-ориентированные решения (EN).
  
  
• "Разработка J2EE Architecture с использованием Rational Software Architect и Rational Unified Process" (developerWorks, август 2005 г.) - информация о J2EE, RUP и Rational Software Architect (EN).
  
  
• Посетите сайт Enterprise Integration Solutions и узнайте о том, как IBM может помочь реализовать электронный бизнес по требованию (on demand) с использованием передовых инструментов для проектирования и развертывания Web-сервисов в SOA (EN).
  
  

• Загрузите Macromedia®Flash®Player для запуска демонстрационного флэш-ролика о применении шаблона WS Response Pattern.(EN)
  
  
• Загрузите плагин RUP для SOA Rational Unified Process Plug-In for SOA V1.0.(EN)
  
  
• Загрузите бесплатную пробную версию Rational RequisitePro V2003.06.15. (EN)
  
  
• Загрузите бесплатную пробную версию Rational Software Architect V6.0. (EN)
  
  
• Разработайте ваш следующий проект при помощи пробного программного обеспечения IBM, которое можно загрузить непосредственно с сайта developerWorks. (EN)
  
  
• На IBM alphaWorks размещена эталонная реализация RAS под названием Reusable Asset Specification Repository for Workgroups, доступная для загрузки.(EN)
  
  
• Закажите бесплатный SEK for Linux - набор из двух DVD-дисков, содержащий новейшее ознакомительное программное обеспечение IBM для Linux: DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Подключайтесь к сообществу developerWorks, принимая участие в блогах developerWorks.(EN)

Об авторах

		Хе Лей (He Lei (Joyce)) - штатный инженер-программист IBM Enterprise Integration Design Center, Пекин, Китай. Получила степень магистра по вычислительной технике в BeiHang University в 2003 г. После прихода в IBM работала над проектом China Grid для Grid Computing Group и над проектами клиентов EIS design center. В настоящее время занимается инструментальными средствами IBM SOA.

		Сунь Ин Линь (Sun Ying Lin (Neo)) - инженер-программист в IBM Enterprise Integration Design Center, Пекин, Китай. Получил степень магистра по вычислительной технике в BeiHang University в 2005 г. После прихода в IBM занимался инструментальными средствами IBM SOA.

		Тянь Чэнь (Tian Chen (Simon)) -инженер-программист IBM Enterprise Integration Design Center, Пекин, Китай. Получил степень магистра по вычислительной технике в BeiHang University в 2004 г. После прихода в IBM занимался инструментальными средствами IBM SOA.

		Доктор Эоин Лэйн (Eoin Lane), главный инженер решений, руководит выборкой (и разработкой) шаблонов приложений из ключевых SOA-проектов IBM, а также прохождением этих шаблонов через процесс управления шаблонами IBM для ускорения их принятия. Также, для содействия SOA-разработке Эоин специализируется в Model Driven Development (MDD) (основанной на ресурсах разработке) и Reusable Asset Specification (RAS).

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

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

Поделиться этой статьей: забобрить сохранить в memori

В начало