Guía Javañol – Práctica 3

El objetivo de esta práctica es crear un servicio accesible por red que permita reservar plazas hoteleras sobre un hotel imaginario durante un mes. Este servicio será consumido por una segunda aplicación Java que actuará de cliente y que interactivamente permitirá al usuario realizar operaciones sobre el sistema de reservas.

Requisitos funcionales

Las reservas siempre serán sobre días completos desde las 12 am hasta las 12 am del día siguiente. Aunque una reserva implique dos días, sólo se considerará que hay una reserva por día y es aquella que tiene la habitación reservada, por ejemplo a las 19h. Se entenderá que todas las habitaciones son dobles, con un único precio base por habitación.

El hotel tendrá dos tipos de habitaciones, normal o suite, con precios diferentes por tipo. También con dos tipos de régimen cada una de ellas: media pensión o completa.

El régimen representará un % de incremento sobre el precio de la habitación. Una reserva será para sólo una habitación. Actualmente el hotel sólo dispone de 5 habitaciones regulares y 2 suites.

Requisitos técnicos

El cliente y el servicio intercambiarán información mediante algún sistema de serialización de objetos, por ejemplo JSON. Tanto el servidor como el cliente usarán Sockets TCP/IP para establecer la conexión y poder intercambiar documentos. Los datos de las habitaciones disponibles, reservas y precios provendrán de una base de datos SQL usando JPA y QueryDSL.

Para la gestión de disponibilidad se debe implementar un calendario usando cualquier estructura de información que permita saber qué habitaciones hay libres cada día de agosto. Se debe incorporar algún mecanismo de sincronización que garantice que NO se hacen dos reservas sobre la misma habitación en los mismos días.

El servidor debe exponer las siguientes operaciones:

  • availability Devuelve el listado de TIPOS de habitaciones disponibles entre dos fechas. Cada registro devuelto debe contener el TIPO de habitación al que hace referencia y una lista de los regímenes posibles para la habitación indicando el precio estándar por día para ese régimen (y ese tipo de habitación). Si no hay ninguna habitación disponible de un tipo, obviamente ese tipo se debe omitir en la respuesta.Entradas:
    • from LocalDate
    • to LocalDate
    • roomType Tipo de habitación (opcional)Salidas:
    • Objeto de tipo HotelAvailResponse con la disponibilidad contenida dentro.
  • valuate Valorar una disponibilidad. Es decir, dadas dos fechas, el tipo de habitación y el régimen solicitado, obtiene el precio total de la posible reserva. Devuelve error si no está disponible.Entradas:
    • Objeto validado del tipo PreBookingRequest con todos los campos obligatorios.
      • from LocalDate
      • to LocalDate
      • roomType Tipo de habitación
      • mealPlan Tipo de régimenSalidas:
    • Objeto de tipo PreBookingResponse conteniendo los parámetros de entrada, más un timestamp de cuándo se realizó la operación y el precio de la posible reserva.
  • confirmation Realiza la reserva. Dadas dos fechas, el tipo de habitación, el régimen escogido y el código de cliente (un String cualquiera). Ejecuta de nuevo una valoración y si tiene éxito bloquea dicha habitación durante los días indicados. Devuelve información acerca de la reserva: el precio final, el identificador de la habitación y el identificador de la reserva. Esta operación debe modificar el calendario y la tabla de reservas.Entradas:
    • Objeto validado del tipo BookingRequest con todos los campos obligatorios.
      • from LocalDate
      • to LocalDate
      • roomType Tipo de habitación
      • mealPlan Tipo de régimen
      • customer Tipo de String que identifica al clienteSalidas:
    • Objeto de tipo BookingResponse que contiene toda la información de la reserva.
  • cancellation Dado un identificador de una reserva, libera la habitación para las fechas de la reserva dejando el calendario y la base de datos actualizada.Entradas:
    • bookingId Identificador de la reservaSalidas:
    • Confirmación de la operación realizada correctamente o error si no se encuentra la reserva en el sistema.
  • bookings Listado de reservas, con posibilidad de indicar un rango de fechas opcional como filtro. Devuelve el listado de reservas confirmadas no canceladas. Produce la misma información que la confirmación pero con aquellas reservas que estén en el intervalo.Entradas:
    • from LocalDate para el inicio del rango
    • to LocalDate para el fin del rangoSalidas:
    • Listado de reservas en forma de Collection<BookingResponse>.

Notas de implementación

ara facilitar el inicio del proyecto, el programador deberá definir cómo serán los do- cumentos que intercambiarán el servidor y el cliente. Como guía se deja una posible definición del documento de respuesta de disponibilidad en JSON indicando qué clases Java producen tal documento.

La respuesta de disponibilidad esperada por el servidor debe contener el siguiente formato:

{  "availability" : [
   {
     "roomType" : "regular",
     "prices" : [
        {
          "mealPlan" : "MP",
          "dayPrice": 100
        },
        {
          "mealPlan" : "PC",
          "dayPrice": 150
        }
      ]
    }, {
      "roomType" : "suite",
      "prices" : [
        {
           "mealPlan" : "MP",
           "dayPrice": 170
        },
        {
           "mealPlan" : "PC",
           "dayPrice": 200
        }
       ]
    }
  ]
}

El anterior mensaje JSON será generado automáticamente de la serialización del siguiente modelo Java:

public class HotelAvailResponse{
    private List<RoomAvail> availability;
    /* getters and setters */
}

public class RoomAvail{
    private String roomType;
    private List<RoomPrice> prices;
    /* getters and setters */
}

public class RoomPrice{
    private String mealPlan;
    private Float dayPrice;
    /* getters and setters */
}