i want this seminar report

JIRO
Jiro(pronounced gyro as in gyroscope) is a Sun product that provides the infrastructure and plumbing for building distributed applications. Distributed services such as event handling, logging, transaction management, security, as well as basic communication services for distributed objects are included.It is written in Java and uses the Jini¿ name and lookup services. It is a product implementation of the Federated Management Architecture, which is a three tier architecture consisting of clients, mangement services and managed resources. This technology provides a middle layer of components and services that facilitate connectivity between managed resources and management applications. These resources can be anywhere on the corporate network, connected with any combination of routers and hubs, and use any standard management protocol such as Simple Network Management Protocol (SNMP).The code is platform-independent, enabled with a Java Virtual Machine.The Jiro management layer supplies basic management functions such as fault notification, scheduling, distributed logging, and transaction rollback.
A product based on Jiro technology is an implementation
based on the Federated Management Architecture (FMA) Specification, which describes extensions to the Java? language environment. FMA
Specification defines a component model called the FederatedBeans model.The success of the initiative
surrounding the Jiro technology will be availability of a wide variety of FederatedBeans
components from different suppliers. The FMA platform supports automated
communication between networked Java Virtual Machines, thus promoting applications
that are federations of the constituent components.

The Jiro Technology Solution
The need for the Jiro technology because of a storage sector dominated by point
products that are not compatible with each other.of information that are difficult to
integrate, complex to manage, or that actually prohibit cross-platform information
management are the problems of the present storage landscape.Its history began when it was decided to develop a Java
language extension designed to make it easier for the developer to create new storage
management applications, enable faster design cycles, lower development costs, and offer
a wider market potential.This project also intended to remove the need to conform to multiple
APIâ„¢s and interface specifications.

The High Level Architecture
-the representation of the resources to be managed,
-the interaction with the wishes of the user
-the computational logic that is needed in order to translate the wishes of the users into
the desired actions
The three tiers of the system are
1) Client/Presentation:
It may be as simple as an administrator sitting infront of his console but It is necessary to be able to initiate actions from CLIâ„¢s, scripts, periodic
schedulers, and components of the management system itself.

2)Logic:
contain the actual programs that are the applications implementing
the logic needed to perform management decisions and management functions.The applications commonly contain a number of modules, architectural subapplications,The FMA specifically defines such a
component model, i.e., FederatedBeans.
that deal with various aspects of the overall tasks to be performed
3)Resource/Information:
contains both the physical hardware
used to create the storage resources: the disks, tapes, disk subsystems, automated
libraries, channel interconnects, storage area networks etc.

Full seminar report pdf:
[attachment=1031]

[attachment=3807]


Jiro Technology

Overview
What is Jiro for?
Jiro pieces in Common with Jini
Where Jiro extends Jini (I)
Example Station Sequence
Where Jiro extends Jini (II)
Jiro References

Questions
What is Jiro for?
Jiro is SMI's implementation of the Federated Management Architecture (FMA)
The FMA was developed as part of the Java„¢ Community Process (JCP) to describe interfaces for building software components to manage heterogeneous storage networks.
Jiro is to Storage Management architectures what Enterprise Java Beans are to web-based business architectures.


Jiro pieces in Common with Jini
The Jiro implementation takes advantage of Jini by using some of its interfaces and implementation code (not a requirement of the FMA).
These parts of Jiro are parts of Jini:
Leasing
Lookup Service
Transaction Service
Valid in Jiro ==> valid in Jini



Where Jiro extends Jini (I)
Stations include:
Acceptor-Referent pattern(?) supports:
Remote static invocation
Remote constructors
Context mechanism for security, transactions, controllers and logical threads
Remote deployment of services
Get the jar files into the right locations with the right RMI-codebase property set.
Example Acceptor-Referent Sequence (I)
GOAL: Instantiate a remote Jiro-aware object.
1/ Client instantiates a Proxy using any one of the available constructors. The last argument of the constructor is the station address of the station that is to host the referent object.
2/ The Proxy class will need to lookup an appropriate Station Proxy by querying a lookup service with the station address supplied.


