What are Application Policies?
Application Policies (hear-after called
simply Policies) are definitions that are returned from a policy data store,
and is used during run time by application software. In the past, these might
have been hard coded parameters that were embedded within an application
program. Sometimes, some of these parameters are placed into configuration
files where the settings can be changed by editing these files and restarting
the application (or having the application re-read the configuration file).
Policies generally replace the majority of configuration data in a
configuration file.
Policies can provide far more data than configuration files. A policy may
refer to additional policies and applications as needed to solve advanced
and/or provide for more dynamic applications.
Back to top
Who would use them?
If you have hundreds of applications that use
configuration files, it is often hard to manage them, especially if many are
related to different versions of application software running at different
sites. It is often impossible for one organization to locate all of these
applications as they tend to be managed by various groups or organizations
within different locations.
Configuration data in a centralized policy store allows an inventory of the
existing configurations to exist and be managed, as well as determine what
systems are actually out there in the network.
A set of policy might be created to support application data sharing among
different companies - those that partner with other organizations to utilize
services that provide synergistic capabilities between companies.
Back to top
How are they different than configuration files?
In their simplest form, A policy is nothing different than
a configuration file. The major differences are:
- They can be far more complex
- They can be highly dynamic (other applications, from anywhere on the
network can alter a Policy as required).
- They can be tied to other objects, and used by more than one application
on any system within a network.
Back to top
Why use a Policy?
- Centralized management - applications can be anywhere, but the
operational settings are visible no matter where they are.
- Policies allow applications to be far more scalable; as you need more
processing power, the added processors can share one or more dynamic
policies.
- Can hold things that configuration files cannot (for example, Serialized
Java Classes).
- Any program that can access an LDAP Policy Store can use or share a
policy.
- Existing programs can be adapted to use a Policy in place of a
Configuration File and join in as a new processing agent to a larger
application solution.
- Different parts of a Policy, or groups of policies can be used by
different applications at the same time.
- Any application can provide dynamic updates to one or more Policies.
- Policies can be versioned - that means that you could have different
policies of the same name available at the same time, allowing applications
to roll forward or backward depending on:
- New Software Releases
- Special Events
- work hours/off hours
- Holidays
- Reaction to application load - ie. additional application processors
can alter functionality based on need for support.
- A policy can be defined for all operational interfaces. This could
mean a unique policy for each unique devices. This becomes important as
new features must be added. XML, which can be associated with a policy,
provides a means to support new devices. This is particular important when
considering the plethora of new Internet enabled devices that are
appearing, especially in the area of Wireless.
Back to top
Why use an LDAP Directory Server to manage Policies?
The vast majority
of policy accesses are for reading the current policy and any related
sub-policies that are required. Applications often need a large group of
attributes that define required functionality.
LDAP Directories allow you to store objects that inherit objectclasses.
These can be used to define complex processes. An objectclass can be extended
by creating your own objectclasses.
Attributes can be multi-valued, ie. there can be more than 1 value
associated with an attribute. This is extreamly useful if you want to allow
different applications to be able to identify what they could be operating
against or groups of related data providing status.
LDAP Directory Objects can be almost anything. They can be raw data or they
can be unique programs. One example is Serialized or Marshalled Java classes.
Java has the ability to extend itself during run time - this method is a
variation of RMI (Remote Method Invocation); A Java application can overload
new classes from a Directory server that can alter the way an application
operates. This capability allows a centralized Policy store to distribute
application updates from a centralized source. Because versioning is
available, each individual application can be brought up with the changes as
needed, or only some application servers need accept the changes. Its managed
from a central point.
Back to top
Policy Management.
LDAP Directory Servers store data in a way that
really only allows you to access it via LDAP (a Protocol). This is not really
an issue as LDAP is easily accessed from C/C++, Java, PHP, ADSI and thru text
based LDIF formatted Directory commands that are applied using script files.
Portions of policies will be created by engineers; operational information,
XML DTD's, program logic, etc. - these should not be modified by anyone except
the engineering staff. Other portions are configuration related; these should
be managed by the systems operations group in an organization. Lastly,
portions of the policies may be updated by the applications running against
the policies.
Policy Management applications need to be created to allow Operations Staff
to properly configure the Policy Based applications. Other Policy viewer
applications need to exist that allow the current status of the policy be
viewed by anyone who needs to see it. Engineering alterations need to be
provided in the form of an LDIF file that is applied as an entire entity using
a script to apply it - this way it retains the entire information as provided
by engineering.
Policies must be maintained within a Configuration Management system. They
can become as complex as a program and casual modification may cause
processing to occur inconsistently, or in a fashion that was not tested or
designed to do.
Back to top
Benefits - Pros
- Faster application deployment when leveraging existing applications that
use the same or related policies.
- Central applications management.
- Central device management.
- Improved applications scalability - many applications can share the same
policies, and provide a degree of parallelism that is hard to do in a
distributed environment.
- Support Organizations have access to application operational status and
conguration information.
- X.509 based Security can be brought into applications - PKI is very
strongly tied to policy management. A consistent method can be created and
adapted to each new application that requires it.
- Portions of applications can be disabled during run time and used for
other purposes, allowing the applications to provide methods to adapt to
usage loading.
- Different versions of the same named policy can be available at all
times. This allows application function rollback to occur at any time. It
also allows the same application in different environments to operate using
different policies, allowing a rolling update to occur to multiple sites
with little or no down time.
Back to top
Issues - Cons
- Infrastructure must be in place.
- All systems must know how to interact with the Policy Server.
- Network must be able to support the Policy Based applications.
- Network Delays may affect Directory Access operations - the design of
the applications will need to take this into account.
Back to top
Configuration Management
Policies are textual representations of
character, integer and binary data. Typically, a policy is created by an
engineering staff. This data is pushed into a Directory Server by use of an
LDIF formatted file.
Engineering staffs must be able to test within an environment that closely
mirrors the production environment. They must also be able to identify the
policy components that are not configuration related or application run time
specific and develop changes that can be applied to a system that is operating
(this is most effectively done with versioning of Policies).
Once developed, the Policies need to be archived into a Configuration
Management System. These should be stored in LDIF format - this is text based
and supported by all major Configuration Management Systems. The LDIF file can
either be manually created by Engineering, or collected from the test
environment using tools that are provided with the the various Directory
Servers.
Back to top
Redundant Policy Servers
There are many opportunities for failure if
the network is unreliable. Policies are usually stored on a different
networked system from where the application usually operates. If the
application is dependent on 100% access to the Policy Server, it will fail.
For this reason, redundant Policy Servers should exist in the networks where
the applications are. Replication is a feature of all of the major LDAP
Directory Servers available - this includes: iPlanet Directory Server,
Microsoft Active Directory, OpenLDAP, Novell NDS, Oracle Directory Server,
etc.
Depending on your applications needs, the replication intervals may not
need to be real-time. The issue of network availability may impact situations
where your policies must be updated by a remote application server.
Your network may need to access another server anywhere on the planet in
order to operate against a Policy Server. Many networks may have delays
associated with them that your application will need to deal with. If this is
tied to performance related issues with the network, then it is reccomended
that that a policy server co-exist in the same area.
Back to top
Summary
A Corporate Strategy needs to be defined where application
standards that utilize policies must be defined. Policy infrastructure needs
to be put in place - this means 2 or more LDAP Directory Servers that are set
up with replication of the policy storage trees. Management must make a
commitment to support the technology and make it a part of their long term
focus.
- Policies, in their simplest terms, operate very much like configuration
files - something well understood by programmers, system administrators and
support organizations. This makes it fairly painless to adapt to existing
technologies and applications.
- New devices, such as VPN Servers, Routers, Internet Appliances and
Wireless devices need to consider how to utilize policies to deploy their
applications with.
- Security via PKI and policies can standardized.
- Operations is simplified as compared to having to manage configuration
data on dispersed systems.
- Support can be effective because the methods and configuration can be
made accessible to support organizations. This should reduce support costs
and reduce down time once issues are detected.
- Engineering benefits in that they can more easily reuse and expand upon
existing applications. Many parameters can be exposed to allow for improved
support or application tuning.
Back to top
Questions? Comments? Contact Engineering
|
