By 高焕堂 2009/06/05
[Go Back]
云端(Cloud)领域小框架的设计策略
- 框架设计要领不在于技术,而在于心境。
- 因为框架是个送人的礼物,要表现爱心。
1. 从享受礼物到赠送礼物
兹回顾过去20年来的软件开发经验了。其中有两项重要的事迹:
- 1980年代后期,CORBA是一项对象导向的服务标准API,实现此项标准的系统中,最著名的商业中间键软件就是Orbix系统。然而,在系统架构上,API是一种约束,不是一种礼物,不能用来嘉惠予AP开发者。导致CORBA和Orbix系统架构无法支撑理想的商业模式,而终告消失匿迹。
- 1990年代中后期,继CORBA之后的是Microsoft公司推出COM/DCOM系统架构,虽然提供了当时先进的对象导向(Object-Oriented)的API,但还是API,仍然是一种约束,不是一种礼物,不能用来嘉惠予AP开发者。与CORBA和Orbix一样的系统架构,一样无法支撑理想的商业模式,也终告消失匿迹。
后来,IT业界逐渐发现:API可用来框住应用程序(AP),如同一把利剑;若要获得开发者的青睐,利剑必须搭配面包,就像钓鱼勾必须搭配鱼饵,才能吸引鱼群。于是,Microsoft改变观点,把焦点放在面包上,发现对象导向技术里的抽象类别(Abstract Class)及其提供的预设函数(Default Function)以及其它具体类别,所整合而成的框架(Framework)正是一项极具诱惑力的鱼饵。此外,由框架所提供的主动型 API,也能发挥巨大的控制力。因之,Microsoft于2001推出.NET框架来取代COM/DCOM,由于.NET框架融合了面包与利剑,既能嘉惠广大的开发者,又能有效框住众多的应用程序。于是,.NET框架成为Microsoft赠送给广大的开发者的最佳礼物,表达了Microsoft对全球广大第三方开发者关怀和爱心,让他们因.NET而受惠。
到了2007年,Google也依样画葫芦,买来Android框架,当成礼物赠送给全球的手机硬件厂商,也赠送给全球广大的AP开发者。由于Android框架「礼物」嘉惠予硬件厂商,所以硬件厂商也是受惠者,因而大力支持Android,也让Android声势扶摇直上。老子说:
「圣人无积,既以为人己愈有,既以予人己愈多。」
Google拿Android框架礼物来送人,所以Google会是最大的获利者。例如,Google公司CEO在接受华尔街日报访问时,他提到Android将带给Google公司每年100亿美金的收益,如下报导:
“Here is howa CEO talks to the Wall Street Journal when he wants his company’s stock pumpedup.
Today, Eric Schmidt was quoted saying, “If we have a billion people using Android,you think we can’t
make money from that? ”This was inresponse to his statement and belief that Android could potentially
make $10 billion dollars ayear in advertising revenue for Google.”
http://km.funddj.com/kmdj/News/NewsViewer.aspx?a=e2d6a048-85b9-4c97-8ce0-2f7faf25b283
(据华尔街日报报导,谷歌(Google)执行长Eric Schmidt预计,经由手机广告与应用服务的下载的服务,Android作业平台每年可带来100亿美元以上的营收。)
2. 我们能贡献些什么样的礼物呢?
那么,我们又如何找到自己贡献的空间呢? 如果拿一颗汉堡(Hamburger)来做比喻,则『UI层』面子就像汉宝上层面包和芝麻,而『平台层』里子就像汉堡下层的面包和牛肉。如下图:
如上图所示,一颗完整美味的汉堡,除了面包、牛肉和芝麻之外,还需要新鲜的蔬菜、起司和酱料等。也就是目前全球广大AP开发者最需要的是各行各业(即各领域)的内容(即礼物本身)。如果我们把注意力放在领域内容(Domain-Specific Contents)上,并且设计精致的礼盒(即软件框架),将之包装起来,成为形形色色的特殊领域框架(Domain-Specific Framework),并且附随在Android手机或Android电视机里,大量赠送给Android Market上的全球数以万计AP开发者,表达了我们对全球广大第三方开发者关怀和爱心,让他们都能享受美味可口的礼物。[歡迎光臨 高煥堂 網頁: http://www.cnblogs.com/myEIT/ ]
于是,手机或电视机厂商获得『平台层』里子;我们则获得『领域层』里子,却给予Google极大的面子,则里子、面子兼具地嘉惠予全球广大的开发者,基于这利己利人的作为,大家都是受惠者。
3. 领域框架与平台框架之结合:曹操的高度智慧
曹操的挟天子(大盘子)以令诸侯(玉珠)。
- 平台框架像大盘子
- 领域框架像小盘子
- 玉珠皆落小盘大盘
本来玉珠直接落到大盘子里。现在,小盘子迭在大盘子上,而玉珠则落在小盘子上。如下图所示:
大框架提供的API包含doPost()函数(如同汉宪帝的圣旨),小框架则将其转换成为自己的API:getMediaObject()函数(曹操的命令)。所以是挟天子以令诸侯。
- 小框架就扮演着曹操角色,实现了
- 挟天子(大盘子)以令诸侯(玉珠)
Android的myActivity类别 与myUploadPost类别之沟通,必须经由大框架和小框架。所以整体系统的控制点在于大框架与小框架里。至于大、小框架何者拥有较大控制权,就得视其框架API和类别内容而定了。
- 就商业利益看,小盘子获利较大。
- 其实曹操的金银财宝比汉宪帝多。
如下图:
在撰写ac01类别时,仍然使用大框架的Servlet接口,AP仍然依赖于大框架的接口。如果小强龙想完全主导地头蛇的话,就必须想办法去避免ac01类别直接使用大框架的接口。于是改善系统架构如下:
其中,CalculateSub类别、CalcuateProxy类和ICalculate接口整合起来成为小框架,让ac01类别和CalSub类别都使用到小框架的接口(如Add()和Mul()函数),而不直接使用大框架的接口(如Servlet接口)。就完整实现了「挟天子以令诸侯」的目的。
4. 框架设计范例:云框架里的小框架
- 从云看端的观点
兹拿公有云平台为例,TM设计模式提供两个API来支持公有云,基于TM模式的框架让公有云成为系统强龙。如下图:
图-1 云强龙的系统架构(型式一)
稍微调整一下上图-1,得到下图-2,这是常见的层级(Layered)结构。
图-2 云强龙的系统架构(型式二)
这系统架构支撑XX公有云的云主,让其稳居强龙地位。由于框架拥有主动型API,所以云主敢大胆地让外人(地头蛇)进来撰写领域模块软件。于是,在公有云平台(含框架)里,会有含有众多外人(例如图4.2中的A、B、C等地头蛇)进来撰写各自的领域模块。
- 从端看云的观点
公有云像百货公司,而领域模块像专柜店面。领域云际平台就像连锁专柜企业。就云际平台而言,它也希望自己成为强龙。它除了撰写云际平台软件之外,还在各公有云里撰写领域模块(如同开设专柜)。如下图所示:
图-3 端(领域云际平台)期待成为强龙
虽然A领域云际平台期望自己是强龙,但是从上图可以看出,其系统架构并不能支撑A连锁专柜成为强龙。其原因是:在公有云里的「A领域模块」只提供被动型API给公有云框架来调用(实现了公有云框架的主动型API),因而扮演地头蛇的角色。那么,如何才能调整上述的系统架构,才能支撑A领域云际平台的强龙地位呢?方法是:在公有云里创造自己的主动型API,如下图:
图-4 从端看云的强龙系统架构
起初,可能必须由A领域云际平台负责撰写公有云里的「A领域模块_Stub」,然而随着A领域云平台所支撑的商业强龙地位日益形成,可能转变为A领域云际平台与YY公有云平台合作一起开发「A领域模块_Stub」,或者由YY公有云平台负责撰写「A领域模块_Stub」。
为了让A领域云际平台不直接使用YY框架的被动型API(因为这个API是由YY公有云平台所定义的,其定义权掌握在YY公有云平台手中,而不是由A领域云际平台所定义的),就增添一个「A领域模块_Adapter」。为了说明上图的经济效益,还是拿曹操的「挟天子以令诸侯」来做比喻最为传神了。上图的「A领域模块_Adapter」和「A领域模块框架」成为曹操角色,将YY云平台的API封装起来,达到「挟天子」的意境。由于「A领域模块框架」提供主动型API来调用A领域模块_Stub,逐渐形成「令诸侯」的意境。◆
[Go Back]
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步