Dynamic Load-Balancing of Jini and .NET Services ∗

Ying Chen Lin Sy-Yuan Li Yuan-Shin HwangDepartment of Computer Science and Engineering

National Taiwan Ocean UniversityKeelung 20224

Taiwan

Abstract

Jini and .NET are the two most popular distributedcomputing environments nowadays. Jini architecture pro-vides an infrastructure for defining, advertising, and find-ing services in a network, while .NET lets developers buildInternet-based, distributed applications using .NET Remot-ing. These two environments are very similar in manyaspects and both are capable of facilitating implementa-tion of distributed programs. However, they are not com-patible. Clients in Jini can not request remote servicesfrom .NET systems and clients in .NET can not find Jiniservices. Furthermore, none of these environments pro-vides load-balancing mechanisms. To solve these two prob-lems, this paper integrates Jini and .NET and proposes asmart proxy architecture. Consequently, Jini and .NET ser-vices can now make themselves visible to both Jini and.NET clients, and any Jini or .NET client can transpar-ently switch to a less-loaded Jini or .NET service througha smart proxy once the current service is too busy. Specif-ically, this paper solves two important issues for Jini and.NET: interoperability and dynamic load-balancing. Exper-imental results show that this technique can dynamicallydistribute Jini and .NET clients quite evenly over Jini and.NET services when proper load-balancing strategies areimplemented onto smart proxies.

1. Introduction

Jini is a Java-based infrastructure developed by Sun Mi-crosystems that can provide all the services necessary tosupport parallel and distributed applications [1, 6, 19].Since its introduction, Jini has been applied to enterprise ap-plications [11], grid computing [2], embedded systems [3],sensor networks [18], and even home networking [9]. A Jini

∗This research was supported by NSC grant NSC94-2213-E-019-008and MOEA project 95-EC-17-A-01-S1-034

service can place its own proxy object in any Lookup ser-vices in order to register to offer itself for use to Jini clients.Any client looking for a service finds Lookup services andreceives a service proxy from any available Lookup ser-vices. Afterward, the client can request the service directlythrough the service proxy.

The .NET framework is Microsoft’s initiative to delivera new way of building and deploying applications and ser-vices [8]. Specifically, .NET remoting provides power-ful remote interaction among objects and hence enablesdevelopers to build widely distributed applications easily,whether application components are all on one computeror spread out across the entire world [14]. .NET remotingprovides an abstract approach to interprocess communica-tion that separates remote objects from a specific client orserver application domain and from a specific mechanismof communication. As a result, it is flexible and easily cus-tomizable.

Jini and .NET are the two most popular distributed com-puting environments nowadays. Although these technolo-gies are implemented quite differently and are based on dif-ferent philosophies, they are remarkably similar in manyways. However, they are not compatible. In other words,clients in Jini can not request remote services from .NETsystems and .NET clients can not find Jini services. Thispaper presents an approach to make Jini and .NET interop-erable. Specifically, Jini and .NET services can now makethemselves visible to both Jini and .NET clients by register-ing to the Jini Lookup services, while Jini or .NET clientscan locate Jini or .NET services through the Lookup ser-vices and then make requests directly to Jini or .NET ser-vices. Furthermore, since requests to services are in factinitiated through proxies, clients will not be able to tellwhether they are connected to Jini services or .NET ser-vices.

In addition to the issue of interoperability for Jini and.NET, another important topic is dynamic load-balancingamong Jini and .NET services. Since the prototype im-plementations of Jini and .NET do not provide any load-

balancing mechanism [15, 17], programmers have to explic-itly incorporate code in clients to communicate with load-balancing systems. Couples of load-balancing systems havebeen proposed and analyzed, and clients in these systemsmake requests to the load-balancing systems [4, 5, 7]. Inother words, the process of load balancing is not transpar-ent to clients. As a result, the clients in these systems willlook significantly different from the clients in the originalJini system. This paper proposes a smart proxy architectureas a remedy [10, 12, 13]. A Jini or .NET client can eas-ily switch to any less-loaded Jini or .NET service through asmart proxy without knowing it.

In order for a smart proxy to decide if a client shouldswitch from the current service to a less-loaded Jini or .NETservice, the load information of services is stored in the Ser-viceTable on Jini Lookup services. A smart proxy will con-sult the ServiceTable to choose an appropriate Jini or .NETservice for the client according to its load-balancing strat-egy. As a result, the switching process is transparent tothe client. Several strategies have been developed and theexperimental results demonstrate these strategies can dis-tribute loads evenly.

Since smart proxies of clients consult the ServiceTableon Lookup services before making requests, services mustperiodically report their load information to the Lookup ser-vices. However, such update actions will introduce extranetwork communications. This paper presents an easy wayto reduce such extra overheads—a service updates its loadinformation when it renews its lease with Lookup services.

The main results of this paper are as follows:

• This paper integrates Jini and .NET. Jini and .NET ser-vices can now make themselves visible to both Jini and.NET clients by registering to the Jini Lookup services,while Jini or .NET clients can locate Jini or .NET ser-vices through the Lookup services and then make re-quests directly to Jini or .NET services.

• This paper presents a dynamic load-balancing mecha-nism for Jini and .NET, which is based on the smartproxy architecture. A Jini or .NET client can easilyswitch to any less-loaded Jini or .NET service whenthe current service is over-loaded.

• The load information of services is stored in Lookupservices, and is updated when services renew leaseswith Lookup services. Consequently, updating load in-formation does not incur additional network communi-cations.

The rest of this paper is organized as follows. Section 2briefly overviews main features of the Jini and .NET, andSection 3 introduces the smart proxy architecture for dy-namic load-balancing. Experimental results will be pre-sented in Section 4, and Section 5 concludes this paper.

2. Background

This section provides brief descriptions of the Jini and.NET.

2.1. Jini

Jini is a Java-based connection technique developed bySun Microsystems that can be used to build a flexible net-work of resources and services to be shared by a group ofclients [1, 6, 19]. It provides the necessary protocols forservices to register themselves with Lookup services andfor clients to discover services.

2.1.1. Jini Proxies

Proxies play an important role in the Jini system. They actas the gateway to remote services. That is, they deal withany network-related functions for clients, transmitting anyparameters to remote services and receiving any return val-ues from the services.

Service Proxy Object

Discovery request

Discovery Response

LookupRequest

Lookup Response

Jini ClientLookup Service

Figure 1. Service Registration

Service Proxy Object

Discovery request

Discovery Response

LookupRequest

Lookup Response

Jini ClientLookup Service

Figure 2. Service Lookup

A Jini service can place its own proxy object in anyLookup services in order to register to offer itself for use

ServiceProxyObject

Jini Client Jini Service

Figure 3. Service Request

to Jini clients, as shown in Figure 1. Any client lookingfor a service finds Lookup services and receives a serviceproxy from any available Lookup services (Figure 2). Af-terward, the client can request the service directly throughthe service proxy, as depicted in Figure 3.

2.1.2. Leasing

Jini deploys the notion of leasing to allow clients and ser-vices to leave easily without disrupting other members.Jini’s leasing model sets time limits that services are avail-able to clients. A Jini member offering a resource does sothrough a lease, which represents a period of time which theservice is available. As a result, a service usually periodi-cally renews its lease with the Lookup service.

2.2. .NET

.NET is a set of Microsoft software technologies for con-necting information, people, systems, and devices [15].

2.2.1. C#

C# is a new programming language designed for building awide range of enterprise applications that run on the .NETFramework. It is simple, modern, type safe, and object ori-ented. C# is very similar to Java syntactically and can beinteroperable with Java via bridging tools such as JNBridge.

2.2.2. .NET Remoting

Microsoft .NET remoting provides a framework that allowsobjects to interact with one another across application do-mains [14]. The framework provides a number of services,including activation and lifetime support, as well as com-munication channels responsible for transporting messagesto and from remote applications. .NET Remoting has a log-ical and cohesive object model that facilitates both simpleconfiguration changes and advanced extensions to the .NET

Clients

Proxy

formatter

transport

server

dispatcher

formatter

transport

channelservice

crosscontextchannel

servercontexterminator

leasesink

stackbuilder

RemotingObject

Figure 4. .NET Remoting Infrastructure

Remoting infrastructure. .NET Remoting architecture isshown in Figure 4.

2.2.3. Proxies

