Jini-based Management - Hasselmeyer

http://ww

w.ito.tu-darm

stadt.de

Peer HasselmeyerDepartment of Computer ScienceDarmstadt University of Technology

Java Intelligent Network InfrastructureJini Is Not Initials

Jini-based ManagementPart I: Jini

2

Jini: “Zero Administration”

“Plug and Play”At home: desired, needed, useful, possibleAt work:– small workgroups: mostly like at home– large systems: administration needed

Service providers: vitalJini federations need administrationJini can be used for “traditional” management as well

Jini& M

anagement: W

hy?

3

Overview

Jini, what’s that?– introduction– overview

Jini infrastructure– lookup service– discovery & join

protocols– programming

example– more details

Jini programming model– leasing– distributed events– transactions

Summary

Jini: Talk Outline

4

Jini

Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systems

Jini: Introduction

5

Jini


•framework of APIs with usefulfunctions / services

•helper services (discovery, lookup,...)•suite of standard protocols andconventions

•facilitates writing / deploying distributed applications

Jini: Introduction

6

Jini


•services, devices, … find each other automatically (“plug and play”)

•added, removed components•changing communication relationships•mobility

Jini: Introduction

7

Jini

Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systemsBased on Java and implemented in Java– may use RMI (Remote Method Invocation)– requires JVM / bytecode everywhere– type safety, array bounds, sand box, ...– code shipping

Strictly service oriented

Jini: Introduction

8

Service Paradigm

Everything is a service (hardware / software / user)– like object-orientation: “everything” is an

object– e.g. persistent storage, software filter, help

desk, …Services are defined by interfaces and provide their functionality via their interfaces– services are further characterized by their

attributes (e.g. “600 dpi”, “version 21.1”)

Jini: Introduction

9

Service Paradigm

Jini’s run-time infrastructure offers mechanisms for adding, removing, and finding servicesServices (and service users) “spontaneously” form a system (“federation”)

Jini: Introduction

10

A Jini Federation

Printservice

Picture storageservice

Picture mailingservice

Network

Camera 2(client)

Camera 1(client)

Jini: Introduction

11

What Kind of Services?

Devices:– printer, fax machine, ...– storage, persistency, logging, ...– computation, ...

Software:– spell checking, format conversion, ...– online banking, stock trading, ...– tourist guide, local maps, hotels,

restaurants, ...

Jini: Introduction

12

Spontaneous Networking

Objects in an open, distributed, dynamic world find each other and form a transient community– cooperation, service usage, …

Problem: no a priori knowledge of existence, interface, functionality, and trustworthiness of services– “traditional” client/server model: server

knows nothing about its clients, but client knows the server, its interface (API, protocol) and its functionality

Jini: Introduction

13

Spontaneous Networking

Objects must be able to find each otherMust be fast, easy, and automatic

But: what for?

me X

who else?

Jini: Introduction

14

Why Spontaneous Networking?

Ubiquitous computing– numerous, small, mobile devices with

network connection– must adapt to varying environments

“Service-based networks”– evolution of services on the web– machine to machine communication

becomes more important– distributed components cooperate on-the-

fly to solve problems

Jini: Introduction

15

Jini Functionality

Component discovery and bindingTypical middleware functions– naming/trading service– transactions– event model– no communication protocol, only bootstrap

Self-healing: leasing

Jini: Introduction

16

Bird’s-Eye View on Jini

Jini consists of a number of APIsIs an extension to the Java 2 platform dealing with distributed computingIs a layer of abstractionbetween application and underlying infrastructure (network, OS) → “middleware”Extension of Java in three dimensions

Network

Operating system

Java technology

JiniJini technologytechnology

Applications Services

Jini: Overview

17

Jini’s Extensions to Java

Extensions regarding networked systems

Distinction may seem blurred

Infrastructure Programmingmodel

Services

Java • JVM• RMI• …

• Swing• Beans• …

• TransactionService

• EnterpriseJavaBeans

• …Jini • Discovery

• Lookup• Join

• Transactions• Leasing• Distributed

Events

• JavaSpaces• Transaction

Manager

Jini: Overview

18

Overview






Summary

Jini: Talk Outline

19

Jini Infrastructure

Main components are:– lookup service as repository / naming

service / trader– protocols based on TCP/UDP/IP

• discovery, join, lookup– proxy objects

• transferred from service to clients• represent the service locally at the client

Jini: Infrastructure

20

Jini Infrastructure

Goal: spontaneous networking and formation of federations without prior knowledge of local network environmentProblem: How do service providers and clients get to know their local environment?

Jini: Infrastructure

21

Lookup Service

Similar to RMI registry and CORBA naming serviceRepository of service providersTasks: – registration of services– distribution of services (clients find

services)Main component of every Jini federationMay be redundant and hierarchically organized (similar to DNS)

Jini: Lookup Service

22

Lookup Service

Reference implementation uses Java RMI for communication– required: objects must be able to migrate

through the netNot only name and address of a service are stored (as in traditional naming services), but also set of attributes– e.g.: printer (color: true, dpi: 600, ...)– attributes may be complex classes

• e.g.: user interface(s)


23

Jini Federation

Client

LookupService

Service

-

registerlook

up

use


24

Discovery: Finding a LUS

Goal: Finding a lookup service without knowing anything about the network– to advertise (register) a service– to find (look up) an existing service

Discovery protocol:– multicast to well-known address/port– lookup service replies with a serialized

object (interface ServiceRegistrar)• proxy object of lookup service gets loaded to

discovering entity• communication with LUS via this proxy

Jini: Protocols

25

Where is the lookupservice?

Lookup Service

???

Lookup Service

That’sme!!!

Lookup Service

ProxyProxyLookup Service

ProxyProxy

Multicast Request

Reply

Communication

Lookup ServiceLookup Service

