Browse Prior Art Database

LDAP Based High Availability for Java application resources

IP.com Disclosure Number: IPCOM000125716D
Original Publication Date: 2005-Jun-14
Included in the Prior Art Database: 2005-Jun-14
Document File: 8 page(s) / 135K

Publishing Venue

IBM

Abstract

There are many resources that have the ability to be replicated. This gives architects the ability to design highly available systems. One of the biggest issues is the lack of standards around how to access these resources. This means that application writers have to design, code and maintain the interfaces that manage the connection policies between these resources.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 8

LDAP Based High Availability for Java application resources

It is getting more and more critical to design applications that are highly available. To meet this requirement vendors have design HA (High Availability) features into their packages. Typically, vendors have supported HA failover. By supporting HA the vendor's protect their package from hardware failures. In the event of a hardware failure on one machine the package will be failed over to another machine.

    Vendors have increasingly implemented some form of data replication in their package. By implementing data replication the vendors allow their customers to design redundancy into their architecture. Their customers can have multiple instances of the vendor's package in multiple locations. Thus in the event of a failure in one location the other locations remain unaffected. This is the best way to design systems that demand zero or minimum downtime.

    This has made it possible for customers to design highly available applications. However, customers have found the goal hard to realise. This is because of a number of factors:

Applications affinity.

No clear standards for implementing HA application between vendor packages.


1.


2.


3.

    Figure 1 shows how applications that are designed to use a replicated package. The package has been replicated in three locations to support three instances of the application. Under normal operating conditions each application connects to the local copy of the package. In the event of a failure the application is design to connect to one of the remaining instance of the package.

Coding overhead.

Page 2 of 8

 Cloud Cloud Cloud

 Cloud Cloud Cloud

 Cloud Cloud Cloud

Appication

List of queue managers

Queue Managers

2

[This page contains 3 pictures or other non-text objects]

Page 3 of 8

Figure 1: The current implementation of an HA application

    To support this implementation a list of available resource must be maintained. When this was first done the list was coded in the application. This meant that each application had a separate list to maintain. Each one was tailored to support the needs of that instance of the application. This proved to be very hard to maintain and administer.

    The next evolution was to have the list available resource held outside the application. LDAP (Lightweight Directory Access Protocol) became the popular location to hold this information. However the problem still remain. There are no common standards on how to implement this setup for an application that can access multiple instance of a package. Each vendor has its own interface.

    The main idea is to have a list of resources and an exit, which is used to test the resource. An attempt is made to connect to the resource to verify its availability before retuning the connection details to the application.

Design Goals

It is proposed that the new implementation meets the following design criteria:

Existing applications, that use LDAP to lookup their resources, should be able to...