See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/275275693

ARQUITECTURA DE REFERENCIA PARA PHP

Conference Paper · April 2015

CITATIONS READS
0 595

3 authors, including:

Abraham Calás
University of Information Sciences
9 PUBLICATIONS   1 CITATION   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Event data logging and extraction for process mining View project

Influence analysis in technological networks (SNA) View project

All content following this page was uploaded by Abraham Calás on 22 April 2015.

The user has requested enhancement of the downloaded file.

 ARQUITECTURA DE REFERENCIA PARA PHP

Abraham Calás Torres1 *, Katia Saria Preval 2, Ricardo E. Suarez Riquenes 3.

Facultad 3, Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½,
Boyeros, Ciudad de La Habana, Cuba.

*Autor para la correspondencia: acalas@uci.cu

RESUMEN

Una organización desarrolladora de software que pretenda llegar al máximo nivel de productividad, debe
formalizar los procesos de su dominio de solución desde el punto de vista tecnológico. Partiendo de los
requisitos tecnológicos comunes en el entorno de las soluciones, se definen las estructuras necesarias para
actuar como base de los sistemas. Esta definición se puede institucionalizar con la creación de una
arquitectura de referencia para cada plataforma tecnológica en que desarrolle la entidad. En este artículo
se propuso una arquitectura para los sistemas que desarrollen sobre PHP. Se utilizó Symfony2 como
marco de trabajo base debido a la posibilidad de ser extensible y a los numerosos esfuerzos de su
comunidad por impulsar el uso de buenas prácticas de programación. La arquitectura en capas que se
describió así como los componentes que responden los requisitos tecnológicos son parte del resultado de
la arquitectura de referencia propuesta.

Palabras claves: arquitectura, arquitectura de referencia, capas, componentes, requisitos tecnológicos.

REFERENCE ARCHITECTURE FOR PHP

ABSTRACT

A software development organization that seeks maximum productivity, should formalize the processes of
its domain solution from a technological point of view. Based on the common technological requirements
in the environment of the solutions, the necessary structures are defined to act as base systems. This
definition can be institutionalized with the creation of a reference architecture for each technology
platform in which the entity is developing. In this article, an architecture for systems developed on PHP
was proposed. Symfony2 was used as base framework due to the possibility of being extensible and the
many efforts of their community by promoting the use of good programming practices. The layered
architecture described and the components that respond to the technological requirements are part of the
result of the reference architecture proposal.

Keywords: architecture, components, layered, reference architecture, technological requirements.

INTRODUCCIÓN

La arquitectura de software es una disciplina que permite diseñar a un alto nivel la organización de un
sistema. La arquitectura de un sistema es a menudo la misma para sistemas con requerimientos similares
y, por tanto, pueden soportar reutilización a gran escala (Sommerville, 2005). Cuando se trata de precisar
una arquitectura ideal que presente todas las características deseables en un dominio de aplicación,
entonces es necesario definir un modelo de referencia. Estos tipos de arquitecturas representan un
mecanismo de información para los arquitectos de aplicaciones del dominio seleccionado. Con las
arquitecturas de referencias no solo se puede lograr una implementación adecuada, también es posible
utilizarla como base para la evaluación y comparación de sistemas de un mismo dominio.

La diversidad de tecnologías existentes, hacen difícil el entendimiento entre aplicaciones aun usando un
mismo lenguaje de programación. En el caso del lenguaje PHP existen infinidades de marcos de trabajo
que proveen un conjunto de patrones y buenas prácticas para los desarrolladores. Pero lograr que dos
sistemas desarrollados en distintos marcos de trabajo puedan reutilizar sus activos conlleva un alto
esfuerzo. Esta situación provoca que se implemente repetidamente en cada sistema un conjunto de
requisitos tecnológicos que son comunes y pueden ser reutilizados. Según Montilva et al.,
aproximadamente el 75 % de las funciones son comunes a más de un programa (Desarrollo de Software
Basado en Componentes, 2005).

El objetivo del artículo es definir una arquitectura de referencia que sirva como modelo para los
desarrolladores de aplicaciones web en PHP. El artículo en un primer momento define el patrón de
empaquetado propuesto para los sistemas que implementen la arquitectura. Posteriormente se describen
las estructuras que conforman la arquitectura de referencia y se propone un modelo para la integración de
componentes distribuidos. Finalmente, se describe como incide la arquitectura en los atributos de calidad
requeridos para las aplicaciones web de gestión.

DESARROLLO

MATERIALES Y METODOS

La arquitectura de referencia que se propone parte de algunos de los atributos de calidad requeridos en las
aplicaciones web de gestión. Se utiliza como punto de partida: la mantenibilidad, la reusabilidad, la
interoperabilidad y la escalabilidad. Para el cumplimiento de estos atributos se utilizan una combinación
de estilos arquitectónicos que incluye las arquitecturas: cliente/servidor, basada en componentes y en
capas.

Entre los estilos que incluye la arquitectura se encuentra REST, el cual fue diseñado para sistemas
hipermedias distribuidos como la Web. El término fue introducido en la tesis doctoral de Roy Fielding en
2000, quien es uno de los principales autores de la especificación de HTTP (Fielding, 2000). El objetivo
de usar el estilo REST es permitir la creación de recursos que puedan ser brindados como servicios a
través del protocolo HTTP. El uso de este protocolo garantiza la escalabilidad, ya que las aplicaciones que
se integran no necesitan conocer el funcionamiento de los servicios. Las aplicaciones entonces puedan
modificarse o remplazarse siempre y cuando utilicen los mismos recursos.

Para la definición de la arquitectura se utilizaron los cinco principios de diseño propuestos por Microsoft
en la guía de arquitectura para aplicaciones (Microsoft Corporation, 2009).

1. Separación de conceptos: consiste en dividir las aplicaciones en áreas de interés y posteriormente

componer las soluciones parciales para resolver todo el sistema. Un factor importante es la minimización
de los puntos de interacción para lograr la alta cohesión y el bajo acoplamiento.

2. Principio de responsabilidad simple: cada componente debe ser responsable de solamente una
funcionalidad o un conjunto de funcionalidades estrechamente relacionadas.

3. Principio de menos conocimiento: un componente no debe saber acerca de los detalles internos de
otros componentes.

4. No te repitas: las funcionalidades deben ser especificadas una sola vez en un componente, debido
a que la duplicación incrementa la dificultad en los cambios.

5. Minimiza el diseño abierto: solo diseña lo que es necesario. Si los requerimientos no están claros,
evita esfuerzos prematuros en diseños complejos.

Debido a que el lenguaje de programación es PHP, se escogió a Symfony 2 como marco de trabajo para la
implementación de las estructuras propuestas en la arquitectura. Se decidió seleccionar Symfony por ser
uno de los proyectos con mayor reputación en el entorno PHP (SensioLabs, 2015). Symfony es una
filosofía de desarrollo de software y cuenta con una gran comunidad que trabaja en armonía.

Para la lógica de presentación se propone el marco de trabajo AngularJS, que entre otras cosas promueve
el uso de patrones, estándares y buenas prácticas en la web (Green, y otros, 2013). Se puede señalar que
incluye una implementación del patrón Modelo-Vista-Controlador (MVC) así como de Inyección de
Dependencias. Otra característica novedosa que incluye el marco de trabajo es la posibilidad de hacer
vinculaciones entre objetos en el código con objetos visuales. Esta vinculación hace que se actualice
automáticamente uno de los lados si el otro es modificado.

RESULTADOS Y DISCUSIÓN

EMPAQUETADO

El patrón de empaquetado cuenta con tres niveles, dos de ellos responsabilidad de la arquitectura de
software y un tercer nivel relacionado con las abstracciones propias del proceso de diseño.

