exo文件

EXo平台很高兴宣布其新的Portlet Container 2.0和Portal 2.1的发布。 eXo是第一个门户网站，为消费者和提供者提供对新的Java Portlet 2.0 API（JSR 286）和Web服务远程Portlet 2.0（WSRP）的全面支持。 该公告使您有机会了解eXo Portal，Portlet容器和企业内容管理（ECM）提供的新功能。

eXo平台架构概述

在详细介绍eXo平台产品的门户，Portlet容器和ECM组件之前，对平台体系结构进行概述很重要。

从eXo Platform的第一个版本开始，就使用了名为Pico Container的控制反转（IoC）容器来提供服务之间的依赖关系的松散耦合。 实例化组件实现并将其注入依赖组件是容器的责任。

eXo平台的所有组件均作为插件开发，并使用IoC容器连接在一起。 下图显示了eXo平台堆栈中从较低层到较高层的每个组件：

Web 2.0门户

新版本的eXo Portal建立在先前版本的基础上，我们消除了由于AJAX等Web 2.0技术而使可扩展模型增加的用户复杂性。

实际上，在大多数其他门户网站都使用静态布局的时候，eXo率先引入了动态布局的概念。 主要区别在于，通过动态布局，您正在管理一棵嵌套容器的树，其中的叶子是portlet。 容器负责其子级的布局，就像处理Swing UI对象时一样，如下图所示。 开箱即用的容器渲染器将在行，列或选项卡中显示子代。

结果，将容器从一个位置移动到另一位置只是数据结构侧的树操作。 在客户端，我们使用JavaScript代码来创建拖放库，以简化该树的操作。 因此，如下一个屏幕快照所示，不仅可以将容器和portlet拖放到页面内，还可以将一种类型的容器或portlet拖放到页面中。

每个portlet都有一组元数据，允许门户网站在页面中呈现它。 该元数据包括标题，大小，图标和边框的外观（如下一个屏幕截图所示），还包括我们是否应该显示边框及其图标（以最小化或最大化portlet）。

一旦所有这些信息都填满，门户网站就可以呈现实际上不同类型的页面。 用户登录时，每种类型都会汇总到用户菜单中（如下一个屏幕截图所示）。 页面类型为：

• 门户页面，即每个用户将看到的页面。 某些页面甚至可以由匿名用户查看，这可以作为Extranet或Internet网站（例如我们自己的网站）的基础
• 用户页面可视为一组仪表板，用户可以在其中添加新页面及其内容（但前提是公司政策允许）
• 组页面，这些页面将添加到用户菜单中他们所在组的页面，例如市场营销或销售页面

您还可以在上一个屏幕快照中看到当用户登录时出现的左可折叠列。它包含一种在页面和一些管理菜单之间导航的方式，以及用户可以根据需要配置的一组小部件。 如前所述，小部件是完整JavaScript组件，可使用REST协议与服务器进行通信。 在将来的版本中，它们将基于Google OpenSocial标准。

eXo Portal 2.0也是一个完整的AJAX门户，这意味着当您从一页移动到另一页时，仅刷新屏幕的一部分。 为此，我们使用JavaScript XMLHttpRequest对象在每次更改页面或必须修改页面中一个或几个portlet的内容时异步调用服务器（例如，当一个portlet向另一个消息发送消息时）使用JSR 286标准调用）。 当然，这可以极大地改善服务器调用，因为除非发送事件，否则仅需要一个render() 。 这与普通用例形成对比，在普通用例中，每个Portlet都必须呈现其片段，这需要花费更多时间（即使已缓存它）。

在每次请求时，门户网站都会返回一个XML文件，该文件包装了将在页面中更新的所有不同HTML片段。 该XML文件的结构为：

* {PortalResponse}
*      |
*      |--->{PortletResponse}
*      |
*      |--->{PortletResponse}
*      |          |-->{portletId}
*      |          |-->{portletTitle}
*      |          |-->{portletMode}
*      |          |-->{portletState}
*      |          |
*      |          |-->{PortletResponseData}
*      |                 |
*      |                 |--->{BlockToUpdate}
*      |                 |         |-->{BlockToUpdateId}
*      |                 |         |-->{BlockToUpdateData}
*      |                 |
*      |                 |--->{BlockToUpdate}
*      |
*      |--->{PortalResponseData}
*      |      |
*      |      |--->{BlockToUpdate}
*      |      |         |-->{BlockToUpdateId}
*      |      |         |-->{BlockToUpdateData}
*      |      |
*      |      |--->{BlockToUpdate}
*      |
*      |--->{PortalResponseScript}

