Ch01.Intro.

fm Page 1 Friday, May 4, 2001 10:42 AM

1
The Jiro Technology
and the Federated
Management Architecture

The field of data storage resource management is growing at an astound-

ing rate. Between 2000 and 2003, according to International Data Corpo-
ration (IDC) estimates, almost 10,000 petabytes of storage will be shipped
to users. Software revenue in this area is expected to grow from a $5 billion
annual business in 1999 to a $10.4 billion dollar industry by 2004. The
driving factors behind the explosive growth of data storage are simple real-
izations. First, information is business, and lost information is lost money.
In addition, any time that information is not available translates directly
into lost revenue.
Software in the storage industry is informally broken up into four
categories.

 Backup, restoration, archiving, and hierarchical storage manage-

ment (HSM). This category covers traditional tape backup and
archiving. Data is moved to a secondary medium, such as remov-
able tape, and protected, typically by physical separation from the
primary medium. In the event of critical failure, data is restored
from the secondary medium. HSM blends the primary storage,
often disk-based, with secondary storage, such as tape media or
other disk platters. In this way, all data appears to the end user to
be available, although secondary media usually pays a penalty in
first-read access.
 Storage utilities. Tools in this category are largely focused on sin-
gle disk activities. They provide disk defragmentation and optimi-
zation as well as disk use and reporting.

1
Ch01.Intro.fm Page 2 Friday, May 4, 2001 10:42 AM

2 Chapter 1 The Jiro Technology and the Federated Management Architecture

 Storage resource management (SRM). These tools provide a view

of storage resources and allow management and monitoring of the
resources from that view. Typically, an SRM application contains a
topological view of a storage network coupled with the ability to
manipulate individual network nodes from a control panel. Often,
the control panel is a management utility provided by the vendor
of the managed resource.
 Storage replication and availability. These tools provide high
availability and failover capabilities for storage. Replication and
availability enable 24  7 uptime of storage for worldwide opera-
tions. These tools are typically used to move large snapshots of
data to a mirror device or a secondary storage device for use in the
event of failure of the primary storage device.

Because of commodity storage pricing, budget constraints, and the

rapid evolution of storage technology, heterogeneous storage networks
are becoming more prevalent in enterprise data centers. These networks
require the same kind of attention as that given by network administra-
tors to maintaining the kinds of computer networks that are found in vir-
tually all companies. Each device and network connection involved in the
retention of critical data in the storage network must be continuously
monitored for potential problems that would disrupt the flow of informa-
tion to its destination. Standards in this industry are evolving, and new
standards need to be developed before heterogeneous networks can be
managed without significant investment in training on each device that is
plugged in to the storage network. Most of the existing standards focus on
the management of components within the storage network rather than
on management of the storage network as a whole.1
The Federated Management Architecture (FMA), from Sun Micro-
systems, defines a management architecture and a service component archi-
tecture for building components and applications for heterogeneous
management solutions. Jiro, also available from Sun Microsystems, is a free
implementation of the infrastructure defined by the specification. Jiro
comes in two forms: The first is a reference implementation of FMA and the
services that it defines, complete with development tools. The second, a
runtime-only kit, is also available for deployment of Jiro applications to var-

1. There is a notable exception to this rule with the advent of the Web-Based Enterprise
Management (WBEM) initiative from the Distributed Management Task Force (DMTF).
You will see in this book how WBEM and the FMA actually complement each other’s
capabilities.
Ch01.Intro.fm Page 3 Friday, May 4, 2001 10:42 AM

Chapter 1 The Jiro Technology and the Federated Management Architecture 3

