Notes: 2.0

Release 2.0 of Project OpenPTK builds on the success of Release 1.x. The goal ... enable developers to create custom interfaces to a variety of repositories ... has not changed. Release 2.0 gives the developer more choices for how they want to create custom interfaces. Release 2.0 also supports more back-end repositories. The "core" Framework Tier has also been enhanced to include "models", authentication, authorization, pre-actions, post-actions.

Following features, enhancements and resolved issues are new in Release 2.0:

Contents

1 Servlet-Based (Engine Architecture)
2 RESTful-based Web Service
3 Service / Operation Level Configuration
4 Client-Side Java API
5 Authentication
6 Authorization
7 Models, Views and Relationships
8 Actions
9 Encryption
10 Templates
11 Definition Functions
12 Enhanced Search
13 Services
14 Release 2.0

Servlet-Based (Engine Architecture)

Problem

Release 1.x was a monolithic design. The OpenPTK architecture was "packaged" with the application and deployed as a single unit. This made it difficult and near impossible to separate the OpenPTK Framework and Services from the application and maintain and manage them as separate components from the developers application or client.

Solution

A client-server design ... OpenPTK Release 2.0 user a client-server design allowing the "client" to communicate to the "server" as an "Engine" taking client requests, applying the proper authentication, authorization, encryption, etc and fulfilling these requests with back-end services. The new "Engine", is made up from the architecture components below from the:

Server Tier
Framework Tier
Service Tier

RESTful-based Web Service

Problem

Web 2.0 Developers are leveraging a variety of tools and languages to build end-user interfaces. Solutions are being built (such as AJAX) which require a standardized mechanism to access information. These types of applications typically use a RESTful Web Service which supports standard JSON/XML data structures.

Solution

In Release 2.0, OpenPTK's "Server Tier" provides the RESTful Web Service (supporting JSON and XML). The RESTful Web Service offers multiple ways to "represent" the data between the Server and the applications. Bi-directional data can be represented using either JSON or XML syntax.

Service / Operation Level Configuration

Problem

In Release 1.x, OpenPTK's Service architecture is used to define and implement access to a provisioning backing-store (SPML, JNDI, LDAP). A Service provided an implementation of some or all of the OpenPTK Framework "operations" (Create, Read, Update, Delete, ...). All "operations" when to the same backing-store.

Solution

In Release 2.0, OpenPTK's Service architecture separates the definition and implementation of access to the various provisioning backing-stores. A Service can be configured where each Operation could reference a different backing-store. For example, a Service, related to a Context could have its CREATE, UPDATE, and DELETE Operations use SPML, while its READ and SEARCH Operations use JNDI.

Client-Side Java API

Problem

Release 1.x had little in the way of a Client-side Java API.

Solution

Release 2.0 includes a fully documented Client-Side Java API that includes only those classes necessary for a client to connect over REST to the OpenPTK Server Tier implementing all connection, encryption, conversion of the contents to/from the OpenPTK Server. The Client-Side Java API can always be reached at:

http://javadoc.openptk.org

Authentication

Problem

Release 1.x didn't include authentication to the OpenPTK framework or services. It was up to the implementer to include their own authentication framework.

Solution

Refer to the detailed design and implementation notes on Release 2.0 Authentication.

Authorization

Problem

Release 1.x didn't include authentication to the OpenPTK framework or services. It was up to the implementer to include their own authentication framework.

Solution

Refer to the detailed design and implementation notes on Release 2.0 Authorization.

Models, Views and Relationships

Problem

Release 1.x didn't include any ability to connect up back end services to one another resulting in a model made up of views and relationships between these services. It was up to the implementor to do create and implement their own connections.

Solution

Refer to the detailed design and implementation notes on Release 2.0 Models, Views and Relationships.

Actions

Problem

In Release 1.x, OpenPTK was focused on performing basic operations within Contexts such as basic CRUD operations (Create, Read, Update and Delete) and few more around passwords. Outside of performing these basic data tasks, there was no facility to perform other actions, such as sending an email.

Solution

Release 2.0 includes the ability to define pre and post actions to a particular operation. An example action might be the sending of an email:

This simple action is contained as part of the create operation of a context within the OpenPTK config file.

<Action id="notify" mode="post">

<Properties>

<Property name="sendemail.subject" value="Your Account has been created"/>

<Property name="sendemail.fromaddress" value="%{email.fromaddress}" />

<Property name="sendemail.toaddress.attribute" value="email" />

<Property name="template.document" value="EmailTemplate-AccountCreated" />

</Properties>

</Action>

The Operation Actions define the notify action.

    <OperationActions>
        <Action id="notify" classname="org.openptk.context.actions.Notify">

<Properties>

<Property name="plugin.template" value="template"/>

<Property name="plugin.email" value="sendemail"/>

</Properties>

        </Action>
        ...
    </OperationActions>

The Plugins define the sendmail and template plugins.

    <Plugins>
        <Plugin id="sendemail" ... classname="org.openptk.plugin.sendemail.SendEmailPlugin">

            <Properties>
                ...
            </Properties>

</Plugin>

<Plugin id="template" ... classname="org.openptk.plugin.template.TemplatePlugin">

            <Properties>
                ...

</Properties>

        </Plugin>
    </Plugins>