|PREV NEXT||FRAMES NO FRAMES|
|org.identityconnectors.common||Common utilities for all Connectors.|
|org.identityconnectors.common.logging||This package is responsible for providing logging to the Framework and the Connectors.|
|org.identityconnectors.common.pooling||Contains pooling configuration class only.|
|org.identityconnectors.common.script||Scripting support in ICF.|
|org.identityconnectors.common.security||Provides facility to secure String and ByteArray, so it is securely stored in a memory (or transported to Connector Server).|
|org.identityconnectors.framework.api||The Connector API presents a consistent view of any Connector, regardless of which operations the connector actually implements.|
|org.identityconnectors.framework.common.serializer||Serialization used when talking to Connector Server.|
|org.identityconnectors.framework.spi||'Service Provider Interface' package - the developer of a connector-bundle implements the SPI.|
The Connector framework provides a consistent, generic layer between calling applications and the Connector bundles that access target resources. Each target resource may be a system or application in its own right, but a Connector bundle enables any calling application to manage objects that exist on the target resource.
Calling applications use the Connector API; Connector bundles implement the Connector SPI.
The Connector 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
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
and other subclasses of
NOTE: The developers of this framework made a conscious decision to throw
(and subclasses of
RuntimeException) rather than using declared exceptions.
The reasoning, briefly, is as follows:
RuntimeExceptionis ubiquitous; any piece of code can throw them (even without intending to do so).
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.
The design for Connectors derives from requirements of the Sun Identity Manager product. Sun Identity Manager currently supports remote management of target resources through its Resource Adapter technology. Sun Identity Manager and its deployers have developed more than seventy Resource Adapters for enterprise customers who needed provisioning solutions for their heterogeneous environments. Connectors represent the next generation of this technology. Connectors are designed to minimize coupling, to maximize re-use, and to harness the power of open-source development to achieve best-of-breed solutions.
|PREV NEXT||FRAMES NO FRAMES|