rest api

rest api  representation state transfer передача состояния
для взаимодействия с внешними сервисами нужен API
rest работает поверх http
варианты 
-  soap api
-  rest api
-  json api
кеширование прозрачность  CRUD create read update delete
использование метода http как действие приложения 
требования к рест апи :
сервер рест апи обязан быть stateless rest api server
набор ресурсов и идентифицируется урлом
есть представление сущностей ямл джейсон
меняем их при помощи хттп методами

Примеры архитектурных стилей и моделей

Примеры архитектурных стилей и моделей

Есть много распространенных способов разработки программных модулей и их связей, в том числе:

Blackboard
Клиент-серверная модель (client-server)
Архитектуры, построенные вокруг базы данных (database-centric architecture)
Распределенные вычисления (distributed computing)
Событийная архитектура (event-driven architecture)
Front end and back end
Неявные вызовы (implicit invocations)
Монолитное приложение (monolithic application)
Peer-to-peer
Пайпы и фильтры (pipes and filters)
Plugin
Representational State Transfer
Rule evaluation
Поиск-ориентированная архитектуры
Сервис-ориентированная архитектура
Shared nothing architecture
Software componentry
Space based architecture
Структурированная
Трех-уровневая

Технологические ошибки, возникающие в SOA-проектах

Технологические ошибки, возникающие в SOA-проектах

Технологические ошибки, возникающие в SOA-проектах

andrey.maslov » 15 дек 2010, 17:24

Эксперт перечислил наиболее частые технологические ошибки, возникающие в ходе SOA-проектов:

* Недооценка технической сложности крупных SOA-решений;
* Ошибочный выбор инфраструктурных компонентов приложения (ESB, оркестровки и адаптеров);
* Недостаточные основания для внедрения SOA-решения (например, отсутствие доказательств концепции и стресс-тестов);
* Недостаточное оснащение SOA-решений, сервисов и пользовательских приложений в части безопасности/управления/техподдержки;
* Предоставление недостаточной/несвоевременной документации.

Собственно, что-нибудь ещё можете добавить?

В догонку, "Самые частые организационные ошибки":

* Недооценка важности управления проектами;
* Уверенность в том, что проект SOA должен быть организован как любой другой проект разработки приложений;
* Не предвидеть взрывного роста количества сервисов в развитой SOA;
* Отказ от центров компетенции по интеграции или SOA;
* Использование только приглашённых архитекторов (или вовсе отказ от архитекторов).