- Nivel Sistema: nivel más alto del encapsulamiento. Agrupa a todos los componentes y al marco
de trabajo que implemente la arquitectura.

- Nivel Componente: corresponde a la abstracción de los procesos concretos que responden a una
solución.

- Nivel Diseño: corresponde a las abstracciones de diseño (clases, librerías y otros recursos).
 Figura 1 Niveles de empaquetamiento.

ARQUITECTURA

Existen modelos formales para describir arquitecturas, pero la modelación de la arquitectura que se
presenta se hará a través de un diagrama de bloques. Las cajas representan los elementos que conforman a
un componente, y las flechas representan el flujo de datos de un elemento a otro.

La estructura de cada componente está conformada básicamente por cinco capas: presentación, servicios,
negocio, acceso a datos y datos. Cada uno de los niveles solamente puede hacer uso de los componentes
de niveles adyacentes, esta restricción posibilitará la optimización y el refinamiento de un nivel sin afectar
los otros. Dentro de las capas se adjunta del marco de trabajo Symfony 2 que posibilita la implementación
de las estructuras diseñadas.
Componentes 1 ..N

Presentación
HTML5 + CSS3 + JavaScript

Sistemas externos
Usuarios
JSON, XML,
YML

Servicios
Interfaz de servicios
RESTful

Negocio
Servicios Recursos

Servidor
Agente de Acceso a datos
servicios
Entidades
Doctrine 2
Datos

RESTful Base de
datos

Figura 2 Modelo de capas de la arquitectura de referencia para PHP.

Presentación y sistemas externos

La capa de presentación es una parte importante para una aplicación; una capa de presentación diseñada
de manera inadecuada puede conducir a demasiada complejidad, falta de flexibilidad así como también a
una experiencia ineficaz y frustrante. En esta capa se propone el uso del marco de trabajo JavaScript:
AngularJS, creado por Google para desarrollar aplicaciones web. Aunque no se desecha la opción de
emplear JQuery para el manejo de objetos del navegador y Bootstrap para estilizar las aplicaciones. Con
AngularJS es posible desacoplar completamente del servidor la capa de presentación, debido a que la
comunicación se hará a través de una interfaz de servicios. Esto garantiza que la lógica de presentación no
necesite conocer cómo se procesa la información en el servidor, solamente hace uso de los recursos
publicados. La creación de equipos que se especialicen solamente en la capa de presentación es posible,
además de permitir que toda la lógica programada sea reutilizada en caso de cambio de tecnologías en el
servidor.

La capa de presentación también incluye a los navegadores, que son los encargados de interpretar todo el
código programado en JavaScript + HTLM5 + CSS3 y mostrar a los usuarios la interfaz resultante.

De forma paralela a capa de presentación se encuentra un componente que representa a los sistemas
externos. Este componente permite que los sistemas puedan acceder y consumir los recursos que son
públicos en algunos de los formatos estándares para este tipo de comunicación (XML, JSON y YML).

Servicios

La capa de servicios es el punto de entrada hacia la lógica de negocio programada en el servidor. En esta
capa el único componente es la Interfaz de Servicios RESTful, que tiene como objetivo comunicarse
bidireccionalmente con los recursos definidos en la capa de negocio. También es papel de este
componente proveer un formato estandarizado (estilo REST) para brindar recursos a través del protocolo
HTTP. El estilo arquitectónico REST difiere de las usuales llamadas a operaciones a través de web
services. REST está diseñado para gestionar los recursos mediante las operaciones permitidas por HTTP
(CA Techologies, 2015), las más utilizadas son:

- GET: para obtener los datos del recurso.

- PUT: para modificar los valores de un recurso.

- POST: para enviar al servidor los datos de un nuevo recurso y que sea almacenado.
 - DELETE: para eliminar un recurso especificado.

Es una tarea necesaria establecer aspectos de la seguridad en el consumo de recursos, ya que puede
comprometer la integridad de los sistemas. Se propone la utilización de HTTPS para que los recursos
viajen cifrados a través de la red y el estándar abierto SAML para la autenticación de los clientes.