ious platforms. This book explains how to leverage Jiro to build dynamic
management applications.
Initially FMA was targeted at management solutions for storage area
networks (SANs), but it is now being applied in a variety of management
domains outside that realm. In fact, there are no boundaries in the specifi-
cation or limitations that force FMA to fit only within storage networks.
You can build a variety of network and device management solutions using
the same architecture and components as the FMA proposes.
The goal of the FMA is to help software providers build dynamic, pol-
icy-based management systems. It is dynamic in the sense that software can
be built to recognize the addition and removal of management components
and resources without explicit system administrator intervention. For
example, if a system administrator were to add a new redundant array of
independent disks (RAID) device to a storage network, existing policies in
the network could automatically take advantage of the new device.
Policy-based management is an approach, still evolving, for managing
diverse networks of hardware and software components. The driving forces
behind policy-based management schemes are the complexity, dynamic
growth, and heterogeneous nature of storage networks and networks in
general. Policies are rules that generically describe how to handle various
occurrences in a network. Today, many policies reside in a primitive device:
the brain of the system administrator. In Jiro, management policies are
embodied in the form of software components. A collection of policies with
rules for managing occurrences in a network has much the same effect as a
system administrator watching for occurrences in individual components
in the storage network.
Software-based policy components offer important advantages: You
need to train them only once, they don’t get bored with the job, and they
rarely quit (unless they are beta-level components). Today, most SRM soft-
ware is written with only partial automation. In a typical task, software is
used to detect a new device and to map that data into a graphical represen-
tation of the existing network infrastructure. But if a device must perform
an actual task, such as changing the read cache size on a RAID device, the
task must be completed by an operator who sets out to adjust performance
in a storage network. Adjusting the cache size on a RAID device would
involve navigating the topology, bringing up the device’s proprietary con-
sole management system, and then changing the cache size. In these con-
sole-driven applications, system administrators watch for events and
occurrences in the individual resources and react to them in human time. A
console may notify the administrator of one occurrence or another, but this
capability is not applied to all components in a storage network.
Ch01.Intro.fm Page 4 Friday, May 4, 2001 10:42 AM

4 Chapter 1 The Jiro Technology and the Federated Management Architecture

A policy-based management application, in contrast, would recognize

that performance is suffering in a particular segment of the storage net-
work. The application would then discover the low cache hit rate on the
RAID device and would modify the cache size to raise the number of cache
hits to a reasonable level. All this would be done without manual interven-
tion from an operator.
The FMA specification is constructed so that vendors can create their
own FMA implementations of the specification, just as Jiro is a Sun Micro-
systems implementation of the specification. A particular vendor may wish
to build an implementation to tailor its operations to a particular device.
For example, Jiro is very good at running on a Sun Solaris or Intel-based
server. Some vendors may have an interest in making an implementation of
FMA to run onboard a limited-size network attach storage (NAS) device.
The technique of providing an architecture, specification, and interfaces has
been proven to work in many other products and services available in the
marketplace. For example, the Jini architecture, and several other Sun
Microsystems specifications related to Java technologies, often provides
specifications and implementations separate from the services defined in
the architecture.
The Jini lookup service illustrates that a specification is a powerful
way to dictate behavior and interface. A lookup service is similar to a nam-
ing service or Web server. A Jini lookup service (covered in detail later in
the book) is a place on a network where components can locate distributed
components and proxies to devices that can be used to achieve a specific
purpose. Vendors can to create lookup services for Jini that are suited to
specific devices yet interoperate with other lookup services from other ven-
dors or can be tailored to other platforms. For example, a lookup service on
a pocket device that is run using the Palm operating system is constructed
very differently from a lookup service on a mainframe. The services provide
different qualities of service (QoS) and use different underlying storage
techniques, but the lookup services can interact with each other. Further-
more, a programmer using either lookup service is not required to under-
stand the implementation of the services and can program to each lookup
service using the same interfaces.
To understand how to use FMA, which is embodied in the Jiro imple-
mentation of the specification, it’s helpful to look at the three-tier architec-
ture that is involved in creating componentized management solutions.
This architecture is a generalized construct, and solutions tend to blur the
lines between its layers. Within the general architecture, FMA defines ser-
vices and constructs for common behaviors in the three-tiered architecture.
It is these common behaviors and service interfaces, defined in the FMA
specification, that you must examine to build your own implementation.
Ch01.Intro.fm Page 5 Friday, May 4, 2001 10:42 AM

