I will build a prototype for a hotel reservation system outlining the way Software Configuration Management makes the job easier. Don’t worry if you are not fully familiar with the technologies used. The purpose of this application is purely for reference, so you can sit back and relax.

At this point I will use my time machine and get a screenshot for the final application so you can see how it will look like. Or, I can insert the screenshot after it finished. I think the first way seems more reasonable. This is what the public reservation site looks like:

If you like it, you can download the application from the book’s website: http://orbitalhotel.alexandruserban.com.

Now let’s get back to our time and start the development lifecycle on the Orbital Hotel product. The first phase is the specifications phase.

Specifications—Project Architecture

In order to build a software system, we need a list of requirements. What is the purpose of the system? What are the actions performed by the system and against the system? Who will use the system and how? The answers to these questions will let us identify the main parts of the system and the way these parts work together.

System Requirements

Let’s take a look at the Orbital Hotel’s reservation system’s requirements. The purpose of the reservation system is to allow guests to make room reservations. There are several room types each having a number, occupancy, price, availability, description, and image. The reservations can be made by using the hotel’s internet website, through the websites of travel agencies (third parties), or by making phone calls to the hotel’s client service. Reservations can be also made by internal client service staff who receive phone calls from guests.

When guests use the hotel’s website, they will create a user with a username and password and input their personal details such as first name, last name, address, city, zip code, state, country, phone, email address, and card number. Then they will choose a room and complete the reservation details such as arrival date, the number of nights they will be staying and the number of adults, teenagers, children, and pets. They will also be able to cancel their reservation.

When making a reservation over the phone, a guest will provide the same personal information and reservation details to the hotel’s client-service staff. The staff will create a reservation for the guest using an internal application. The staff members will also authenticate using a username and password.

Travel agencies and other third parties must also be able to make hotel reservations.

Taking a big picture about the type of system we are going to build, what we need is an application design that will be as flexible as possible. It should provide us with a variety of options like reservations through phone calls, personal or third-party websites, smart devices like PDAs or cell phones, and so on. This is where we gather the specifications and plan the system architecture. In this phase we have to consider as many aspects as we can, based on our requirements and specifications.

So, let’s see what the main existing application architectures are, and see what application architecture fits our requirements.

Application Architectures

The computer and computer programming history is a very short one in comparison with that of other industries. Although it is short, it has evolved and continues to evolve very rapidly, changing the way we live. Taking into account the architectures used at the beginning of computer programming, we can see an evolution from the single, powerful, fault-tolerant, expensive super mainframe computer applications, towards multiple, distributed, less expensive smaller machine applications, the personal computers.

During this evolution, three main application architectures can be identified:

• Compact application architecture
• Component application architecture
• Service-Oriented Architecture (SOA)

We are going to take a brief look at these application architectures and outline their characteristics.

Compact Application Architecture

During application development for the single mainframe, there was no clear separation between application layers and no reusable components were used. All the data access, business logic, and user interface-specific code were contained in a single executable program.

This traditional compact architecture was used because the mainframe computers had specific proprietary programming languages and formats for accessing and manipulating the data.

All the data access-specific procedures as well as the business logic and business rules code are written in this programming language. At the surface, a user interface is presented to the user for data visualisation and manipulation.

This application architecture works for applications that do not need data input from multiple sources and can be easily developed by a single programmer. However, this approach has several major disadvantages when it comes to building large-scale systems:

• Application components cannot be reused in other applications because they are tightly coupled and dependent on one another. Tight coupling means that in order for a piece of code to use another piece of code, it must have intimate knowledge about its implementation details.
• Being tightly coupled, a change to one component can affect the functionality of another, making debugging and maintenance a difficult task.
• The application is actually a black box; no one, except the main developer, knows what it is in there.
• Applying security is another problem because the user interface cannot be separated from the business logic components using security-specific mechanisms like authentication and authorization.
• Application integration is affected because the code is platform dependent. Integration between two such applications requires special and specific coding and can be difficult to maintain.
• Scalability issues are considered when the system grows and need to be scaled across several machines. Using this application architecture, scalability is not possible as you can’t separate different application parts across different physical boundaries because of the tight coupling.

To address the issues with the compact application architecture, the component-based application architecture was developed.

Component Application Architecture

In the component application architecture, the application’s functionality is defined using components. A component is like a black box, a software unit that encapsulates data and code and provides at the surface a set of well-defined interfaces used by other components. Since a component only needs to support a well-defined set of interfaces, it can change the inner implementation details without affecting other components that use its external interfaces. Components that export the same interfaces can be interchanged, allowing them to be reused and tight coupling to be eliminated. This makes them loosely coupled because they don’t need to know internal implementation details of one another.

This separation of application functionality using components allows the distribution of development tasks across several developers and makes the overall application more maintainable and scaleable. In the Windows environment, the most used component application architecture is the Component Object Model (COM).

