LS4D Architecture
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
10/16/2008
This topic provides an architecture overview of Live Search for Devices (LS4D).
With LS4D, a search request sent from a portable navigation device (PND) must pass through an LS4D server before it is routed to the Live Search servers. The LS4D server is also known as the Live Search Provider. Communication between a PND and the LS4D server occurs by using the LS4D Protocol over HTTP. When the LS4D server receives and verifies a search request, it packages the search request into a SOAP request. The SOAP request is sent to and parsed by the Live Search Engine.
The high-level architecture, including descriptions of the LS4D protocol, LS4D Web service on the LS4D server, and software components, is described in this topic.
Architecture Diagram
The following diagram shows the architecture components of Live Search for Devices (LS4D):
.gif "Local Search for Devices Architecture")
Architecture Components
LS4D consists of the following components:
- Live Search application: an application on the portable navigation device (PND) that provides an intuitive UI and uses the LS4D API to retrieve search results from the Live Search Engine.
- LS4D Client API: the software abstraction that encapsulates the implementation of the LS4D protocol. The Live Search application calls into this API to retrieve search results from the Live Search Engine. The LS4D client API is a native (C/C++) API.
- LS4D Wire Format Encoder/Decoder: a component that translates the structure that has the LS4D request into an LS4D custom format to send over HTTP to the LS4D server. This format is used as HTTP1.1 payload for the Windows Internet Services (WinInet) request.
- LS4D Transport Layer: a component that takes both the request encoded by the LS4D protocol as message payload, the Device ID, and the Device Group ID to form an HTTP request packet. Then, it sends the packet over to the LS4D server. It also receives the response from the LS4D server.
- LS4D Server: this remote server hosts the LS4D Web service implementation that accepts Live Search requests. The HTTP requests are sent over an IP-based network. To initiate these requests, the Windows Embedded NavReady powered device must be connected to either a desktop computer by using ActiveSync Desktop Pass-through (DTPT)over USB, a Wi-Fi hotspot by using Bluetooth, or a paired cellphone, that uses GPRS to connect to an IP-based network, by using Bluetooth Dial-up Networking (DUN).
- LS4D Web Service: the LS4D Web service resides on the LS4D server. When a request is received, it logs the requester (Device ID and Device Group ID) included in the request header. If the request is permitted to pass through the LS4D Web service, it is parsed and translated into a Live Search SOAP API request that is compatible with the Live Search Engine. If the LS4D API call is not in the proper format, the LS4D Web service might return status code 401 (Bad/Invalid Request). The LS4D Web service might also cancel the request.
- Live Search Engine: the central core service provided by Live Search that is responsible for handling and responding to the Live Search requests.
See Also
Concepts
Overview of Live Search for Devices
Live Search for Devices (LS4D)