Вопрос

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

У меня есть большой опыт работы с J2EE (Websphere) и веб-сервисами, но я был бы признателен за совет о том, как создать такой SOA.

Где же подводные камни?А как насчет безопасности?Насколько мелко должны быть измельчены услуги?и т.д.

Также были бы полезны ссылки на учебные пособия и рекомендации по книгам.

Спасибо!

Это было полезно?

Решение

Подводные камни

  • Управление версиями / обратная совместимость:менять контракт становится действительно сложно, когда у вас много клиентов.Я видел, как многие сайты обновляли API, вводя версию в URL

Степень детализации

  • Каждая услуга должна быть разумно автономной (не ожидайте, что люди сделают 3 звонка, прежде чем получат то, что им нужно).

Независимость от платформы

  • Попробуйте предоставить более одного способа доступа к вашим API (WS, JSON, REST ...)

Другие советы

Люди не могут прийти к единому мнению о том, что на самом деле означает SOA.

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

(хотя консенсус, возможно, возрос с тех пор, как это было написано)

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

Называйте меня SOA-скептиком."Плач Фаулера" все еще кажется уместным.

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

EIP image
(источник: amazon.com)

Нашел эту IBM Redbook (#sg246303) что является довольно хорошим введением в основы SOA.

Как сказал Алан, я бы начал читать Книга Шаблонов корпоративной интеграции.Существует несколько способов их реализации либо с использованием системы обмена сообщениями напрямую, такой как JMS, либо с использованием проектов с открытым исходным кодом, таких как Верблюд - апач, например , смотрите каталог узоров.

Я бы также посмотрел на понимание того, как создавать хорошие RESTful-сервисы, используя JAX-RS с Джерси как простой способ легко предоставить ресурсы для ваших систем любому пользователю в Интернете с любого языка / платформы, не попадая в SOAP / WS-* deathstar :)

Получите ESB (корпоративную сервисную шину):Mulesource - хороший выбор (открытый исходный код, зрелый, но в то же время передовой).Как только вы поймете это, вы поймете SOA.

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

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

На данный момент лучшая книга, которую я нашел, это SOA Компас также доступно на Амазонка

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top