de.fhg.igd.atlas.core
Interface LSClientService

All Known Implementing Classes:

LSClientServiceImpl

public interface LSClientService

Defines the interface to a LSClientService implementation. The LSClientService provides the functionality of the Location Server Client (LSClient) which allows a user to register and lookup locations of mobile objects.

Version:

"$Id: LSClientService.java 1913 2007-08-08 02:41:53Z jpeters $"

Author:

Jan Peters

See Also:

LSClient

Field Summary

static String

WHATIS_PREFIX The WhatIs entry key for this service.

Method Summary

LSPReply	lookup(byte[] implicitName) Lookups the given implicitName on the local SeMoA system, on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPLookup).
LSPReply	lookup(LSPLookup lookup) Processes the given lookup request on the local SeMoA system, on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPLookup).
LSPReply	register(byte[] implicitName, URL contactAddress, byte[] newCookie, byte[] currentCookie) Registers the given implicitName and contactAddress on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPRegister).
LSPReply	register(LSPRegister register) Processes the given register request on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPRegister).

Field Detail

WHATIS_PREFIX

public static final String WHATIS_PREFIX

The WhatIs entry key for this service.

See Also:

Constant Field Values

Method Detail

lookup

public LSPReply lookup(LSPLookup lookup)

Processes the given lookup request on the local SeMoA system, on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPLookup).

 
  +--localLookup
  |  
  +--proxyLookup
  |  |
  |  +--globalLookup
  |
  +--globalLookup
 

The lookup request is processed on the local SeMoA first.

If this request was not successful and a LSProxy is existent in the local LAN, it is used to process the lookup request. The proxy itself forwards the request to the corresponding LSServer in the case, that the searched entry is not found on the proxy.

If no LSProxy is existent in the local LAN, the request is processed directly by the corresponding LSServer as described.

Following reply states and bodies are possible (see LSPReply):

• ACKNOWLEDGE (LSPLookupResult body)
• IMPLICIT_NAME_NOT_FOUND (no body)

• WRONG_VERSION (no body)
• REQUEST_TYPE_INVALID (no body)
• REQUEST_BODY_INVALID (no body)

• INTERNAL_CLIENT_ERROR (no body)
• IO_ERROR (no body)

The SERVER_ERROR_FLAG of the reply is set, if the reply state of the LSServer received by the proxy had been an IO_ERROR.

The PROXY_ERROR_FLAG of the reply is set, if the reply state of the LSProxy received by the client had been an IO_ERROR.

If the proxy can be found locally, it is accessed directly through the LSProxyService interface, otherwise the request is send within the local LAN.

If the corresponding server can be found locally, it is accessed directly through the LSServerService interface, otherwise the request is send over the internet.

Parameters:

lookup - The register lookup.

Returns:

The reply to the given request.

lookup

public LSPReply lookup(byte[] implicitName)

Lookups the given implicitName on the local SeMoA system, on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPLookup).

 
  +--localLookup
  |  
  +--proxyLookup
  |  |
  |  +--globalLookup
  |
  +--globalLookup
 

The lookup request is processed on the local SeMoA first.

If this request was not successful and a LSProxy is existent in the local LAN, it is used to process the lookup request. The proxy itself forwards the request to the corresponding LSServer in the case, that the searched entry is not found on the proxy.

If no LSProxy is existent in the local LAN, the request is processed directly by the corresponding LSServer as described.

Following reply states and bodies are possible (see LSPReply):

• ACKNOWLEDGE (LSPLookupResult body)
• IMPLICIT_NAME_NOT_FOUND (no body)

• WRONG_VERSION (no body)
• REQUEST_TYPE_INVALID (no body)
• REQUEST_BODY_INVALID (no body)

• INTERNAL_CLIENT_ERROR (no body)
• IO_ERROR (no body)

The SERVER_ERROR_FLAG of the reply is set, if the reply state of the LSServer received by the proxy had been an IO_ERROR.