Similar to Jini, .NET Remoting uses proxies to per-form a variety of remote task depending on the archi-tecture. In the Microsoft .NET Framework there aretwo classes that work together to form the Remotingproxy: TransparentProxy and RealProxy [16].The client of a remote object instance always commu-nicates with that remote object through an instance ofa TransparentProxy, which gives the caller the ap-pearance of the target object. TheRealProxy class isthe source of information about and communication withthe actual remote object. A caller obtains an instance oftheTransparentProxy class from theRealProxy inwhich theTransparentProxy is contained.

2.2.4. Leasing

A lease is an object that encapsulatesTimeSpan valuethat the Remoting infrastructure user to manage the lifetimeof a remote object. The Remoting infrastructure providestheIlease interface that defines the functionality. Whenthe runtime activates an instance of either a well-knownSingleton or a client-activated remote object, it asks theobject for a lease. When the client calls a method on a re-mote object, the .NET Remoting infrastructure will decidehow much time remains until the lease expires.

3. Smart Proxy Architecture

In order to distribute service requests as evenly as possi-ble, a Jini and .NET system must provide the following twofeatures:

• Services can update their load information.

• Clients can obtain the load information of services andswitch to less-loaded services easily.

This section presents a smart proxy architecture that pro-vides these two features through the leasing models andproxies of Jini and .NET. Services will periodically updatetheir load information to the Jini Lookup service when theyrenew leases, and clients will consult with the Lookup ser-vice to determine if it is necessary to switch to less-loadedJini or .NET services. This approach can perform dynamicload-balancing of Jini and .NET services while not incuringextra network communications. Figure 5 depicts the systemwith dynamic load-balancing mechanism via smart proxies.

Jini

LookupService

ServiceTable

Jini service Service ID

IP

Port

Number of Jobs

.NET serviceUpdate information

Client(Jini or .NET)

Lookup serviceProxy

Smart Proxy

Get less-loaded service

Get less-loaded service

Reference

Switch

JNBridge

Update information

Figure 5. Smart Proxy Architecture

3.1. Integrating Jini and .NET via JN-Bridge

JNBridge is a Java/.NET interoperability tool that en-ables Java code to fully participate in the cross-languagedevelopment capabilities of Microsoft .NET. Consequently,Java code can be called from .NET code and Java classescan be extended by .NET classes, and vice versa. How-ever, .NET does not implement the main feature of Jini: atrio of protocols calleddiscovery,join, andlookup. Specif-ically, .NET does not contain the Lookup services provided

by Jini. Therefore, .NET services will now have to regis-ter themselves and upload their proxies to the Jini Lookupservices.

3.2. Updating Load Information via Leases

A ServiceTable residing on the Lookup service keeps theload information of all services. Services must periodicallyreport their load information to the Lookup services. How-ever, each update action will initiate one extra network com-munication, even though the load information contains onlyfew bytes, Such an overhead can be easily avoided sincethere is already a periodic communication existed betweenany service and the Lookup service— lease renewal. There-fore, the load information can be piggybacked onto the leaserenewal object of services. As a result, no extra networkcommunications will be incurred.

3.3. Switching Services via Smart Proxies

When a client first looks for a service, it will down-load a smart proxy from the Lookup service. Afterward,the client will request a service directly through the smartproxy, which will consult the load information on the Ser-viceTable and choose an appropriate service based on itsload-balancing strategy (Section 4 will compare the effi-ciencies of several load-balancing strategies). That is, theclient can switch freely between Jini and .NET servicesas shown in Figure 5 and the process is transparent to theclient.

Host CPU Memory O.S. Clients Services

S1 P4 512M Windows 2k 2 Jini + 1 .NET 1 (Jini)

S2 P3 256M Windows XP 2 Jini + 1 .NET 1 (Jini)

S3 P4 512M Windows 2k 2 Jini 1 (.NET)

Table 1. Clients and Services

4. Experimental Results

The experiment platform consists of 3 network-connected computers, as listed in Table 1. Each computerhosts a Jini or .NET service that accepts requests from apool of 8 Jini and .NET clients. In addition, a Lookup ser-vice is hosted by the first server, S1. The configuration ofthe experiment platform is depicted in Figure 6.

Experiments have been conducted for the configura-tions with different load-balancing strategies implementedin smart proxies, as listed in Table 2.