服务器响应包含3种类型的XML：

• 一个用于门户组件片段 ，包含在<PortalResponseData>标记中-这还包装了要更新的组件的ID
• 每个要更新的portlet片段一个-这也包装了portlet信息，例如要更新的窗口状态和portlet模式。 知道eXo Portal 2.x AJAX功能的Portlet还可以告诉门户网站直接更新哪些HTML标签，以避免完全刷新Portlet（这是完全兼容的JSR 286 Portlet所必需的）
• 执行动态评估的JavaScript代码 ，因此可以在新生成的页面中使用

<PortalResponseScript>内部返回JavaScript由了解eXo门户对JavaScript的处理的门户或portlet生成。 此外，返回JavaScript需要定义全局JavaScript函数（使用语法function() ），以便在eval()方法期间动态添加到页面中。 同样，如果portlet是纯JSR 286，那么它将无法使用该便捷方式。 在这种情况下，门户网站解析<PortletResponseData>并看到尚未设置blockToUpdate。 因此，它将解析整个portlet片段以找到所有脚本，以便可以将它们添加到页面。 几个包含JavaScript的第三方JSR 168 portlet已通过测试，例如SpagoBI。

新eXo Portal的另一项重大改进是，所有门户网站配置文件（包括组，用户和门户网站页面以及小部件或portlet首选项）现在都存储在标准存储库中。 我们在下一个屏幕截图中看到，根用户页面存储在JCR位置/exo:registry/exo:users/root/UserPortalData:的XML文件中/exo:registry/exo:users/root/UserPortalData:

使用JCR层不仅方便其存储性能和集群功能，而且还方便使用JCR提供的高级服务，例如通过REST服务进行本机公开（以允许第三方应用程序操纵门户页面）。

eXo Portlet容器：JSR 286和WSRP 2

eXo Portlet Container 2.0实现了Java和Web服务门户世界的两个新的主要规范：

• Portlet API 2.0
• WSRP 2

作为门户的一部分，Portlet容器负责管理将在多窗口环境中公开的应用程序。

对于这个新版本，我们对内部体系结构进行了重大改进。 我们特别利用了先前引入的插件机制，因此为portlet容器提供了扩展点。

Portlet API 2.0（JSR 286）

Portlet API 2.0于2008年6月13 ^日发布，eXo是第一个兼容的实现，并提供Portlet容器和门户网站来使用这些Portlet。 该规范是JSR 168的扩展，专家组特别关注确保JSR 168 portlet将在JSR 286容器中工作。

Portlet 2.0 API引入了许多新功能，例如：

• Port-Portlet间通信 （IPC），允许将事件和参数发送到其他Portlet（在同一WAR中不是必需的）
• Portlet过滤器模仿servlet过滤器的行为
• 公共参数，以在渲染阶段与所有portlet共享渲染参数
• 高级缓存行为，因为这部分在JSR 168中非常有限
• 一个新的serverResource（）方法可以更好地处理图像插入（而不是通过servlet）
• URL侦听器机制，用于在调用URL时触发处理程序

Portlet间的通信说明

我们将不介绍JSR 286规范中的所有新功能，但将详细描述一个主要功能：Portlet间通信（aka IPC）。

在详细介绍IPC流程之前，让我们看一下在JSR 168 Portlet请求的上下文中该流程是什么。 在JSR 168中，将请求分为两个阶段：

1. processAction() ：它以单个portlet为目标来更改JavaBean等业务对象的状态
2. render() ：在页面的每个portlet上调用，并负责呈现HTML片段

重要的是必须看到两阶段请求是强制性的，因为呈现HTML片段可能依赖于修改后的JavaBean对象，因此processAction()方法应该在任何render()调用之前发生。

由此可见，JSR 168仅在单个portlet的上下文中定义了用户界面呈现。 它没有定义有关Portlet之间通信的任何标准方法，这是构建复合应用程序的关键。

也就是说，开发人员经常利用这样的事实，即可以使用HTTP会话在多个portlet之间共享JavaBean对象。 但是，这是限制性的，因为这种基于会话的共享仅限于部署在同一WAR中的portlet。

在现实生活中，Portlet可能来自不同的提供者，并捆绑在不同的WAR中。 我们仍然希望在Portlet之间提供一些交互，允许门户网站用户创建功能强大的复合应用程序。 例如，您可能已经构建了一个通讯簿portlet，以显示用户的详细信息（包括其地址），并希望更新使用Google Maps Web服务的第三方portlet，以在地图上显示地址位置。