ProxyProxy

Jini: Protocolsforeign network

Discovery

26

Join: Registering a Service

Service provider already received a proxy of the lookup serviceProvider uses this proxy to register its service (register())Provider sends the lookup service– its service proxy– attributes that further describe the service

Provider can now be found and used in this Jini federation

Jini: Protocols

27...

Lookup Service

Service database in LUS

Join

Lookup Service

ProxyProxy

Entry 1 Entry 2 Entry n...Serviceproxy

Entry1Entry2 Entry n...Serviceproxy

Registration

Service

Registration

Jini: Protocols

28

Lookup: Searching Services

Client knows lookup service (e.g. via discovery protocol)Looking for certain (type of) serviceCreates query for lookup service– in form of a “service template”– matching by service type and/or attributes

and/or registration number of service– wildcards possible

Jini: Protocols

29

Lookup: Searching Services

Lookup service returns one or more matches (or zero)Selection usually done by clientService use by calling functions of service proxyAny protocol between proxy and service provider possible

Jini: Protocols

30...

Lookup Service

Service database in LUS



Lookup

Lookup Service

ProxyProxy Lookup?

??

Comm

unication

Comm

unication

Client


Jini: Protocols

31

Jini Programming Example

How is a service implemented?How does a client get access to a service?How is a service described?

Jini: Protocols

32

The “Running Example”

Lookup Service

Officeapplication

Printerproxy Any protocol

Communication between application and printer via function calls of proxy

Printerproxy

Printerproxy

Jini: Protocols

33


Printer registers itself with the office’s lookup servicePrinter provides print interface as its servicepublic interface Print extends java.rmi.Remote {

public PrinterParams readPrinterParams() throws java.rmi.RemoteException;

public SuccessCode print(Document doc)throws java.rmi.RemoteException;

[...etc...]}

Jini: Protocols

34


Implementation of service consists of provider and proxyProxy is stored in the lookup service and will be transferred to clients upon requestProtocol between proxy and service provider depends on implementation and is not stipulated by JiniExample uses RMI

Jini: Protocols

35

Implementing Service Provider

public class PrintImpl extendsUnicastRemoteObject implements Print {

[...]public PrinterParams readPrinterParams()

throws RemoteException {// something should be done here

}public SuccessCode print(Document doc)

throws RemoteException {// something else should be done here

}[...]}

Jini: Protocols

There’s noJini in here!

36

Registering a Servicepublic class PrintRegistration {public static void main(String[] args) {

System.setSecurityManager(new RMISecurityManager());

[...]Print service = new PrintImpl();Entry[] attribute = new Entry[1];attribute[0] = new ServiceInfo(

“Print Service”,“HyperClear”, “Shiny Inc.”, “2000”, “”, “08/15”);

JoinManager jmgr = new JoinManager(service,attribute, (ServiceIDListener) new Listener(),new LeaseRenewalManager());

[...]}}

Jini: Protocols

37

Multicast Discovery Clientpublic class MCExample implements DiscoveryListener {public static void main(String[] args) {

[...Security Manager etc...]LookupDiscovery ld =new LookupDiscovery(LookupDiscovery.ALL_GROUPS);ld.addDiscoveryListener(new MCExample());

[...]}public void discovered(DiscoveryEvent ev) {

ServiceRegistrar[] regs = ev.getRegistrars();ServiceRegistrar reg = regs[0];Class[] cl = new Class[] { Print.class };ServiceTemplate tmpl =

new ServiceTemplate(null, cl, null);Print proxy = (Print) reg.lookup(tmpl);

}public void discarded(DiscoveryEvent e) {}

}

Jini: Protocols

38

Overview






Summary

Jini: Talk Outline

39

Discovery

Protocols to find lookup servicesMulticast request protocol– client asks for local lookup services– no prior knowledge of local network

necessary– usually does not cross subnet boundaries

Unicast request protocol– used to contact known lookup services– works across subnet boundaries and over

the Internet

Jini: More Details

40

Discovery

Multicast announcement protocol– protocol for lookup services to announce

their presence– announcements are sent out periodically

Example: printer registers with the office via multicast, but gets service for software updates from a dedicated lookup server via unicast discovery

Jini: More Details

41

LUS Details: Groups

There may be lots of lookup services in a large Jini systemIdea: split lookup services into groups– group name: simple text identifier– clients/services always announce interest in

certain group(s)– unwanted groups are ignored– services do not explicitly register for certain

groups, rather with LUS that carries groupe.g. one lookup service per department: accounting, production, research, ...

Jini: More Details

42

LUS Details: Proxy Interface

public interface ServiceRegistrar {public ServiceRegistration

register(ServiceItem item,long leaseDuration)

throws RemoteException;public java.lang.Object

lookup(ServiceTemplate tmpl)throws RemoteException;

public ServiceMatcheslookup(ServiceTemplate tmpl,

int maxMatches)throws RemoteException;

[...]}

Used by serviceproviders

Used by clients

Jini: More Details

43

Join: More Features

To join, a service supplies:

– its proxy– its ServiceID (if previously assigned;

“universally unique identifier”)– set of attributes– set of groups (or ALL_GROUPS)– (possibly empty) set of specific lookup

services to join

Jini: More Details

ServiceItem(Object service,ServiceID id, Entry[] attributes)

44

Join: More Features

Registration with a lookup service is bound to a lease– service has to renew its lease periodically

to stay registeredDiscovery and join can be handled by objects of class JoinManager

Jini: More Details

45

Lookup: More Features

Client looks for service(s) registered with a lookup service by supplying a template:

Any combination of search criteria possibleWildcards possible, represented by nullAttributes: only exact matching possible (no “larger-than”, ...)

Jini: More Details

ServiceTemplate(ServiceID serviceID, java.lang.Class[] serviceTypes,Entry[] attrSetTemplates)

