| 操作系统 办公 实用知识 设计 开发 WEB开发 移动开发 数据库 软件工程 网管 安全 管理 信息化 答疑 渠道 |
Services API 工具包开发应用程序本文将向您展示如何使用 IBM Workplace Collaboration Services 2.5 API 工具包开发扩展 Workplace Collaboration Services 环境的应用程序。 Workplace Collaboration Services 2.5 API 工具包 是为了使 Workplace Collaboration Services 2.5 变得可扩展和可定制而设计的编程工具。该工具包公开了许多公共 API,这些 API 允许您与大多数 Workplace Collaboration Services 内置应用程序服务(如电子邮件和网络会议)进行交互。此工具包允许 ISV、业务合作伙伴和其他人构建与 IBM Workplace 基础设施交互和集成的定制应用程序组件。目前,该工具包是作为一个单独的组件提供的,由几个 JAR 文件和一个安装在 Workplace Collaboration Services 2.5 服务器之上的 EAR 文件组成。您可以在这里下载最新的 Workplace Collaboration Services API 工具包。 在本文中,我们将讨论 API 的设计。沿着这一思路,我们将仔细查看一个已经创建好的示例 portlet 应用程序,该应用程序将操作一个文档服务。使用本文中演示的设计和编码方法,您可以开发与其他业务组件交互的应用程序。您还会发现一个部署好的示例 WAR 文件,以及我们的示例的源代码。(可以从本文结尾处的“下载”部分下载该示例。) 本文假定您是一位经验丰富的应用程序开发人员,熟悉 Workplace Collaboration Services 或其他 IBM Workplace 产品。有关的更多信息,请参阅 IBM Workplace application development page。 用 Workplace Collaboration Services 进行应用程序开发 在开始深入研究 API 的细节之前,理解一些与 IBM Workplace Collaboration Services 2.5 相关的应用程序开发概念非常重要。IBM Workplace 应用程序是一个基于模板的页面程序集,在这个程序集中,每个页面都可能由一个或多个组件组成。这是一个将人员、内容和过程组合在一起、成功地完成某一项任务的虚拟场所。每个组件通常都是一个 portlet,因为 portlet 是基于门户的基础设施(如 Workplace Collaboration Services)的、基本的、“不可分割的”元素。 Workplace Collaboration Services 包含一些内置模板,比如 Discussion、Document Library、Customer Support Team 和其他可以用来快速构建应用程序的模板。开发人员可以扩展和定制这一模板集。 在 Workplace Collaboration Services 应用程序开发环境中,通常有三种类型的开发人员角色: 组件开发人员使用 Workplace Collaboration Services API 工具包提供的 API 构建 Workplace Collaboration Services 应用程序和组件,同时还使用 J2EE 编程模型。组件开发人员还负责将定制组件与任意第三方系统集成在一起。 回页首 API 的类别 公共 Workplace Collaboration Services API 可以划分为 6 个主要类别。 Collaborative Application Component Interfaces Collaborative Application Component Interfaces (CACI) API 允许开发定制业务组件,并在 Workplace Collaboration Services 环境中集成这些组件。您可以实现一个或多个 Lifecycle、Membership、Templatable、Sensor 和 Transactional 接口。这使得 Workplace Collaboration Services 能够在发生特定事件期间调用您的实现,比如在创建和毁坏组件的时候。 Workplace Mail Messaging SPI Workplace Mail Messaging SPI 允许您扩展默认的 Workplace Collaboration Services 邮件服务。您可以检查信封和每条邮件消息的内容,确定每条消息的目标文件夹。这些 API 通常用于病毒扫描和垃圾邮件过滤。 Workplace Instant Messaging SPI 使用 Workplace Instant Messaging SPI,您可以检查 Workplace Collaboration Services 环境中的即时消息传递通信量。这些 API 通常用于聊天记录和聊天事务。(请参阅 developerWorks: Lotus 上的文章“使用 IBM Workplace Instant Messaging SPI 进行翻译”。)您可以在一个 servlet 中实现此接口,并向 Workplace Collaboration Services 注册它。 IBM Workplace Collaboration Services Java Server Pages (JSP) 标签 JSP 标签使您能够向 portlet 添加协作功能(如到场提醒)。尽管 JSP 标签库已经包含在 Workplace Collaboration Services 2.5 服务器中,但您将在随工具包提供的示例中找到大量关于如何使用它们的文档。例如,Noteboard 示例演示了 person 标签的用法。 IBM Workplace Client Technology 平台的 API 使用这些 API,可以用新的应用程序扩展 IBM Workplace Client Technology 平台。 Component and Application Infrastructure Services API Component and Application Infrastructure Services API 被细分为两类: Component Services API 允许您访问现有 Workplace Collaboration Services 业务组件提供的服务和内容。业务组件的例子包括 Team Calendar、Discussion 和 Document Library。 回页首 API 的设计 此 API 工具包中的对象是为改进易于使用性和一致性而设计的。API 中的对象模型很容易理解,因为它基于 GUI 中使用的命名约定。这使您可以快速地将 API 对象与 GUI 中看到的内容联系起来。例如,可以使用应用程序数据对象来表示 Workplace Collaboration Services 应用程序,这一技术与 GUI Common 对象中使用的技术相同,可以抽象 GUI Common 对象,在整个 API 中表示类似的概念。例如,无论何时需要,都可以在整个 API 中使用相同的人员对象和组对象。多数情况下,还可以看见针对这些服务方法的类似搜索选项和数据检索选项。 这些 API 还根据 Workplace Collaboration Services 访问控制和用户策略的指示,增强了业务服务组件的安全性。因为对这些 API 的调用只在当前已登陆用户的安全上下文中起作用,所以无法忽略业务服务组件的安全性。另一方面,Web 服务使用基本的身份验证和 LTPA 来识别安全上下文。 SDO 兼容的设计 Workplace Collaboration Services API 的设计类似于 Service Data Objects (SDO) 编程模型的设计。尽管 Workplace Collaboration Services 2.5 中没有使用 SDO,但数据模型是以某种将来不用重构数据对象就可以使用 SDO 的方式设计的。 SDO 支持以下三个关键概念: 数据对象,支持惟一的数据访问,并提供利用某种“开放式”数据锁定方法,以切断连接的方式来存储数据的能力。 Workplace Collaboration Services API 工具包使用与 SDO 设计兼容的数据对象。您将发现,无论何时将数据集合对象传递给某一服务,或者从某一服务检索数据集合对象,都将使用 DataObjectList(请参阅此工具包的 Java 文档)。更确切地说,每次检索一个数据图(一个 DataObjectList),都可以通过使用 RetrievalOptions(这是另一个数据对象,请参阅 Java 文档)来指定您想要多少数据。可以将这些检索选项作为服务方法参数传递,指出您所需要的数据量。 回页首 公共 API 包括 Java Object Factories、EJB delegates 和一个 a Java EJB 层。这些 API 可以访问公共 API 服务实现。您应该注意到,同一组 API 既可以用在服务器上,也可以用在 IBM Workplace Client Technology 平台上,并且在联机和脱机模式下都可以运行。此外,这些 API 是作为 Web 服务公开的。这意味着任何 Web 服务客户机都可以使用 HTTP/SOAP 来访问业务组件服务。 通常,业务组件服务是在调用内部 Workplace Collaboration Services API 的 Plain Old Java Object (POJO) 中实现的。Workplace Collaboration Services API 工具包在 POJO 实现的服务之上有一个瘦 EJB 层。即使 EJB 只委托对 POJO 实现的调用,它们也要提供对该服务的远程访问。因为 EJB 难以处理,所以在这之上提供了一个委托层。这些委托是根据它们的使用情况(在联机或脱机模式下,在服务器或 Workplace Client Technology 平台上)分别配置的。根据特殊的运行时模式,委托被配置为直接访问服务 EJB 或 POJO 代码(这样就忽略了 EJB 层)。绝对不能直接调用这些委托;它们是通过内部的委托工厂机制动态生成的。 API 推荐利用 FactoryCreator 接口创建所需的 API 服务工厂来使用此工具包。该工厂允许创建 Workplace Collaboration Services API 服务,这适合当前的操作模式。 典型的 API 使用场景是调用工厂类方法来创建服务方法和内容对象。在需要进行特殊类型的调用时,可使用内容对象调用服务对象方法。 回页首 在本文提供的示例代码中(请参阅“下载”部分),我们根据用户提供的输入,创建了一个简单的 JSF portlet,它将调用工具包 API 来创建文档的。在这个示例接口中,我们将请求文档库的名称(创建文档库是创建文档的先决条件)、将创建的文档的名称以及表示文档内容的文本。 当用户通过单击提交按钮提交该请求时,可以使用 API 定位文档库。如果找不到指定的文档库,执行将停止,并发送一个错误,指出用户没有在试图创建文档之前创建文档库。如果找到指定的文档库,则在该文档库中继续使用所提供的内容和指定名称创建文档。 我们的应用程序所使用的文档服务创建过程的逻辑流由三个基本步骤组成: 调用 FactoryCreator 的静态方法来创建 ServiceFactory。 调用 FactoryCreator 的静态方法来创建 DocumentFactory。 让我们一块一块地查看示例代码。本文并没有讨论 portlet 的创建和 JSF 代码;而是重点讨论了最终创建文档的页面代码类。首先,要导入随工具包一起提供的必要 API 类: import com.ibm.workplace.api.factory.FactoryCreator; ServiceFactory fac = FactoryCreator.createServiceFactory(); DocumentFactory dfac = FactoryCreator.createDocumentFactory(); 要使用我们的示例应用程序,则必须先安装 Workplace Collaboration Services 2.5 API 工具包。然后,安装从本文的“下载”部分可以获得的一个简单的 doc.war 文件,并定制一个页面来包括 SimpleDoc portlet。在设置好 portlet 之后,可转至 Documents 页面,并创建一个叫作 mylibrary1 的库,如图 1 所示。 图 1. 创建 mylibrary1
图 2. SimpleDoc portlet
Enter library name 是为存储文档而创建的库名。在我们的示例中,此名称为 mylibrary1。 图 3. 新文档
在本文中,我们讨论了可在 Workplace Collaboration Services 2.5 API 工具包中使用的 API 的一般类别,查看了 API 的设计,以及如何将它们与 SDO 编程模型联系在一起。我们还查看了组件服务 API 工作方式的一些细节。并研究了本文提供的示例应用程序,向您展示如何使用 API 来调用 DocumentLibraryService 对象上的方法,从而创建一个文档。使用其他 DataObjects 和调用其他服务 API(比如使用 MailService 发送邮件和使用 CalendarService 创建事件条目)与我们的示例非常相似。
今日推荐
|
重点推荐
领军企业技术文库
+更多领军技术文库
最新专题
电子杂志订阅
| ||||||||