这就是为什么JSR 286（如下一个序列图所示）（从规范文本本身获取）引入了processEvent()阶段，该阶段将在processAction()阶段结束时触发事件：

通过将事件附加到ActionResponse对象（扩展PortletResponse ），从processAction()操作方法启动事件。 然后，portlet容器将事件传播到门户层，该门户层负责标识事件应针对的portlet实例。

事件分派不在规范范围内，但是门户级别的一种解决方案是针对位于同一页面中并且可以处理事件的每个Portlet实例。 请注意， processEvent()方法也可以触发新事件。 门户网站有责任避免无限循环调用。

IPC配置

Portlet的IPC配置在portlet.xml文件中完成。

<portlet>
<description xml:lang="EN">TestProcessEvent</description>
<portlet-name>TestProcessEvent</portlet-name>
<display-name xml:lang="EN">Test ProcessEvent</display-name>
<portlet-class>
org.exoplatform.services.portletcontainer.test.portlet2.TestProcessEvent
</portlet-class>
<expiration-cache>0</expiration-cache>
<cache-scope>PRIVATE</cache-scope>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
<portlet-mode>edit</portlet-mode>
<portlet-mode>help</portlet-mode>
</supports>
<supported-locale>EN</supported-locale>
<portlet-info>
<title>TestProcessEvent</title>
<short-title>TestProcessEvent</short-title>
</portlet-info>
<supported-processing-event><name>MyEventPub</name></supported-processing-event>
<supported-publishing-event><name>MyEventPub</name></supported-publishing-event>
</portlet>
[...]
<event-definition>
<name>MyEventPub</name>
<value-type>
org.exoplatform.services.portletcontainer.test.portlet2.MyEventPub
</value-type>
</event-definition>

在此示例中，相同的portlet发布并处理事件。 确实，在实际示例中，将是两个不同的portlet！ 请注意，使用了事件别名，并且关联的事件类在XML文件中仅定义了一次。

使用IPC

Portlet通常扩展GenericPortlet类，该类本身实现定义了processEvent()方法的EventPortlet接口。

下面的代码示例显示了如何在processAction()方法中注册事件对象以及如何在processEvent()方法中检索事件对象：

public void processAction(ActionRequest actionRequest, ActionResponse actionResponse)
throws PortletException, IOException {
MyEventPub sampleAddress = new MyEventPub();
sampleAddress.setStreet("myStreet");
sampleAddress.setCity("myCity");
actionResponse.setEvent(new QName("MyEventPub"), sampleAddress);
}
public void processEvent(EventRequest req, EventResponse resp)
throws PortletException, IOException {
System.out.println("In processEvent method of EventDemo... !!!!!!!!!!!!!");
Event event = req.getEvent();
System.out.println("  -- name: " + event.getName());
System.out.println("  -- value: " + event.getValue());
MyEventPub sampleAddress = new MyEventPub();
sampleAddress = (MyEventPub) event.getValue();
resp.setPortletMode(PortletMode.EDIT);
}

请注意，WSRP 2规范还支持processEvent()阶段，因此事件可以从使用者传播到另一台服务器上的生产者，开发人员只需确保可以使用JAXB序列化事件即可。

独立Portlet容器

eXo Portlet Container 2.0可以作为独立的应用程序下载，以简化其在第三方应用程序中的嵌入。 它带有一个轻型管理门户，该门户演示了JSR 286 portlet的兼容性，如下面的屏幕快照所示。 您可以选择在WAR中部署的一个或多个Portlet并查看它们。

在以下屏幕截图中，我们选择了ResourceDemo portlet，该portlet使用serverResource()方法显示图片，以及在进行AJAX调用后返回的一些标记：

嵌入式Portlet容器

由于它们是标准Portlet，因此您也可以在eXo企业门户或WebOS中部署portlets2.war ，以测试和了解新规范。

您将需要打开应用程序注册表。 通过此管理Portlet，您可以浏览按类别组织的Portlet。 有一个按钮可以快速导入所有已部署的portlet应用程序WAR：

屏幕快照显示了在部署和导入portlets2.war之后应该获得的"portlets2"类别。 在右侧，您将看到我们的演示JSR 286 portlet，如TestPublicParam2和TestProcessEvent1 。

一旦正确配置（可以应用权限），就可以使用停靠栏左侧的“ +”图标将portlet添加到桌面页面：

