Part 1 of this series described the difficulties that organizations face as they try to smoothly roll out and maintain the operational integrity of increasingly advanced software systems. Clearly it's no longer adequate to simply install software and hope for the best. Instead, tools are required to assist in sizing platforms and ensuring that the imposed load is matched by the scalability of the software. If such tools can be made enterprise ready, this could help facilitate a more natural and converged service-provider model.

To begin, take a look at how you can instrument an Apache Derby database for purposes of both deployment and management.

A Derby touchpoint

Figure 1 illustrates a hypothetical Derby management system. (As you'll see, only the topmost element is hypothetical!)

At the top of Figure 1 is an application that manages touchpoints -- creation, deletion, listing active touchpoints, and so on. This application might be part of an overall IT management system, or it might be a stand-alone package.

The touchpoint manager (TM) in Figure 1 represents an additional layer of software to what is traditionally the case. The TM provides the managed object model of the Derby instances. In effect, the TM subsumes the Derby instances under its control. However, the TM doesn't become a bottleneck -- the Derby instances continue to operate transparently, fulfilling the requirements of their clients. The key point is that the TM can monitor and control the Derby instances.

Below the TM are Derby touchpoints -- software entities that the TM owns. The touchpoints in turn create Derby instances. If the Derby instances operate in server mode, remote clients can interact with them as shown on the left of Figure 1. The client in Figure 1 does all the usual database table-related actions, such as creating, modifying, deleting, resizing, and so on. These actions result in changes to the databases at the bottom of Figure 1.

A server-mode Derby entity can service the needs of multiple distributed Derby client programs. As far as the client is concerned, this is just normal software operation. However, what's different about the Derby instances in Figure 1 is that they have been packaged (or instrumented) as autonomic computing touchpoints. The touchpoint is the managed object entity to which I've been referring. Touchpoints allow you to reach into and control an associated set of Derby instances.

Take a quick look at a typical life cycle for these managed object/touchpoint entities.

Life cycle of Derby touchpoints

The manager in Figure 1 handles the life cycle of all the touchpoints in the diagram. The typical life cycle stages include the following:

• Touchpoint creation
• Database creation (if not already present)
• Database access by client programs
• Touchpoint monitoring (manager retrieves information about the Derby instances)
• Touchpoint modification (manager changes the configuration of one or more of its touchpoints)
• Modification of the associated Derby instances by the touchpoints
• Touchpoint deletion (manager removes one or more of its touchpoints and, hence, the associated Derby instances)

You can see that the use of the TM and its associated touchpoints introduces an element of indirection. Derby clients continue to interact with Derby instances as normal, however the TM/touchpoint model provides additional power to the IT manager. This is the power to manage rather than merely deploy Derby technology.

What else does the use of touchpoints give you? The all-important element of standards compliance.

Back to top

WSDM standards-compliant Derby touchpoints

The Derby touchpoints in Figure 1 are in fact created as Web services. Web services technology is all the rage at the moment, which might make this all sound rather complex and difficult to understand. But in fact, the IBM AIDE toolkit makes the whole process of touchpoint creation, modification, and deletion pretty straightforward. Much of the code is automatically generated, and the touchpoint can be easily deployed to a Java™ Platform, Enterprise Edition (Java EE) application server, such as Apache Tomcat or IBM WebSphere® Application Server. In addition, Apache Axis provides Simple Object Access Protocol (SOAP) messaging. So, the amount of handcrafted code required is quite small. Basically, it's restricted to the peculiarities of your application domain.

So it's not too hard to produce the scenario depicted in Figure 1. In fact, if you visualize the AIDE framework (Eclipse or the IBM Rational® Application Developer for WebSphere Software and Rational Software Architect toolkits) as the TM, you're nearly there! AIDE incorporates advanced software components and technologies. Among them are:

• Wizard-based Web service creation.
• Model-driven software development.
• An event-notification mechanism.
• Java EE application server support.
• Axis SOAP client and server support.
• WSDM-compliant IT management software.

The event-notification mechanism is a means by which important occurrences can be automatically reported. For example, if the structure of a Derby database table is modified, you could program such a modification to produce an event. The event handler could then notify the IT manager (or perform some other action). The key thing to note about events is that they occur without the need for monitoring.

The important point is that you can easily use the cutting-edge software techniques and tools that are part of AIDE to create the required Derby managed objects. (For the grisly details of how to do this, see the tutorial link in the Resources section at the end of this article.) So for relatively little effort, you get a lot, namely:

• A Web services-based front end.
• A standards-compliant (WSDM) platform.
• Potential access by WSDM-compliant management tools.
• The ability to launch a Derby instance from a browser.

As you saw in Part 1, the requirements for employing Derby as a managed object are:

1. The framework must allow remote starting and stopping of a Derby instance.
2. You must use an application server infrastructure to run Derby.
3. Extending the source code of a Derby client program is easy.
4. Access to Derby infrastructure data is easy.
5. You can effectively handle Derby errors and exceptions.

You must now determine whether the proposed autonomic computing architecture shown in Figure 1 can fulfill these requirements. Let's take each requirement in turn with reference to Figure 2. Briefly, Figure 2 represents the Derby touchpoint after deployment to Tomcat. It allows the user to test whether Axis is running, verify that the servlet container (namely Tomcat) is running, interact with the touchpoint, and view the Web Services Description Language (WSDL) for the Web service.

Requirement 1: Remotely starting and stopping Derby touchpoints

Starting and stopping Derby touchpoints is as easy as clicking a link, as you'll see when you run the Derby touchpoint yourself. In Figure 2, the link to click is Create & browse.

Requirement 2: Using application servers

Can AIDE support code generation and deployment onto de facto application servers? You bet it can! AIDE supports automatic deployment (and undeployment) onto Tomcat, WebSphere, and others. As I mentioned in relation to Figure 2, you can also verify that the application server is running.

Requirement 3: Extending touchpoint source code

AIDE facilitates model-driven architecture, which allows both programmers (that is, coders) and designers (that is, non-coders) to change the model, and then auto-generate the required code. It's also possible to directly modify the code if required. Listing 1 illustrates an excerpt from the touchpoint Java code that starts an instance of Derby.

private void start(int port, int poolSize) throws BaseFault {
Thread derbyInstance = new Thread() {

public void run() {
InetAddress localhost;
try {
localhost = InetAddress.getByName("localhost");
System.out.println("Creating NetworkServerControl on " + 
    localhost.getHostAddress() + ":" + _port);
_server = new NetworkServerControl(localhost, _port);
System.out.println("Created NetworkServerControl");
_server.start(null);
System.out.println("Started Derby server");
_server.trace(true);
System.out.println("Turned on trace for derby server");
} catch (UnknownHostException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Don't worry about the complexity of Listing 1. It's included just to show you that the resource (Derby in this case) can be started from within the touchpoint. As you can see, there's a fair bit of console output (calls to println). These calls direct their text into the Eclipse workbench console window.

Requirement 4: Accessing Derby infrastructure data

Using touchpoints, you can dip into a Derby instance and pull out configuration data. Figure 3 illustrates a sample of the type of Derby data that the touchpoint can extract (pageSize, databaseConnectionURI, and so on). Other data items not shown in Figure 3 include deadlockTimeout and escalationThreshold.

You might ask why infrastructure data is important. One reason is to enable the TM to keep track of the touchpoint-based Derby instances under its control. The touchpoint simply extracts the management data that's required.

Requirement 5: Handling Derby errors and exceptions

Because touchpoint technology uses the Java programming language, it inherits all the usual Java exception and error handling. So you can see and respond to any errors that occur appropriately. This includes SQL exceptions as well as core Java exceptions.

In addition, AIDE supports notifications, as mentioned above. These are asynchronous messages that touchpoints emit to indicate the occurrence of important events. Listing 2 illustrates the use of notifications in which the touchpoint modifies the value of the deadlock timeout.

	
public void setDeadlockTimeout(int newDeadlockTimeout) {
int oldDeadlockTimeout = deadlockTimeout;
setDatabasePropertySQL("derby.storage.deadlockTimeout", 

Integer.toString(newDeadlockTimeout));
deadlockTimeout = newDeadlockTimeout;

if (eNotificationRequired())
eNotify(new ENotificationImpl(this, Notification.SET,

AutonomicPackage.DERBY_TOUCHPOINT__DEADLOCK_TIMEOUT,

oldDeadlockTimeout, deadlockTimeout));
}

The statement following if (eNotificationRequired()) notifies any listeners of the change to the deadlock timeout. Listeners are those entities interested in the underlying resource -- for example, an IT manager. For more information on this topic, see my AIDE tutorial series.

Back to top

Run the Derby touchpoint

I assume that you've downloaded and installed a copy of the AIDE toolkit. If you want to try the steps described above, you need the AIDE toolkit and the associated tools, such as Tomcat and the Java Development Kit (JDK). My autonomic computing tutorial series describes the AIDE tooling in detail. In particular, the tutorial listed in Resources provides sufficient detail on Derby to enable you to run the examples described in this article.

Why IT management and deployment are different

To get an idea of the difference between deployment and management, take a quick look at an important piece of open source software: Axis. Axis is a client and server SOAP system that provides the means to build Web services and deploy them to a Java EE application server (such as Tomcat). Clients can then access deployed services in the usual way. Listing 3 illustrates the steps to deploy, run, and list a minimal Web service using Axis.

	
java org.apache.axis.client.AdminClient deploy.wsdd
<Admin>Done processing</Admin>
Successful execution of this command has made the service accessible via SOAP.

% java samples.userguide.example3.Client 
    -lhttp://localhost:8080/axis/services/MyService "test me!"
You typed : test me!

The AdminClient can also provide a listing of all the deployed 
    components in the server:
% java org.apache.axis.client.AdminClient list
A big XML document is returned here

After you've deployed the service on Axis, any subsequent management is on an ad hoc basis. It's possible to structure Axis Web services so that they provide a basic level of logging. But the problem of management is more or less left to the developer. This is what I mean by a deployment-only approach.

Converged versus traditional service provider models

In a traditional service provider model, the services are extremely well designed and sized to suit the needs of the customers. Bandwidth is a good example: The network core is designed with x amount of bandwidth. The bandwidth x is then divided among the customers in a manner that minimizes congestion. Similar considerations apply to other service provider offerings, such as telephony and Virtual Private Networks (VPNs).

Traditional service provider offerings are invariably designed in a deterministic fashion. As a result, the management requirements of these services are well understood -- for example, telephony systems typically feature a midnight test. This type of test runs once a day and detects any anomalies, such as phones off the hook.

IT services are more troublesome to manage. Usage patterns are bursty in nature. For example, LAN bandwidth consumption can increase during lunchtime as staff use online games or perform downloads. Managing IT services therefore requires additional instrumentation beyond mere deployment. This is one path to high-value services that are scalable, highly available, and manageable.

Conclusion

The problem of IT service provision continues to grow as organizations try to roll out increasingly advanced software offerings. This problem is compounded by the demands of more technically savvy users. It's no longer sufficient merely to deploy software, such as Derby databases, and hope that the systems are resilient. Instrumentation is required that automates the management task.

IBM's autonomic computing technology is relatively new and may prove to be up to the task of automating IT management. The AIDE toolkit in particular provides Derby database touchpoints that facilitate a complex management life cycle. AIDE achieves this functionality by incorporating a wide range of leading-edge software.

Derby touchpoints allow the easy incorporation of Derby instances into the IT management landscape, which helps fulfill the management requirements outlined in Part 1. A key concept in trying to understand the autonomic management of Derby is the difference between deployment and management. Deployment is a subset of management and is never a substitute for management.

Can IBM autonomic computing form the basis for a converged service provider model? It ticks many of the boxes. Just as Java has gradually become the main programming language, it's possible that autonomic computing will fill a growing need for IT management. The standards bodies have never managed to provide a solution basis for network management. Given this record, there seems no reason to expect a standard solution for IT management. So a vacuum exists, and IBM is working to fill it by using its own resources and open source software. A strong case can be made for touchpoint-based IT management.

Resources

Learn

• "Hit the ground running with AIDE, Part 5: Build an autonomic computing system: Database engine management using autonomic touchpoints" (developerWorks, September 2006) describes the use and management of Derby database instances using autonomic touchpoints.
  
  
• Network Management, MIBs and MPLS: Principles, Design and Implementation by Stephen Morris deals with the software side of network management using the Multiprotocol Label Switching (MPLS) technology as a core topic. It discusses the details of how to start with technology and derive managed solutions.
  
  
• Visit the Apache Derby site for Derby resources.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  
• Visit the Autonomic computing zone for more information about autonomic computing and IBM's efforts in this area.
  
  
• Check out the developerWorks Apache Derby project area for articles, tutorials, and other resources to help you get started with Derby today.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  
• Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Learn more about the IBM Cloudscape™ database, which is built using the Apache Derby code base.
  
  

Get products and technologies

• Download a free trial version of AIDE. AIDE includes tools like the IBM Manageability Endpoint Builder (for building endpoints that allow products to expose manageability interfaces) and the IBM Manageability Endpoint Simulator (previously known as IBM Touchpoint Simulator).
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  
• Download Apache Derby.
  
  

Discuss

• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• A Derby touchpoint
• WSDM standards-compliant Derby touchpoints
• Run the Derby touchpoint
• Why IT management and deployment are different
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Open source on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers