Application of XML in Location Based Service
4 SERVICE METADATA The Service metadata basically provides the information regarding Web Service we design. In a Web Services environment, a Web Services Description language (WSDL) file describes the web service in a machine-readable format so that the service can be explored by other web service. WSDL also explains how the service is evoked and what is return by the service. WSDL files define input and output properties of any service and its protocol bindings. WSDL files are written as XML documents. WSDL is used for describing and locating Web Services. Web Services are defined by the four major elements of WSDL, “portType”, “message”, “types” and “binding”[4]. Element portType defines the operations provided by the Web Services and the messages involved for these operations. Element message defines the data elements of the operations. Element types are data types used by the Web Service. Element binding defines the communication protocols. By using WSDL, a Web Service will have the following benefit: -
There are two ways to create a Web Service. The first approach, which is known as the Top Down Web Service, let developers generate WSDL file through programming language code. In our framework, we let Apache Axis to generate our WSDL file by default, so that we can speed up our development process. Another approach is the Bottom Up Web Service, which will need the developer to create their WSDL file manually. From the WSDL file, Apache Axis will generate the Java code using its WSDL2Java tool. We figure out that the Bottom Up approach is the better technique and more suitable for developing an enterprise services such as LBS, As WSDL can be generated from our Unified Modeling Language (UML) diagram which will give us the whole picture about all the project. Some commercial tools, such as Altova XMLspy provide modules and graphical interface for creating WSDL. In terms of integration with other service, a concept called service chaining was introduced. Web Services are actually components, which is similar to Microsoft COM+, CORBA and Java Beans. It promotes reuse, which means that it is accessible through the web. A Service Chain is defined as a sequence of services where, for each adjacent pair of services, occurrence of the first action is necessary for the occurrence of the second action. When services are chained, they are combined in a dependent series to achieve larger tasks. Three types of chaining defined in ISO 19119 and OGC [5]: -
Basically, chaining can be done by accessing the WSDL file of the required service. From there client stubs can be automatically generated. In Apache Axis 2, stubs were used to simplify the process of writing client code, as stubs contain information on service interface, method to retrieve the stub to a standard endpoint and their implementations in Java code. 5 DATA TRANSFER AND TRANSFORMATION The communication between web services is carried out by passing XML messages wrapped in an interoperable container to allow the messages to cross different networks, use different application architectures and systems. The wrapping mechanism is known as SOAP. SOAP is best thought of as a standard sized envelope, which keeps the contents of the message secure and also guarantees the message will be deliverable through a standard letterbox. A SOAP message consists of an envelope containing an optional header and a required body, as shown in figure 3. The Envelope is the top element of the XML document representing the message [6]. The header contains blocks of information relevant to how the message is to be processed. This includes routing and delivery settings, authentication or authorization assertions, and transaction contexts. The body contains the actual message to be delivered and processed. It is a container for mandatory information intended for the ultimate recipient of the message. Anything that can be expressed in XML syntax can go in the body of a message. SOAP defines one element for the body, which is the Fault element used for reporting errors. SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules  FIGURE 3 SOAP STRUCTURE To make use of SOAP in an OpenLS system, the XLS envelope that is defined in XLS.xsd must be put inside the SOAP body [7]. The XLS envelope is the top-level element in the XLS schema. It contains Request and response header element as well as request and response body element. Depending on the service requested such as directory, geocode, presentation and others, the XLS request element must contain proper type of desired service and uses proper namespace according to the service schema. Figure 4 shows the basic structure of XLS envelope. Figure 5 and figure 6 shows the request and response element for directory service respectively. Notice that the request provides basic information of generating query to the database, while response element returns the information from the database using shared element defined in location ADT.  FIGURE 4 XLS ENVELOPE  FIGURE 5 DIRECTORY REQUEST  FIGURE 6 DIRECTORY RESPONSE |