46

Entries & Attributes

Registration not only with name for a service (like in naming service)Attributes further describe serviceAttributes are structured as entries– entry consists of set of attributes

• e.g.: PrinterParams (dpi: 600, type: color, …)– every serializable data type is possible– data and methods– complex classes possible

• e.g. different user interfaces (AWT, Swing, speech, ...)

Jini: More Details

47

Lookup Service vs. Naming Service

Naming service Lookup serviceDescription by name (text) only• e.g. /devices/printers/ →

printers• search by name only

Description byServiceItems• type & attributes• arbitrary search dimensions

Name implies type Type is explicitStandardized namingconventions

Standardized interfaces

Usually no expiration of entries(heartbeat, keep-alive)

Services have to renew theirentries in the lookup serviceperiodically (leasing)

Identified by (static) address;clients need to know address

Discovery; no networkinformation necessary

groups can be modeled byaddresses

group concept

Jini: More Details

48

Proxy: Features

All communication between clients and services is handled by service’s proxyProxy object is stored in the lookup service upon registrationUpon request, object is sent to clientClient communicates with service provider via service proxy: client invokes methods of the proxy objectClient only needs to know interfaceProxy implementation hidden from client

Jini: More Details

49

Proxy: Implementation

Implementation of service functionality is independent from service interfacePartition of service functionality depends on service implementer’s choiceParts of or whole functionality may be executed by the client (within the proxy)

ClientClient ServiceService

ProxyProxy Communication


ProxyProxy Comm ication

Jini: More Details

50

Proxy: Implementation

When dealing with large volumes of data, it usually makes sense to preprocess parts of or all the data– e.g.: compressing video data before

transfer


ProxyProxy Communication


ProxyProxy Comm ication

Jini: More Details

51

Jini 1.1

More classes belong to standard Jini(i.e. net.jini.*), e.g. JoinManagerHelper classes– JoinManager, LeaseRenewalManager– Discovery utilities, protocol utilities– ServiceDiscoveryManager & LookupCache

Helper services– LookupDiscoveryService– EventMailbox– LeaseRenewalService

Jini: More Details

52

ServiceDiscoveryManager

Eases handling of multiple lookup servicesSupports different access patterns:on-demand, cached, reactiveLookupCache– states of LUSes are mirrored: increased

communication and memory use– immediate access to available services– usefulness depends on usage scenario,

especially useful for frequent and low-latency queries

Jini: More Details

53

LookupCache ExampleJini: M

ore Details

public class LCExample {public static void main(String[] args) {System.setSecurityManager(

new RMISecurityManager());[...]

ServiceDiscoveryManager sdm =new ServiceDiscoveryManager(null, null);

Class[] cl = new Class[] { Print.class };ServiceTemplate tmpl =

new ServiceTemplate(null, cl, null);LookupCache cache =

sdm.createLookupCache(tmpl, null, null);[...]Print proxy = (Print) cache.lookup(null);

[...]}}

Groups, locators, ...

Lease renewal manager

Item Filter

Item Filter

Listener

54

Overview






Summary

Jini: Talk Outline

55

Leases

Lease is a contract between two partiesLease grantor is willing to let lease taker (client) access a certain resource for a certain amount of timeLease can be extended (renewed) if resource access is still desired– extension can be denied by grantor

Resource is released upon lease expiration or cancellation (by client)

Jini: Programm

ing Model

56

What To Use Leases For?

For allocating hardware and software resources intelligently– no administration necessary (for removal of

stale resource reservations)– e.g. storage, ...

Distributed “garbage collection”– lease expired → “garbage”

Inside Jini– registrations with lookup services– resources: transactions, event registrations

Jini: Programm

ing Model

57

Distributed Events

Objects in a JVM can register interest in certain events of another object in a different (remote) JVM– network failure– crossing of event notifications– late and lost messages

“publisher/subscriber” modelArchitecture:

Subscriber Eventsource

1. Registration2. Event occurs

3. Send notification

Jini: Programm

ing Model

58

Distributed Events

Delivery separated from event semanticsDifferent delivery behaviors desired by applications, e.g. guaranteed, in-order,…Interfaces do not reflect particular delivery behaviorEvent mechanism can be extended to accommodate different application semantics

Jini: Programm

ing Model

59

Transactions

Transactions encapsulate a number of operations– “all or nothing” semantics– operations appear to happen

simultaneously (from outside transaction)– method to ensure consistency

Two-phase commit protocol– method to perform transactions– two phases:

• vote on transaction validity• commit/abort operations

Jini: Transactions

60

Transactions

Central: a manager– ensures consistency: each transaction

participant will ultimately “commit” or “abort”– performs 2PC protocol

Example: transfer money from one bank account to another

Jini: Transactions

61

Transactions: Properties

Design goal: maximum flexibility, minimum number of interfacesObjects must implement certain interface to participate in transactionsTraditionally transaction manager enforces certain semantics (ACID properties)Jini separates protocol from semantics:– 2PC performed by manager– semantics implemented by participants

Jini: Transactions

62

Distributed Transactions in Jini…

…are no transactions in a traditional (database) sense“Lightweight” transactionACID properties– atomicity / consistency / isolation / durability– each participant implements these

properties as he sees fit• e.g.: transient objects do not need persistency

– main property is atomicity, other properties are “sometimes” optional

Transactions are leased from manager

Jini: Transactions

63

Transactions: Participants

Transaction manager– coordinates transaction– Jini service– implements interfaceTransactionManager

Clients– initiate transactions

Transaction participants– objects that perform transactional operations– implement interface TransactionParticipant

– participation is initiated by join operation

Jini: Transactions

64

Transactions: Semantic Objects

Transactions have no fixed semanticsParticipants need to know the type of a transaction: “semantic objects”– Java type defines the kind of transaction– class Transaction tells objects to use