Negocio

La capa de negocio implementa las funcionalidades principales del sistema y encapsula la lógica de
negocio. En los componentes del sistema, esta capa es la que incluye todos los servicios que responden a
los requisitos funcionales de la aplicación. Cuando se refiere a servicios, se habla de los propios de
Symfony 2, que son clases cuyas instancias el marco de trabajo se encarga de inyectar en otros
componentes. Al ser una clase común es posible reutilizar toda la lógica que se programe aun cuando se
utilice otro marco de trabajo.

Fabien Potencier en su libro de buenas prácticas recomienda desacoplar totalmente la lógica de negocio
respecto al marco de trabajo (Potencier, y otros, 2014), por tal motivo es que se propone que toda la lógica
se programe en servicios.

Aunque los servicios contienen la lógica de negocio, el punto de comunicación con la capa superior, es
responsabilidad de los recursos. Los recursos son los objetos que se instancian para ser devueltos de forma
serializada a partir de datos obtenidos de la capa de acceso a datos o de servicios que implementen la
obtención de información. Para persistir o eliminar los datos de los recursos, se puede hacer también por
la vía de servicios o de la capa de acceso a datos.

Un recurso no es únicamente un objeto que pueda ser construido dentro de la aplicación en dónde se
encuentra definido. Puede suceder que la fuente de información para conformar el objeto se encuentre en
otra aplicación. En este caso el recurso pasa a ser una dependencia del sistema que se resolverá a partir de
la integración distribuida de aplicaciones. Este tema es mejor explicado en la sección de componentes
distribuidos.

Acceso a datos

Esta capa provee acceso a la información que almacena el sistema en sus bases de datos, y permite
también acceder a los datos expuestos por otros sistemas. En esta capa se incluye Doctrine 2, el mapeador
de objetos-relacional seleccionado por Symfony. Su objetivo es persistir información en bases de datos
relacionales, o extraer los datos en forma de objetos.
Los objetos que se persisten en bases de datos, son instancias de clases de tipo Entidad. Estas clases son
las utilizadas por Doctrine para instanciar los objetos con la información extraída de las bases de datos.
También se pueden utilizar para definir recursos que serán publicados por la vía de servicios. De la misma
forma en que se pueden brindar recursos, se provee en esta capa un agente de servicios encargado de
consumir recursos de aplicaciones externas.

Datos

En la capa de datos se encuentran las fuentes de datos de la cual se persiste o extrae información. En la
arquitectura se propone utilizar las bases de datos relacionales soportadas por Doctrine (Oracle, MySQL,
PostgreSQL, SQL Server). También es posible que los recursos externos publicados por otras aplicaciones
sean una fuente de datos.

COMPONENTES DISTRIBUIDOS

En la arquitectura se propone un modelo (Figura 3) que permita la colaboración entre aplicaciones

distribuidas de un mismo dominio.

Figura 3 Modelo de integración distribuida de recursos.

El componente Integrador es el encargado de recoger las dependencias y recursos expuestos en el entorno.

Con esta información debe ser capaz de resolver que dependencias puedan ser satisfechas con los recursos
brindados. Si una aplicación con dependencias intenta instanciar alguna, es labor del componente
Integrador informarle la dirección donde pueden ser extraídos los datos del recurso. De esta forma es
transparente a cada aplicación la ubicación de los recursos necesitados. El hecho de utilizar HTTP como
protocolo de comunicación, permite también que los recursos compartidos puedan ser generados por
aplicaciones con diferentes tecnologías.

Un problema que puede causar la distribución de recursos es la disponibilidad de los datos. Si alguna de
las aplicaciones que expone recursos deja de funcionar, entonces puede fallar el proceso que se esté
ejecutando. Para afrontar esta situación se propone que se manejen este tipo de excepciones en los
procesos que requieran de alta disponibilidad y puedan seguir funcionando aun cuando no encuentre el
recurso.