在这里，许多portlet被添加到了扩展坞中，我们显示其中的3个： TestPublicParam1, TestPublicParam2 and TestPublicParam3. 这些portlet演示了新的JSR 286 Public Parameters。

此功能使您可以在processAction()阶段中设置一些渲染参数。 然后，可以在所有portlet的所有render()方法中访问这些参数。 在JSR 168中，渲染参数只能由关联的portlet查看。

在上一个屏幕中，如果我们单击Portlet 1或2的“设置公共参数”选项，我们将看到3个Portlet中都有公共参数。 如果单击第三个portlet中的链接，则第三个portlet中的那个将覆盖portlet 1和2的公共参数。

WSRP 2

除了Java Portlet API外，还更新了Web服务远程Portlet 2.0（WSRP）以支持我们上面讨论的新功能。

现在可以提供一个插件实现，它将外部组件暴露给门户网站层，就好像它们是真正的Portlet。 WSRP 2使用者插件是此类插件的真实示例，如下图所示：WSRP 2使用者插件将以与JSR 286插件公开本地portlet完全相同的方式将远程portlet公开给门户。

这样做的好处是，门户网站UI将类似地处理本地和远程Portlet：不再需要JSR 168或286代理Portlet。 由于用户必须在portlet首选项中配置诸如WSDL文件的远程地址之类的内容，因此它们具有侵入性。 现在，此任务是管理员在配置使用者插件时的责任。

WSRP生产者体系结构没有太大变化，但是代码本身已被完全重写。 在2008年期间，一旦有其他生产者和消费者可以进行测试，我们将继续检查消费者/生产者与其他市场参与者的互操作性。

WebOS：门户布局

从技术上讲，WebOS只是Portal 2.0版本的自定义布局。 这意味着Portlet不必位于容器内。 因此，portlet和窗口小部件显示为可拖动的窗口，它们可以相互重叠，就像您桌面上的标准操作系统一样，但都在浏览器的范围内。 由于页面显示为多窗口环境，因此可能与普通门户网站完全具有多个桌面（门户，组或用户的桌面）。 例如，一个桌面可能包含协作应用程序，例如Mail，Calendar或Content（如下一个屏幕截图所示），而另一个桌面可能包含访问ERP后端的portlet。

WebOS的目标是在浏览器中重现最佳的人体工程学模式。 这就是为什么我们在一个独特的环境中混合了几种现有操作系统的功能和外观的原因。 最值得注意的是：

• 包含WebOS页面的portlet的扩展坞。 右键单击一个图标可让您从扩展坞中删除Portlet。 接下来的两个屏幕截图显示了底座，但显示在两种不同的外观中。 “ +”按钮允许您将新的portlet添加到用户有权使用的扩展坞和页面。
• 左列上的“开始菜单”允许用户访问发布和管理功能，例如创建新页面的向导。 它还提供了一种更改使用中的语言环境或更改所选皮肤的方法。 如前所述，它还允许用户定义一组可用于所有页面的窗口小部件，而在WebOS页面内添加的窗口小部件仅在其中存在。

eXo应用程序注册表中可用的任何Portlet和小部件都可以在WebOS布局中使用。

eXo Java内容存储库和ECM

除了新的门户网站外，eXo平台还发布了其企业内容管理（ECM）解决方案的新版本，该解决方案使用JCR作为基础，就像在门户网站中一样。

Java Content Repository：文件系统

eXo Java内容存储库（eXo JCR）是我们对JSR 170的实现。它规范了内容在存储在集中式存储库中时的结构，版本控制，锁定和搜索方式。 与eXo平台的其他组件类似，该产品具有很多优化和扩展，如以下架构所示。 这些都可以在产品的独立发行版中找到，可以从OW2 forge下载。

JCR的模式可以分为三个区域：

• 核心部分是规范实现和一些API扩展，以及eXo如何管理存储部分
• 协议连接器，例如FTP，CIFS，WebDAV，DeltaV，DASL
• 构建的应用程序和插件，例如Microsoft Office和Open Office插件

这三个部分将更详细地探讨。

JCR核心

eXo JCR实现是JSR 170的多存储库和多工作区的实现。JCR后端的入口点是存储库对象，但在规范中并不一定要提供多个存储库；它在规范中是必需的。 但是，在某些情况下这很有用。

存储库可以访问一个或多个工作空间； 在此，该规范并未对多个工作区提供强制支持，但是由于它是一项有用的功能，因此我们选择实现它。

进入工作空间后，您可以浏览Nodes树，可以将其视为标准文件系统文件夹的增强版本。 树的叶子是Property对象，可以有几种类型，例如Date或Binary。 如果我们使用文件系统类比，则可以将二进制属性视为文件。 下图描述了所有这些：

在eXo实施中，每个工作区都可以指向不同的数据库，所有元数据信息（例如文件的路径）以及某些属性（例如Dublin Core元数据）都存储在该数据库中。 出于性能原因，文件本身可以存储在关联的文件系统（NAS，SAN ...）上。 每个工作空间还可以配置一些高级缓存，缓冲，交换，索引或安全策略。 当需要可伸缩性时，也可以对存储库进行集群。

下一个XML片段显示了用于设置JCR环境的定制配置文件。 我们可以在那里定义所有存储库配置，但是我们将仅详细描述一种工作空间配置（请检查XML片段中的注释）：

<repository-service default-repository="repository">
<repositories>
<!-- ############################################################ -->
<!-- Every repository needs a system workspace to store the JCR   -->
<!-- configuration info as well as the version history. The       -->
<!-- default workspace is the one that would be returned by the   -->
<!-- login method when no workspace is specified                  -->
<!-- ############################################################ -->
<repository name="repository" system-workspace="system"
default-workspace="collaboration">
<!-- ########################################################################## -->
<!-- The first step is to define the workspace security such as the JAAS domain -->
<!-- it applies to. It is also possible to plug a custom policy manager there   -->
<!-- ########################################################################## -->
<security-domain>exo-domain</security-domain>
<access-control>optional</access-control>
<authentication-policy>org.[..].PortalAuthenticationPolicy</authentication-policy>
<workspaces>
<!-- ######################################################################### -->
<!-- Each repository can contains several workspaces, each one with a Root     -->
<!-- Node that can have its own structure and permission configuration         -->
<!-- ######################################################################### -->
<workspace name="system" auto-init-root-nodetype="nt:unstructured"
auto-init-permissions="*:/platform/administrators read;
*:/platform/administrators add_node;
*:/platform/administrators set_property;
*:/platform/administrators remove" >
<!-- ####################################################################### -->
<!-- Each workspace can have its own way to store content but the most usual -->
<!-- one is to use a database for the metadata information and a File System -->
<!-- for the binary documents. Here we use a simple file system but with a   -->
<!-- storage algorithm that store the content in a tree to split the number  -->
<!-- of files per folder. The Swap directory is used when we upload files    -->
<!-- ####################################################################### -->
<container class="org.exoplatform.services.jcr.[..].JDBCWorkspaceDataContainer">
<properties>
<property name="sourceName" value="jdbcexo"/>
<property name="dialect" value="hsqldb"/>
<property name="multi-db" value="false"/>
<property name="update-storage" value="true"/>
<property name="max-buffer-size" value="204800"/>
<property name="swap-directory" value="../temp/swap/system"/>
</properties>
<value-storages>
<value-storage id="system" class="org.[..].TreeFileValueStorage">
<properties>
<property name="path" value="../temp/values/system"/>
</properties>
<filters>
<filter property-type="Binary"/>
</filters>
</value-storage>
</value-storages>
</container>
<!-- ###################################### -->
<!-- Caching, Indexing and locking are then -->
<!-- configured                             -->
<!-- ###################################### -->
<cache enabled="true">
<properties>
<property name="maxSize" value="20000"/>
<property name="liveTime" value="30000"/>
</properties>
</cache>
<query-handler class="org.exoplatform.services.jcr.[..].SearchIndex">
<properties>
<property name="indexDir" value="../temp/jcrlucenedb/index"/>
</properties>
</query-handler>
<lock-manager>
<time-out>900000</time-out><!-- 15min -->
<persister class="org.exoplatform.services.jcr.[..].FileSystemLockPersister">
<properties>
<property name="path" value="../temp/lock"/>
</properties>
</persister>
</lock-manager>
</workspace>

规范的一个重点是定义内容结构的能力，这称为NodeType 。 例如，在给定的公司中，将在Web上发布的每篇文章都需要包含标题，作者，摘要，缩略图和文章的全文。 NodeType将用于定义每个字段，其类型（日期，字符串...）以及其他一些信息，例如标题是否为必填项。 然后，每个创建的文章都必须满足那些NodeType条件。

eXo JCR的一个有用功能是能够通过Java接口API动态添加新的NodeType。 该API可用于开发基于eXo JCR的任何类型的应用程序。 这就是eXo ECM的实现方式。

规范中添加了其他一些功能，以帮助第三方应用程序在JCR之上构建创新服务：