their standard transaction semanticsParticipants accept only certain transaction typese.g. DBTransaction– requires database semantics– transient objects not allowed (durability)

Jini: Transactions

65

JavaSpaces

Tool for developing distributed applicationsPlatform for exchanging objects between distributed applications– “shared blackboard”– “bag full of objects”

Jini service– implemented completely in Java (and RMI)– interaction with service via local proxy

Objects: data and methods

Jini: JavaSpaces

66

What To Use JavaSpaces For?

Models “object flow”– e.g. producer / consumer applications– load-balancing

Job-oriented view– jobs / events are put into the space and

picked up “eventually”, e.g. workflowBuilt-in properties:– concurrent access possible– write / read are atomic operations– access within transaction possible

Jini: JavaSpaces

67

Basic Operations: write

write puts an entry into a JavaSpaceUses copy of the object, never the object itselfwrite returns a lease– entry in a JavaSpace has a limited duration– “garbage collection” in a JavaSpace service

Producerwrite(Entry)

LeaseJava

Space

Jini: JavaSpaces

68

Basic Operations: read/take

Uses template (Entry)– same matching semantics as for lookup– if more than one match, select and return

one entry at randomWaiting for arrival of entry possibletake = read + removal of entry

Jini: JavaSpaces

Producer Renew leaseLease

JavaSpace Consumer

read(Entry)

69

Basic Operations: notify

Notify listeners at arrival of certain entriesUses Jini distributed eventsClients can register with a JavaSpace– registration requires a “matching template”– clients implement RemoteEventListener– registration is leased

Jini: JavaSpaces

70

Overview






Summary

Jini: Talk Outline

71

Summary: What to Remember

Infrastructure for service/component-based systemsDynamic, distributed binding at runtimeComponent selection by interface plus additional attributesProtocol independentMobile code (proxies)“Self-healing”: leasingEvents, transactions

Jini: Summ

ary

72

Conclusion

A number of good ideas– simplicity, “less is more” → flexibility– discovery, join, lookup– extension of name services by attributes– leases, events, transactions → recurring

design patternsRight direction– ubiquitous networks, service-centric– support for mobility, spontaneity

Individual concepts are not new, but together they offer new possibilities

Jini: Summ

ary

73

But...

Resource usage– each service usually requires a JVM

Small devices– JVM and RMI required on device– adaptation to resource-restricted

environment necessary (how?)– proxy objects are moved to client (memory)

Standardized (base) interfacesWhat about the competitors (SLP,UPnP, e-speak, .NET, ...)?

Jini: Summ

ary

74

Problem Areas

Security– important in distributed systems, especially

in open, dynamic environments– authentication, encryption– Java RMI security extension does not seem

to be the solution– what about charging for services?

Scalability– does Jini scale to a global level?

Jini: Summ

ary

75

Suggested Reading

Jini Homepage:http://www.sun.com/jini

Jini Community:http://www.jini.org

W. Keith Edwards: Core Jini, 2nd edition, Prentice Hall, 2000– good motivation, very detailed– don’t be frightened by more than 1000

pages (everything is said at least twice...)

Jini: Summ

ary

76

End Of Part 1...

Peer HasselmeyerIT Transfer Office (ITO)Darmstadt University of Technology

Email: [email protected]: http://www.ito.tu-darmstadt.de

Slides: http://www.ito.tu-darmstadt.de/publs/presentations/im01.pdf

Jini: Summ

ary

http://ww

w.ito.tu-darm

stadt.de

Peer HasselmeyerGerd AschemannDepartment of Computer ScienceDarmstadt University of Technology

Jini-based ManagementPart II: Jini and Management orManagement and Jini

78

Introduction

Jini and management

Jini Other

Jini

Oth

erAge

nt

Manager

ManagingJini with existing

technologies

Managing existing systems

with Jini

Management in the Jini domainManagement in the Jini domain

Managing existing systems

with Jini

Introduction

79

Overview

Management withJini– Why Jini?– use of Jini

conceptsManagement within Jini– entries, UIs– Administrable– events

FMAManagement of “inherited” systems– nannies

Management with existing protocolsSummary

Part 2: Talk Outline

80

Hardware/devices: network element,computer system, printer, ... (“MOs”)

Services:print spooler, ...

Management: supervision,configuration, deployment,...

Management with Jini

Different paradigms:– “traditional” management: focussed on

network elements and systems

Managem

ent with Jini

81

Hardware/devices: network element,computer system, printer, ... (“MOs”)

Management with Jini

Different paradigms:– “traditional” management: focussed on

network elements and systems– Jini: service-oriented → service

management

Managem

ent with Jini

“Low-level” services:storage, printing, ...

Managementservices:

supervision,configuration,

...

“High-level” services:deployment,...

82

Extensibility (1)

Extensibility: adding functionality (= services)Here: adding functionality at runtime– no need to stop/restart entire system

Two kinds of services:– “real” services (e.g. print spooler, video-on-

demand, ...)– management capabilities (e.g. printer

configuration, traffic supervision, ...)

Managem

ent with Jini

83

Extensibility (2)

Components find each other automatically (lookup/join)– location independent

Components can be deployed only when needed– one size doesn’t fit all– don’t waste disk space, computation power,

and setup time on services you don’t needComponents can be individually bought or leased

Managem

ent with Jini

84

Exchange/Migration of Components (1)

Service updates and migration (and additions) are handled the same way:– start new version (at new place)– stop old service

Clients automatically use new service instanceProblem: finding out when clients are finished using old service– clients have to use leasing for service

access

Managem

ent with Jini

85

Exchange/Migration of Components (2)

Sequence:– start new service– remove old instance from lookup service

(cancel its lease)– wait until clients’ leases expired (maybe

cancel them)– shutdown old service

Managem

