OpenICF Framework 1.5.20.25 Documentation
Calling applications use the Connector API; Connector bundles implement the Connector SPI.
The Connector API (org.identityconnectors.framework.api)
is generic (in that it can be used to manipulate any type of object, not merely accounts),
but the Connector API is optimized to support provisioning operations and password management.
Every supported operation is synchronous to the caller.
This Toolkit is designed to support development with minimal dependencies of Connector bundles that implement the SPI. The Toolkit allows a developer to implement a Connector bundle and to test the bundle within the Connector framework so there is no need to implement it or test it within the context of each calling application.
The developer of a Connector bundle is expected to implement the operations
(Java interfaces within the org.identityconnectors.framework.spi.operations package)
that make the most sense for the target resource the developer intends to support.
The developer is expected to be appropriately flexible in tolerating inputs,
to be as reasonably robust in handling errors,
and to throw errors whenever it is prudent to do so.
Applications that use Connectors should expect
java.lang.IllegalArgumentException,
java.lang.UnsupportedOperationException,
java.lang.IllegalStateException
and other subclasses of java.lang.RuntimeException.
NOTE: The developers of this framework made a conscious decision to throw RuntimeException
(and subclasses of RuntimeException) rather than using declared exceptions.
The reasoning, briefly, is as follows:
- Declared exceptions tend to bloat code (and changes in declared exceptions tend to ripple).
RuntimeExceptionis ubiquitous; any piece of code can throw them (even without intending to do so).- Java defines subclasses of RuntimeException that cover most common situations.
One of the main functions of this framework is to prevent coupling between a Connector and any application that uses it. A calling application will be coupled only to this framework and not to any specific Connector.
- Each Connector implementation must be easy to replace and should not depend on a specific version of the framework.
- Because an application may use multiple Connectors, the framework must provide classpath isolation (and may provide JVM isolation at some point in the future).
- Classpath isolation ensures that there is no issue with conflicting third-party libraries.