1.1 Management Solution Architecture 5

Because the specification defines standard mechanisms and services for the
software components, you can use components from a wide variety of ven-
dors to construct dynamic management solutions that are customized for
individual management domains.

1.1 Management Solution Architecture The future of storage man-

agement, as well as distributed systems management, lies in policy-based
management architectures. Software components that implement policy-
based management solutions embody the reactions and decisions of an
administrator: a storage administrator, a network administrator, a system
administrator, or any type of computer operator. The important part of cre-
ating an automated, policy-based solution is to ensure that the software
components provide enough information for the policy component to
make its decision and implement a solution. A solution may be as simple as
e-mailing someone who can solve a physical problem, such as a broken
cable; another solution might automatically replace a failed device.
A componentized management solution architecture can be viewed
as comprising three tiers, as shown in Figure 1.1. The software that
builds the management solution uses the upper two tiers: the client and
management components. Decisions made by policy software compo-
nents are based on information that is mined from the lower tier, the
shared resources.
The lower tier consists of shared resources. In the storage manage-
ment field, shared resources consist of hardware, such as RAID boxes,
SAN switches, NAS devices, routers, and other equipment that forms the
storage network. Hardware is the most obvious shared resource in storage

Management Solution

Client

Management Components
Jiro: Event Service, Scheduling Service, Log Service,
Controller Service,
Jini: Transaction Service, Lookup Service

Shared Resources

Figure 1.1 Three-tiered management architecture

Ch01.Intro.fm Page 6 Friday, May 4, 2001 10:42 AM

6 Chapter 1 The Jiro Technology and the Federated Management Architecture

networks, but other software components, including file managers, vol-

ume managers, backup software, and so on, also need management. Thus,
both the hardware and the software components that need management
are considered shared resources. Typically, when a problem is detected in
a storage network, a system administrator manipulates a combination of
hardware and software to resolve the problem.
Shared resources are often manipulated through control points: firm-
ware or software interfaces that change the behavior of the resource.
Obviously, not all problems can be solved by manipulating a software
control point. For example, you can flip all the bits you want but you will
not be able to repair a broken fiber optic cable that way. On the other
hand, by manipulating redundant network infrastructure via software
control points, you may be able to route network traffic around the bro-
ken cable.
There are a variety of ways that shared resources make their control
points available for use. Networking hardware typically uses Simple Net-
work Management Protocol (SNMP). Storage devices themselves use a
variety of control mechanisms, including Small Computer System Inter-
face (SCSI), SNMP, SCSI Enclosure Services (SES), File Transfer Protocol
(FTP) servers, Web servers, and more. Software is typically manipulated
from application programming interfaces (APIs) in a software develop-
ment kit (after you get past the GUI and want to write additional features
for it) or command line invocations.
In the near future, the Web-based Enterprise Management (WBEM)
initiative may provide a single mechanism and location for retrieving infor-
mation about managed elements. This central repository of information is
known as a Common Information Model Object Manager (CIMOM). It
contains data that adheres to a standard modeling scheme known as the
Common Information Model (CIM). The central database of information is
static; if dynamic data is required, a provider (a specialized software compo-
nent) is supplied to the CIMOM. The provider then uses the correct man-
agement API to access a device or piece of software and determine the
status of the managed element. In a sense, the WBEM environment further
divides the shared resources tier into three tiers: the CIMOM, the provider
components, and the shared resources. The advantage of this arrangement
is that you can access information as well as the control points for any hard-
ware or software component in a network by using a single interface to the
CIMOM.
The middle tier of management solutions consists of software com-
ponents that can be assembled to create solutions that address specific
problems. These software components collect data from the bottom tier
Ch01.Intro.fm Page 7 Friday, May 4, 2001 10:42 AM