ATRIBUTOS DE CALIDAD

La arquitectura influye en los siguientes atributos de calidad:

- Escalabilidad: la web ha crecido exponencialmente sin degradar su rendimiento. En este entorno

también las aplicaciones pueden crecer de forma distribuida y no impactar en el rendimiento de
las mismas.

- Interoperabilidad: REST utiliza el protocolo HTTP, el cual es globalmente utilizado por casi todas
las plataformas tecnológicas. Mediante esta vía los componentes pueden inter-operar e
intercambiar información independientemente de la plataforma, usando un estándar conocido.

- Mantenibilidad: muchas de las buenas prácticas de la filosofía de desarrollo de Symfony son

apropiadas también para la arquitectura. Entre estas podemos encontrar la limpieza,
documentación y utilización de estándares en el código, el uso de patrones de diseño, y la
realización de pruebas unitarias. Todas estas prácticas permiten realizar cambios posteriores en el
sistema con mucha facilidad.

- Reusabilidad: la arquitectura propone la separación de los procesos a ejecutar en diferentes

componentes evitando la duplicación de funcionalidades. Cada componente debe brindar
servicios y recursos a través de interfaces que permitan esconder al re-usador la lógica
implementada. De esta forma la reutilización no se limita solo a la tecnología empleada.
CONCLUSIONES

Existen numerosas bibliotecas de código y marcos de trabajo para realizar aplicaciones web de gestión
sobre PHP. Las organizaciones que produzcan software sobre esta plataforma y no establezcan modelos
genéricos para el desarrollo, pueden afectar la reutilización, interoperabilidad, escalabilidad y
mantenibilidad de las soluciones. La definición de una arquitectura de referencia en la organización
permite llevar todos los sistemas a un mismo lenguaje. La arquitectura propuesta incluye una combinación
de estilos arquitectónicos que agregan valor a las soluciones y mejoran los atributos de calidad
mencionados.

La separación en capas de las estructuras de los componentes permite maximizar la mantenibilidad del
código y provee una división clara del lugar dónde debe ser tomada cada decisión tecnológica o de diseño.
El uso del estilo REST para el consumo de servicios a través del protocolo HTTP, permite globalizar las
soluciones más allá de la plataforma de desarrollo. Con el uso de este estilo también es posible hacer un
modelo de integración distribuida entre aplicaciones de un mismo entorno. Finalmente, es válido decir
que la arquitectura de referencia no es un modelo estático, sino un modelo extensible que promueve las
buenas prácticas de diseño y programación.

REFERENCIAS BIBLIOGRÁFICAS

Baryolo, Oiner Gomez. 2012. Marco de Trabajo Sauxe. Ficha Técnica. s.l. : Brigadas Técnicas Juveniles, 2012.

CA Techologies. 2015. A Guide to REST and API Design. [En línea] 2015. http://www.ca.com/API.

Desarrollando un framework REST sobre los componentes de Symfony2. Marqués, Asier. 2012. 2012. deSymfony.

Desarrollo de Software Basado en Componentes. Montilva, Jonás A., Arapé, Nelson y Colmenares, Juan Andrés.
2005. Mérida – Venezuela : s.n., 2005.

Eguiluz, Javier. 2012. Desarrollo web ágil con Symfony2. 2012.

Fielding, Roy T. 2000. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis. [En
línea] 2000. http://roy.gbiv.com/pubs/dissertation/top.htm.

Green, Brad y Seshadri, Shyam. 2013. AngularJS. s.l. : O’Reilly Media, Inc, 2013.

Microsoft Corporation. 2009. Application architecture guide. 2009.

 Potencier, Fabien, Weaver, Ryan y Eguiluz, Javier. 2014. Buenas prácticaspara aplicaciones Symfony. s.l. :
Librosweb, 2014.

REST vs Web Services. Marset, Rafael Navarro. 2007. 2007. Modelado, Diseño e Implementación de Servicios Web
2006-07.

View publication stats