Example Acceptor-Referent Sequence (II)
3/The Proxy extracts context information to be passed explicitly to the Station Proxy.
4/ The Proxy class passes the operation request to the Station Proxy
5/ The Station Proxy forwards the request to the Station
6/ The Station uses the explicitly passed context information to establish a context
7/ The Station locally instantiates the Referent object


Example Acceptor-Referent Sequence (III)
8/ The Station must now create an Acceptor for the new Referent object
9/ The newly created Acceptor is returned to the Proxy as an Acceptor embedded in a binding information object
10/ The Proxy then binds the returned Acceptor. All remote method invocations on the Proxy will now be forwarded through the Acceptor to the Referent Object



Where Jiro extends Jini (II)
Extended Services
Event Service
Instead of 1-n source-listeners there is n-1-n sources-service-observers/responsibles
New Services
Logging of messages
Scheduling of events
Persistence of services
Security (based on JAAS) of method calls
Controllers and Logical Threads


Jiro References
http://jiro.com is the place for Jiro resources.
There are no published Jiro books (such work is in progress).
Jiro„¢ Technology Questions

[attachment=7603]

INTRODUCTION
Today's sciences and businesses depend on information a vast mountain of information. As the demand for storage to hold all of this continues to grow at phenomenal rates, the management challenges are growing too . In fact, the diversity of installed storage
systems and the wide distribution of those systems are on the verge of creating a crisis in
management, sometimes described as a “nightmare.”

The amount of management that needs to be done is also increasing . The cost of
management is one of the significant areas of rising cost in using computer systems. Since management is a continuing cost, it has a large influence on the assessment of “return on investment” (ROI). All aspects of a system need management: software, processors boards, options, network connections, storage devices and networks, modems, printers, and all the other pieces that are put together to make a “system.” Management, includes installation, configuration, asset deployment and inventory, performance monitoring, error and failure detection, upgrade and replacement; as well as more difficult things like capacity planning, service level contracts, load balancing, all of which may be controlled by policy decisions made by the owning organization. Because storage and storage subsystems are amongst the most complex parts of the management problem, as the storage systems often including processors, switches, and storage area networks, effective solutions to storage management problems are urgently required. Thus, the initiative surrounding the Jiro technology focuses its attention on storage management.

Developers lack standard middleware infrastructures for efficiently building capable
solutions for heterogeneous management tools, applications, and services. Further
complicating this situation, to provide storage solutions, developers must port their
products to multiple proprietary platforms, a costly, time consuming process.

THE JIRO TECHNOLOGY SOLUTION
The need for the Jiro technology is acute due to a storage landscape dominated by point products that do not interoperate, creating large islands of information that are difficult to integrate, complex to manage, or that actually prohibit cross-platform information management. The intent of the Jiro technology is to bring the benefits of community source processes to the development of storage management solutions. This platform, together with basic services and a component model, brings an order to the creation of the software that can automate or add intelligence to all management functions. The elements and their relationship are defined in the Federated Management Architecture (FMA)

The history of the Jiro technology activities starts with proposal made to Java language extension designed to make it easier for the developer to create new storage management applications, enable faster design cycles, lower development costs, and offer a wider market potential. It is further intended to alleviate the need to conform to multiple API’s and interface specifications. Following the requirements of the Java Community ProcessSM (JCP), a call for experts (CAFE) was issued, followed by the formation of the Expert Group, a work group made up of representatives from a number of interested industry leaders. The Group was convened under the terms of the Process, and the FMA Specification is the result of the work of that Group.

Using Jiro for management
Jiro implements an infrastructure for creating integrated and automated management software in a distributed, cross-platform environment. That infrastructure, a standard extension to the Java platform, is specified by the Federated Management Architecture (FMA). Jiro goes further than just platform independence, however, and introduces Jini-connection technology for distributed management across a network. Jini's leasing, for example, provides a mechanism for allowing management services to come and go in the network, and provides the software that uses these services to recover the associated connections. Moreover, Jiro introduces a middle tier of management between the thin-client Java GUIs popular today and such Java-based agent technologies as Java Management Extensions (JMX) and the Java Dynamic Management Kit (JDMK).

