第11章Webアプリケーション開発

Web applications are used worldwide, and specific internationalization and localization requirements must be observed to facilitate the creation of web applications that people all over the world can use. This can be challenging. To meet internationalization and localization prerequisites, services and products must be flexible to compete in international markets. This includes having the malleability to adapt to the cultural needs of target markets around the world. In global markets, language barriers are just one internationalization and localization issue that must be considered for web applications.¹

The Web transitioned from its 1.0 phase, where the primary usage was viewing content composed of text and images, to its 2.0 phase of user interaction. As it evolved, three technologies dominated the Web’s programming landscape, commonly referred to as the trifecta:

• hypertext markup language (HTML): a standard markup language used to describe the structure and content of web pages.

• cascading style sheets (CSS): a standard style sheet language used to alter the presentation style of the content found in HTML (or other markup languages).

• JavaScript (JS): a scripting language that adds interactivity to web content and server-side functionality. Various other scripting languages and competing approaches were used prior to the adoption of JavaScript.

The adoption of HTML was already a given on the Web, and with the introduction of CSS in 1996, a stronger push for separating content and style was introduced so that the styling of content could be specified solely as part of style sheets rather than HTML tags. Web pages at this time mostly consisted of static content, which would be generated and delivered on the web server. Essentially, the user would select an action in their browser that sent an HTTP request to the server such as the following:

• When clicking a hyperlink on a web page, the browser would send an HTTP GET request to the web server. This request asked for a specific resource (such as a web page or an image), and the server would respond by sending the requested data back to the browser.

• When filling out a form on a web page and clicking the submit button, the browser would send an HTTP POST request to the server. This request included the data that was entered (like a username and password), and the server processed it and responded accordingly.

1 To learn more, check out Lionbridge’s blog (https://openstax.org/r/76Lionbridge) post about globalization.

Essentially, the web server performed all the HTML content rendering on the server side, and the client (web browser) would present what it received. The browser in this model acts as a thin client, as it has minimal functionality. Figure 11.4 illustrates the components of a traditional Web 2.0 architecture using Java-based technologies. Notice the shift in user interaction with the website compared with a Web 1.0 website. Also note that users are able to interact with applications via an application server that can retrieve data from a database or file system. This enables support for managing web sessions that allow navigation across multiple pages.

Many of the original web applications were stateless, meaning that prior requests had no bearing on future requests. For example, it was not possible to create a shopping cart as part of a web session that would keep track of the session and what was purchased on a site and maintain the state (i.e., content in this case) of the cart. In contrast, a stateful application is software that maintains the state of an application over time, while in the case of a stateless application, state is not maintained by the system and previous actions do not impact future ones. Stateless applications are simpler and easier to implement and maintain but offer limited functionality.

As previously mentioned, Web 2.0 was partly driven by user demand for more interactive functionality. Interactivity requires maintaining some state (e.g., the web session and the content of the cart as per the previous example), thereby increasing the system’s complexity. This increased the demands on the web server for almost all the processing needed to generate and present the website content. Increased functionality led to more complex systems, and a clear separation of responsibility between the website’s rendition, business logic (i.e., the logic implemented as part of the web application), and persistence layers were needed to improve the quality and performance of the website while leveraging engineering expertise in given domains.

As you learned in Chapter 10 Enterprise and Solution Architectures Management, the Model-View-Controller pattern is tailored to address this separation of responsibility. In the MVC pattern, the Model is the persistence layer responsible for data storage and retrieval. It has a well-defined API that the Controller uses. The View is the presentation layer that handles the user interface. Finally, the Controller acts as the business logic layer that performs processing and enforces rules to generate applicable content within a given application domain and separates the user interface from the data. It also has a well-defined API that the View understands. The best-practice design concept used to create software systems in a way that ensures weak associations with other components is called loose coupling. This concept allows for separation of concerns between components, which leads to maintaining high cohesion within websites’ functionalities. MVC components are loosely coupled in that the various components can interact with one another to access the specific functionalities provided by each component. High cohesion ensures that everything that is needed to provide a specific functionality is included in one of the components. For example, on a banking website, functionality for deposits and withdrawals may be collocated on the server within the same component to ensure high cohesion; however, features for applying for a loan may be located within another component. Three popular server-side web application frameworks that implemented the MVC pattern were Apache Struts, ASP.NET, and Ruby on Rails.