My previous post on the announcement of OpenPTK provided a high-level architecture diagram making up the components of the OpenPTK. Over the next few weeks, documentation and more detail on this architecture will be uploaded to the documentation section of our website. Here some initial thoughts on the OpenPTK Architecture. Details will follow in future blogs and documents.

btw, check out Derrick Harcey's recent blog on OpenPTK and OpenSSO.

Project OpenPTK Architecture

The architecture is broken up into 3 different tiers (Consumer, Framework, Service). The java source of the project has been somewhat segmented into different packages representing the consumer and service tier along with specific areas of the framework.

Consumer Tier
Today, there are 3 mechanisms in the consumer tier to talk with OpenPTK's framework. These include:

• Java API - A small number of easy to use classes to support Java developers. The java developer should only need to use the org.openptk.provision.api and org.openptk.provision.exception packages. These includes items like creation of a OpenPTK context, calling a OpenPTK provisioning operation (i.e. create, read, update, delete, etc...). This Java API is used directly the Portlet and Command Line sample applications shipped with OpenPTK, as well as the other consumer tier mechanisms.
• JSP Taglibs - A JSP Taglib package has been provided to support the JSP developer in integrating access to OpenPTK services into their JSP pages. Sample taglib applications (User Management Lite, Tablib Test Samples) has also been provided with OpenPTK.
• Web Service (.wsdl) - A set of web services has also been provided to support web service requests. A sample Provision Web Service application is also provided to deploy a server to respond to requests from web service clients.

Service Tier
The service tier provides a common Service interface to the Framework tier. Regardless of the type of service (i.e. SPML, LDAP, JDBC, ...), each service has the option to provide one of eight types of provisioning operations:

• Create
• Read
• Update
• Delete
• Search
• Change Password
• Reset Password
• Forgotten Password

It is up to the service developer of a particular service to implement the methods for each operation. The current release only includes a fully functional SPML 1.0 implementation. The framework can pick which of the operations to use (as defined in the Framework Configuration).

Framework Tier
The framework tier is the abstraction layer providing the linkage between the consumer and service tiers using a number of different types of framework services. Here is a partial list:

• Configuration - When a consumer first initializes the framework a configuration .xml file is used to describe many components (context, service, logging, attributes, transformations). This configuration will allow for the definition of many of each component allowing the consumer to pick and choose at run time.
• Context - Defines which Service, Logger and various debug/audit flags to use.
• Request - Object used to make all requests to the service tier, regardless of the type of service.
• Response - Object used to receive all responses from the service tier.
• Logging - Specifies a class to use for logging. Initially, loggers to a filesystem is included, but this is expected to be enhanced to support other logging options (i.e. database).
• Debugging - Most components from the framework have a debugging component, allow for messages to be emitted.

If you have questions, comments, please don't hesitate to leave them here, or by visiting the Project OpenPTK website.

Technorati Tags: identity, identity management, openptk, provisioning