yongtree
2010-11-22 13:14

API是应用程序编程接口(在此我们不特指为函数调用),与服务接口类似,SOA替代API是可以的。语言与库是同体,有语言就有库,库通过API调用。将它们映射到管理系统,组件是库,好的系统是柔性的,不是硬盒,也可组合共享,库的作用在此。组件中需要有业务实体、规则算法、状态及流程编排等领域中可描述的的语义对象来创建模型。SOA比API高阶,如果SOA死了,API就是化石了,反推,SOA是不会死的,只会被新的编程接口模式所替代,组件是活的,是说要关注业务模型的本质,本质没了,系统就死了。

http://www.po-soft.com/hi/slx/blog/1964

banq
2010-11-22 15:29

最新一篇文章 :

DCI和服务Services (EJB)

文章提到两点对你感兴趣的业务组件课题有帮助:

1.组件概念中的服务是非面向对象的,而DCI中场景更OO;

2.企业可以在建立组件服务库的同时,建立DCI场景库,到底是两个一起建立,还是抛弃传统的服务库,直接建立场景库?

当然,我立场支持后者。

但是因为组件属于技术架构层次,而OO属于面向业务层次,两个水火不容,硬是搞在一起,不匹配阻抗总是不可避免,这也是业务组件吃力不讨好的原因所在。

flyzb
2010-11-23 00:04

参考IBM CBM资料

其实,我是赞成企业的业务中存在业务组件的,比如BOM,应该由单独的一个业务组件来完成。业务组件是可以独立发展的,但是对外提供的服务相对稳定,这样就可以使得我们的企业IT架构更具有柔性。

yongtree
2010-11-23 08:59

板桥的东西一般很深奥哦,我琢磨良久不敢回复。

MVC、DDD、DCI是OO的一些模式,我想说,组件化模型其实也是一种模式,如果说系统要是OO出来的,其复杂度让任何一种OO模式都显力不从心,我们知道,汽车不是OO出来的,飞机不是OO出来的。但它们可能是CO出来的,故而尝试业务系统(ERP)CO出来,是一种想法,从O->C->S,复杂度是递减的,管理C的容器比管理O的容器也相对简单点,因为C本身是O的S,是可运行的实体。如果再把C看作O的话,MVC模式足矣。"OSGI叫喊了那么多年,到现在还无法成为主流" -- 框架是卖给程序员的,组件是卖给企业的。也许黑洞或反物质本身就是一个伪命题,或许根本无法存在。呵呵,继续。

http://www.po-soft.com/hi/slx/blog/1964

sinaID14424
2019-03-11 15:16

组件,就像COM中的Component,内部可包含较多的类的实例,对外提供若干接口,是以二进制形式存在的一种程序,比API高级(API的概念跟C库函数类似,只是简单的一段可执行代码,背后是一个运行时),组件这个词也比较古老了,到了Java和C#时代,组件已经成为默认的开发服务提供方式,组件被实现为二进制,接口为文本描述以供用户参考。SDK的发展:中断调用(汇编)——API(C)——类库(比如MFC,OWL)——组件(COM/Corba)——虚拟机模式(仍然是组件)

2Go 上一页 1 2