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 加持，快人一步