从开发者的角度来讲，WebLogic Workshop 8.1最显著加强的一个方面就是Java 控件体系结构。现在，Workshop中的控件是一个开放的、可扩展的组件模型，不管是公司应用开发者还是ISV（独立软件开发商），都可以利用这种模型加快开发功能强大的服务器应用的过程。控件是Workshop框架的基本构件，不管是你自己编写控件还是使用别人编写的控件，你都会很快喜欢上它们的强大功能。
当然，你会想这种论调你早已听过。J2EE领域已经有了好几个组件体系结构，并且这方面的参考手册已经几乎将你的书架压垮了。为什么还要一个呢？问得很好，让我们分享一点秘密吧。在管道（plumbing）级，Workshop控件根据所使用的特性，将企业JavaBean和消息驱动Bean结合起来。Workshop框架尽可能地利用这些已有组件模型的服务。但是，控件解决了一些已有模型不能解决的关键问题。Workshop控件的基本创新可以被概括为两个词：简单性（simplicity）和强大性（power）。
控件的简单性（simplcity）源于Workshop开发环境和运行时框架的无缝集成,且把控件当作核心构件。简单性体现在两方面。其一，它可以让更多的人不再需要花一大堆的时间来学习J2EE编程，而是将与J2EE编程相关的事情变得相当简单，从而可以成功地开发Java应用。其二，Workshop的简单性使得J2EE专家可以利用它强大的特性，不需要再做那些单调而乏味的工作，从而大大地提高了开发效率。Workshop还为专家提供了一种很好的方式，使他们可以将自己的专业知识封装到控件中，这样别人就可以简单地使用这些控件。
控件的威力源自于它们启动的基于接口的、事件驱动的编程模型。这种Workshop编程模型是Workshop体系结构的一次根本的创新，它使得真实世界应用的开发能够适应快速变化的需求。Weblogic Protal和WebLogic Integration的最新版完全建立在这个编程模型的基础之上。这种经验已经证明Workshop模型足以用于复杂模型的开发。与此同时，把Portal和Intergation作为Workshop的"消费者"，进一步增强了底层基础结构的健壮性和灵活性。于是，Workshop控件的编写者们就可以利用这个基础结构来解决他们自己的开发难题。
本文不能对控件的所有特性一一描述，但是我希望能充分激发你的欲望，使得你试着建立一些自己的控件，你可以从最后部分讨论的大量的Workshop样本控件开始。
集成开发环境下的控件
Workshop环境强调应用的快速和重复开发，这种开发方式就是将已有的共同资源和第三方的应用集成为一个复合的应用。这些应用能够由个人或小的团体设计，并且设计过程可以及时完成，不至于落后于业务的需要（多好的想法啊!）。Workshoph基于核心设计视图/源码视图，这就意味着，开发者可以看到他们所开发的应用的外形，而且外形始终是与源代码同步的。Workshop无意于将编程搞得很神秘，相反，它使用了注释（属性）来配置和管理J2EE管道方面的细节，让开发者只需要专心编写应用的核心业务逻辑。
控件在这种视图/源码式的设计视图中扮演者核心的角色。例如，在构建一个Web服务时，控件是以选项板上的一套资源的形式呈现给用户的。当将控件从选项板拖到设计视图时，它便立即以一套Java方法和回调的形式在视图的右边显现出来，这些Java方法和回调是由该控件的编写者决定的。
控件本身以及控件的方法和回调能够体现控件特有的属性，这些属性可以在属性视图中设定。这些属性对控件的行为方面作出配置，其中控件的行为可以在设计时进行声明性地设置，无需编写代码。
在源码视图中，控件的表现形式就是Java类，源码视图中的一些编辑特性可以大大提高开发效率，例如语句自动完成和后台语法检查。
在运行时，控件通过环境接口就可以访问到一些属性值（以及更多的内容）。
通过这种设计方式的方方面面，我们可以看出，控件意味着和谐一致的用户体验，实现了目标应用与目标资源的完美统一。控件可以用在任何Workshop框架支持的应用中，包括Web服务、JSP和Web流、WLI工作流以及门户（Portal）。而且，控件能访问任何Java资源，包括JDBC 数据库、JMS消息队列、已有的EJB以及具有单项优势（best-of-breed）的ISV的水平和垂直应用服务器。值得注意的是，控件也能够包装和聚合其它控件，使最终应用开发者可以充分利用公司内外多个开发者的专门技术。这种可能性的惟一限制就是控件开发者的聪明才智。
开发控件
更令人振奋的是：像上面描述的一样，任何Workshop开发者能够构建可用于Workshop应用的控件。实际上，在Workshop的新版本中，基本的文件类型是.JCS文件，即Java 控件源（Java control source）的缩写。在Workshop中，JCS文件看起来几乎和JWS文件（Java Web 服务）一致，两者创建的方式也一样。控件展示出的方法和回调在设计视图的左边以箭头的形式显示。任何嵌套在新控件中的控件都显示在右边，就像在JWS中一样。
Workshop开发者可以轻易地设置针对控件的属性。XML"标签"描述文件定义了这些控件的属性，这些属性与它们在属性视图中显示的一致。
XML文件描述了控件所使用的标签（属性集）以及标签中的属性（特定性质）。标签被声明为类级或方法级。属性则包含声明了的类型和规则，例如必需的或可选的。属性也可以用默认值和合法的值指定，例如一个范围或者枚举。在源码视图和设计视图中，Workshop自动支持并加强声明了的规则。例如，在属性视图中，枚举显示为下拉选择列表。在源码视图中，标签内的拼写错误会作为语法错误显示出来。
许多Workshop最初版本的用户都采取了一种特定的模式，他们通过创建多个JWS文件，将分散的功能封装成整个应用中的一些组件。这些早期的Workshop使用者通过内置service控件的实例将这些服务统统放在最终应用中。用JCS文件可以更有效、更强大地将功能打包。JCS之所以更有效，是因为一次调用不需要涉及到整个SOAP的编组和拆编组过程。换句话说，为了做一次调用，传进和返回的参数并不需要串行化和反串行化成XML消息。之所以说JCS比起同等的JWS来更强大，是因为JCS代码自动采用调用者的事务和安全环境。
这并不是说在Workshop中JCS文件取代了JWS文件。JWS Web 服务在实现跨技术、供应商和行业的功能时，仍然是最好的方法。Web服务的发布合同（WSDL）使得它们可以互操作其它的工具，Workshop的映像和XQuery转换支持调用者和被调用者之间的松散耦合。Web服务单独的事务和安全环境正是一些组织在大多数跨领域应用中所想要的。IS经理最不希望看到的就是他的用户应用被另一个部门新建的应用发起的未授权的事务给锁住。
控件向导和自定义属性的创建工具
通常，简化对Java资源的访问的任务包括：引导用户配置控件属性，并且将配置结果在应用中实时显示出来。最后，控件开发者可以声明一个"Insert Wizard"类和/或 "Editor Support"类。这些类扩展了那些提供了简单的基于Swing的JPanel组件或者提供了一个多步骤向导的类。当用户将一个新的控件实例添加到应用中时，这个Insert Wizard类就被调用。Insert Wizard又引起对MBean的调用，以决定适合应用的可用资源，并提供用户容易理解的配置选项。
插入向导（Insert Wizard）的输出就是在一些容器（例如JWS文件或者JCS文件）中的一个控件实例声明，声明中有一些预先配置的属性。插入向导还可以产生一个扩展了的接口（.JCX）文件。下一节将对此作更详细的介绍。声明了控件实例之后，控件开发者还可以提供一个自定义的UI（用户接口），以便编辑控件的属性。通过提供一个编辑器支持类，控件开发者可以利用一个按钮在附近的属性视图中显示出所编辑的属性。该按钮调用控件提供的Swing代码，产生一个或更多的对话框。Editor Support类还可以自定义控件实例UI的其它方面，例如显示在设计视图中的控件的图标及其方法。
被打包的控件
自定义的设计时UI属于高级的控件开发,适合于那些以打包的格式将控件发布给其他人的控件开发者。例如，ISV（独立软件开发商）通过创建打包的控件，要么自己挣钱，要么使ISV产品和服务能够很容易的被Workshop的广大用户使用。在Workshop中，创建打包控件仍然是件容易的事。要创建一个打包控件，控件开发者可以将一个或多个控件创建在应用中的一个单独的控件"project（项目）"中。JCS文件中的注释将引导控件打包这一过程，注释可以指定某些属性，例如设定在控件被使用时要调用设计时UI类。其它的注释指定控件选项板中将显示的label（标签）和icon（图标），或者指定当一个控件被嵌套在另一个控件中时，是否应该从选项板中产生。项目中还可以包含诸如脚本文件和帮助之类的资源。创建好了控件项目之后，所有的控件及其相关文件都被编译成一个单独的jar文件，放到原来应用的类路径上，以便可以被应用中的其它项目使用和测试。Jar是自包含的（self-contained），可用在其它任何应用中，只需将其加入到该应用的库文件夹中即可。库中被适当标记了的控件将自动地显示在选项板中，可以直接用在一个应用中。
通过这种方式，ISV可以轻松地创建带有自己标记的控件，任何Workshop用户都可以轻易地使用该ISV的资源。如果当前讨论的资源已经可以通过内置的Workshop控件（例如EJB或Database控件）来访问，这个带有标记的ISV控件刚好可以作为一个小包装器或者是内置控件的自定义创建器。这一特性使得开发Workshop控件成为ISV十分划算的一种投资。仅仅使用相当小的投资，ISV的产品和服务就可以被更大范围的用户使用。由于使用者包括ISV潜在的客户和系统集成商，在开发基于他们的应用的自定义解决方案以及将他们的应用与客户已有的系统进行集成时，控件就成为一个十分强大的工具。更快的原型开发和集成意味着更快地满足客户需求，并且花费更少的时间和金钱就可以找到高级的J2EE专家来实实在在地做事。这样说并不夸张，Workshop控件有潜力来加速J2EE应用的推广以及Java开发的流行。
控件和Workshop编程模型
有些控件很容易使用和创建，可以在已有的J2EE组件的基础上创建，这样可以大大减少开发资源的投资。但是，如果你精通black-belt J2EE，不需要用到那些GUI，那么，还有没有你需要的呢？你为什么会认为用控件可以解决复杂的应用的问题？
答案就在于Workshop框架提供的服务。这种服务提供了更强大、更灵活的算法。Workshop 框架中最能体现这一点的有两个方面，一个就是控件扩展文件支持的"通过接口编程"，还有就是由Workshop框架会话管理、回调转移（callback routing）和消息缓冲等特性所提供的事件驱动的、异步的编程模式。这些概念通过一个故事就可以最好地描述出来，当然，你就是故事的主角。
相当容易的集成问题
想象一下，假设由你来负责让Java应用的程序员可以使用一个又大又复杂的大型机系统。这个大型机有数百个定义了的事务，而任何一个Java程序员都只需要其中很少的一部分。现在，一些Java程序员正要或者将要使用大部分的这些事务。对于任何单大型机的业务处理，将其映像到一个Java方法标记不过是一个很好理解的、重复调用的任务。
1． 与一个通信服务器挂钩，该服务器负责管理通往适当的大型机机器和区域的管道。
2． 创建一个Java方法标记，作为大型机事务的镜像。因为对合法身份的规定各有不同，创建时使用了一个名字映像算法；又因为数据的类型各有不同，创建时还使用了一个参数类型映像矩阵。
3． 在运行时，反转名字和参数的映像算法（或查找它们存储的结果），使得调用Java方法后，对大型机事务的调用使用的是正确的参数，返回给Java程序的是正确的结果。
4． 最后，将这些为一套相关的事务而服务的代码打成包，并使这些包可用于Java应用程序员的开发环境中。
为一套事务完成了这些任务后，你又可以为下一套需要的事务做相同的事。但是，如果前后两套事务中的java方法标记和一些配置参数有一点小小的变化，那么，比这更多的代码都是不可复制的，因为你没有足够的时间将其实现为一种factory+interface的模式。（不必担心，复制的代码中不会有什么bug，或者，至少你在的时候看不到任何的bug）
呈现给你的接口
基于这种设想，我们呼唤在Workshop中出现可扩展的控件。可扩展控件有一个在JCX（Java Control eXtension）文件中定义的方法接口。JCX通常包含了惟一的一个接口定义和一些方法标记，以及在接口层和方法层插入的自定义注释。JCX中没有实际的代码，实现控件功能的代码放在了前面描述过的JCS中。为了支持扩展文件，JCS必须调用一个invoke（）方法，该方法带有一些不定数量的参数，还要实现一个Method对象，该对象提供了关于被调用的Java方法的名字和数据类型的元数据。在运行时，用户代码首先调用某一个接口方法，接着Workshop 框架转而调用该控件的一个实现类。
对用户来说，JCX控件看上去几乎就是JCS控件的翻版。当插入一个JCX控件时，基本插入向导对话框给用户提供了两个选择，要么创建一个新的接口定义，要么创建一个已有的定义的实例。创建者可以任意控制生成的JCX文件，修改其形状。当JCX组件被加入一个应用时，它看上去很像JCS组件：在设计视图、属性面板以及源码视图中，它们看上去没什么分别。不管是用户，还是开发这个控件的人，都不必担心界面和内部实现的关联；框架会在暗中做好一切。
使用JCX文件时，自定义属性变得尤其有用，因为这样一来它们就可以传送关于方法的额外信息，否则，这些信息就不得不作为参数来传递，或者以某种方式存起来。在大型机的例子中，如果某?quot;区域"中有正在活动的特定的事务，则该区域便被模拟成一个控件级的属性，看上去就是对JCX中接口定义的注释。如果应用开发者需要能够灵活地指向某个区域（例如，对产品进行测试），创建该控件的人可以让这些控件级的属性在声明一个JCX实例时被重载。一个特定的方法要调用的大型机事务的名字可以作为对该方法的注释，这样就可以避免对方法名使用反映像算法。注释的另外一个用处就是作为一个参数"映像"，这样就可以使Java的标记参数的顺序与大型机交互的顺序有所不同。这样做或者可以方便Java程序员，或者可以避免受将来变化的影响。
结果呢？为编写应用的程序员提供了一个熟悉的、与Java关系友好的界面。加上一个自动实现的框架，这样控件开发者就不必为选择代码复制，还是选择支持基于接口模式的应用基础机构的自定义开发而为难。
这下就复杂了
你的信念还丝毫没有动摇吗？那么，就让我们快速回到6个月前，讲一讲同一个故事吧。现在Java程序员已经成功地建立了很多应用，这些应用使用了大型机控件向导生成的JCX。在Java方法和大型机事务之间仍有一个1对1的映像，这样应用开发人员就可以轻松地同步调用大型机函数，等结果出来就可以了。
但是，对应用的要求是越来越高的。现在，开发者需要同时访问大型机事务和一个供应商的Web服务。为了确保一致性和简化出错处理的过程，只有当大型机交互成功时，才可以向供应商下订单。而且，应用还需要从供应商那里检查价格，并根据情况有条件地进行又一次的定购。供应商的通信将通过调用一个Web服务来进行。
你的第一个反应就是扩展已有的Workshop应用，因为你已经被压抑得太久了。于是你添加一个service控件，来发布PO。所有一切与采取了这一连串的步骤之后的JWS方法依然还是同步的。Workshop体系结构为每个顶级的方法调用开启了一个全局事务，在该事务中还使用了一些底层的控件。但是，由于供应商Web服务并没有参与到事务中，你于是决定在处理过程的最后一步向供应商下订单。只要收到返回信息，就立即达成交易。
接下来的一个星期，使用情况开始变得糟糕起来，响应时间越来越慢。你第一个反应就是："我想这玩意儿没什么用了"。你打算告诉老板需要重新从头开始编写，这又要花去你两个星期（如果你不算进即将到来的假期的话，实际上会有4个星期之久）。但是等你还没有解决上一个问题，你又急着要先搞出一个原型来，想给我们看一些实在的证据。你发现服务器很少运行用于为进来的客户端请求进行服务的线程。你还发现大多数时间这些线程都卡在那里，等待供应商Web服务的响应。于是你认为，将这个与所谓的工具效率低很难联系起来。
留下消息，到时候我们会答复你
你记住了上个世纪的这次关于Workshop中的会话Web服务的谈话，并且决定付诸实现。对于最终的消费者，一个会话Web服务意味着对Web服务请求的响应并不在发出请求的这次调用中返回。相反，请求方法什么也不返回，而响应在生成后，则通过一次单独的回调返回。在调用方式中的这样一个简单的变化给Workshop框架带来了全新的强大的功能性和灵活性。
对于刚入门的人，会话模型可以使他们控制自己在他们的public接口中使用回调。在这种情况下，即使请求的底层实现连续地涉及到每个资源并且在最后调用回调方法，一个圈起了所有的3个基本控件的包装器也可以提供一个请求/回调来作为它的方法标记。提供一个仍然是以单线程的方法实现的回调接口有什么好处呢？答案是适应性。如果编程模式变成了一种事件驱动的请求/回调模式，你就可以将实现模式从同步流转变为异步流，而且不必改变你以前的接口合同。
在这个例子中，引入异步流的最好的地方就是在对供应商Web服务的调用中。你认为既然你不需要真正地在事务中一直等到供应商的响应，你可以晚一点收到确认定购的报告。既然在供应商服务中你的大多数线程都卡在当前应用中等待，那么这时就应该释放资源。可以有不同的方法使该异步调用，但是现在让我们假设一下，如果供应商正在使用Workshop本身，并且发布了一个可以执行等价任务的会话服务。Workshop框架将会把服务回调转交给在你控制中的那个处理程序。由于你已经将你的接口变成了事件驱动回调模式，所以当底层的实现发生了改变时，你的调用者就不必作什么变化。
消息缓冲是Workshop支持在会话模式中使用的又一个特点。有了消息缓冲区，调用者就可以将消息放入JMS队列中，异步地调用方法。JMS队列由系统来配置，其具体实现对调用者来说是透明的。在调用者看来，应用的行为没有什么变化--还是先发送请求，然后晚一点收到响应。而对于系统来说，使用缓冲区既提高了效率，又改善了与Workshop应用交互的行为。而采用消息缓冲区带来的最显著的好处就是改善了响应时间。当有一个输入方法用到了一个JWS时，消息缓冲区就释放套接字侦听线程，任其回去侦听另一个客户端请求，而不是继续在该方法本身的代码中运行。在上述情况下，如果让侦听线程运行方法逻辑的话，将导致系统响应变得非常糟糕。
当消息队列被用在一个作为全局事务一部分的内部操作上时（大多数Workshop方法调用正是如此），消息缓冲区对事务就很有意义。JMS的语义是：将消息放入某个队列是一种事务性质的操作，直到，也只有等到写队列时的事务被提交时，接受消息的队列才可以看到新的消息。在我们的例子中，如果供应商换成了对话模式，就可以将一个缓冲区放到一个对提出PO的服务的外绑定调用中。使用该缓冲区的效用就是可以确保PO请求只有当所以事务都成功提交时才可以发送。通过一个事务恢复就可以从队列中去掉PO请求，然后就像队列中从来没有这样的请求一样。
Workshop框架对会话模式和回调的支持离不开一些重要的基础结构的支持。对话可能会持续几分钟或几小时，在对话状态中，必须维持一些系统事件，例如与本服务器簇中其它服务器之间的对话中的传输。对话状态包括一些级别属性的值，例如跟踪收到的消息这一动作的级别。Workshop框架在每次提交时都将对话状态写进磁盘，以确保其持久性。Workshop还提供了一种声明机制，在这种机制下可以在方法中设置基于角色的安全属性，以确保只有在正确的用户环境中才可以进行回调。利用这种强大的基础结构，控件就可以创建切实可用的应用。
怎样开始
如果我还没有说服你控件值得认真去研究，那么我就只好放弃了。你可以继续坚持你的观点，等下一个版本发布时，再看看我们谁对谁错。相反，如果你相信我，并且有兴趣进一步学习，那么首先你要从dev2dev.bea.com网站上下载一个WebLogic Workshop 8.1 beta的拷贝。在SamplesApp中包含了一些控件的例子，它们都是JCS格式，打包在JAR文件中。
控件开发工具箱（Control Development Kit，CDK）是一套专门的例子和文档，供高级控件开发者使用。CDK中的主题包括自定义的设计时UI，用可扩展的方法建立控件，以及控件的一些开发策略。 尽情享受吧！
|
