Development Strategies
From Harmoni
This page aims to provide some guidance as to how the whole Harmoni/OSID system fits together and can be used to build applications. The strategies listed below are not the only way that these pieces can be fit together, they are but a few examples to get your creative juices flowing.
At the time of this writing, the OSID service with the most focus and largest number of implementations is the Repository OSID. This is with good reason, as the Repository OSID can be used to provide access for many kinds of data storage and retrieval systems. One Repository OSID implementaion might provide access to data stored in "institutional repository" system (such as DSpace). Another implementation may provide access to files in a local file-system. An LDAP directory, a database table, or an XML document could be wrapped in and worked with via an appropriate Repository implementation. Along with the Repository OSID the Authentication OSID plays a critical role in the ability to provide controlled access to data.
Similar to its flexibility in covering up many different data storage techniques, the Repository OSID can also be useful for many different client applications. While images and documents are obvious candidates for treatment as Repository 'Assets', other types of data such as blog posts, comment text, wiki pages, web-page hierarchies, configuration information, emails, entries in a course-catalog, and much more can all be mapped to storage in a hierarchy of Repository Assets.
To ease the development of stand-alone applications that do not rely on the existence of external data sources, Harmoni ships with a local-storage implementation of the Repository OSID that provides support for application-defined RecordStructures.
After the Repository and Authentication OSIDs, a number of the other OSIDs can be useful as hidden building blocks used inside of a Repository implementation or other systems. The Authorization, Id, and Hierarchy OSIDs are all useful building blocks, but may often not be directly exposed to consuming applications. Other OSIDs such a Grading, Scheduling, CourseManagement, and Workflow may be used alone to provide access to existing systems in their domain or together in a stand-alone implementation.
Contents |
Using one or more Harmoni/OSID Services
Situation
You are developing a PHP application. You have decided to use one of the hundreds of PHP frameworks for doing your output generation, theming, event control, etc.
Some possible reasons you might have for making use of the Harmoni/OSID Services:
- Your framework doesn't provide any common services and you don't want to have to implement your own common services.
- You want to start development of your application with Harmoni's existing OSID provider implementations and later run the application in production on a custom-tuned implementation that has the performance characteristics you need.
- You want to integrate with existing OSID providers.
- You want to develop an application that works with a local OSID provider now, and that can be easily integrated with a remote OSID provider in the future.
- You wish to store your application's data in an OSID provider so that it can be accessed and worked with by other OSID clients.
In all of the following examples, your application may use its own database tables or other data sources for the storage of information and might only use one of the Harmoni OSID implementations to provide access to functionality in a single area. Alternatively the application may make use of many Harmoni OSID implementations for all of its data storage. Yet another option is to use a mixture of Harmoni OSID implementations, custom OSID implementations, and/or third-party OSID implementations.
Example: Authentication and Agent Management
Lets say that you are writing an application that will provide access to a resource to any authenticated user from your institution. As well, you would like your application to know who is the currently authenticated person and some information about them.
To start off, you can develop your application using Harmoni's included Authentication and Agent implementations with some testing user-data stored in the Harmoni database tables and leave integration with your institutional user information to a later date.
In your application's configuration you will need to configure and start the Authentication and Agent services as well as their dependencies: Id, Hierarchy, and Database Manager.
In your application you can then access the AuthenticationManager and ask it isAuthenticated() and provide options in the interface based on the result.
A 'log-in' page can be created that calls the Authentication manager's authenticate() method to initiate authentication.
A custom logging system can then ask the AuthenticationManager for the current user's Id and give that to the AgentManager to receive an Agent object that can then be queried as to its display name, group membership, and other properties.
When it comes time to integrate with the institutional user information system several options are available:
- If LDAP, use the Harmoni
LDAPAuthenticationMethod(A non-OSID building block in the Authentication implementation). - Create a Harmoni authentication method for your authentication system. This is a non-OSID building block in the Authentication implementation that consists of an AuthNMethod object and AuthNTokens object which provide access to the Authentication system to the Harmoni Authentication implemenation and the Agent implementation. This solution is easy to implement, but less portable than the following one.
- Create your own implementation of the Authentication and Agent OSIDs and start them as Services instead of the existing Harmoni implementations.
Example: Data storage with Repository
Lets say you want your application to store its data in a repository so that it can be accessible to other applications. The current implementation of the Repository OSID does not check Authorizations internally. To start with we will access Repositories and their Assets without authentication. For example, the data-writing application could light-weight blogging system protected by HTTP-Access rules, and the second application could be a read-only RSS feed generator.
In your application's configuration you will need to configure and start the Repository service as well as its dependencies: Id, Hierarchy, DataManager and Database Manager. Once configuration is complete your application can create Repositories, Assets and data-Records as defined in the Repository OSID.
Example: Data storage with Repository, Authentication, and Authorization
If we combine the previous examples and add Authorization, we can build an application that uses OSID Authentication and AgentManagment for accessing local or remote user information and authentication sources and stores its data in a Repository with access control handled by the Authorization implementation.
The same services in both of the examples above will need to be configured, as well as the Authorization service. As with the first example, log-in screens can make use of the Authentication OSID implementation. As with the second example, access to data Assets is done by calling methods on the Repository implementation, though this time checks will be made to the Authorization implementation to verify if the currently authenticated user can access each Asset. Likewise, other authorization checks can be made to determine if the current user can modify an given Asset.
At any point the Authentication and Agent implementations, or the Authorization and Hierarchy implementations can be swapped for custom versions without impacting the operation of the Repository implementation or client application.
Using the Harmoni Architecture
Category:The Harmoni Architecture is a system that provides a structure for web applications that takes care of URL-building, flow-control, and Output Handling. Usage of the Harmoni Architecture does not require usage of any Harmoni services.
When building a Harmoni Architecture-based application, the best place to start is the Example Skeleton. This is an empty application that includes Harmoni and Polyphony. From the default Example Skeleton, add your own libraries and actions and remove the included ones that you do not need. The Example Skeleton comes with the full compliment of Harmoni/OSID services configured and installed with local-storage options. These are all available from anywhere in your application.
Disadvantages
- The primary weakness of the Harmoni Architecture is its theming system, the GUIManager. Depending on an application's needs the GUIManager may be helpful or get in the way. The GUIManager is scheduled for redevelopment, so this weakness may be lessened in the future. As well, it is possible to create your own theming system to use with the Harmoni Architecture or use no theming system at all.
- Other application frameworks may provide features that the Harmoni Architecture does not.
Advantages
- Use class-based action-scripts.
- Make use of the Polyphony library which includes user-interfaces to some common OSID services as well as a large Wizard building system.
- Support for form and parameter name-spaces to prevent input-field conflicts in complex applications.
- When starting from the Example Skeleton, OSID services are all available.
Categories: Harmoni | Manual | PHP OKI
