|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-30
asialee 写道 你们公司的UI不错，做的东西都挺好看的。 我什分同意你的看法。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
Iframe确实很土也有很多问题，但实际做项目的时候，你会发现确实是个好东西。
我们实际的做法是，可以完全控制、能够复用的部件，用标准portlet开发实现。 对于项目中特定的整合需求，尽量用iframe实现，这个对被整合系统方面的技术要求是最低的。 有些时候，也用了楼主提到的httpclient代理的方式，这个也是个好东东，可以克服iframe的种种弊端。 总体的感受是，做portal项目时，思路不能太技术化，能最快解决问题的技术就是好技术，呵呵~ |
| 返回顶楼 | |
|
发表时间：2009-07-30
最后修改：2009-07-30
看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成
iframe - 最土的方式，也是用得最多的方式，不说了。 proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。 xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。 数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。 业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
lnaigg 写道 看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成
iframe - 最土的方式，也是用得最多的方式，不说了。 proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。 xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。 数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。 业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。 哈哈，露两手不错。 我上面说了CAS怎么解决代理模式下的用户认证问题的。实际上CAS的PGT、PT就是应对这种要求的。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
popoer 写道 Iframe确实很土也有很多问题，但实际做项目的时候，你会发现确实是个好东西。
我们实际的做法是，可以完全控制、能够复用的部件，用标准portlet开发实现。 对于项目中特定的整合需求，尽量用iframe实现，这个对被整合系统方面的技术要求是最低的。 有些时候，也用了楼主提到的httpclient代理的方式，这个也是个好东东，可以克服iframe的种种弊端。 总体的感受是，做portal项目时，思路不能太技术化，能最快解决问题的技术就是好技术，呵呵~ 我觉得你确实是实际做了Portal项目的人，很有道理。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
lnaigg 写道 看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成
iframe - 最土的方式，也是用得最多的方式，不说了。 proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。 xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。 数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。 业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。 楼上的强！ 我认为这几种也都可以归结为proxy模式的不同实现，实际都是开发一个通用的框架或者potlet来整合应用，应用不需要真正按照jsr规范去开发portlet了，而是按照你定义的简化版规范来提供数据，根据对数据规范的要求不同，应用系统改造的成本也有所差别。 整合的方式，还忘了一种，就是利用jsonp，纯脚本方式的，不给portal server增加任何负担，也是值得尝试的。 另外，igoogle的widget也是值得研究的。 我认为在portal项目中，整合、认证这些一般都还是比较好解决的，最麻烦的还是权限问题，搞不好一个权限分配问题会需要到N多个系统进行授权，这个也是最难统一整合到一起的。 |
| 返回顶楼 | |
|
发表时间：2009-07-31
最后修改：2009-07-31
楼主的问题不太看的懂。觉得楼主最好多看看企业里使用portal的人，他们的系统是什么样子的。
对于技术问题。主要的实现就是一个所谓的portletcontainer， 依据jsr168. 当然168有很多的限制还有待268的改进。所以基本上每个公司都基于168有自己的扩展来满足那些还不被支持的标准。比如portlet和portlet之间的通信，portlet和portal之间的通信。 要学习jsr168或者268的实现，建议你看一下 pluto 的源代码，只是一个最最简单最最纯粹的portlet container。这个算是必经之路。 |
| 返回顶楼 | |
|
发表时间：2009-07-31
最后修改：2009-07-31
lnaigg 写道 先说说兼容性问题：大部分开源Portal都可以作为一个普通web应用部署，只是因为各个web容器的servlet实现都有所不同，Portal对容器的兼容性也成了很大问题。例如，Jetspeed2移植到weblogic上时就要解决很多问题。所以，想找一个全面兼容各大服务器的Portal很难，起码我没找到。
再说说我所理解的Portal：Portal可以比作一个商场，商场不直接卖东西，只提供一个服务环境、各种基础设施，没招商之前只是一个空壳。Portlet是就是商家，所以“Portlet成了最重要的资产”，这个是很正确的。 其实，不管哪个厂商的Portal，其实都是只做两件事情：页面布局和解析Portlet。其中，解析Portlet这个工作其实是次要的，各个Portal都一样，因为有标准规范（JSR168）。真正考验实力的是页面布局。页面布局分几个部分：页面模版、排版方式、Portlet状态，等。特别是页面模版，各个厂商实现都不同，这是需要细心评估的，因为Portal的二次开发主要是在做页面模版，各种美工。 再说说Portlet：LZ说的伪Portlet，后面有人说的iframe，这些都是属于没有理解portlet思想而产生的思路，是用普通网页开发方式套到Portlet上了。其实portlet开发、部署、卸载、调试都十分方便。真正需要做的是，实现一个功能全面一点的portlet基础框架，能读写数据库、能读到登录用户信息、能与Portal或其他公共应用交换数据，然后是用该框架做实际的业务。 另外，Portal的定位决定了Portlet不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。 呵呵。前半部分完全正确。后半部分不太准确。 页面布局这样的事情是UI的工作，应该是portal产品里最简单没有技术含量的事情。对于portal产品，每家都是遵循jsr168却都有自己的扩展，jsr168的实现方式和这些扩展才是portal的核心。 另外，portlet的接口绝大多数定义了一些和portal集成和数据交换等表现层的东西。和业务逻辑毫无关系。多数的产品都是可以包装成portlet, 部署到portal里。比如struts, 和spring mvc就原生支持portlet dispacher. 还有很多的generic 分发器可以用来做这个包装。portlet 的后台可以很复杂比如工作流引擎像intalio bpms, 比如KM管理如alfresco，甚至是一个拥有全球多个数据中心的超级搜索引擎如google  。当然也可以很简单的显示一个日历
|
| 返回顶楼 | |
|
发表时间：2009-07-31
lnaigg 写道 看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成
iframe - 最土的方式，也是用得最多的方式，不说了。 proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。 xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。 数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。 业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。 lnaigg兄多露两手吧 能不能就每种方式画个图啊？另外能不能就跨context的认证提供一个建议阿？
|
| 返回顶楼 | |
|
发表时间：2009-07-31
Portal其实最大的应该是整合集成（portal的本意），而在其基础上开发应用反而应该是少数才对。
但整合起来，其实，很难。。。。尤其是已经用了很多年的老系统，每个系统都是不同的用户管理和权限控制，没有达到统一认证的前提下，一般都是伪认证。如果有注册码，那基本就死掉了。这种方法虽然可以解决认证的问题，但弊端也是显而易见的。 |
| 返回顶楼 | |