ent with Jini

86

Separation of Concerns (1)

Trend in software engineering: components– Jini can be seen as an infrastructure for

distributed componentsIdea: each service should only handle its own small management areaEach component:– less complex– easier implementation– robust implementation

Managem

ent with Jini

87

Separation of Concerns (2)

Components can be individually deployed, bought, leased, …Components can be reused– can serve for different clients– e.g. only one log service necessary

Managem

ent with Jini

88

Fault Tolerance (1)

Different areasService entries are leased:– automatically removed from lookup service

when stopped / crashed / no connection– clients always see (more or less) recent set

of available services– lookup service does not get overloaded

with stale services

Managem

ent with Jini

89

Fault Tolerance (2)

Redundant services– easy to deploy (just start and forget)– only available ones are used– supervision already handled by

infrastructure:• register with lookup service for events• lease expiry results in removal of service entry• qualified listeners are notified• appropriate action can be taken

Managem

ent with Jini

90

Fault Tolerance (3)

Jini (and RMI) does not hide distribution– programmer is forced to cope with

exceptions:• ignore them (not recommended)• think about them• add meaningful handling: e.g. use different

service– results in more robust software– in small clients: 10-30% more code

Drawback: “new” error conditions– service not available– multiple services available

Managem

ent with Jini

91

Scalability

Basic scheme:– server overloaded → start same service on

another serverProblem: load distributionApplication dependent:– every service is the same: client randomly

selects one service instance (e.g. telephone directory)

– services differ: more than one service has to be contacted by client (e.g. service provider with different costs)

• possible solution: load balancing in service proxy

Managem

ent with Jini

92

Arbitrary Management Structures

Jini allows for any kind of management distribution:– hierarchical, peer-to-peer– distributed, centralized– everything in between is possible

Changes can be made on-the-flyExample:– one (or more) central DHCP service– if needed, departments can run their own– problem: selection of “more specialized”

service

Managem

ent with Jini

93

Protocol Independence

Jini does not care about protocol used between client and serviceJini works at interface levelMaking existing components available to Jini federation is relatively easy– no protocol conversion needed– Jini wrapper needed– wrapper maps between interface and

protocol

Managem

ent with Jini

94

Drawbacks & Problems (1)

Every component needs a JVM or a proxyUsing large numbers of services:– lookup service able to handle large number

of services?– lease renewal requires significant amount

of bandwidth?

Managem

ent with Jini

95

Drawbacks & Problems (2)

Security– yet unsolved– which service is allowed to talk to which?– who is allowed to start services?– who is allowed to administer services?

Managem

ent with Jini

96

Using Jini Concepts

Jini combines a number of concepts– leases– distributed events– lookup & join– transactions

Show deployment areas of conceptsConcepts can be used without Jini

Managem

ent with Jini

97

Leases (1)

Alternative to pinging– e.g. equipment supervision– object migration / RMI needed– additional feature: cancellation– both parties agree on duration– supervision comes free with event

registrations etc.

Managem

ent with Jini

98

Leases (2)

Resource handling– lease-based access to limited resources– resources can be reclaimed and

redistributed after known time– stale event registrations are removed

automatically after some time (no lease renewal)

Charging– service usage can be metered by lease

duration– models only time-based usage

Managem

ent with Jini

99

Distributed Events

Equipment supervision– emitted under certain conditions

Notifications– like notifications in CMIP (or traps in SNMP,

but typed data)– usually registration required (→ no

unsolicited notifications)– multiple arbitrary listeners– registering involves moving an object

• object can be simple RMI object• object might have further functionality, e.g. filter

events at the source, ...

Managem

ent with Jini

100

Lookup & Join

Locate servicesBase functionality for distributed, cooperating software components– extensibility at runtime– service migration– component updates– fault tolerance & scalability by redundancy

Managem

ent with Jini

101

Transactions (1)

Atomicity most important– a certain set of actions has to be completed– “all or nothing” semantics– may be distributed among multiple machines

Example: establishing a connection via a number of switches– if no resources left at one switch the whole

connection fails– already allocated resources at other

switches can be released

Managem

ent with Jini

102

Transactions (2)

Example: coordinated software update– update changes protocol of communicating

machines– all machines must be updated

“simultaneously”– update must be reversible (at least until end

of transaction)

Managem

ent with Jini

103

Overview






104

Introduction (1)

Admin interfaces neededWell known from “classical” management– monitor services– control and configure services

Within the Jini domain: based on and conformant to Java– information modeling

• Java classes and interfaces– remote access

• usually RMI• object migration

Managem

ent within Jini

105

Introduction (2)

Possibilities– entries– within service proxy– dedicated management proxy

Entries– attached to services– available at lookup services → searchable

Managem

ent within Jini

106

Recap: Entry Objects

Service registration consists of proxy and associated set of Entry objects

Clients can retrieve services by specifying a template containing a ServiceID, Entry objects, and Class objects

[...]Print proxy = new PrintImpl();Entry[] attribute = new Entry[2];attribute[0] = new Name(“PrintService”);attribute[1] = new ServiceInfo (“Print Service”,

“GA”, “IM Org.”, “2001”, “”, “08/15”);

JoinManager jmgr = new JoinManager(proxy, attribute,

(ServiceIDListener) this, null);[...]

Managem

ent within Jini

107

Predefined Entry Types

Jini’s Entry types may help in simple administration of a Jini community:

Package Class Descriptionnet.jini.lookup.entry Address “Postal address” of the servicenet.jini.lookup.entry Comment An arbitrary comment ...net.jini.lookup.entry Location Physical location of the servicenet.jini.lookup.entry Name The name of the servicenet.jini.lookup.entry ServiceInfo Some information about the service,

e.g., vendor, version number, etc.net.jini.lookup.entry ServiceType