APPLICATIONS

management automation
To see how this would work in practice, let's take an example from the management of storage resources. Often, an administrator will use volume-management software in order to expand the storage space underlying a filesystem or database. When the filesystem runs out of space, the administrator can add more by adding another disk, keeping the applications running and available. In order to have the highest application availability possible, the administrator will typically set up an alarm that pages her when an out-of-space indication occurs. This leads to a reactive management style, in which the administrator's daily tasks consist mainly of reacting to problems in the system and initiating repairs.
Now let's see how building a set of components in Jiro can help our administrator get beyond the reactive mode of management so that she can spend more time improving the environment. The first set of Jiro components that need to be developed for these situations are called Management Facades. These specialized components allow other components in the Jiro technology environment to monitor and control the managed resources. In addition, thin-client Web GUIs can use these components to give the administrator a complete view of her resources.
The resource vendor typically develops the Management Facades for its products that enable the products to be managed by Jiro-based software. These components, which must conform to the FMA and the standard JavaBeans conventions, are called FederatedBeans components. They will typically use a standard protocol, such as SNMP, to talk to the resource (in the case of a device or system) or native library (in the case of software). They then expose an interface with a rich set of configuration and control variables and metrics that can be used by other FederatedBeans components.
In our storage example, we'll need Management Facades for the disks, volume manager, and filesystem. If the disks were in a storage network, we would additionally benefit from a Management Facade for a fabric switch. We'll create two FederatedBeans components for this example. The first component maintains a pool of spare disks that can be used for multiple applications and hosts in the storage network. It is capable of allocating these disks on demand and controlling their connection to a host by using the fabric switch's Management Facade. We will call this component the Storage Pool Bean.

The Storage Pool Bean
The Storage Pool Bean handles the allocation of disks between the various hosts in the storage network. It exposes an interface that allows other FederatedBeans components to request allocation of a disk to a given host for use by storage software or applications. When new disks are added to the storage network, the bean notices the new disks and adds them to its pool. It will keep its pool of disks in a special zone on the storage network by controlling the fiber channel fabric switch through its Management Facade. Finally, it exposes an interface that allows disks to be returned to the pool.

Infinite Disk Bean
The Infinite Disk Bean sees to it that an application never runs out of space. This adds to application availability without overprovisioning. Its job is to tune the capacity of the available storage to the application's need. It accesses usage information from the filesystem's Management Facade and tracks its usage over time. After predicting an out-of-space condition based on the history of past usage, it then calls the Storage Pool Bean to get a disk from its pool.
When the Storage Pool Bean gets the request for the disk, it calls the switch's Management Facade to change the zone of the newly allocated disk to that of the host. It next creates a device driver entry for the disk on that host and instantiates a Disk Management Facade as a single point of control for the new disk. The bean then returns a reference to the new Management Facade back to the Infinite Disk Bean.
The Infinite Disk Bean next calls the Volume Manager Management Facade to add the new disk to the RAID stripe used by the filesystem. Lastly, the bean causes the filesystem to grow to its new size through the filesystem Management Facade. The bean could also implement a policy for reclaiming disks based on usage as well.

[attachment=7613]

INTRODUCTION
pronounced like gyro

registered name used by Sun Microsystems for an extension to Java and Jini.

open storage management platform

Middle tier implementation of FMA specification

It was standardized as JSR 9 by the Java Community Process.

provides developers with an open environment for creating and deploying storage management services (SMS)
enables network administrators to route backup data from various devices on a network to another device such as a server or a magnetic tape backup unit
 and controlling, monitoring and configuring related data services.

MISSION OF JIRO


deliver a platform that enables true interoperability

platform-independence for the management of storage, servers, applications and devices on networks.
JIRO AS MAIN TOOL
Jiro implements an infrastructure for creating integrated and automated management software in a distributed, cross-platform environment.

introduces a middle tier of management between the thin-client Java GUIs popular today and Java-based technologies


Each resource consists of a functional part and a management part.

Functional part performs the functions of that resource, such as routing packets or storing data

Management part configures and controls the resource.

Data path
functional part of the resources through which the data passes