1.1 Management Solution Architecture 7

and subsequently act on that data based on policies that are configured by
an end user.
Here’s an example of a basic policy:

Notify the system administrator when abnormal temperature trends

are discovered.

Although this policy appears to be very basic, its implementation

can be complex. It can be implemented with the following components:

 Monitoring policy. Data is collected from the shared resource, typ-

ically via a device driver or software API supplied by the resource
vendor. The policy monitors the readings from the control points.
 Notification policy. This policy notifies the system administrator
when the monitoring agent sends out abnormal information, such
as the temperature of a device exceeding a threshold or indicating
an abnormal trend.

An unfortunate effect of the division of components we’ve outlined

here is that the interaction with the hardware, probably done via a device
driver, cannot be reused by a second policy. To create reuse, the monitor-
ing policy could be further subdivided:

 Device interaction component. This provides a component API that

acts on the device’s control points. By breaking the device interac-
tion into a separate component, the device logic is encapsulated
from the policy, allowing the policy the ability to act against any
device that adheres to a known component API, regardless of how
the underlying device control points are manipulated (SNMP, Web-
based, remote method invocation, or anything else).
 Monitoring policy. This is the same policy as before, but this time
it is much thinner because the specific device interactions have
been removed from it. The policy is now written against the API
of the device interaction component.

By creating components that fulfill a specific purpose, you can

achieve a high degree of reuse. All the components in the sample stack
can be reused in many different ways to achieve more interesting and sub-
sequently more complex management schemes.
The top layer of the management architecture is the client layer. Per-
haps the interesting part of creating the client layer is defining the client’s
Ch01.Intro.fm Page 8 Friday, May 4, 2001 10:42 AM

8 Chapter 1 The Jiro Technology and the Federated Management Architecture

real purpose. Some management solutions may be packaged to run in the

background and monitor the network. Typically, a small client application
is packaged with this application to modify the behavior of the various
management policies that are at work. Other management solutions might
give views of the entire network and allow drag-and-drop capabilities for
reallocating storage resources. This client is a much more complex version
of the small client application.
One benefit of the three-tiered architecture is that individuals can
provide components in areas that they specialize in. Hardware manufac-
turers can provide components that interact with the devices, whereas
storage management application providers can focus on storage manage-
ment policies.

1.2 The Federated Management Architecture In many senses, the

solution architecture we’ve described can be built with today’s technology.

 RMI can be used for distribution to and communication with

components that interact with a hardware or software resource.
 Intelligent components can be built from JavaBeans, Enterprise
JavaBeans (EJB), or other component architectures.
 Clients can be built from any of the many client technologies.

You may wonder, What does the FMA specification and Jiro add that
I can’t already build? Generally speaking, FMA and the Jiro implementa-
tion add services and standardization to policy-based management appli-
cations. More specifically, a set of static services is provided that allows
standardization and simplification of management applications. All ser-
vices and clients use the services supplied by Jiro to communicate and
complete tasks.
The static services provided by the FMA specification include a sched-
uling service, an event service, a transaction service, a logging service, and a
controller service. Each service is tailored to the needs of the management
domain. For example, the processing of event delivery can be time-consum-
ing with respect to the actual onboard resources that a device may have to
use to complete event delivery. For this reason, the event service off-loads
event delivery from a component that a developer writes to the event ser-
vice itself. Furthermore, the event service uses a topical event delivery
mechanism rather than the more traditional object-to-object relationship.
In Jiro, a subscriber subscribes to a topic such as .debug.raid.diskonline
rather than locating a specific management component and registering an
interest with it.
Ch01.Intro.fm Page 9 Friday, May 4, 2001 10:42 AM

1.2 The Federated Management Architecture 9

AS part of the architecture proposed in section 1.1, the management