(abstract)Information which may be viewed ina service browser, like an icon or atool tip.

net.jini.lookup.entry Status(abstract)

The state of the object, eitherNORMAL, NOTICE, WARNING, orERROR.

Managem

ent within Jini

108

Example: RuntimeInfo

Entry RuntimeInfo holds information about the system hosting the service package de.tud.cs.jini.mgmt.monitor;public class RuntimeInfo

extends AbstractEntry implements ServiceControlled

{// Entry’s fields must be public objectspublic InetAddress inetAddress;public String hostNameRemote;public Long startTimeUTC;public Date startTimeRemote;// Constructorspublic RuntimeInfo() {

// The default constructor will be used when a// serialized instance is reinstantiated...

}

Managem

ent within Jini

109

public RuntimeInfo(InetAddress inetAddress, String hostNameRemote,Long startTimeUTC, Date startTimeRemote) {// But we can also set them explicitly...

}...

}

RuntimeInfo (cont.)

If such an object is attached to a service as an entry, it will be displayed by LUS browsersIf object has settable properties, these may be changed by the browser– only affects local (client) copy of the object,

not its original/”master” at service/LUS

Managem

ent within Jini

110

RuntimeInfo in browser

Where is the service running?from service perspectivefrom client perspective

When was the service launched? (in localtimezone of server)

When was the service started? (in Universal Coordinated Time)

com.oki.jini.finder.Finder is just another (nice) Jini LUS browser

Managem

ent within Jini

111

Provide a “self-contained” UI (1)

Service proxy implements a textual or graphical user interface, e.g., by extending Applet, Frame or JFrameDrawbacks– client cannot use service at all, if it does not

contain base classes (here AWT or Swing) or cannot interact with a user in an appropriate way, i.e., if the client does not have an I/O device

– download and storage of proxy in LUS wastes bandwidth and other resources

Managem

ent within Jini

112

Provide a “self-contained” UI (2)

Better solution: user interface delegate object(s)– special Entry attributes for user interfaces

“ServiceUI” working group defines standard

Managem

ent within Jini

113

User Interface Delegate Object(s)

UIs are generated by factoriesFactories are attached to services as entriesDifferent kinds of UIs possible– e.g. AWT, Swing, speech, tactile, ...– each type has its own factory, e.g. PanelFactory, JComponentFactory, ...

Different audiences (“roles”) possible– e.g. “main” (user), admin, about, ...– represented by interfaces, e.g. net.jini.lookup.ui.AdminUI

Managem

ent within Jini

114

Managem

ent within Jini

UI Delegate Object(s)Generic entry:

Different factories for different UI kinds

roleObject depends on role of UI factory, currently always service proxy

public interface PanelFactory extends java.io.Serializable {String TOOLKIT = “java.awt”;String TYPE_NAME = “net.jini.lookup.ui.factory.PanelFactory”;java.awt.Panel getPanel(Object roleObject);

}

public class UIDescriptor extends AbstractEntry {public String role;public String toolkit;public Set attributes;public MarshalledObject factory;

public final Object getUIFactory(...) {}}

115

User Interfaces: Deployment

Service browser can display UI– selection depends on available / preferred

technology (AWT, Swing, ...) and role– choose appropriate entry– extract factory– create UI– display UI

User interface objects talk directly with service proxy

Managem

ent within Jini

116

Managem

ent within Jini

UI Scenario

Service Service Browser

UIDescriptor

UIFactory

Proxy Proxy

UI

Communication

Function invocation

Lookup Service

Proxy

Lookup

Reg

istr

atio

n

117

Management Interfaces

Customized Entry types are simple but at most suitable for static management information (sort of “fire and forget”)UIs for management in the small“Real” management: provide dedicated management interface– for periodic polling of a service (like SNMP)– to get notifications of state changes via

Jini/Java remote events– for service control

Managem

ent within Jini

118

Management Delegates

Management functions could be included in service proxy– probably separate interface

Most clients do not need admin functionsBetter solution: management delegates– see UI delegates– same functional power as direct inclusion– separation of concerns/aspects– fetch administration object only on demand

Managem

ent within Jini

119

Administrable service must implement net.jini.admin.Administrable

getAdmin() returns a Java object which implements appropriate admin interfaces for the service

public interface Administrable {public java.lang.Object getAdmin()

throws java.rmi.RemoteException;}

AdministrableM

anagement w

ithin Jini

120

Package Interface Descriptionnet.jini.admin JoinAdmin Control participation of

service in join protocolnet.jini.lookup DiscoveryAdmin Control participation of a

LUS in discovery protocolcom.sun.jini.admin DestroyAdmin Control service

terminationcom.sun.jini.admin StorageLocationAdmin Control location of

persistent storage of theservice

com.sun.jini.reggie RegistrarAdmin Control lease durationand snapshot frequency→ performance of LUS

com.sun.jini.outrigger

JavaSpaceAdmin Administer entries inspace

Sun has only defined very few and simple administration interfaces

These need to be extended in the future

Standard Admin InterfacesM

anagement w

ithin Jini

121

Example: DestroyAdmin

A component implementing theDestroyAdmin interface is finalized by calling its destroy() method

The specification of this interface requires the component to be completely destroyed, i.e., including its persistent state

public interface DestroyAdmin {public void destroy()

throws java.rmi.RemoteException;}

Managem

ent within Jini

122

Managem

ent within Jini

Admin Applications and GUIs

Generic admin GUI is/should be part of LUS browser, e.g., start Suns example browser with “-admin” option

java -Djava.security.policy=$JINI_HOME/example/browser/policy-Djava.rmi.server.codebase=http://./jini-examples-dl.jar

com.sun.jini.example.browser.Browser -admin

123

Custom Admin Interfaces

Standard interfaces are not enough, custom interfaces desiredInterfaces for configuration and control are usually very service specificHowever, some generic functions can be identified– setting information about