The PROXY_ERROR_FLAG of the reply is set, if the reply state of the LSProxy received by the client had been an IO_ERROR.

If the proxy can be found locally, it is accessed directly through the LSProxyService interface, otherwise the request is send within the local LAN.

If the corresponding server can be found locally, it is accessed directly through the LSServerService interface, otherwise the request is send over the internet.

Parameters:

implicitName - The implicit name.

Returns:

The reply to the given request.

register

public LSPReply register(LSPRegister register)

Processes the given register request on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPRegister).

 
  +--proxyRegisterPlain
  |  |
  |  +--globalRegisterEncrypted/Encoded
  |     |
  |     +--globalRegisterPlain
  |
  +--globalRegisterEncrypted/Encoded
     |
     +--globalRegisterPlain
 

If a LSProxy is existent in the local LAN, it is used to process the register request. The proxy itself forwards the request to the corresponding LSServer by using encryption respectively encoding of the request message if security options are available, using plain messages otherwise.

If no LSProxy is existent in the local LAN, the request is processed directly by the corresponding LSServer as described.

Following reply states are possible (see LSPReply):

• ACKNOWLEDGE

• IMPLICIT_NAME_NOT_PRESENT
• CONTACT_ADDRESS_NOT_EXISTENT
• COOKIE_INVALID

• WRONG_VERSION
• REQUEST_TYPE_INVALID
• REQUEST_BODY_INVALID

• INTERNAL_CLIENT_ERROR
• IO_ERROR

The SERVER_ERROR_FLAG of the reply is set, if the reply state of the LSServer received by the proxy had been an IO_ERROR.

The PROXY_ERROR_FLAG of the reply is set, if the reply state of the LSProxy received by the client had been an IO_ERROR.

If the proxy can be found locally, it is accessed directly through the LSProxyService interface, otherwise the request is send within the local LAN.

If the corresponding server can be found locally, it is accessed directly through the LSServerService interface, otherwise the request is send over the internet.

Parameters:

register - The register request.

Returns:

The reply to the given request.

register

public LSPReply register(byte[] implicitName,
                         URL contactAddress,
                         byte[] newCookie,
                         byte[] currentCookie)

Registers the given implicitName and contactAddress on an existing LSProxy and/or the corresponding LSServer in following manner (see LSPRegister).

 
  +--proxyRegisterPlain
  |  |
  |  +--globalRegisterEncrypted/Encoded
  |     |
  |     +--globalRegisterPlain
  |
  +--globalRegisterEncrypted/Encoded
     |
     +--globalRegisterPlain
 

If a LSProxy is existent in the local LAN, it is used to process the register request. The proxy itself forwards the request to the corresponding LSServer by using encryption respectively encoding of the request message if security options are available, using plain messages otherwise.

If no LSProxy is existent in the local LAN, the request is processed directly by the corresponding LSServer as described.

Following reply states are possible (see LSPReply):

• ACKNOWLEDGE

• IMPLICIT_NAME_NOT_PRESENT
• CONTACT_ADDRESS_NOT_EXISTENT
• COOKIE_INVALID

• WRONG_VERSION
• REQUEST_TYPE_INVALID
• REQUEST_BODY_INVALID

• INTERNAL_CLIENT_ERROR
• IO_ERROR

The SERVER_ERROR_FLAG of the reply is set, if the reply state of the LSServer received by the proxy had been an IO_ERROR.

The PROXY_ERROR_FLAG of the reply is set, if the reply state of the LSProxy received by the client had been an IO_ERROR.

If the proxy can be found locally, it is accessed directly through the LSProxyService interface, otherwise the request is send within the local LAN.

If the corresponding server can be found locally, it is accessed directly through the LSServerService interface, otherwise the request is send over the internet.

In the case that an update request could not be processed succesfully, because the corresponding entry has not been found, it's tried to reinitialize the entry with an init request.

Parameters:

implicitName - The implicit name.

contactAddress - The contact address.

newCookie - The new cookie.

currentCookie - The current cookie

Returns:

The reply to the given request.