Typically, components are grouped into logical layers. For example, an application uses the data access layer to access the different data sources, the business logic layer to process the data according to the business rules, and the presentation layer also known as the user interface layer to present the data to end users.

Using well-defined application layers allows for a modular design, component decoupling, and therefore the possibility for component reuse.

Data Access Layer

This architecture forms a chain of layers that communicate with one another. The base is the data access layer, which is responsible for querying, retrieving, and updating the data from and to different data sources while providing a uniform data view to the layers above.

Business Layer

Above the data access layer is the business logic layer. The business logic layer uses the uniform data provided by the data access layer and processes it according to the business rules it contains. The business logic layer doesn’t need to know from what source and how the data was obtained. Its purpose is only data manipulation and processing.

Presentation Layer

At the top of the chain is the presentation layer or the user interface layer. Its purpose is to present the data processed by the business logic layer to end users and to receive input and commands from these end users. The presentation layer will propagate these commands down the chain to the business layer for processing.

Characteristics

The component application architecture solves many software problems and it has been used extensively in the past. But because software evolves continuously, new requirements introduce new challenges.

Let’s suppose we have several applications on different platforms, each incorporating its presentation layer, business logic layer, and data access layer. We want to integrate them into a bigger distributed system, a system that spans across several heterogeneous environments. At some point, one application will need to access the data existing in another application. While components can work well in a homogenous environment on the same platform, for example COM in the Windows environment, problems appear in components working across several platforms. For example, it is very difficult for a COM component to be used from a Java application or vice-versa, mainly because they don’t speak the same language.

Integration between two or more applications running on different platforms would require a middle component-dependent intercommunication layer that is expensive, difficult to build, and reintroduces tight coupling between systems, which is what we tried to avoid in the first place. Avoiding building this intercommunication layer would require that the data exchange between these applications be done by a person who will read the necessary data from the source application and write it into the target application.

We need to integrate these systems, and maintain the loose coupling between them. What we need to do, is make these components understand each other, making them to speak the same language. This is where the concept of services and Service-Oriented Architecture (SOA) comes into play.

Service-Oriented Architecture

SOA describes an information technology architecture that enables distributed computing environments with many different types of computing platforms and applications.

To enable distributed computing environments, SOA defines the concept of services. A service is a well-defined, self-contained unit of functionality, independent of the state of other services.

Let’s see how services can be used to create distributed applications, integrate component-based applications, and make them communicate with each other. We keep our data access layer and business logic layer as they are, but we completely decouple the presentation layer so we can change it later without affecting the other layers. In order to expose the functionality of the business logic layer, we wrap it in a service interface. The service interface wraps the business logic layer components offering a point of access for any process that needs to access the business logic, whose functionality has now become a service.

Service-oriented architecture is basically a collection of services that communicate with each other. The communication can involve either simple data passing or it can involve two or more services coordinating some activity. Whatever the required functionality may be, we have now separated the functionality of applications into specific units, the services that we use to construct flexible, distributed applications.

Typically services reside on different machines. They are exposed to the outside world by service interfaces. A service provider provides its functionality using the service interfaces that are used or consumed by the service consumers. A service consumer sends a service request to a service interface and receives a service response. The following figure represents a typical service consumer-service provider request.

A service can be a service provider and a service consumer at the same time as it can consume other services. They communicate using a communication medium like a local area network for internal services or the Internet for external services. This communication medium is called a service bus.

We saw that services don’t have a presentation layer as we’ve decoupled the presentation layer from the rest. This presents an advantage because we can now use any platform able to understand and consume the service to build a presentation layer. The service interface has to provide a standard and open way of communication, a common language that both service providers and service consumers can understand, regardless of the machine type they are deployed on, their physical location, and the language in which they are written.

XML Web Services

In today’s world, the communication standard used to connect services is achieved using web services. Web services are small, reusable applications that help computers with many different operating system platforms work together by exchanging messages. Web services are based on industry protocols that include XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), and WSDL (Web Services Description Language).

These protocols help computers work together across platforms and programming languages enabling data exchange between otherwise unconnected sources:

• Client-to-Client: Devices, also called smart clients, can host and consume XML web services, allowing data sharing anywhere, anytime.
• Client-to-Server: A server application can share data with desktop or mobile devices using XML web services over the Internet.
• Server-to-Server: Independent server applications can use XML web services as a common interface to share and exchange data.
• Service-to-Service: Systems that work together to deliver complex data processing can be created using XML web services.

The following figure shows an example of services exposed using web services, which deliver their functionality to a wide variety of platforms and applications.

Service-oriented architecture provides us with the maximum flexibility in building applications. Individual services define specific application functions and interact with one another to provide the entire business process functionality.

