o**2
发帖数: 168 | 1 前言
===========================================================
FMP的核心理论一直没有变过， 之所以有1.0、2.0、3.0， 是因为分阶段推广的原因，
不同阶段对功能的要求有不同的取舍。 从目前的结果来看， 我的推广策划能力远远
不及我的编程能力， 所以干脆把FMP的全部功能一起推出来了， 也就是3.0。
3.0的东西我还没有在其他地方发过， 我觉得Mitbbs的小圈子挺不错的， 非常适合先
试试水， 希望能听听大家的意见， 高见和低见都欢迎， 只要不歪楼都行。 我在这里
邀请所有的人来参加讨论， 特别是zhaoce和goodbug， 我挺认同你们平时的一些看法
的， 希望你们能对3.0给出一些专业的意见。
FMP针对的是并发和分布编程， 并发主要是在单机内， 分布就是多机了。 FMP的独特
贡献是提供了一个统一的language independent的编程style和element， 轻松地把这
两个重大问题都解决了。 FMP提供的不是具体的系统或实现， FMP提供的是一个独创的
简洁的设计， 使得设计并发和分布系统的门槛大大降低了。 而且在任何一个Object-
Based的语言上实现FMP本身的门槛都是非常的低， 在校的学生就可以轻松实现FMP本身
。 （我在Java上实现的reference implementation就是1000行左右，还包含空行了。）
简单地说， 在我的眼里，FMP是一个game changer。 当然， 也可能是自己的娃自己觉
得特别， 所以请大家下重手下辣手来拍， 要么把我的梦拍醒了， 要么FMP的确是革命
性的。
现在开始介绍FMP的组成成分了。 （如果你觉得我在这里写的东西有些不完全，那你也
许要读一读FMP的official site，熟悉一下基本概念。）
1, Service object
===========================================================
这个就是之前的active object， 我把它改名的原因有二。 一是service这个词更被广
泛接受， 大家都能接收到它隐含的server-like, service-oriented, 和independent
execution等概念。 二是active object在concurrent programming里更合适， 而
service在distributed programming里更合适。 3.0的重点是分布式编程， 所以只好
挥泪斩马谡了。
下面就是一个service object：
"calculator"
-- int "multiply" (int n1, int n2)
-- int "divide" (int n1, int n2)
这个service object叫做"calculator"， 它有两个services， 一个是"multiply"，
另一个是"divide"。 一个service相当于一个method， 有a number of input
parameters和a return value。 当然，input和output都是optional的。
你按SOA里的service来理解service object就对了，FMP相当于把service-oriented
programming引入了object的级别。
Service objects作为一个概念， 属于虚拟的， 因为在任何一种语言上， 你实现了这
样的interface， 并实现了它的行为（via messenger object）， 那个object就可以
叫做service object。 但对于一个具体的service object， 它不是虚拟的， 你必须
要在你选定的语言上实现它。 FMP规定你必须用通过messenger object来使用和实现一
个service object。
2, Messenger objects - API
===========================================================
Messenger objects是普通的objects， 在Java上的messenger objects是用Java写的，
在JavaScript上的messenger objects是用JavaScript写的。 因为Messenger object
负责提供使用service object的方法， 同时提供实现service object的方法。 所以
messenger不能是虚拟的了， 实际上它更象虚拟机， 因为它让service objects在它里
面”活“起来了。
如何在messenger object的支持下实现一个service object就不介绍了， 请参考http://fastmessenger.com/kb-example-03/。
我在这里介绍如何在messenger object的支持下使用service objects。 一般来说一个
messenger object提供三种方法， 也就是API， 用来使用service objects。
a) messenger.sendRequest ("calculator:multiply", 3, 7)
b) messenger.sendRequest ({}, "calculator:multiply", 3, 7)
c) messenger.sendRequest (futureToken, "calculator:multiply", 3, 7)
首先申明， 相对于调用者， 任何一个service object都是完全asynchronous的。 上
面的调用， 可以在程序的任何地方使用， 可以是和FMP没有关系的代码， 也可以是从
一个service object里调用其他service objects。
a)是最基本的调用方式， 调用的代码给calculator发了request后就不管了， 自己继
续执行， 而calculator则会在合适的时候执行3x7。 合适指的是其他的request都执行
完了， 同时也能弄到一个空隙的线程了。 当然，这个例子不是很好， 因为做了乘法
后又不要结果， 没有什么意义。
b)是需要service的返回值的， 这个 就是包含了足够的信息用来让
messenger执行一次a)形的调用。 也就是将返回值转发给另一个service object。
举个具体的例子：
messenger.sendRequest ({"sheet:cell", 20, 30, ?}, "calculator:multiply", 3
, 7)
它的意思就是叫messenger先发3x7的request到"calculator:multiply"， messenger拿
到结果21后， messenger（而不是calculator）再把结果转发给sheet。 相当于：
messenger.sendRequest ("sheet:cell", 20, 30, 21)
这里假设"sheet:cell"的method singature是：
"sheet"
-- void "cell" (int row, int col, int value)
c)的用途和b)的一样， 只是接收reply的不是一个service object， 而是非FMP的代码
。 这个token支持both sequential和event-driven programming。
futureToken:
boolean isReturnReady () // non-blocking
getReturnValue() // blocking (optional, not all languages support
blocking calls)
void addListner (listener) // non-blocking
3, Messenger objects - Static routing
===========================================================
大家都用过家用的router， 都知道port farwording， messenger的这个功能是类似的
。
messenger.addRoute ("calculator:*", "accountant:*");
上面这个例子就是告诉messenger， 收到给calculator的requests， 都forward到另一
个叫accountant的service object那里去。
大家说说这都有啥用途啊？
4, Messenger objects - Net for distributed applications
===========================================================
这个是3.0的重点了， messenger objects是可以互联的。 首先是异构性， 两个互联
的messenger objects（用m1和m2表示）有很多可能性，典型的有：
i) m1 and m2都是Java的， 在同一个程序中（shared memory）
ii) m1 and m2都是Java的， 在不同的程序中
iii) m1是Java的， m2都是JavaScript的
只要你能access m1，你就可以：
m1.sendRequest ("m2::calculator:multiply", 3, 7)
如果有1000个messenger objects互联了，对你没有区别：
m1.sendRequest ("m1000::calculator:multiply", 3, 7)
要做到这一点很难吗？ 一点都不难。 这里有两个问题： 一是路径问题； 二是数据兼
容的问题。
路径问题我就不解释了， 给你的提示就是： 一个messenger object相当于internet上
的一个computer或router； "m1"相当于"amazon.com"或125.32.54.14， 所有internet
上的协议都可以套用在这里。
数据兼容是一个问题， 当m1 and m2在同一个process里， 也就是case i， 共享内存
， 那基本上没有兼容问题， request和return里可以放任何objects。
Case ii m1 and m2都是Java的， 兼容性差一点， 但是可以用serialization传很多的
objects。 当然和本地资源有关的objects是不能传的了， 比如socket，UI widgets等。
Case iii 是跨语言的， 就更差一级了， 但只要能用JSON表达的objects就可以传。
5, Messenger objects - Net forwarding
===========================================================
在一个大的由messenger objects组成的net里， 每个messenger都有可能要转发
requests， 就好像internet上的routers要转发数据包一样。
messenger.addNetRoute ("m1", "m2");
上面这个例子通知messenger， 检查所有的经过的requests， 目标地址是m1的，全转
发给m2。
结论
===========================================================
FMP 只提供一个统一的programming style and element， 就可以让你设计从小到一个
单个的 service object "calculator"， 并轻松地合并到现有的程序中； 到大到一个
和internet一样大一样分布的应用程序。
恳请不要转发其他版， 我想集中所有的讨论在一个地方。 | o**2
发帖数: 168 | |
|