• service location (cf. LocationInfo entry type)• persistent storage location (cf.StorageLocationAdmin entry type)

• maintenance responsibility, …– disable/enable services, shutdown

Managem

ent within Jini

124

Example: StateAdmin

Jini’s DestroyAdmin interface– does not define exact destroy() semantics– destroy means destroy (including persistent

storage)– does not offer different operation levels for

graceful shutdown or temporary disabling a service

Define another generic interface to perform such tasks

Managem

ent within Jini

125

Managem

ent within Jini

StateAdmin (cont.)

Semantics? (not X.731 / ISO 10164-2!)Standardization required?

public interface StateAdmin {public final int ENABLED = 0;public final int DISABLED = 1;public final int SHUTTING_DOWN = 2;

public int getState();public interface ShutdownHandle {public void cancel() throws RemoteException;

}public ShutdownHandle shutdown()

throws RemoteException;public ShutdownHandle shutdown(Date at);public ShutdownHandle shutdown(long ms);public void enable() throws RemoteException;public void disable() throws RemoteException;

}

Might wait until last lease has expired

126

Event-based Management

Polling is not optimal solutionPush model is more efficient and appropriateUse Jini distributed events for notification deliveryEvent registrations are leased– stale registrations are automatically

removed– periodic lease renewal required

Managem

ent within Jini

127

Event-based Management

New event type StateChangeEventindicates administrative state changeProducers implement new interfaceStateChangeEventSupplier– implemented by the administration object

returned by getAdmin()– only register() function needed

Listener must– implement RemoteEventListener

interface (notify() callback)– maintain lease

Managem

ent within Jini

128

Jini Distributed Events: Forwarding and Filtering

Jini events form a 2-tier architecture– direct relationship between generator and

listener(s)Sun proposes to extend this to a 3-tier or multi-tier architecture– store-and-forward-agents (like CORBA-

event channel)– notification filters– notification mailboxes (kind of a messaging

service)Mobile objects: filtering at source possible

Managem

ent within Jini

129

Overview






130

FMA

“Federated Management Architecture”Specification, based on JiniAdds further functionality and servicesThree-tiered architecture: clients, services, resourcesInitially aimed at storage area networks (SAN), but suitable for all management areasBacked by the Jiro initiative

FMA

131

FMA: Services

All FMA federations must contain at least log, scheduling, transaction, event, security, controller, station servicesEvent service– decoupling of supplier and receiver (3-tier)– hierarchical event topic model (e.g.

“.de.tud.ito.printer.outofpaper”)

FMA

132

FMA: Stations

Management services are hosted on “stations”Services can be remotely installed– code download, initialization, removal, ...

Stations offer a certain runtime environment to services– register service with lookup service– mediate communication– handle persistency, access synchronization– analogous to EJB container

FMA

133

FMA: Communication

Adds a layer on top of RMIInvisible from client and serviceAllows for reference rebinding (“fail-over”)Allows for synchronization

FMA

Client Station

Service

Acceptor

ReferentProxy

AcceptorRMI Stub

134

FMA: Access Synchronization

Access to objects can be serialized by transaction, logical thread, and controller– concurrent access is prohibited

Classes can be marked for synchronizationAutomatically handled by stationController– control arbitration: managed resources can

be assigned to a single dedicated controller– controller service persists issued bindings

FMA

135

FMA: Further Concepts

Persistency– classes can be marked for persistency– automatically handled by station

Security– uses JAAS– security service provides authentication

services and supplies credentials

FMA

136

Example: An FMA Service

Simple Jiro Service:

– similar to RuntimeInfo from before– only provide some simple information about

the system (OS) hosting the service and the service itself (date when service was started)

public interface SysInfo extends Serializable {public String getOSInfo() throws RemoteException;public Date getStartDate() throws RemoteException;

}

FMA

137

Example: Client (1)

The client is a regular Jini client:

It performs “ordinary” discovery and lookupIt is not aware of the FMA infrastructure

[...]usedIF = new Class[]

{ de.tud.ito.sysinfo.SysInfo.class };tmpl = new ServiceTemplate(null, usedIF, null);try {myService = (SysInfo) registrar.lookup(tmpl);

} catch (Exception ex) {}[...]

FMA

138

Example: Client (2)

The client is a regular Jini client:

Once it detects a new service implementing the SysInfo interface, it outputs its information

[...]if (myService != null) {try {System.out.println("OS: ” +

myService.getOSInfo());System.out.println("Remote StartDate: " +

myService.getStartDate());} catch (Exception ex) {}

}[...]

FMA

139

FMA

Example: Implementation (1)

The implementation must provide two features to make it a real FMA service:

public class SysInfoImpl implementsSerializable, SysInfo {

private static final int classModifiers = Modifiers.PERSISTENT;

private Entry[] getLookupEntries() {return new Entry[] {

new ServiceInfo(“SystemInfo”, “ITO”, “ITO”, “0.1b”, “”, “”)

};}

[...]

Inform the Jiro container (the station) about how to handle persistency.Modifiers.PERSISTENTmeans: it is the duty of the station to maintain the persistency of the service.A set of Entry objects for registration with

the Jini LUS (like any other Jini service).

140


Attributes and persistent state[...]/** The date when this instance was started */protected Date mStartDate;/** # times start date has been read */protected int mNoCalls;

protected StationAddress station;

public synchronized Date getStartDate()throws RemoteException {

mNoCalls++;[...]}

Methods changing object state must be declared as “synchronized”. Stations will serialize object after each call to preserve persistent state.

FMA

141


Write a LogMessage to the Jiro Log service when getStartDate is called:Date now = new Date();String nowstr = now.toString();LogService logger =

ServiceFinder.getLogService(this.station.domain);LocalizableMessage lmsg =

new LocalizableMessage(this.getClass(),"getStartDate”,new java.io.Serializable[] {

nowstr, “StartDate = ”+mStartDate },null);

