Developing plug-ins by using the System Programming Interfaces
The following System Programming Interfaces, found in the ServiceRegistryClient.jar file on the client CD, are available for use with WSRR: a validation interface, a modification interface, a notification interface, and a WSDL parser extension interface. These interfaces are available in a base form that applies to all objects stored in WSRR. The validation, modification and notification interfaces are available also in an extended governance form that applies only to objects that are part of a governance lifecycle. Classes written to these interfaces are referred to as WSRR plug-ins as they hook into the standard processing performed by the WSRR application.
For a full description of the different types of plug-in, details of how to deploy them, and sample custom plug-ins, see the Related links sections .
When developing a plug-in, the plug-in code should use the API Delegates to perform actions in WSRR. For more information, please see the Related links section.
- When developing your plug-in, be aware that there might be a chain of plug-ins that is run for each plug-in event. If a previous plug-in makes changes to the object that is passed as the plug-in parameter, then, depending on the nature and mechanism by which those changes are made, the changes might not be visible in the parameter supplied to your plug-in. If you want your plugin to itself make changes, first retrieve the object by bsrURI from WSRR to ensure that you are working with the latest version, otherwise it is possible that changes made by a previous plug-in in the chain might be lost.
- Do not start native Java worker threads in your plug-in class; the thread does not have access to the J2EE context provided by the WebSphere Application Server container, and this can result, for example, in security problems.
Plug-in development is described in detail in the following subtopics: