Python PHP SOA дизайн - PullRequest
Новая
       0

Python PHP SOA дизайн

1 голос
/ 17 июля 2011

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

4-х уровневая архитектура .. 

|-------- database (NoSQL + SQL polyglot store)                --------|
|-------- python for all the heavy business logic              --------|
|-------- php would talk to python using SOA and render HTML   --------|
|-------- front-end (html+css+js)                              --------|
  • у нас будет два экземпляра python (2 машины), один будет сервером торнадо для совместной работы в реальном времени, а другой будет обслуживать бизнес-логику не в реальном времени.
  • PHP будет взаимодействовать с машиной не в реальном времени через четко определенные интерфейсы RESTful.
  • машина для совместной работы в реальном времени будет напрямую общаться с клиентом JS в браузере

Мои вопросы ...

  • Видите ли вы непосредственные недостатки в дизайне?
  • Какую наилучшую транспортную среду вы рекомендуете для связи RESTful - XML, JSON или protobuf (protobuf используется google)
  • как вы думаете, кеширование между слоями Python и PHP - хорошая идея? PHP не будет напрямую взаимодействовать с БД - только через Python.
  • что-нибудь еще, что вам нужно указать?

--- ОБНОВЛЕНИЕ ---

Хотя мне не разрешается раскрывать специфику приложения, я хочу сказать, что приложение очень совместный характер и имеет дело с большим количеством редактирования текста в браузере. Что-то вроде Google Docs - но не совсем.

Причина, по которой слой PHP важен, заключается в том, что ...

Нам нужно сохранить слой Python полностью независимым от шаблонов HTML. Этот слой не должен даже знаю, что мы создаем веб-приложение. Причина этого в том, что у нас есть несколько шаблонов. HTML для продвинутого браузера довольно сложный с большим количеством элементов управления, событиями жестов мыши и AJAX. Шаблон для старых браузеров (IE-6,7, FF-2,3 и т. Д.) прост и «только для чтения» - без взаимодействия ajax.

Существует также третий набор шаблонов, который нам нужно использовать для компонента приложения Adobe AIR. Компания также планирует выпустить мобильные и настольные версии приложения, если оно окажется успешный.

По этой причине мы просто не можем позволить себе вводить HTML на уровне python. Что мы можем сделать, это заменить слой PHP на другой слой Python (с django или что-то) обрабатывать шаблоны. Но мы думаем, что можем лучше обрабатывать шаблоны в PHP - потому что это так хорошо для шаблонов. Мы НЕ собираемся добавлять какую-либо сложную логику - просто Механика презентации.

1 Ответ

3 голосов
/ 17 июля 2011

Несколько мыслей о ваших идеях: Как упоминается в комментарии Микко, слой PHP кажется излишним. Не ясно, какую функцию он на самом деле реализует, особенно с точки зрения абстракции, которую он предоставляет поверх уровня обслуживания. Современный дизайн приложений имеет тенденцию к реализации пользовательского интерфейса в javascript + html. Поскольку вы уже взяли на себя обязательство раскрывать бизнес-логику через http, она также должна выполнить всю проверку ввода и авторизацию / аутентификацию, так что промежуточному программному обеспечению php просто не придется много работать.

Фактическая служба RESTful не диктует поддерживаемые выходные данные, скорее, она делает все возможное, чтобы удовлетворить Accept-Content-Type из запроса. По крайней мере, в Python проще всего поддерживать json. Protobuf все еще довольно молод, поэтому, если вам действительно не нужна строгая типизация, я не буду этого делать. Тем не менее, XML полезен с самоописательной точки зрения и может быть предпочтительнее, если внешний и внутренний интерфейсы разрабатываются изолированно.

...