- •Часть I………………………………………………………………. 53
- •Часть II……………………………………………………………. 59
- •Аннотация
- •Проблема в корне
- •Эволюция программных архитектур
- •«Подводные камни» soa
- •Классическое представление концепции soa
- •Верно, но рано
- •Ресурсы
- •Аннотация
- •Введение
- •Общий обзор материала
- •Основные сценарии использования
- •Раздел 2.1описывает запрос на бронирование путешествия в виде soap-сообщения, который дает возможность описать различные составляющие soap-сообщения.
- •Раздел 2.3демонстрирует примеры обработки ошибок. Soap-сообщения
- •Обмен soap-сообщениями
- •Сценарии обработки сообщений об ошибках
- •Модель обработки soap
- •Атрибут "role"
- •Атрибут "mustUnderstand"
- •Атрибут "relay"
- •Использование различных протокольных привязок
- •Http-привязка soap
- •Использование soap поверх Email
- •Более сложные сценарии использования Использование soap-посредников
- •Использование других схем написания кода
- •Различия между soap 1.1 и soap 1.2
- •Аннотация
- •Часть I Введение
- •Проектирование Web-сервисов
- •Недопустимость генерации wsdl
- •Проектирование интерфейсов
- •Непрозрачность сети
- •Отличие Web-сервисов от распределенных объектов
- •Определение ограниченных интерфейсов
- •Разнесение бизнес логики и политики
- •Разделение проектирования и реализации
- •Часть II Введение
- •Инструменты
- •Модульные описания Web-сервиса
- •Пространства имен
- •Обработка ошибок
- •Document/literal против rpc/encoded
- •Что можно ожидать
- •Аннотация
- •Введение
- •Понятие сервисно-ориентированности
- •Почему не достаточно bpm, ea и ooad
- •Oбъектно-ориентированная (оо) парадигма против сервисно-ориентированной (so)
- •Элементы soad
- •Что дает soad?
- •Первые элементы soad
- •Пример: Наряд на выполнение авторемонтных работ
- •Выводы и перспективы на будущее
Выводы и перспективы на будущее
В этой статье мы обсудили и обозначили необходимость разработки нового, сходящегося подхода к анализу и проектированию SOA-систем, служащего неким мостом между бизнесом и IT. Мы также сделали предположение, что этот новый междисциплинарный SOAD-подход должен являться целостной методологией моделирования, строящейся на современных, проверенных и доказавших свою эффективность подходах OOAD, EA и BPM. В то время как нотация и методология применения SOAD еще только должны будут детально описаны, ключевые элементы подхода, такие как концептуализация (или определение) сервисов, их классификация и агрегация, политики и аспекты использования, сходящийся подход к моделированию, семантические переходы и сборка сервисов (для повторного использования), уже могут быть определены. SOAD потребует улучшений существующих методов программной инженерии, направленных на дальнейшее повышение удобства их использования и расширения возможностей применения в проектах разработки корпоративных приложений. Через некоторое время будут разработаны и лучшие практики и шаблоны. Очевидно, что UML будет и в дальнейшем доминировать в качестве нотации моделирования процессов, однако, вероятно, потребуется его улучшение для использования в SOAD с его более широкой предметной областью. Следующими шагами на пути формализации SOAD будет определение необходимой сквозной методологии применения, нотации, необходимых ролей, их обязанностей и сфер ответственности, а также утверждение предлагаемого подхода в ходе реализации проектов.
Ресурс
Olaf Zimmermann, Старший IT-архитектор (Senior IT Architect), IBM Enterprise |
Pal Krogdahl, Системный архитектор (Solution Architect), IBM |
Clive Gee, Старший архитектор решений (Senior Solution Architect), IBM |
© 2004 IBM, Оригинальный текст |
© 2005 UBS, Перевод и адаптация на русский язык |
На русском языке публикуется впервые с разрешения авторов |
Комментарии к переводу принимаются по адресу: info@ws.ubs.ru |
Оригинальный текст статьи можно найти http://www-106.ibm.com/developerworks/webservices/library/ws-soad1/
|
Данная статья размещена по адресу http://www.ubs.ru/ws/ws_soad1.html |