1. Request level load balancing: Each request of a client might be directed to a different service. This requires the service to be stateless and involves an additional level of indirection, means an additional instance that takes a request and forwards it to the least loaded server. 2. Session level load balancing: The session level load balancing is carried out only while requesting a service. Once the service is returned to the client all subsequent calls are directed to this component. The service only takes part in further load balancing once the session has been closed. The responsible object in the K2 Component Server is the Trader/Arbitrator.

K2 provides load balancing at both session and request level depending on state of the object. If the object is stateless then load balancing will be done at request level otherwise it is done at Session Level.

The trader is responsible for the session level load balancing. The purpose is to find a service offer that matches the query requirements. There are two possible scenarios. Either the client is querying for a factory that is able to create a new session component or it queries for a service that is registered as a Session Component in the Trader. In the latter case the Trader takes care of finding a Session Service that is currently not involved in another ongoing session.

The Load Balancing Algorithm can be individually assigned to a particular Service Type, as they are stored in the Service Type Repository. The default algorithm used is a mixed random and load based selection. The algorithm first makes a random selection throughout its potential offer space and selects one offer. In case the load for the server that implements that offer is below a certain threshold the offer is returned to the client. In the other case the Trader selects randomly another offer and checks again for the load.

Request level load balancing requires an additional layer of indirection. In K2 this layer is implemented in a MultiProxy stub, that means the load balancing for stateless objects is carried out be the client itself. The MultiProxy stub is initialized with a complete offer list as returned by the Trader. A client is making a request on the MultiProxy stub as it would be on the normal stub. The MultiProxy stub will first randomly pick one of its stubs and then delegate the request to this selected one. The MultiProxy stub does not depend on load information as it is costly to transfer the load information to a client.