cocoon研究(值得深入研究)
cocoon是一个通用的基于组件的web开发框架，它着重于分离开发中的关注点，为整个系统各功能单元解耦合，因此使用cocoon的处于不同角色的开发者在互相不了解的情况下也能够进行良好的交互协同。
但凡有过系统分析经历的开发者都明白，在进行系统分析和设计得的时候，对关注点的分离，对系统中各单元的解耦合，是一个焦点也是一个难点。那么cocoon中是怎么实现关注点的分离呢？
cocoon中引入了"组件管道"的概念，这里的管道概念和unix shell 中的管道概念相同，就是将一系列分离的操作串在一起，前一操作的输出为后一操作提供输入，以完成一个较复杂的处理，就像一节一节的管道前后相连，数据在其中流动。处于管道中的每一个组件都负责一个明确的特定的任务。通过将不同的组件加入到管道中形成一个整体，就使得仅仅通过对组件的"堆砌"而不用编程就能提供一个完整的web解决方案成为可能。
cocoon自称为"web应用开发中必不可少的粘合剂"，而且是一种在达到关注点分离的同时还能提升开发进度和降低开发冲突的万能胶水。
cocoon被设计为可以与现存的J2EE应用共存和互操作，在不需要修改基础架构的情况下为系统增加新的功能。
cocoon可以和很多数据源交互。包括文件系统、RDBMS、LDAP、纯XML 数据库、SAP® 系统和基于网络的数据源。它可以使输出内容适应不同设备的能力，比如HTML、WML、PDF、SVG、RTF等许多格式。cocoon可以被作为一个servlet运行于web服务器中，也可以通过一个功能强大的命令行接口使用。由于cocoon的抽象设计是经过深思熟虑的，所以可以为开发者提供一个自由的扩展空间以满足自己特殊的需求，而且这些扩展都是高度模块化的，这样就使整个系统是建立在一个相当灵活和清晰的架构平台上，帮助用户达到随需应变的发展要求。
cocoon的组件化和关注点分离的概念得益于它底层所使用的excalibur框架，而excalibur又是Avalon框架的延续。Avalon项目是apache下的一个子项目开始于1999年2004年分割为Excalibur、Loom、Metro、Castle。它倡导反向控制(IoC)和关注分离（SoC)。
此外，cocoon还内建了高级的控制流机制。通过连续的页面流控制隐藏了复杂的请求/应答处理，并使视图层和数据层的分离更加清晰。
下面介绍一下cocoon的主要应用领域。
动态的多频道的web内容发布——cocoon能够与很多数据源相连并提供多种输出格式
自动的创建静态内容——cocoon可以使数据脱离视图而存在
离线模板生成——cocoon提供命令行接口（CLI）、ant task、bean等操作手段
EAI
CMS
Portal
i18n
.....
Cocoon是一种Java服务器框架，它允许使用XSLT（XML样式表语言转换(XML
StylesheetLanguage-Transformation)）转换动态发布XML内容。通过依靠XML描述内容以及使用XSLT将内容转换成多种格式，Cocoon提供了用于构建内容、逻辑和表示在很大程度上彼此分离的应用程序的平台。
相关站点/下载地址：http://jakarta.apache.org/tapestry/
cocoon是一个基于XML的Web发布框架，提供了一套机制真正实现了内容，逻辑，和表现形式的分离cocoon具有高效的可配置性和复杂的缓存机制.
Cocoon使用管道的概念来描述将内容发布到Web的过程。它包含各种各样的可重用组件，这些组件可以配置成使用最低限度的Java开发生成复杂的行为。例如，通过单独使用XML和XSLT，Cocoon可用于：
提供静态文件和动态生成的响应使用任意数量的处理将用户请求透明地映射到物理资源执行简单和多级XSLT转换将参数动态传递到XSLT变换生成各种各样的输出格式，包括XML、HTML、PNG、JPEG、SVG和PDF这大大增加了使用XML和XSLT中现有技巧进行工作的功能。Cocoon让您能以最少的麻烦生成动态网站。
一、Cocoon1和Cocoon2
Cocoon是一个开放源码项目，它是作为ApacheXML工作的一部分开发的。Cocoon2完全重写了原始的Cocoon应用程序，并且是建议使用的版本。新用户应该一开始就使用Cocoon2，同时鼓励Cocoon1的现有用户进行升级。
Cocoon2项目的目的是吸取Cocoon1开发中的教训并使用它们来设计一个更有效和更可伸缩的平台。特别是，Cocoon1依靠文档对象模型（DocumentObjectModel(DOM)）API在组件之间传递XML数据。DOM是传递数据的一种低效方式，因为通常的DOM树会消耗几倍于原始XML文档的内存。这在很大程度上限制了Cocoon的可伸缩性。Cocoon2是围绕SAXAPI构建的，SAXAPI是操纵XML数据的一种轻量级方法。
两个Cocoon版本之间的另一个主要区别集中在应用程序管理上。在Cocoon1中，个别的XML文档通过包含Cocoon处理指令信息声明了应该如何处理它们。这将文档绑在特定处理上，极大限制了以不同方式重用内容的灵活性。Cocoon2将处理的管理划分到一个称为网站地图（sitemap）的配置文件。这将处理逻辑与内容本身分离，依次分离内容、逻辑和显示。
二、cocoon的安装
cocoon本身是一个web application,需要在有Servlet engine的服务器中运行。 解开cocoon的安装包（现在稳定的版本是2.0.3)，会有一个名为cocoon.war的WAR包, 这是安装唯一用到的文件。将它Copy到TOMCAT_HOME/webapps目录下，然后启动Tomcat, Tomcat会自动解开cocoon.war到TOMCAT_HOME/webapps/cocoon目录，这时键入URL: http://localhost:8080/cocoon ,如果看到cocoon的Welcome页面，就表明Cocoon已经成功的安装了，非常简单。需要注意的是，这时应该关了tomcat,将cocoon.war删除，原因是我们将要在以后的时间里不断的修改和配置TOMCAT_HOME/webapps/cocoon中的文件， 而cocoon.war已经无用了。
三、cocoon是一个高度的可配置性的环境，有几个文件是和配置有直接关系的。
TOMCAT_HOME/webapps/cocoon/WEB-INF/web.xml
TOMCAT_HOME/webapps/cocoon/WEB-INF/cocoon.xconf
TOMCAT_HOME/webapps/cocoon/WEB-INF/logkit.xconf
TOMCAT_HOME/webapps/cocoon/sitemap.xmap
cocoon本身是web application,自然有web.xml
cocoon.xconf是cocoon的配置文件，相当于JSP中的web.xml文件在JSP中的作用logkit.xconf是cocoon的日志配置文件，灵活性很大。
sitemap是cocoon的一个核心的概念，sitemap.xmap中有许多复杂的配置项，要会配置他们,首先要对cocoon有一个整体的认识，随着你对cocoon认识的更多，你对sitemap.xmap的配置也就越了解。
四.cocoon的基本概念
Pipeline是Cocoon2(cocoon2和cocoon1是有很大的不同的，所以无需知道任何关于cocoon1的东西)的基本概念.Pipeline由多个cocoon 组件构成,输入流经过Pipeline到输出流，每个组件会对输入流进行处理，然后送到下一个组件处理，直到最后的输出。处理的组件和输入流都是在前面提到的sitemap中配置的。在一个应用中可以有多个Pipleline,每个Pipeline中可以有多个不同的处理，每个处理和输入的URL有关。
4.cocoon的基本组件
Matcher :是捕获URL地址，将其和Pipeline的一个处理流向关联
Generator :将输入流转换成Java 的SAX程序，为后续的处理提供SAX程序
Transformer :对Generators产生的SAX程序进行格式转换
Serializers ：对经过Generators和Transformer转换的结果产生最后的输出流，
输出流可以是html,xml,wml,jpeg,png,pdf等不同格式的文件.
XSP:全称是eXtension Server Page,也有人叫XML Server Page,是Cocoon提供的一种服务器脚本语言，类似于JSP或ASP,但是完全基于XML的,它可以作为Generator的输入流
5.一个简单的URL请求处理的过程
cocoon在sitemap中寻找和URL匹配的Matcher项，然后对应Generator中配置的输入流(通常是XML文件或XSP文件A，用相关的Generator处理组件处理输入流,接着读取Transformer的中的输入流B(通常是XSL文件，Transformer组件用B对A进行格式转换(如将XML文件转换为HTML格式),一个管道中可以有0个或连续多个Transformer处理,最后Serializer组件根据Serialize的类型(html,wml,pdf,jpeg等)产生最后的输出。
相关的Sitemap片断
再谈Cocoon兼谈JSPhax（原作）
发信人:HAX(海曦),信区:WebDevelop
标题:再谈Cocoon兼谈JSP
发信站:饮水思源(2002年06月06日01:17:17星期四),站内信件
著名的 IBM DW 中文网站，推出了Cocoon 2的简介教程，从而再次把我们 的目光吸引到Cocoon上。以下是我在CSDN的XML讨论区发表的个人看法，贴过来涨点人气。
IBM的这个教程非常好，强烈推荐。BTW，IBM的DW网站比CSDN有用多了。
关于Cocoon，希望有一本《XSP/Cocoon/XML核心技术内幕》，基本上编译了一些基本的Cocoon文档，有一定的参考价值。这也是我看到的国内唯一的一本Cocoon的参考书。但是该书如同其它国内书籍一样，对于基本理念的阐述不够详细和清晰。
Cocoon的原始动力是为了实现Content-Style-Logic的三层分离，这是一个Web Engineer的很好的实践。
Cocoon也源自于以前的ServerPages技术（主要是针对JSP，当然ASP和PHP也有同样的问题）的缺陷。尽管JSP提出了JSP Model 2，来实现Model-View-Controller分离，即用JavaBean表示数据（内容），用Servlet控制业务逻辑，用JSP实现显示逻辑和表现层，但还是有些实践上的缺陷。关于这个问题的描述，在2000年10月的文章《JSP 技术 - - 是友还是敌？》（http://www-900.ibm.com/developerWorks/cn/java/w-friend/index.shtml）中有详尽的讨论。
但是如果我们跟上技术发展的步伐，就会看到这个问题由于标签库技术的成熟和servlet过滤器机制的诞生而得到解决。TagLib早就有了，但是直到临近JSTL即JSP Standard Tag Library的正式发布，其威力才真正显现。
从角色任务上看，程序员主要负责JavaBean、Servlet和编写自定义标签库（现在可以使用JSTL从而大大减少负担）；设计者编写“不包含java代码”的JSP，实际上是若干种标记的混合，HTML+JSTL+自定义标签。我认为这种框架比较适合于以Java程序员为主的团队，以及业务逻辑复杂的应用。
注意，正如JSP的内嵌Java代码可以实现业务逻辑，JSP的TagLib技术，一样可以用于实现业务逻辑。当然使用TagLib将比内嵌Java代码好许多，因为代码被封装到了TagLib中，因此对于小的应用还是可以使用JSP，而不用写Servlet。例如使用JSTL的sql tag，来直接处理数据库（这实际上意味着基本没有或者只有极其简单的包含在sql语句中的业务逻辑）。也可以用像
Apache的Struts是一个基于JSP实现MVC的很好的框架，建议有兴趣的同志研究研究。
而Cocoon，用XML表示数据（内容），用XSP（非常类似JSP的XML形式）编写业务逻辑，用XSLT实现表示层（HTML、WML、某种格式的XML甚至PDF），并用sitemap（Cocoon 2）集中管理。XSP逻辑单则与JSP的TagLib从概念到用法非常相似，只是实现方法略有不同。JSP的TagLib包括一个xml格式的定义文件和实现的Tag类，并被编译使用；而XSP逻辑单则在运行时（当然可以进行Cache）应用XSLT进行从标记到代码的转换。
（按照我对IBM教程的理解）事实上按照管道的概念，从原始数据到最终呈现可以有任意层，至于如何分层，每个层的用途，则在于设计者。这也是为什么Cocoon被定位于Web发布“框架”。
一个处理流程可以被描述为：（摘自IBM教程）
从用户接受请求。
确定用来解释该请求并生成响应的适当管道（使用匹配器）。
从可用的预配置的组件构造管道。
指示管道为请求服务。
将由管道生成的响应返回用户，可能对结果进行高速缓存以便以后使用。
在JSP Model 2里，Servlet扮演“调度员”的角色，我们用它来控制任务分派，这有点类似管道所作的事情。事实上，Cocoon就是一个大Servlet。只是Servlet在2.3之前缺乏管道机制，只能进行简单的forward和include，如果需要多重处理机制，就不得不依靠扩展库（比如IBM的WebSphere），或者采用Cocoon。但是现在Servlet有非常强大的filter机制。这使得Cocoon与JSP越来越有结合的趋势。
但Cocoon的特点在于，除了核心功能（Core-Cocoon）之外，它还包括内部组件（包括Matchers、Generators、Transformers、Serializers、Aggregators等）、内部逻辑单（Response、Sitemap、XSP、XSP-Request、Util、XSP-Cookie、Log等）。这样它就有一个非常适合Web发布的环境。而使用JSP，相对来说，需要自己进行配置和写部分的基础代码。
从角色任务上看，站点管理员负责定义Sitemap，程序员主要负责XSP逻辑单，设计者编写XSLT样式表（包括XSLT和目标代码如HTML），因为程序员和设计者都使用XSLT，其实就是在写格式转换，只是编写者需要熟悉如何处理输入和输出（如设计者要面对HTML，程序员要考虑数据库）。此外，在此之前需要有额外的角色来定义所用到的XML或其他中间格式。我认为这种框架比较适合于非Java程序员为主的团队，管理员只要熟悉XML，程序员和设计者需要掌握XSLT；以及适合于业务逻辑相对简单，而着重于xml数据和灵活的格式转换需求的应用。
没有评论:
发表评论