Основная задача при построении сервисно-оринтированной архитектуры - выделение сервисов и их реализация. При этом, чтобы оценить трудозатраты на данный процесс, необходимо уметь хотя бы приблизительно определять сложность того или иного сервиса. Предлагается следующая градация сервисов по уровню сложности реализации.
1. Простые сервисы
2. Сервисы средней сложности
3. Сложные сервисы
Позволю себе заметить, что все перечисленные виды сервисов можно реализовать как с использованием Oracle SOA Suite, так и с использованием Oracle Service Bus. Единственный водораздел, который я вижу, - к сложным автор относит сервисы с сохранением состояния (пункты 4 и 6). Для их реализации подходит Oracle SOA Suite.
Понравилось сообщение - подпишитесь на блог и Twitter
1. Простые сервисы
- Выставляются с помощью основанных на стандартах интерфейсов и не требуют использования адаптеров для своей реализации.
- Реализуют простые или вовсе не реализуют требований по верификации данных.
- Реализуют простые или вовсе не реализуют требований по трансформации данных.
- Не требуют реализации безопасности.
- Используют простой каркас для журналирования. Не требуют отдельного механизма обработки ошибок.
- Могут быть легко найдены в UDDI. Таксономия четко определена. Находятся простые конечные точки.
- Не требуют использования WS-* стандартов, таких как WS-ReliableMessaging или WS-Addressing.
- Не предполагают использования механизмов обеспечения гарантированной доставки сообщений.
- В основном это - утилитные сервисы с простыми операциями чтения и изменения данных.
2. Сервисы средней сложности
- Выставляются с помощью основанных на стандартах интерфейсов.
- Реализуют простые или среднего уровня требования к верификации данных.
- Реализуют простые или среднего уровня требования к трансформации данных.
- Используют простой каркас для журналирования. Требуют отдельного простого механизма обработки ошибок.
- Требуют простую реализацию безопасности. Например стандарт WS-Security для авторизации/аутентификации, реализованное с помощью утилит шифрование и протокол SSL.
- Могут быть легко найдены в UDDI. Таксономия четко определена. Находятся простые конечные точки.
- Могут включать простые WS-* стандарты, такие как WS-Addressing и WS-ReliableMessages.
- Требуют некоторого механизма обеспечения гарантированной доставки сообщений.
- Сервисы реализуют большинство операций взаимодействия с отдельным приложением или системой.
3. Сложные сервисы
- Выставляются с помощью основанных на стандартах интерфейсов.
- Реализуют сложные требования к верификации данных (например проверку даты и временной зоны).
- Реализуют сложные требования к трансформации данных (например из одного стандарта представления сообщений в другой).
- Используют комплексный подход к журналированию. Реализуют корреляционные множества. Требуют отдельного сложного механизма обработки ошибок с возможностями повторного вызова и отправки уведомлений.
- Требуют среднюю или сложную реализацию безопасности. Например цифровую подпись, шифрование, SAML.
- В UDDI присутствует множество версий. Требуют поддержки таких стандартов, как WS-Policy и WS-Trust.
- Могут включать WS-* стандарты, такие как WS-Coordination.
- Требуют обеспечения гарантированной доставки сообщений.
- Сервисы реализуют объемное и сложное взаимодействие с множеством систем.
Позволю себе заметить, что все перечисленные виды сервисов можно реализовать как с использованием Oracle SOA Suite, так и с использованием Oracle Service Bus. Единственный водораздел, который я вижу, - к сложным автор относит сервисы с сохранением состояния (пункты 4 и 6). Для их реализации подходит Oracle SOA Suite.
Понравилось сообщение - подпишитесь на блог и Twitter
Комментариев нет:
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!