• Encapsulation: Just as an object encapsulates its internal implementation details inside while providing public methods to external objects, services encapsulate their internal complexity and implementation from the service consumers who don’t have to know the internal details.
• Mobility: As services are independent and encapsulated, they can be deployed in any location. Since they are using the same standard communication language, they are accessed in the same way irrespective of their physical location or implementation details.
• Parallel development: A service-oriented application is built using several service layers and clients. These application components can be built in parallel by developers specialized in specific layer functionality, speeding up the development process.
• Platform independence: Service providers and service consumers can be written in any language and deployed on any platform, as long as they can speak the standard communication language.
• Security: More security can be added to a service-oriented application at the service interface layer. Different application components require different security levels. The security can be enforced by using firewalls configured to allow access only to the required service providers only by the required service consumers. In addition, by using Web Service Enhancements (WSE), authentication, authorization, and encryption can be easily added.
• Reusability: Once a service is constructed and deployed, it can be used by any other service consumer without problems related to platform integration and interoperability.

Choosing an Application Architecture

Now that we have seen the existing application architectures, we must choose one that meets our project requirements. As you may have guessed by this point, the best application architecture we can use for our project is a Service-Oriented Architecture (SOA). The SOA allows us to build a distributed system, a system that has great flexibility and interoperability with other systems on other platforms. This will allow us to build the business logic functions and expose them as services that will be used by higher functionality layers.

Choosing an Application Platform

After choosing our application architecture, we must choose a platform capable of building and supporting it. For the purpose of our system we will choose the Microsoft .NET Framework platform and build the system using Microsoft Visual Studio.NET 2005 and Microsoft SQL Server as the back-end database for storing the data.

Microsoft .NET Framework

From a Service-Oriented Architecture point of view, the .NET Framework is the Microsoft strategy for connecting systems, information, and devices through software such as web services. .NET technology provides the capability to quickly build, deploy, manage, and use connected, security-enhanced solutions through the use of web services.

Intrinsically, the .NET Framework is an environment for development and execution that allows different programming languages and libraries to work together to create Windows-based applications that are easier to build, manage, deploy, and integrate with other networked systems.

The .NET core components are:

• • The Common Language Runtime (CLR): A language-neutral development and execution environment that provides a consistent model and services to manage application execution that includes:
    • Support for different programming languages: A variety of over 20 programming languages that target the CLR, such as C#, VB.NET, and J#, can be used to develop applications.
    • Support for libraries developed in different languages: Libraries developed in different languages integrate seamlessly, making application development faster and easier.
    • Support for different platforms: .NET applications are not tied to a single platform and can be executed on any platform that supports the CLR.
    • Enhanced security: The .NET Code Access Security model provides a managed environment for application execution and security.
    • Automatic resource management: The CLR automatically handles process, memory, and thread management, enabling developers to focus on the core business logic code.

 

• • The Framework Class Libraries (FCL): An object-oriented library of classes that extends a wide range of functionality including:
    • Support for basic operations: Input/output and string management, standard network protocols, and network standards such as TCP/IP, XML, SOAP, and HTTP are supported natively to allow basic operations and system connections.
    • Support for data access and data manipulation: The FCL includes a range of data access and data manipulation classes forming the ADO.NET technology that natively supports XML and data environments such as SQL Server and Oracle.
    • Support for desktop applications: Rich desktop and mobile client applications can be easily created using the Windows Forms technology.
    • Support for web applications: Thin web clients, websites, and web services can be created using web forms and XML web services technologies that form ASP.NET.

 

In the planning phase we’ve gathered the project requirements and specifications and we’ve also chosen an application architecture. The next phase is the design phase.

Designing the System

In the design phase, we will create an application design based on the application architecture, project requirements, and specifications. Gathering all the information needed to design the system is a difficult task, but the most important step is to start writing down the first idea.

System Structure

The system will be composed from the following main component categories:

• Core components (Data Access Layer, Business Logic Layer) forming the middle-tier component layers.
• Web service components (XML Web service) forming the Service Interface layer.
• Website components (ASP.NET website) forming the front-end WebReservation application, a web presentation layer.
• Windows Application components (Windows Forms Application) forming the WinReservation application, a Windows presentation layer.

The following figure illustrates the overall system structure, outlining each system component:

As we saw earlier, one major advantage of a service-oriented application is the decoupling of the presentation layer from the business logic layer. This allows for the business logic layer being exposed as a web service to be used by other third parties to integrate its functionality into their business process.

Database Structure

The back-end database is hosted by a Microsoft SQL Server system. According to the project specifications the internal database structure will be composed of the following database tables:

• User (Contains the user accounts)
• Guest (Contains the personal details of the guests)
• Room (Contains the details of each of the hotel’s rooms)
• Reservation (Contains the details of the reservation made by each user)

The following figure illustrates these tables and the relations between them. The bold fields are mandatory (not NULL).

The User table contains the following rows: