Control Concepts

As you saw in Chapter 3, "WebLogic Workshop Application Development Basics," controls are objects that encapsulate business logic or provide access to resources. Controls provide an elegant, consistent, and straightforward mechanism to access resources and logic, as though they were simple Java objects.

Control Runtime Architecture

Controls are supported by a runtime architecture covering two key areas: method dispatch and invocation . During dispatch, the correct code is located to run, and then during invocation, the code is called with the appropriate wrapping context.

In general, dispatch requires that a client request be sent to the correct method within some control. Dispatching clients could be JavaServer Pages (JSPs), in the case of Web applications, controls, or other components , such as Web services. Behind the scenes, all dispatch requests are handled by an EJB runtime made up of three EJBs in the com.bea.wlw.runtime. core .bean package.

SyncDispatcherBean , a stateless session bean, handles dispatch requests for synchronous methods . AsyncDispatcherBean , a message-driven bean, handles dispatch requests for asynchronous methods, and AsyncErrorBean , a message-driven bean, supports notification of asynchronous delivery failures via the onAsynchFailure callback.

Invocation, the second step in any method call, is performed after the correct method has been determined. From a client perspective, there's no difference in calling a method directly; however, three areas are involved in the method invocation:

• A dynamic proxy, implementing the control's methods, that accepts the client method invocation

• A callable implementation of the methods, generated at compile time, that performs the client method request

• A control container that houses the callable implementation and provides runtime context

COMPONENTS VERSUS CONTROLS

The term component is used to mean any type of Workshop object that implements functionality. Technically, controls are a subset of components and can be written by hand or generated from other controls and components. More specifically , components can be any Java object meant to be used as abstraction around functionality. In general, components are things such as Web services, Enterprise JavaBeans (EJBs), business processes, or controls.

The control container provides a number of services to the control, including initialization, event and callback support, and dispatch services.

Figure 6.1 shows how a client method invocation actually occurs and should be familiar to anyone with a Remote Procedure Call (RPC) background.

Figure 6.1. Method invocation.

Component Types

WebLogic Workshop components are, for all practical purposes, either Java classes or Java interfaces but with specialized file name extensions that tell Workshop what the component is. Table 6.1 describes the major component types and their extensions. Note that this table focuses only on components and controls and omits other similar functionality, such as Java Page Flows (JFPs).

Table 6.1. Workshop Component Types

NAME	EXTENSION	DESCRIPTION
Java Web Service	.jws	Java Web Services (JWSs) are used to define services that are visible beyond the scope of the local application. JWSs are made available by using Web Services Description Language (WSDL) and can be accessed by WebLogic Workshop clients or other clients that aren't Workshop Web service aware. JWSs look much like Java classes but can support callback methods as well as conversations and can use other Workshop components. JWS controls can have synchronous, asynchronous, or callback support.
Java Control Source	.jcs	Java Control Source (JCS) components are used to encapsulate other controls, business functionality, or logic. JCSs are completely user developed, can expose synchronous, asynchronous, and callback methods, and be callback clients. JCS controls can be used only by WebLogic Workshop applications but can be packaged in control projects. JCSs also have an associated child Java interface that should not be edited directly.
Java Control Extension	.jcx	Java Control Extensions (JCXs) are created by wizards and expose the functionality of another component, such as a Java Process Definition (JPD) or a resource. JCXs are generated from other components or from resources and can be enhanced in limited ways. JCXs cannot contain references to other controls, but can contain inner classes and can be used only with WebLogic Workshop. For all practical purposes, consider a JCX as you would an interface.
Java Business Process Definition	.jpd	Java Business Process Definitions (JPDs) are used to define loosely coupled business processes and can be made available as Web services, for direct use by external clients, or as controls for use in WebLogic Workshop applications. JPDs are quite different from other components in that they typically have a single entry point, have state that is persisted to backing store, and can survive a server reboot. They can be called directly, called via a message, or based on timed events.

Control Underpinnings

Compiling a control in WebLogic Workshop is more than just creating the appropriate bytecode. Because of annotations, you might need specialized background resources, specialized support code, or other mechanisms to support a specific control. WebLogic Workshop code is compiled in two ways: automatically or on demand via the Build menu. Except when you're producing a final version of an application or a project, Workshop's automatic compile mechanism is sufficient for application development.

Control Methods

Before you begin developing controls, a more detailed examination of control functionality is necessary. As discussed in Chapter 3, control methods can be synchronous, asynchronous, or callback. Figure 6.2 shows a simple JCS that contains all three possible methods.

Figure 6.2. Methods within a Workshop control.

From a consumer perspective, synchronous and asynchronous methods are similar, with the exception of return values. Both synchronous and asynchronous methods can take traditional Java parameters as input. Synchronous methods can return any Java primitives or complex data types, whereas asynchronous methods (often referred to as buffered ) must always return void .

BUFFERING AND ASYNCHRONOUS METHODS

Asynchronous methods are also referred to as buffered methods . When an asynchronous method is added to a control, backing code is generated to support buffering the messages via a Java Messaging Service (JMS) queue. As a result, when a call is made, a JMS message is formed , added to a queue, and then processed by a dispatcher removing the message and calling the method. As such, asynchronous methods buffer all method calls.

WebLogic Workshop supports a mechanism known as a callback . Figure 6.3 depicts a callback method. Callbacks are not a new concept; however, the ease with which they can be created and used in Workshop is certainly new. In a control, a callback method is indicated with a left-pointing blue arrow. When a control is added to another control, a Web service, or a Java business process, any callback methods are shown in blue. When you click on a callback definition, the method call is automatically added to the new control's definition. Workshop then opens the control in Source View and places the cursor at the beginning of the newly added callback method. You can then code the callback method to do whatever is required with the parameters the called control returns.

Figure 6.3. Callback within a Java control.