• 对于所有Word，PDF或Open Office文档，都将对都添加到JCR中的每个Office文档的Dublin Core进行本地支持，并将其属性提取并附加到JCR Node
• 审核功能已添加到JCR节点，并且可以记录对内容的每个操作
• 安全性得到了增强，并且可以插入自己的安全管理器-这很方便提供对文档访问的高级分析
• 除了标准的观察功能外， 其他事件通知还允许在对工作空间进行持久更改时调度事件。 eXo JCR还提供了一个扩展，可在每次瞬态会话级别更改时调度并触发事件。 例如，这用于都柏林核心的本地支持

最后，我们还开发了一种自定义的存储和身份验证机制，该机制提供了JCR存储库的软件即服务（SaaS）版本。 为此，我们利用了Amazon Web Services EC2和S3服务。 EC2允许您动态实例化虚拟机，而S3是Internet上的存储系统。 因此，如果您拥有EC2和S3帐户，则可以启动配置有自定义版本的eXo JCR的付费Amazon Machine Instance（AMI）。 它将使用S3存储文件，并使用EC2托管数据库和JCR服务器。 我们发布的第一个AMI还带有可插拔身份验证模块（PAM），使您可以利用Linux OS定义的用户。

JCR协议

从平台开发之初开始，我们就决定将JCR放在我们存储策略的中心，该策略是在标准关系数据库之上应用高级服务。 因此，我们开发的并且属于产品线一部分的每个应用程序都将其内容存储在JCR中。 这为大多数企业数据提供了有用的集中化。

因此，必须能够直接从第三方应用程序访问该信息。 为了减轻这种互操作性，我们使JCR存储库可以通过许多协议访问：

• WebDAV可能是最流行的WebDAV，因为大多数操作系统（例如Windows或Mac OS）本身都支持WebDAV 。 它允许您将远程服务器挂载为文件系统的本地分区，然后通过常规文件系统界面浏览远程文件夹和文档。
• DeltaV和DASL是WebDAV协议的两个RFC扩展。 它们分别为默认协议添加了版本控制和搜索功能。 这些已在eXo插件（例如Microsoft Office插件）中广泛使用，我们将在下一部分中介绍
• CIFS是一种Microsoft协议，用于通过网络共享驱动器。 eXo实现了一个抽象层，以允许将任何JCR存储库视为CIFS / Samba服务器
• RMI是一种Java协议，它允许您将Java对象远程公开给运行在不同JVM中的其他Java应用程序。 我们已经实现了所有RMI存根，使您可以远程公开整个JCR API
• FTP是为大型文件交换而优化的协议。 eXo在JCR之上实现了FTP服务器。 可以使用简单的客户端（例如下一个屏幕快照中的客户端）传输6 GB的文件：

有关WebDAV的更多详细信息

WebDAV协议只是HTTP协议的扩展，该协议利用了PUT，GET和DELETE方法。 如我们所见，JCR规范允许您管理结构化内容，但是对于标准文件系统却不是这种情况，因此只能通过协议公开JCR语义的一个子集。 通常在处理文档管理系统（DMS）时就足够了。 有趣的是，我们完全利用REST框架构建了WebDAV服务器。

下一个屏幕截图显示了一个名为协作的JCR工作区，该工作区已作为文件夹安装在Mac OS文件系统中：

最后，为了简化第三方开发人员的工作，我们用Java和C＃构建了一些客户端API，以面向对象的方式对WebDAV HTTP请求的创建进行建模。 Java中的简单WebDAV复制方法如下所示：

DavContext context = new DavContext("localhost", 8080, "/jcr-webdav/repository");
CopyCommand copy = new CopyCommand(context);
copy.setResourcePath(srcName);
copy.setDestinationPath(destName);
int status = copy.execute();

通过不同的协议公开存储在JCR中的内容，使第三方供应商或集成商可以开发与平台交互的自定义​​应用程序。

某些应用程序（例如文字处理）或扫描功能（如扫描仪）非常普遍，因此我们还决定直接将自己的插件编码到现有产品中。

Microsoft Office 2003套件就是这种情况，我们已经为其开发了C＃插件。 我们还开发了一个基于Java的OpenOffice插件。 在这两种情况下，都使用WebDAV，DeltaV和DASL协议。 这两个插件的功能几乎相同，并创建了一个名为“ Remote Documents”的新菜单。 它允许您：

