本系列的文章，从Documentum业务对象框架（Documentum Business Object Framework，BOF）开始，介绍了用于BEA WebLogic Workshop的Documentum 业务对象控件(Documentum Business Objects Control，DBOC)。
本文是第2部分，介绍了一些实现上的底层支持技术，讨论与Documentum安全性的集成，并研究一些示例代码。这篇文章是在第一篇文章（可从Ness的Web站点上得到）所介绍的概念基础上形成的。
作为Documentum和BEA的合作伙伴，Ness科技受邀在 BEA的Workshop和Documentum基于服务的业务对象之间建立集成。这一集成包括控件、示例应用程序和集成的帮助，所有这些都可以在第一次使用控件时下载并安装到Workshop中。
DBOC是怎样集成到Workshop中的？
WebLogic Workshop引入了Java控件，把它作为一种封装业务逻辑、方便地访问企业资源的方法。为Workshop集成开发环境（IDE）提供的内置平台控件，可以连接数据库、EJB、消息队列等。
因为BEA致力于推广控件，所以他们使应用程序开发人员可以容易地建立自己的自定义控件，代表应用程序的具体逻辑，并为开发团队提供一套一致的工具。
为了进一步推动Java控件的创新，Workshop的8.12版本引入了一个扩展开发工具包，支持第三方控件和用户界面组件无缝地集成入WLW环境。DBOC就是这一新的扩展性框架的第一个实现。
我们会稍花一点时间来讨论这是如何办到的，因为大家可能想做类似的集成工作，把自己的自定义控件集成进IDE，其中可以包含利用DBOC的控件，但是当然不仅限于此。
在第一次安装WebLogic Platform 8.12版本时，在BEAHOME\ext_components文件夹里会放入一个 DocumentumBusinessObjectsControlStub.zip文件。
这个小小的压缩包里包含有关控件的足够信息（文本、图标、下载URL），所以它可以在Workshop的增加控件菜单里显示。
在准备第一次使用DBOC时， Workshop 会提示它还没有安装，然后会下载完整的控件档案压缩包DocumentumBusinessObjectsControl.zip，取代原来的存根文件。
然后，系统就会把BEADocumentumControlProj.jar文件插入当前项目的库文件夹，这样项目就可以使用其中的功能了（请看下图）。
Workshop还会把示例应用程序安装到BEAHOME\weblogic81\samples\partners\Documentum文件夹。最后，再把DBOC的帮助文件安装入Workshop的帮助系统，编排文件索引，使得可以在帮助的内容列表的扩展区域里使用DBOC的帮助。
有关扩展开发工具包的更多详细信息，可以在Workshop的帮助系统中找到，也可以在dev2dev.bea.com站点在线得到。
穿戴整齐，却无处可去
完成这一步骤后，像大多数控件一样，会弹出了一个向导，让您开始填写信息。
但是， Documentum 环境要求我们要特别注意几个项目。和许多其他实用控件（报表生成器之类的）不同，DBOC控件不是自包含的实体，它实际是一个达到更大型的运行系统的桥梁。可以把它当作到数据库系统的连接。您不该试图把整个数据库系统拷贝到每个J2EE应用程序项目。相反，您应当指定共享的数据库服务器的位置，然后访问这些资源。在使用DBOC的情况下，我们需要指定Documentum基本类库(DFC)资源在开发人员机器上的位置。DFC只安装一份非常重要，这样DFC才不会重复，特别是要考虑到实际只需要Documentum业务对象注册表（DBOR）的一个实例，这样所有的业务对象都会包含在一个位置（否则会带来维护上的麻烦）。
关于DFC资源，需要了解两个WebLogic环境。
- 需要更新Weblogic服务器域的SetDomainEnv.cmd 文件，以便在服务器的Classpath中可以找到DFC的jar文件。
- 需要设置Workshop IDE 的应用程序属性，以便IDE识别DFC和BOF资源。这样， Workshop 可以做一些有用的工作，例如语法检测、自动完成等。
探索DBOC
DBOC使得访问Documentum基于服务的对象非常简单。没有必要声明（或者根本不需要了解或考虑）home 和remote接口，只需要在向导中回答一些问题，就万事俱备了。
向导的头两步是所有Java控件都需要的公共步骤：
- 第一步是给控件代表的变量命名。
- 在第二步，确定是利用现有控件的.jcx文件或者让向导为您建立一个新的.jcx文件。在上面的屏幕中，我们正在建立一个名为inbox.jcx的新控件。
在第三步，要提供针对于DBOC的信息。 - 所有的业务对象都在DBOR中注册。控件向导读取DBOR，并在下拉列表中列出所找到的全部SBO。
上图只显示了默认的Documentum安装所提供的SBO。而在实际情况下，列表中会显示出所有从Documentum开发人员网站下载或者自行开发的SBO。
- 最后，为DFCSessionManager（SessionManager）对象提供访问SBO所必需的凭证信息。我们会在本文后面详细介绍这方面内容。
点击Create按钮后，向导就会建立一个指向新的（或现有的）控件文件的变量。在上面的示例中，向导建立了inbox.jcx文件，并把它放在当前项目中。
控件文件里有什么？
DBOC不仅仅是SBO外面的简单包装器，它还加入了一些所有SBO都需要的实用特性。您的代码与代表SBO的控件进行交互。
在.jcx文件中的代码非常简单：
需要注意的关键一点是，控件文件本身只是扩展了SBO提供的Java接口以及DBOC自身提供的实用代码。向导对DBOR进行查询，然后建立新的接口，并把您提供的其他信息作为标签属性（docbase、 安全类型、用户名、口令） 保存在.jcx文件里。当在设计视图里查看控件实例时，控件的标签属性可以在属性编辑器中使用，可以在其中做任何必要的修改。
当WLW IDE 以图形方式显示控件时，它会枚举控件的所有可用方法，包括来自SBO的方法和来自控件的实用工具方法。
凡是以getSBO… 和setSBO… 前缀开始的方法，都是DBOC自己提供的实用工具方法。可以用这些方法取得和设置控件的属性。
需要记住，用这些前缀开始的方法不与SBO对话，它们只是引用控件的属性。提供这些方法是为了在运行的时候可以使用控件自身的信息。有人可能会说，前缀应当是getSBOControl…和setSBOControl…，但是开发人员一般喜欢简洁，所以更短的名字保留了下来。所有剩下的方法则都是SBO自身提供的功能。
SessionManager对象
SessionManager对象在DFC 5.1中引入，SessionManager对象是Documentum Business Object服务使用的所有会话所必需的接口。它负责集中实体、会话和事务。
DBOC设计用于减少需要手工编写的代码数量。所以，如果还不存在SessionManager对象，DBOC能够为您建立一个，这是合情合理的。
SessionManager对象负责表示试图访问SBO的Documentum用户的标识。即使SBO可能是不进行Docbase事务的Java代码，也是一样。
DBOC的安全类型属性接受三个值，分别代表处理用户凭证的三个不同方法：
- Registered Identity
这个值来自控件向导中选择“Use control generated Session Manager with the following identity”（使用控件生成的具有以下标识的Session Manager）。它提供了最简单的认证方法。SessionManager由控件本身（不是由客户端代码）生成。客户端只需把用户ID、口令和Docbase设置成控件的属性。SessionManager会由控件在运行时生成，根据控制中设置的凭证进行连接。 - Principal Identity
这个值来自控件向导中选择“Use control generated SessionManager for principal identity”（使用控件生成的代表主体标识的SessionManager）。这个选项便于使用Documentum的Principal Security。与Registered Identities一样，SessionManager也是由控件本身自动生成的。
但是，必须使用控件客户端来创建并注册超级用户的凭证，并注册IdfPrincipalSupport对象。然后客户端只需把Principle User帐户设置为控件的属性。
所以，您要提供能让SessionManager访问SBO的超级用户帐户名称和口令，还要提供没有口令的用户帐户名称（主体帐户）。SessionManager作用的时候，就好像主用户提供了正确的凭证一样。所有应用在用户帐户上的访问控制列表也都适用。
对于超级用户执行管理性任务来说，这项技术特别有用，因为这些任务需要通过在运行时模拟用户来访问用户数据。
- Assign SessionManager at Run-Time
当在控制向导中选择“Assign SessionManager at Run-Time”（在运行时分配SessionManager）时设置这个值。与前二个选项不同，这个选项要求控件客户端建立SessionManager对象，并把该对象作为控件的属性传入。它给控件客户端提供了最大的灵活性（当然在客户端代码需要的设置代码也最多）。在代码的其他地方已有SessionManager对象在使用时，这个选项最有用，有可能是在应用程序开始时设置一次SessionManager，而不用在控件初始化时设置。
页面流示例的示例代码演示了用于以上全部三种场景的技术，可以用作建立自己代码的指导。
查看一些示例代码
下图显示了来自Web服务示例的代码片断。这个示例是个简单的演示，用DBOC访问用户的收件箱。它在收件箱项目之间循环，累计计数器，然后把收件箱中项目的数量返回给Web服务。
虽然这很基础，但是确实可以作为页面流示例的基础，可以采用这个技术，并在其上进行扩展，查询每个收件箱项目，然后把数据在Web页面上表示出来。
在写这篇文章的时候，关于收件箱SBO，几乎还没有公开的文档，所以这个代码恰好可以给您一个起步的地方。
为了让代码能够识别DFC API，需要在代码顶部加入import语句（一定记得服务器的Classpath已经更新，其中包含这些jar文件）。如果要访问另外的SBO，就必须更新Classpath，以便把它们也包含进来。
可以看到，下图是一段混合代码，既处理控件本身，也处理DFC。
在示例代码中，变量inbox是扩展SBO并具有DBOC实用工具方法的控件。
例如，第33行显示了一条语句如何能够根据控件的属性对SBO进行设置：inbox.setDocbase(inbox.getSBODocbase());
这条语句告诉系统把SBO的Docbase属性设置成控件的docbase属性中所包含的值（在设计时设置的）。
下面，我们开始处理DFC的IInboxCollection和IInboxItem接口。
在第39行，代码通过getItem方法，请求控件把所有收件箱项目返回到一个集合。
要想查看inbox控件其他可以使用的方法，只要输入inbox和一个句点，然后让Workshop弹出方法列表（下图是部分列表）即可。
代码剩下的部分就非常简单了；它对集合里的每个项目执行循环，增量计数器。循环完所有项目之后，方法就返回计数值。当然，这全都封闭在Try/Catch块里，以便捕获可能发生的任何错误。运行这个Web服务示例的结果就是一个简单的服务响应，在这个例子中，有三个收件箱项目被计数。
一旦您知道了如何与收件箱SBO建立基本的连接，您就可以使用其他收件箱方法了。
例如，如果您想修改页面流示例，让它按照发件人和日期对结果排序，您可以在用getItems方法填充集合之前，添加一个对setSortBy方法的调用。下面的代码根据发件人降序排列收件箱，在每个发件人里，则按发送日期升序排列。
inbox.setSortBy("sent_by DESC, date_sent ASC", true );
IInboxCollection iInboxCollection = inbox.getItems();
setSortby方法接受二个参数：
- 第一个参数是一个字符串，定义OrderBy子句，可以简单到就是一个字段名，也可以复杂到包含多个字段和方向。
- 第二个参数是一个布尔值，指明是否为更新的OrderBy子句（在这个例子里，必须为true）。
我们还要去哪里？
本文对于Documentum业务对象控件做了更进一步的考察。
Business Object Framework是Documentum的战略组成部分，DBOC是BOF与J2EE框架集成的第一个实现。就在我们完成的时候，其他使用WebLogic Workshop框架的开发人员可以利用新的扩展开发工作包把他们自己的控件、服务和帮助提供并集成到Workshop IDE中。
我们已经指出了一些DBOC提供的实用工具方法和安全性选项，利用它们可以在运行时使用SBO，从而实现更大的灵活性。最后，我们还显示了代码既需要处理控件本身，也需要处理SBO提供的方法。
DBOC允许您方便地把Documentum SBO集成到WebLogic Workshop环境。学习了这个集成，只需下载并安装WebLogic Platform，插入DBOC，修改一些WebLogic服务器的配置，并按照示例教程的指导即可。
作者注：特别感谢Documentum的Kevin O'Connor，感谢他创建DBOC项目，支持Java控件工作，以及对本系列文章所做的贡献。
如果对本文有疑问，，请联系作者： Alan Zenreich ，电话：201-488-7222 转160.
欢迎继续阅读本系列的第3部分
原文出处：
http://dev2dev.bea.com/products/wlworkshop81/articles/DCMT2.jsp