Serving XML with JSP
Today's E-Commerce Sites Must Interoperate with Software Components of All Types, Not Just Web Browsers
Original: Duan Yunjian / Willie Wheeler
Blueski.xlt 01/01/15 compile you
Download All Contents All Contents (427K) Download Programs and Additional Documents (250K)
For each successful e-commerce site, two main requirements should be satisfied: 1 has practical usability; 2 Interoperability in different computing environments.
From a range of availability, various web applications, such as e-commerce sites, which seem to be different from desktop-based applications. Now we can unfortunately see that the desktop app is full of mediocre or even worse content, and there is no good availability, this may be because the customer's money has been paid before discovering the problem. However, in web applications, mediocre products are already a glimpse, while other sites will join the competition ranks at any time. On the other hand, e-commerce systems must work together with other systems. These systems are distributed on a wide variety of hardware and software platforms. Includes those desktop computers, PDAs, cellular phones, and more with large small displays. In this highly competitive industry, no company is willing to take the risk of customers or potential business partners because of "incompatible". In addition to the above two aspects, e-commerce sites should provide dynamic content because commercial data is clearly dynamic. How to combine these requirements and have become a real challenge. For example, the standard mode of dynamic content is to dynamically generate HTML on the server, and then send it to the client, we assume that there is a browser. This may violate usability because HTML does not provide a sufficiently rich operation control when developing user interfaces. Also this also violates interoperability because customers may use other devices without browsers.
In this article, we will explore a way to meet usability, interoperability, and dynamic content requirements, thereby meeting all e-commerce development project requirements. Our approach is to serve XML (Serving XML with JSP) using JavaServer Pages (JSP). We will demonstrate these concepts through a simple e-travel tour service site. We will use JSP to generate dynamic content, use XML to help complete the availability and interoperability.
Figure 1 Welcome to D & W Travel Zoom!
To run these code, you have to do a lot of things, but all is free.
First, you need a web server with a JSP engine, we recommend apache's Tomcat3.1 (http://jakarta.apache.org/tomcat)
He has Windows, Solaris, and Linux versions. (If you use Tomcat, remember to set the Java_Home environment variable, let it point to the path where the JDK is located, then add our path to the application called DW-Travel.) Second, you need a support XSL ( XSLT's browser, there is only one option: Microsoft Internet Explorer 5 (www.microsoft.com/windows/ie). No NetScape (even Netscape 6 preview version 1) is fine. (However, this does not violate our statement about interoperability, please continue to be optimistic about it)
Third, you need Java Plug-in (www.java.sun.com/products/plugin) because our app contains a Java 1.2-based applet. Fourth, code requires the use of Sun's Project X XML Parser (www.java.sun.com/products/xml). (Any W3C-compatible DOM Parser is working, but you need to make a little modification on CITYDAO.JAVA, because you have used different Parser.)
Finally, of course, you have to download these code.
Figure 2. Choose a city zoom
Introduction to D & W Travel Site
D & W Travel Service is a virtual E-Travel service that helps visitors from global visitors to plan their itinerary.
If it is a very mature version, she will get a perfect tourist plan through some graphical interfaces. The purpose of this article is that as long as it can provide sufficient functional development, it is possible to satisfy the user. When a user visits, she sees a friendly page, which allows you to log in or register a new account, find a hotel, or look at the user usage rules (see Figure 1).
In fact, we only provide "Find Hotels" features. Other features are just one look. If you click, the result is returned to the main page, or a prompt to return an incorrect connection.
Figure 3. Here is your hotels zoom in.
When the user selects "Find Hotels", she will be brought into the second page (shown in Figure 2). She can choose a city from the map. If she doesn't have a city in the place where she is hit, I will not happen. If you click on the right city, then you have chosen the city, and if she hits the place is a region with a lot of cities, then there will be a dialog. The appearance and ask you to choose an exact city.
Figure 4. Choose a city zoom!
Once the user selects a city, she can see the third page, which lists all the hotels in the city (see Figure 3). In our site, only 3 hotels in 3 cities: Los Angeles, San Diego and Pittsburgh. If you choose another city, the hotel list will be empty. .
Figure 5. Class Diagram zoom in!
Application Frame Structure Our Application (Translation: The following is no longer translated into 'application') Use a standard 3-Tier structure (see Figure 4). The layers are logical instead of physical physics. The first layer is a representation, allowing the user to see Application data. The intermediate layer consists of business objects and Application logic, which provides a well-defined interface, indicating that the layer can easily access, thereby adapted to various requests in business services. The third layer is a data layer, which maintains the business object persistence. Usually the data layer is one or more databases, but the text files in our example are enough. The 3-layer model is more flexible and retractable than traditional Client / Server structures, so this is also the reason why we use it.
In our Application, the first layer includes a browser, Java Applets, and a corresponding Application (some are Java based, some are not). In this article, we choose the IE5 and Citymapapplet map.
In the second layer, we have Java-based Web Application, which uses the Model-View-Controller (MVC) type, which will be elaborated in the next section. In the third layer we only use a file, including hotel data. (Our Application also includes an XML file, which contains urban data, but we can also treat it as a web document, because it exists in the root of the web app document, customers can directly point to it. ).
Indicates that the layer sends a message to the intermediate layer, (by http request), the intermediate layer is reply with XML, or is stored (provided by the XML file), or is dynamically generated (provided by JSP). We can see that using XML instead of HTML means that we can get dynamic content without having to sacrifice availability and interoperability. (Figure 5 is a class diagram of D & W Travel Site) Web Repayment
Application will generate two types of data for users. First, urban data, including name and related data. This is static. If the customer issues a request for urban data, we don't have to choose which data should be sent, we will issue all the data. So, we put the data directly in a file. The second is the hotel data, including the name, address (sometimes city name) and phone number. This is dynamic data. Because the customer requests different cities will get different hotel lists. So we need to use different strategies, need a server-side mechanism to read the hotel data, decide which needs to be issued and then issued. Although we can also define a static file for each city, but if you have changed, modify programs or processes will be difficult. OK. Now let's explain the mechanism of server-side that serve the customer data request. In a standard MVC-based Java-based Web Application, JavaBean and the rear end of the model (possibly Database, or Enterprise JavaBeans) to establish a connection. The HTML page and JSP page are views (View). The servlet or JSP front end component constitutes a connector Controller. (More specifically, please refer to JavaPro 2000/4: "Divide and Conquer Your Workflow with JSP") As we pointed out in the beginning, this approach is still a certain difficulty, customer The end must be HTML, which limits usability and operability. We don't use this way, because the D & W Travel site has an applet (does not have a usual HTML-Parsing performance), which requires city data from the web app. Looking forward to the future, it is clear that serrving html can meet the interoperability requirements we mentioned, and new customer electronic devices will be more and more. The solution is to put the data as an XML that is not processed without formatting, without having to format HTML. If the data is static, such as our city data), we can use the XML file directly. If the data is dynamic (like our hotel data), you can use JSP to dynamically generate XML. This is what D & W Travel site is done. Let us take a look at the web layer in detail: All hotels relating to client requests from Hotel / Index.jsp this front-end component:
By the way, we chose index.jsp as the name of the front-end component, because Tomcat defaults index.jsp as a Welcome file. Tomcat Tomcat Points URL Path / DW-Travel / Hotel / points to /DW-TRAVEL/Hotel/index.jsp. This / dw-travel / hotel / is the entrance of the Hotel module. If you don't use Tomcat, then your servlet engine may not use index.jsp as a Welcome file. At this time, you'd better make it a little more, for example:
Let's take a closer look at HotelController (view documentation). HotelController is Session-Scoped, and each customer has an independent instance. HotelController accepted command (encoded as an HTTP parameter in the customer's request), and accessed the model in such a way: executing the command, and then determined which document should reply to the client. If the client requests urban data, HotelController does not have to access the model. It simply passes cities.xml to the client, this is just a static file (see Figure 6). If the requested hotel data, HotelController will load the hotel data from the data layer (here, just hotels.txt) and load it into a vector variable of JavaBean. Then HotelController places this vector in the session domain so that the hotel-xml.jsp can process it. Finally, it sets the page to HotelS-XML.JSP, which can pass the dynamically generated XML to the client (see Figure 7).
Figure 7. SEQUENCE DIAGRAM for XML Broswer Zoom
The key to achieving interoperability is that HotelController can assume that the client can process XML. In the current various browsers, only IE5 can handle XSLT-based XML. However, the development of XML-based communications is very fast. At the same time, there is a good method, that is, developing the technology of the server-side detection customer browser type, after the detection, can be generated directly according to the different clients, either by servlet or JSP, generate HTML by the server-side XSLT or XML. This ensures that our Application can interoperate with different browser. Here, we just easily provide XML and assume that the client can process it. This discussion seems to have exacerbated only the differences between IE5 and our interoperability. However, you can use XML does not mean that HTML cannot be used.
APPLET-based representation The map in the second page is implemented with a Java Applet called a citymapapplet. It shows approximately 900 cities, most of which are accurate. (This is made by students in the course, altitude and latitude, etc.). Applet reads city data from the server and then submit it. The city is a world map (use GNU Generic Mapping Tools). It is very simple to find the functionality of the hotel to find the hotel: As mentioned earlier, the user has the interest in finding a hotel, and Application provides users with the option of choosing the city. Advocating a city, Application returns to the hotel in the city List (Figure 3). In fact, using applet is not the only solution to selecting a city, not everyone will install Java Plug-in in the browser, although anyone can download it, but use HTML to replace it seems more competitive. But on the other hand, from some people-machine interaction point of view, Applet is very good in providing multi-form interactions, so various different users require various performance and functions. Different designs have achieved a variety of different availability. Applets provides the possibility of ensuring continuous availability. Therefore, Applet is still one of the ways to develop client interfaces. Although you have been using HTML instead of applets, sometimes you need to keep the possibility of applets.
Let's take a look at how the CitymapApplet has obtained data. CityMapapplet uses a CityDao data access object to view documentation to get a city's Vector variable. CityDao.read () produced a DOM tree (that is, an org.w3c.dom.document) XML document representation, the URI: // Uri Points at cities.xml Document Document = XmLDocument, located at the cities.xml file specified by applet. Createxmldocument (URI);
Then it takes out urban data along the DOM and puts a vector variable. Finally, it returns the Vector variable.
Note that the CityMapApplet reads XML data from a static cities.xml. If a customer requests urban data, it always gets all the data instead of a subset of urban data.
Once Applet gets the city data from CityDao.Read (), it has been prepared for accepting customer input. When the user selects a city, Applet will prompt the browser to turn to a URL with urban parameters, and return to the city in XML: URL = New URL (GetCodeBase (), "../?cmd-get- Hotels = 1 & CTRY-Name = " CTRYNAME " & City-Name = " CityName); getAppletContext (). showdocument (URL);
Applet's AppletContext member is a Java represented by the APPLET in the viewer. Java has strict restrictions on the permissions of the browser (especially compared to JavaScript), but it does have permissions such as asking the browser to turn to a new URL. This is what the showdocument () method is made. Thus, in the above code, the applet does not care what the actual Application is to do, it is reusable.
We also have to brief Hotels-XML.jsp to view the documentation. In the previous Web-Tier discussion, the JSP dynamically generates XML representing a hotel provider, which is placed in the session through HotelController. Since the XML contains pure data (that is, it does not include information related to page expression), we still have a way to join the XML to join the message, we add the following to XML: This row tells the XML client, and the hotels.xsl style sheet will be used to represent XML data. In our case, the XSL translation (XSLT) will be a well-defined HTML document (Figure 8), exceptional only the label at the beginning and end needs to meet the XML standard. Converting XML to HTML seems to be the most commonly used features of XSLT. But don't forget that there are other functions, such as translation XML to Wireless Markup Language (WML), Scalable Vector Graphics (SVG), Mathml, or any other XML-based tag language. This way, if you want to support wireless users, you can convert XML data to WML only if you need an XSL style sheet. This is a huge gain in interoperability! Figure 8. XSLT in Action is magnified.
To apply an Extensible Stylesheet Language (XSL) style to process XML, the client must have an XSL processor. Currently, IE5 is the only XSL processor that is available. Although the discussion of XSL has some of the categories discussed in this article, we still have to give some content about its working principle.
XSL is a tag language that is defined by XML, which has some markers with a symbolic symbol, and some XML conversion tags. Since we are performing XML to HTML conversion, we do not use the XSL format object, and focus on XSLT. The root element of the XSL style is
XSLT is a template-based idea. You can use it to define the rules of the template, which can map the XML node to and represent the relevant templates. For example, a template rule in Hotels.xs defines an HTML template for the
< XSL: Apply-Templates SELECT = "Hotels" /> [etc.]
