With this as the backdrop, let's look at these extensibility points in more detail.

WebLogic Workshop 8.1 Java Controls
BEA WebLogic Workshop Java Controls provide developers with the ability to easily connect with existing data, systems, applications, and business logic. Controls are visual components with events, methods, and properties that handle all of the details of connecting to an external resource or piece of business logic. Developers interact with controls by handling events, calling methods, and setting properties. In addition to the suite of built-in Controls (see Figure 1), Workshop 8.1 also makes the Controls model extensible so that all users (including ISVs) can build custom Controls that seamlessly plug into the Workshop integrated development environment.

Creating Java Controls
To create a custom Java Control, developers use familiar visual designers to specify the interface (i.e, the methods and events supported), set properties to dictate runtime behavior, and write the business logic using procedural Java code to implement these methods. Developers build the control(s) in a separate Workshop "Control Project" within an application. When the Control Project is built, all of the controls in the project are compiled into a single JAR file. This JAR is self-contained and can be moved to any other Workshop application by adding it to the application's Library folder.

Workshop also helps guide the Control user through the tasks of configuring the Control's behavior and appearance within an application. Control authors can provide either a simple Swing-based JPanel wizard or a multistep wizard presenting a set of configuration choices in terms the user understands.

Java Controls expose a set of simple properties by which a user can implement advanced runtime functionality such as asynchronous communication, security roles, life-cycle events, transaction support, and so on. Authors of custom controls have the freedom to populate the Properties sheet for the benefit of the controls' users.

Packaging and Distributing Java Controls
Controls are easily packaged and distributed as standard JAR files. Users consume controls by importing JARs into their application Library folder (see Figure 2). Controls then automatically appear on the design palette of the user, ready for incorporation into an application.

Application and Project Templates
WebLogic Workshop ships with a project and application template mechanism that is part of the application subsystem. Templates allow development teams to start with an appropriate architecture as part of the initial project structure by pre-populating an application or project with the required supporting files and resources (i.e., JSPs, EJBs, JAR files, images, etc.). They offer a way for system architects and ISVs to package and distribute best practices and starting points for developers.

Templates are stored in the weblogic81\workshop\templates directory and are packaged as zip files. A template can be made up of Java Controls, EJBs, JSPs, images, and/or any other file. They are loaded into an IDE based on an XML template definition file. Template zip files are read the first time the New Application, New Project, Add Project, or Install menu is opened.

Project Templates
WebLogic Workshop supports two types of templates: application and project. A project template can be created for populating a single new or existing project of a specific project type within Workshop. A project template may also be extended by other project templates and referenced by application templates.

Application Templates
An application template can be used for populating a new or existing Workshop application. Application templates can contain any number of elements, including project templates. Project templates defined inside the application template will not appear in the New Project and Add Project dialog and may only be used when creating this application.

Listing 1 is an example of the template definition file associated with creating Web applications.

WebLogic Workshop 8.1 IDE Extensions
There are several levels of depth by which to extend and integrate with WebLogic Workshop's IDE; from simple tool bar icons that launch external applications to fully integrated applications with custom windows, menus, and property sheets.

A Workshop extension is composed of the following artifacts, packaged together as a JAR or directory.

WebLogic Workshop itself is the culmination of several extensions pulled together into one common interface. wlw-ide.JAR is the main Workshop executable, containing the core class files, utility classes, and the mechanism to load extensions, but the interesting code to run the IDE is contained in the required Workshop extensions. WebLogic Workshop defines two types of extensions: required and optional. Required Workshop extensions are:

Optional extensions include

To cause Workshop to load a specific extension at startup, the extension's JAR file is placed in the extensions' subdirectory below the directory containing the wlw-ide.JAR file that contains the IDE core. An extension may also be fully exploded to directories and class files in the "extensions" subdirectory.

Creating Workshop Extensions
A WebLogic Workshop extension is simply defined as a JAR or a directory that contains at a minimum the extensions.xml, the file that declares an extension's participation in the IDE. By creating a JAR file with the extensions.xml file shown in Listing 2 , we can add a new tool bar icon to Workshop. It's that easy.

The % signs in "%sqlEditor.extension.actionSQLAttributeEditor%" are a means of referring to a localizable string resource and that it's optional.

This extension places a new button on the toolbar with database.gif as its icon. When the new toolbar button is pressed, the SQLAttributeEditor is displayed.

For more complex extensions, the JAR file would contain the Java code that is the extension's implementation, a manifest file that defines the class path, and attributes that reference dependent JARs that need to be available at runtime by the extension.

At startup, the core IDE runtime reads all the extension.xml files, batches them together and ensures that the requested services by each extension are available.

Extensions may define handlers for the <extension-xml> tag found in the extension.xml file. Handlers are associated with a particular id attribute. All extension.xml files are scanned for fragments contained within the <extension-xml> tag and those fragments are passed to handlers defined for the particular id attribute. This mechanism allows extensions to create extendable infrastructure in which other extensions can participate. The handler class is instantiated by the core IDE and is completely responsible for parsing the xml contained in the fragment.

Services
One important aspect of an extension is its ability to expose and consume the various IDE services. A service is essentially a public interface that has a single instance implementation and provides access to functionality in an extension. In addition to handlers for <extension-xml> tags, an extension may declare services that it implements. For instance, the debugger extension defines a debugger service that, among other things, provides a method for setting a breakpoint. The shell provides a document service with a method for opening a document. Services are consumed by the extensions Java classes and registered with the system using special tags in the extensions.xml file. Many services have associated tag handlers that allow extensions to add functionality to the service. Some of the most widely used services include:

Custom Tag Library Extensions
Tag Library Definition Extension (tldx) files allow developers to integrate their tags into Workshop. Integration services provided by the IDE allow developers access to both the data palette and design palette, error checking in source view, and custom rendering of their tags in the JSP Designer.

To build custom tag libraries for WebLogic Workshop, developers supply a tld/tldx pair, a tag handler JAR, and a tldx handler JAR (currently the tldx JAR must live in the workshop/extensions directory). Associated Help documents may be placed in WebLogic Workshop's Help directory.

Conclusion
BEA WebLogic Workshop 8.1 offers a rich extensibility model for developers and ISVs to integrate their products and services directly into the development environment.