• 将当前编辑的文档直接保存在远程eXo JCR服务器上，并以几种不同的格式保存-例如，我们支持Word模板文档（扩展名为.dot的文件）：
• 支持文档版本控制，这意味着任何文档修改都会创建一个新版本：
• 也可以使用内置的Microsoft Word差异工具来比较存储在JCR服务器上的文档的2个版本：
• 利用全文搜索查找已经保存在服务器上的文档。 搜索同时查看文档文本和关联的元数据。 下一个屏幕截图显示了OpenOffice中的界面：

通过访问JCR存储的广泛支持的协议，扩展现有应用程序以将它们连接到eXo内容存储库是非常简单的。 另一个有趣的插件（也基于WebDAV协议，并用C＃编码）是由Kofax为Ascent Capture应用程序创建的插件，它是一种扫描和光学字符识别工具（OCR）。 该插件使您可以在JCR中动态存储传入的打印字母。 我们还将提取的信息注入到JCR中的文档元数据中。

企业内容管理

eXo企业内容管理（ECM）是一组Portlet，提供Web内容，文档和记录管理工具。 它建立在eXo JCR之上，并利用了我们先前介绍的功能和连接器。

ECM产品还带有一些预定义的工作流，您可以对其进行自定义，以轻松地在公司内共享和传播ECM内容和文档。 您还可以添加自己的工作流程定义，并以多种不同方式生成它们。 工作流引擎实现本身是可插入的，我们提供了两种实现（jBPM和Bonita），但是您也可以编写自己的实现。

一些现成的演示文稿portlet促进了eXo门户的集成，该portlet提供了多种方法来在门户内部显示您的内容以供内部网或Internet /外部网使用。

因此，eXo ECM为捕获，生产，管理，发布和记录企业内容提供了强大的支持。 所有这些都是以高度可定制的方式执行的。 但是，该产品背后的主要动力仍然是在易于使用的界面中提供高级功能，该界面可模仿真实操作系统中的现有应用程序，例如文件浏览器。

ECM文件资源管理器

eXo ECM的核心组件之一是File Explorer应用程序。 此Portlet为ECM提供了用户友好的后台入口点。

驱动器：

文件资源管理器的主页显示了我们称为“驱动器”的托管存储库的快捷方式。 有三种不同类型的驱动器：

• 个人驱动器为每个用户保留。 可以将其中的文档设为私有或与他人共享
• 组驱动器定义了仅限于某些用户组的区域
• 通用驱动器是存储库其他区域的快捷方式

可以在驱动器上设置权限，以便用户只能看到与其权限集相关的驱动器。 驱动器还可以配置许多其他内容，例如工作空间中的路径位置或要在资源管理器中应用的视图（缩略图，列表...）。 下一个屏幕截图显示了ECM管理Portlet和几个预配置的驱动器：

文件浏览

ECM File Exploring用户界面的设计与在本地计算机上管理文件一样容易。 在左侧，一个熟悉的树视图显示文件夹。 地址栏的顶部显示当前文件夹的路径。 在右侧，工作区显示文件夹中的文件。 工具栏使用户可以操纵内容。 可以按主题将工具栏操作分组（例如：常规，协作，搜索），并且已对UI进行了调整，以提供熟悉的外观，例如Windows File Explorer之一：

根据用户的权限，可用于给定文档的操作数会更改。 可以为所有“记录管理”文档禁用某些Web 2.0功能，例如对文档进行标记，投票或注释（如下屏幕所示），但启用将在Web上发布的内容：

还存在其他几种动作，从常见的动作（例如管理文档的版本）到更复杂的动作（例如检查文档的结构）（例如，与之关联的元数据类型）。

此portlet是任何文档管理和记录管理过程以及Web内容管理过程的基础。

File Explorer（文件浏览器）使您可以轻松地将文档添加到File Plan（文件计划）中，然后该记录将成为一条记录，该记录将在系统中保留一段时间，然后再被切断。 eXo ECM实施了DOD 5015.2记录管理规范。 上载PDF时，将提取PDF属性并将其绑定到JCR中的文档。 然后，可以对该元数据执行高级搜索，例如，查找具有“主题”属性的都柏林核心“文章”值的所有文档。 在下一个屏幕截图中，上传了PDF文档，并启动了高级搜索操作。 该表单使我们可以选择我们要搜索的Dublin Core属性。 然后将出现一个弹出窗口，允许您在属性具有的所有值中进行选择。 在屏幕快照中，属性值列表“ Article”中有一个唯一条目。 也可以组合属性约束以进行更高级的搜索：