services in the Federated Management Architecture are split into three
categories:

 Static services. Provided by Jiro and Jini, these components pro-

vide the mechanism for common capabilities required by the
management domain (see Figure 1.2).
 Management facades. Provided by component builders, manage-
ment facades provide network-enabled access to shared resources
via a component architecture. Management facades use the static
services to expose their behavior and information to other com-
ponents.
 Management policies. Provided by management software build-
ers, policies rely on available management facades and static ser-
vices to monitor and react to information.

Dynamic services constitute the general category of FMA software

components that refers to both management facades and management
policies. Created by application programmers, dynamic services rely on
the static services and behaviors dictated by FMA as well as on other
dynamic services built either by the programmers or by other companies
that specialize in particular managed elements. Because all management
components rely on the same services, common behaviors and predict-
able architecture are enabled. Static services, provided by Jiro, are guaran-
teed to be available. Dynamic services may or may not be present based
on a particular management system.
Examples of dynamic services include management facades repre-
senting RAID devices or volume management software (or both). Other

Management Solution

Client

Management Components (Services)

Static Jiro Services: Event Service, Scheduling Service, Log Service,
Controller Service
Static Jini Services: Transaction Service, Lookup Service
Developer-Provided Dynamic Services

Shared Resources

Figure 1.2 FMA with services provided by Jini and Jiro

Ch01.Intro.fm Page 10 Friday, May 4, 2001 10:42 AM

10 Chapter 1 The Jiro Technology and the Federated Management Architecture

examples of dynamic services take the form of management policies. A

management policy can be constructed that manages the RAID devices
attached to a SAN switch. The policy can be in control of resource alloca-
tion to particular hosts on an as-needed basis.
In addition to the static services defined by FMA, FMA defines
aspects, which aid the programmer in adding capabilities to management
facades and policies. An aspect is a private class variable that modifies the
behavior of a class, an instance of the class, or methods within the class.
In a sense, the aspects modify the behavior of a service without modifying
the interface or class hierarchy.
An example of an aspect is an instance variable that, when set cor-
rectly, makes the object instances persistent in their station. A station is
essentially a Java virtual machine (JVM) that is enabled as a network host
for base and dynamic services. If a station goes down, the state of your
object is restored when the station comes back up. Other aspects give you
ways to set methods as transactional, security modifiers, and more.
In addition to the aspects, Jiro, as defined by FMA, gives you other
infrastructure capabilities that are not generally available in the base Java
and Jini libraries. Infrastructure capabilities include the following:

 Distributed context, which allows multiple processes to be unified

in synchronization and security actions
 Proxy rebinding, which allows proxies to “reattach” themselves to
an object instance if the instance leaves the network for a time
 Extended RMI semantics, which allows invocation of static meth-
ods, constructors, and distributed context information

At this point, you should be getting a sense of what the Federated

Management Architecture and the Jiro implementation of the architecture
do. You should also be getting the sense that Jiro is big—too big to cover
completely in an introductory chapter. To summarize, FMA and Jiro pro-
vide the following:

 Static services for use by management applications and

components
 An architecture for creating policy-based management applica-
tions and components
 Infrastructure capabilities tailored to management solutions that
go beyond those available in Java and Jini

This book covers much more on the architecture of solutions and

the services and infrastructure provided by Jiro. Our primary focus is on
Ch01.Intro.fm Page 11 Friday, May 4, 2001 10:42 AM

1.3 Exercises 11

how you can build dynamic services for inclusion in a Jiro management
domain.

1.3 Exercises
1. Download the Jiro SDK and this book’s code samples from the Jiro
community site at http://www.jiro.com if you plan on running and
using the samples.
2. Locate any errata and feedback forums that are also located at the Jiro
Web site. These should be found in the “Discussion Forums” area.
Ch01.Intro.fm Page 12 Friday, May 4, 2001 10:42 AM