Python PHP SOA 设计
我正处于一个中等规模的应用程序的规划阶段——经过一些讨论和会议，我和我的学院得出了一个结论：我们将在这个应用程序中使用 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 模板。那层不应该 甚至知道我们正在构建一个 Web 应用程序。 原因是我们有多个模板。高级浏览器的 html 相当复杂 有很多控件、鼠标手势事件和 ajax。 适用于旧版浏览器的模板（IE-6,7 FF-2,3等） 简单且“只读”——没有 ajax 交互。
我们还需要将第三组模板用于应用程序的 Adobe AIR 组件。 该公司还计划发布手机和平板电脑。该应用程序的桌面版本（如果是） 成功的。
因此，我们无法在 python 层引入 HTML。 我们能做的就是用另一个 python 层（用 django 或其他东西）替换 PHP 层 来处理模板。但我们认为我们可以在 PHP 中更好地处理模板—— 因为它非常适合模板。我们不会添加任何复杂的逻辑——只是 演示机制。
I am in the planning stage of a moderately big application -- and after some discussions and meetings, my colleges and i have reached a conclusion that we'll be using SOA for this App. Here is the brief plan...
a 4-tier architecture..
|-------- 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) --------|
- we will have two instances of python (2 machines) one will be tornado server for real time collaborations and the other will serve the non-realtime business logic.
- PHP will talk to the non-realtime machine via well defined RESTful interfaces.
- realtime collaboration machine will directly talk to JS client in the browser
My questions are...
- do you see any immediate flaws in the design?
- what is the best transport medium you recommend for RESTful communication -- XML, JSON, or protobuf (protobuf is used by google)
- do you think caching between Python and PHP layers is a good idea? PHP will not do any direct DB communication -- only through Python.
- anything else you need to point out?
--- UPDATE ---
Although I am not allowed to reveal the specifics of the app, I want to tell that the app is a highly
collaborative in nature and deals with a lot of editing of text in the browser. Something like Google Docs -- but not exactly.
The reason PHP layer is important is because...
We need to keep the Python layer completely independent of HTML templating. That layer shoudn't
even know that we're building a Web App.
The reason for this is that we have multiple templates. The html for advanced browser is fairly complex
with lot of controls, mouse gesture events and ajax.
The template for older browsers (IE-6,7 FF-2,3, etc.)
is simple and "read only" -- with no ajax interactions.
There is also a third set of templates that we need to use for the Adobe AIR component of the app.
The company also has planned to release the mobile & desktop versions of the app if it turns to be
successful.
For this reason, we just can't afford to introduce HTML at the python layer.
What we can do is replace PHP layer with another python layer (with django or something)
to handle the templating. But we think we can handle templates better in PHP --
because it is so good for templating. We are NOT going to add any complex logic -- just
the presentation mechanics.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对你的想法的一些想法：正如 Mikko 的评论所提到的，PHP 层似乎是多余的。目前尚不清楚它实际将实现什么功能，特别是在它在服务层之上提供的抽象方面。现代应用程序设计倾向于使用 javascript+html 来实现 UI。由于您已经致力于通过 http 公开业务逻辑，因此它还必须完成所有输入验证和身份验证/身份验证，因此 php 中间件不会有太多工作要做。
实际的 RESTful 服务并不规定它支持的输出，而是尽力满足请求中的 Accept-Content-Type 。至少在 Python 中，支持 json 通常是最简单的。 Protobuf 还很年轻，所以除非你真的需要它提供的严格类型，否则我会远离它。不过，从自我描述的角度来看，XML 很有用，如果前端和后端是独立开发的，那么 XML 可能是首选。
A few thoughts on your ideas: As Mikko's comment mentions, the PHP layer seems superfluous. It's not clear what function it will actually implement, specifically in terms of the abstraction it provides on top of the service layer. Modern application design is tending towards implementing the UI in javascript+html. Since you're already commited to exposing the business logic via http, it must also do all of the input validation and auth/auth already, so the php middleware just won't have much of a job to do.
An actual RESTful service doesn't dictate the outputs it supports, rather, it does its best to satisfy the
Accept-Content-Typefrom the request. In Python at least, it's usually easiest to support json. Protobuf is still pretty young, so unless you really need the strict typing it provides, i'd keep away from it. XML is useful, though, from a self-descriptive point of view, and might be preferred if the front and back ends are being developed in isolation.