在eXo ECM中，可以利用JCR NodeType功能来指定文档的结构。 这是通过管理Portlet（在“内容类型”部分中）完成的。 一旦创建了内容结构，下一步就是创建一个表单，该表单将允许您创建该内容的实例。 这种形式在eXo ECM中称为对话框，并且被编写为Groovy模板，该模板也存储在eXo JCR中（因此可版本化）。 在下一个屏幕截图中，将显示一个包含多个字段（名称，标题，摘要...）的表单。 此表单是呈现的对话框模板，每个字段可以具有几种类型之一（例如，RTF编辑器，日期，上载字段...）。 所见即所得（WYSIWYG）编辑器允许您在JCR存储库中导入和上传图像。 创建后，结构化内容可以通过另一个名为视图模板的Groovy模板来呈现，该模板仅用一些HTML代码装饰内容实例字段。 现在可以在工作流程中验证内容并发布到网上了：

动作

eXo ECM的主要功能是可以将操作附加到任何节点（包括文件夹）的功能。 动作是节点生命周期的挂钩（例如，添加，更新，删除），可以启动新的工作流程或运行自定义的Groovy脚本。

下一个屏幕截图显示了默认文档验证工作流程，该文档验证工作流程是在将文档复制到“ Validation Request”文件夹中后立即激活的。 验证文档后，将其复制到“挂起”文件夹中，等待发布日期。 当该日期到达时，作业将文档移动到“实时”文件夹，直到到达发布日期结束为止：

当文档位于Live文件夹中时，第三方应用程序或内容发布portlet只需指向该文件夹，进行查询以提取上次发布的文档并应用漂亮HTML模板来显示它。

动作也可以启动Groovy脚本，因此让我们用一个简单的脚本来说明此功能，该脚本使用DocumentReaderService在控制台文档中打印文档元数据属性，例如作者和创建日期。 实际上，动作脚本还使用IoC，从而简化了eXo注册服务的调用：

public class DisplayDocumentProperties implements CmsScript {
private DocumentReaderService readerService;
private RepositoryService repositoryService;
// Constructor injection of needed eXo services
public DisplayProperties(RepositoryService repositoryService,
DocumentReaderService readerService) {
this.repositoryService = repositoryService ;
this.readerService = readerService;
}
public void execute(Object context) {
// load node from JCR
String workspace = context["srcWorkspace"];
String path = context["srcPath"];
Node document = (Node) repositoryService.getRepository()
.getSystemSession(workspace).getItem(path);
// extract document properties
String mime = document.getProperty("jcr:mimeType").getString();
InputStream data = document.getNode("jcr:content")
.getProperty("jcr:data").getStream();
Set properties = readerService.getDocumentReader(mime)
.getProperties(data).entrySet();
// display properties
propreties.each() { print " ${it.key} ${it.value}" };
}

可以通过管理用户界面添加脚本，然后将其绑定到操作并因此绑定到JCR节点。 例如，在发布过程中，我们还可以根据最新发布的新闻动态生成RSS feed（此操作本身存在于eXo ECM中）。

商业模式

eXo Platform SAS商业模型是传统的开源模型，与Red Hat或MySQL非常相似。 eXo为最终用户和公司提供两种发行版：

社区版可以从OW2 forge中免费下载。 该版本每2或3周发布一次，其中包含所有最新代码和提交。 基本的质量检查流程将应用于此过程。 测试在以下三个开源应用程序服务器上执行：Tomcat，JOnAS和JBoss。 该发行版的源代码在公共SVN服务器上可用，位于本文介绍的每个模块的主干部分中。

企业版是社区版的稳定版。 它位于SVN服务器上自己的分支机构中，并且仅对购买了年度订阅的用户可用。 每个产品每6到9个月发布一次版本，那时在SVN服务器中标记了源代码。 这种分布的QA过程是一个广泛的过程，其中包含1500多个集成测试用例以及压力测试。 该发行版还通过了多个专有应用程序服务器（例如BEA WebLogic，Oracle Application Server和IBM Websphere）以及专有数据库的认证。 管理员和用户手册也是该软件包的一部分。 最后，附加担保和赔偿适用于此分发

eXo Platform SAS还针对其他两个市场：

• 具有独立软件供应商（ISV）的OEM市场将在其应用程序中捆绑eXo产品。 根据客户需求使用专用许可证和特许权使用费模型
• SaaS一个（软件即服务），使您可以在一段时间内租用eXo应用程序。 从技术上讲，该模型利用了Amazon EC2（分配了一些虚拟机）和S3（允许您将数据存储在云中）

翻译自: https://www.infoq.com/articles/exo-platform/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

exo文件