SP0 is the original prototype implementation of Jini and.NET, which does not have dynamic load-balancing mech-anisms [15, 17]. Once a client has chosen a Jini or .NET

Jini Service Jini Service C# Service

Lookup Service

Ethernet

Client(C#)

Client ClientClient(C#)

Client Client Client Client

Figure 6. System Configuration

���������� � �� � ��� ��� ��� ��� ��� ��� �� �� ��� � ��������������

� !" #�����$%���#�����$%���&'��$%���Figure 7. Numbers of Clients Served by Ser-vices

service, it will not switch to other services at all. Figure 7shows that S1 has only 1 job all the time, while S2 and S3are requested by 3 and 4 clients, respectively. This figuredemonstrate that such a strategy leads to very unbalancedloads — the queue length of S3 is 4 times of the length ofS1.

Any smart proxy in the SP1 configuration will alwayscheck the load information of all services and then make itsclient switch to the least-loaded Jini or .NET service. How-ever, Figure 8(a) shows that the Jini and .NET system underSP1 is not balanced either. The reason is because the loadinformation of services might not be up-to-date since ser-vices only update the information when leases are due. Asa result, almost all the clients might switch to the same ser-vice that appears to be the least-loaded. Figure 8(a) revealsthat frequently all clients request the same service, whileleaving other services unoccupied. SP1UB is a variationof SP1 that services will update their load information oncean upper bound is reached, which is set to 3 in this paper.Consequently, load information of services will always beup-to-date and hence the loads are more balanced, as shownin Figure 8(b).

SP2 tries to avoid the situation of SP1 that all clients rush

Configuration Load-Balancing Strategy

SP0 Original configuration of Jini

SP1 A client always uses the least-loaded service

SP1UP A client always uses the least-loaded service;

A service updates its load information

when the upper bound is reached

SP2 A client randomly pick one of the two

least-loaded services

SP2UP A client randomly pick one of the two

least-loaded services; A service updates its load

information when the upper bound is reached

SP3 A client finds a service using a weighted voting

strategy (weight = 1/queue length)

SP3UP A client finds a service using a weighted voting

strategy; A service updates its load information

when the upper bound is reached

SP3UP SC A client finds a service using a weighted voting

strategy (weights are scaled);

A service updates its load information

when the upper bound is reached

SP4 A client finds a service using a weighted voting

strategy (weight = service rank)

SP4UP A client finds a service using a weighted voting

strategy; A service updates its load information

when the upper bound is reached

SP4UP SC A client finds a service using a weighted voting

strategy (weights are scaled);

A service updates its load information

when the upper bound is reached

Table 2. Setup of Experiments

to one same service by choosing two least-loaded servicesand then randomly picking one for request. Figure 8(c)demonstrates that the Jini and .NET system under SP2 isbetter balanced than SP1. However, the services in the Jiniand .NET system under SP2 might still have to serve up to 6or 7 clients from time to time. Similar to SP1UB, servicesin SP2UB update their load information once a pre-set up-per bound is reached, and the loads are better distributedthan SP2, as depicted in Figure 8(d).

SP3 uses a totally different strategy from SP1 and SP2.Each service Si uses the reciprocal of its queue length asits load, i.e.Li = 1/|Si|. The only exception is when thequeue of any service is empty and the queue length will beset artificially to 0.1. When a client makes a request, itssmart proxy will use a random number generator to pick a

()*+,-./0123 113 143 153 673 683 693 8:3 863 833 423 413 443 453;<=>?@>ABCDEF

G<C<@>HI<A> G<C<E>HI<A> JKE>HI<A>LMNO(a) SP1

PQRSTUVWXYZ[ YY[ Y\[ Y][ _[ ^[ a[ b[ `[ [[ \Z[ \Y[ \\[ \][cdefghfijklmn

odkdhfpqdifodkdmfpqdifrsmfpqdiftuvw(b) SP1UB

xyz{|}~����� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ����������������

�����������������������������������(c) SP2

 ¡¢£¤¥¦§©ª« ©©« ©¬« ©­« ®« ®°« ®±« °²« °®« °«« ¬ª« ¬©« ¬¬« ¬­«³µ¶·¶¹º»¼½¾

¿» ¶ÀÁ¹¶¿»½¶ÀÁ¹¶Âý¶ÀÁ¹¶ÄÅÆÇ(d) SP2UB

ÈÉÊËÌÍÎÏÐÑÒÓ ÑÔÓ ÕÖÓ ÕÕÓ ÕÓÓ Ò×Ó ÒÑÓ ÒØÓ ÒÙÓ ØÚÓ ØÒÓ ØÔÓ ÓÖÓ ÓÕÓÛÜÝÞßàÞáâãäåæ

çÜãÜàÞèéÜáÞçÜãÜåÞèéÜáÞêëåÞèéÜáÞìíîï(e) SP3

ðñòóôõö÷øùúû ùüû ýþû ýÿû ý�û ÿ�û ÿýû ÿûû ú�û úùû úúû úüû ûþû ûÿû��������� �

�������������� ������� ���������(f) SP3UB

�������� !"# !$# %&# %%# %## "'# "!# "(# ")# (*# ("# ()# #*# #"#+,-./0.123456

7,3,0.89,1.7,3,5.89,1.:;5.89,1.<=>?(g) SP3UB SC

@ABCDEFGHIJK LMK LIK LKK NOK NPK NNK NQK KRK KLK KJK JMK JIK JKKSTUVWXVYZ[\]

_T[TXVaTYV_T[T]VaTYVbc]VaTYVdefg(h) SP4

hijklmnopqrs qss rts rqs rus rvs wxs wws wys uzs urs uss sts sqs{|}~��~������

�|�|�~��|�~�|�|�~��|�~���~��|�~����(i) SP4UB

������������ ��� ��� ��� ��� � � �¡�  ¢�  ��  �� ��� ��� ��� ���£¤¥¦§¦©ª«¬­®°±² ³¤«¤ ¦µ¤©¦³¤«¤­¦µ¤©¦¶·­¦µ¤©¦

(j) SP4UB SC

Figure 8. Experimental Results

service and the service Si will be chosen with the probabil-ity of Li/

∑3

j=1Lj . Figure 8(e) shows that SP3 performs

better than SP1 and SP2. Similar to SP2UB, services inSP3UB update their load information once an upper boundis reached. In addition, SP3UB SC is a scaled versionof SP3UB, that is, the weight of the service Si is com-puted asLi = 1/(2 × |Si|). Figure 8(f) and Figure 8(g)show the loads are very well balanced under SP3UB andSP3UB SC.

SP4 is similar to SP3 and the only difference is how theload is computed. The load of service Si is its rank in queuelength, i.e. Li =(service rank ofSi). In other words, theservice with shortest queue length (ranked 3) will have aload of 3, while the busiest service will get a load of 1.Similarly, services in SP4UB update their load informa-tion once an upper bound is reached, and SP4UB SC usesthe square of the rank of service Si as the scaled weight ofSi (i.e. Li =(service rank ofSi)2). Figures 8(h)∼(j) showthat SP4 delivers even better load-balancing efficiency thanSP3.

¹¹º»¹»¹º¼¹¼¹º½¹½¹º¾¹¾¹º

SP0 SP1

SP1_U

BSP2

SP2_UB

SP3

SP3_U

B

SP3_UB_S

CSP

4

SP4_U

B

SP4_U

B_SC

Jini service

Jini service

C# service

Figure 9. Average Numbers of Jobs

Figure 9 presents the average numbers of clients servedby services under all configurations. It shows that the av-erage numbers of requests from clients to S3 and S2 in theoriginal Jini and .NET system are 4 and 3 times of the num-ber to S1, respectively. After deploying the load-balancingstrategy SP1, the situation gets worse since all clients rushto the same service that appears to be the least-loaded. Onthe other hand, it depicts that loads get better balanced whenSP2 is adopted. In addition, the average queue lengths ofservices under SP3 in Figure 9 show services are well bal-anced. Finally, Figure 9 demonstrates that the strategy usedby SP4 can lead to well-balanced distributions of Jini and.NET client requests.

Figure 10 shows the distributions of the numbers of jobson services. It reveals that under SP0 and SP1, the num-bers of jobs on servers are not balanced. On the other hand,it illustrates that under SP2, SP3, and SP4 dynamic load-balancing strategies services have spent most of time serv-ing 2 to 3 requests from Jini and .NET clients, which indi-

0

100

200

300

400

500

600

700

SP0

SP1

SP1_U

BSP2

SP2_UB

SP3

SP3_UB

SP3_

UB_SC

SP4

SP4_

UB

SP4_

UB_SC

0 1 2 3 4 5 6 7 8

Figure 10. Distributions of Numbers of Jobs

cates the Jini and .NET system is well balanced.

5. Conclusions

This paper has integrated Jini and .NET into one dis-tributed computing environment so that Jini and .NETclients can make request to Jini and .NET services. In ad-dition, this paper has presented a dynamic load-balancingtechnique for Jini and .NET services. This technique usesa smart proxy architecture to dynamically redistribute Jiniand .NET clients among Jini and .NET services based onits load-balancing strategy. In addition, the dynamic load-balancing process is transparent to clients. Several load-balancing strategies have been developed and the experi-mental results have demonstrated these strategies could dis-tribute loads quite evenly. Furthermore, the load informa-tion of any service is updated when the service renews itslease with the Lookup Service. Consequently, updating loadinformation does not incur additional network communica-tions.

References

[1] K. Arnold. The Jini architecture: dynamic services in a flex-ible network. InProceedings of the 36th ACM/IEEE confer-ence on Design automation, pages 157–162, 1999.

[2] M. Baker and G. Smith. Jini meets the grid. InProceedingsof the 2001 International Conference on Parallel ProcessingWorkshops, pages 193–198, Sept. 2001.

[3] M. Beveridge and P. Koopman. Jini meets embedded controlnetworking: A case study in portability failure. InProceed-ings of the The Seventh IEEE International Workshop onObject-Oriented Real-Time Dependable Systems (WORDS2002), pages 11–18, Jan. 2002.

[4] L.-S. Cheung and Y.-K. Kwok. The design and performanceof an intelligent jini load balancing service. InProceed-ings of 2001 International Conference on Parallel Process-ing Workshops, pages 361–366, sep 2001.

[5] L.-S. Cheung and Y.-K. Kwok. A new fuzzy-decisionbased load balancing system for distributed object comput-ing. In Proceedings of 7th International Euro-Par Confer-ence, pages 183–190, 2001.

[6] W. K. Edwards.Core Jini. Prentice-Hall, 2nd edition, 2001.[7] V. Georgiev and V. Getov. Assignment schemes for repli-

cated services in jini. InProceedings. 10th Euromicro Work-shop on Parallel, Distributed and Network-based Process-ing, pages 129–136. IEEE, 2002.

[8] S. Guest. Microsoft .NET and J2EE InteroperatibilityToolkit. Microsoft Press, 2003.

[9] R. Gupta, S. Talwar, and D. P. Agrawal. Jini home network-ing: A step toward pervasive computing.IEEE Computer,35(8):34–40, Aug. 2002.

[10] P. Ledru. Smart proxies for Jini services.ACM SIGPLANNotices, 37(4):57–61, April 2002.

[11] S. Li. Professional Jini. Wrox, 2000.[12] H.-H. Lin. Load-balancing Jini services with smart prox-

ies. Master’s thesis, National Taiwan Ocean University, June2004.

[13] H.-H. Lin, C.-H. Tu, and Y.-S. Hwang. Dynamic load-balancing of Jini services with smart proxies. InPro-ceedings of The 2005 International Conference on Paral-lel and Distributed Processing Techniques and Applications(PDPTA’05), Vol. II, pages 721–726, 2005.

[14] S. McLean, J. Naftel, and K. Williams.Microsoft .NET Re-moting. Microsoft Press, 2002.

[15] Microsoft Corp. .NET: Driving busi-ness value with the microsoft platform.http://www.microsoft.com/net/default.mspx.

[16] J. Sievert. Create a custom marshaling implementation using.net remoting and com interop.MSDN Magazine, 18(9), sep2003.

[17] Sun Microsystems, Inc. Jini network technology.http://www.sun.com/software/jini/index.xml.

[18] T. Urnes, A. S. Hatlen, P. S. Malm, and Ø. Myhre. Buildingdistributed context-aware applications.Personal and Ubiq-uitous Computing, 5(1):38–41, Feb. 2001.

[19] J. Waldo. The Jini architecture for network-centric comput-ing. Communications of the ACM, 42(7):76–82, July 1999.