|
锁定老贴子 主题：新近接触的一个企业应用协作平台
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
时间：2005-05-17
曾见过这样的一个系统，系统分“两层”编程。业务逻辑层和界面层。界面层接受用户请求，组织成XML，内容大致为请求命令和相关参数。业务层接收XML，解释XML，处理请求，访问数据库，产生数据，组织成XML回复给界面层，界面层解释XML，再转成界面语言。
这种结构下，一个逻辑不复杂的交互，几行业务语句却需要一堆的XML相关代码，本末倒置，下水重过肉。 |
| 返回顶楼 | |
|
时间：2005-05-17
thatway 写道 这种结构下，一个逻辑不复杂的交互，几行业务语句却需要一堆的XML相关代码，本末倒置，下水重过肉。 是不是说明负责人对技术的兴趣胜过项目本身？ 如果说本来就是一个技术实验性的项目，也不必如此厚非 |
| 返回顶楼 | |
|
时间：2005-05-17
nihongye 写道 1.所有的信息都是xml，相应的通过xpath,xql,dom等xml协议访问xml.
2.该平台管理着一系列soap节点，平台负责soap请求的分发。 3.最让我吃惊的是工作流的节点间流动着xml,因此对信息的操作，相当灵活。 xml的使用，相对数据库记录，数据的描述和访问手段丰富得多。相对对象，从信息的描述到访问又简单得多。 研究过一端时间的MS的集成服务器Biztalk（也有把它叫做面向服务的工作流引擎等等）,处理的方式看上去比较一致，消息一进去就转成xml，处理完了再转成想要的格式输出。 因为没有在实际项目中使用，我一直对它的效率很表示怀疑。 |
| 返回顶楼 | |
|
时间：2005-05-18
thatway 写道 曾见过这样的一个系统，系统分“两层”编程。业务逻辑层和界面层。界面层接受用户请求，组织成XML，内容大致为请求命令和相关参数。业务层接收XML，解释XML，处理请求，访问数据库，产生数据，组织成XML回复给界面层，界面层解释XML，再转成界面语言。
这种结构下，一个逻辑不复杂的交互，几行业务语句却需要一堆的XML相关代码，本末倒置，下水重过肉。 这本来就是一种莫名其妙的结构，怎么会是业务层来“接受XML，解释XML，处理请求，访问数据库，产生数据，组织成XML回复给界面层” 奇怪 这帖子也该删了，咋没人行动呢？ |
| 返回顶楼 | |
|
时间：2005-05-18
我倒有兴趣知道我错在哪里。虽然表达差了点，但看官们也能看得明白吧？
|
| 返回顶楼 | |
|
时间：2005-05-18
引用 这本来就是一种莫名其妙的结构，怎么会是业务层来“接受XML，解释XML，处理请求，访问数据库，产生数据，组织成XML回复给界面层”
奇怪 这帖子也该删了，咋没人行动呢？ 对异构平台的整合采用xml描述数据的结构，当然业务层处理的是xml数据，很奇怪吗？ |
| 返回顶楼 | |
|
时间：2005-05-18
nihongye 写道 对异构平台的整合采用xml描述数据的结构，当然业务层处理的是xml数据，很奇怪吗？ 怎么说业务层直接面对的是DOM,是很奇怪 |
| 返回顶楼 | |
|
时间：2005-06-04
怎么不提是什么平台？
|
| 返回顶楼 | |
|
时间：2005-06-05
|
| 返回顶楼 | |
|
时间：2005-06-06
BEA提出的Web Services的best practice有一条就是所有的参数和返回值都是xml的形式，当然wls提供了xmlbean，其实别的系统也可以用一些XML bean相同的东西
|
| 返回顶楼 | |