LogMessage msg = new LogMessage(lmsg, LogMessage.INFO, null);

logger.log(msg);

FMA

142

FMA

Example: logviewer

Show log messages with Jiro logviewertool

143

Overview






144

Management of Non-Jini Systems

Management of existing systems with Jini-enabled components should exhibit the advantages described beforeExisting devices must be accessible by the Jini layerJini-like solution: cooperating set of small management services– instead of one monolithic proxy

Jini Managem

ent-Federation

145

DHCP TFTP SNMP Watchdog ...(device spec.,

eg., lpd)

devi

ces

serv

i ces

man

agem

ent Jini M

anagement-Federation

Addressed example problem: Integration of a new device

146

Example: Nannies

Extensibility: new factories, sensors, etc.; components find each other: no configuration neededScalability: as many factories, sensors etc. as you like/needMigration, updatesSeparation of concerns: simple services, each focused on one functionality

Jini Managem

ent-Federation

147

Jini Management Federation

Split up functionality into small, loosely coupled components (separation of concerns)Reduce services to core functionality, e.g.– DHCP message receiver (“sensor”)– DHCP protocol engine (“binder”)– address management– DHCP lease management

Allow for re-implementation of service semantics, e.g., policy driven address assignment in DHCP

148

Jini Managem

ent-Federation

DHCPoffer

Nanny Architecture

Device

DHCPdiscover

Nanny Meta

Factory

Nanny Factory

Nanny FactoryServices

Nanny Factory

Nanny Factory

Nanny Factory

Nanny

notify

register

obtain

notify

instantiate notify ConfigurationServiceobtain

offer

prepare

download

DHCP Service

Sensor

TFTP Service

Sensor

149

Architecture Details (1)Jini M


Nannies– vendor-specific, device type-specific– provide intelligence for the integration of the

new device– go to vendor’s Web portal to obtain

appropriate NannyFactoryNannyFactory, NannyFactoryServiceNannyMetaFactoryProtocol services: sensor and binder

150

Architecture Details (2)Jini M


Integrate existing configuration serviceEvents/Notifications– DeviceUnknown– DeviceConnect– DeviceDisconnect– DeviceTimeout

151

Overview






152

Management with Existing Protocols

Manage Jini services with existing protocols– SNMP, CMIP, (IIOP,) …

Three solutions– build agent inside service– attach agent as entry– create proxy

• information model specific• generic (possible?)

Example: Jini and JMX/JDMK

Managing w

ith Existing Protocols

153

JMX/JDMK

Java Dynamic Management Kit (JDMK) is implementation of Java Management Extensions (JMX)

JMX/JDM

K and Jini

154

JMX/JDMK and Jini

Download MBeans from device via LUS

JMX/JDM

K and Jini

155

Overview






156

Summary/Conclusion

Jini is an interesting new technology– runtime extensibility, fault tolerance, …– requires management

• self-configuration (“zero administration”) vs.• external administration

– provides new possibilities for managementMust be integrated with legacy and proprietary environmentsNeeds standardizationNew challenges for the management community

Summ

ary/Conclusion

157

Suggested Reading (1)

AdventNet Agent Toolkit; AdventNet, Inc.; 1999 (http://www.adventnet.com/products/agentbuilder/)JSMAN CmisJava API; (http://www.jsman.com/)Java Dynamic Management Kit, A White Paper; Sun Microsystems, Inc.; 1998 (http://www.sun.com/software/java-dynamic/wp-jdmk/)Java Management Extensions (JMX); Sun Microsystems, Inc. (http://java.sun.com/products/JavaManagement/)Jini Technology and the Java Dynamic Management Kit Demonstration; Sun Microsystems, Inc.; 1999 (http://www.sun.com/software/java-dynamic/wp-jdmk.kit/)

Suggested Reading

158


Federated Management Architecture (FMA) Specification; Sun Microsystems, Inc. (http://java.sun.com/aboutJava/communityprocess/jsr/jsr_009_fma.html)Jiro Technology (http://www.jiro.com/)The ServiceUI Project; Bill Venners; Feb/2000 (http://www.artima.com/jini/serviceui/)Gerd Aschemann, Svetlana Domnitcheva, PeerHasselmeyer, Roger Kehr, Andreas Zeidler: A Framework for the Integration of Legacy Devices into a Jini Management Federation. Proc. DSOM'99,Springer-Verlag, pp. 257-268, 1999 (http://www.ito.tu-darmstadt.de/publs/)

Suggested Reading

159


Gerd Aschemann, Peer Hasselmeyer: A Loosely Coupled Federation of Distributed Management Services, Journal of Network and Systems Management, vol. 9, no. 1, March 2001, pp. 51-65(http://www.ito.tu-darmstadt.de/publs/)Peer Hasselmeyer, Markus Schumacher, Marco Voß: Pay As You Go – Associating Costs With Jini Leases.Proc. EDOC'00, IEEE Publishing, pp. 48-57, 2000 (http://www.ito.tu-darmstadt.de/publs/)Peer Hasselmeyer, Roger Kehr, Marco Voß: Trade-offs in a Secure Jini Service Architecture. Proc. USM'00, Springer Verlag, pp. 190-201, 2000 (http://www.ito.tu-darmstadt.de/publs/)

Suggested Reading

160

Contact Information

Peer HasselmeyerIT Transfer Office (ITO)Darmstadt University of Technology

Email: [email protected]: http://www.ito.tu-darmstadt.de

Slides: http://www.ito.tu-darmstadt.de/publs/presentations/im01.pdf

Contact Information

Jini-based Management - Hasselmeyer

Documents

Transcript of Jini-based Management - Hasselmeyer