Qué es la tasa de reposición de efectivos.

Definición de tasa de reposición.

En esta entrada te vamos a explicar qué es la tasa de reposición de efectivos, un término que en los últimos años ha estado muy de moda, pues ha sido empleado como instrumento para recortar las gastos de personal de las Administraciones Públicas. 

Posiblemente cuando hayas leido noticias del tipo "los sindicatos negocían la tasa de reposición" o "el gobierno eleva la tasa de reposición de efectivos para cuerpos prioritarios, como los relacionados con las TIC o la lucha contra el fraude fiscal" no conocieras el significado de la tasa de reposición.

La primera versión de esta entrada fue publicada en el año 2010. Hemos decidido actualizarla con fecha de 21 de Octubre de 2016.

¿Qué es la tasa de reposición?

La tasa de reposición de  efectivos no es más que el número de funcionarios que ingresan en la Administración dividido por el número de funcionarios que salen de ella por jubilación.

Una definición más formal sería "la tasa de reposición de efectivos es la ratio que determina el número de funcionarios de nuevo ingreso que se pueden incorporar en una administración pública en función de las bajas que se hayan producido en el año anterior".

Es decir, el significado de esta última definición es que se tienen en cuenta bajas, defunciones, jubilaciones, excedencias sin reservas de puesto, pérdidas de la condición de funcionario, renuncias voluntarias, etc

Para el cómputo de las plazas de nuevo ingreso se tendrá en cuenta los funcionarios que reingresen de una excedencia sin reserva de puesto, pero no los funcionarios que asciendan por promoción interna.

De todos modos, para evitar interpretaciones, lo mejor es acudir a la fuente: la Ley de Presupuestos Generales del Estado. En esta ley, que se aprueba todos los años (veremos si para 2017 también, o directamente se tiene que prorrogar la de 2016) se incluye la siguiente definición de tasa de reposición (tomada de la Ley de Presupuestos Generales del Estado para el año 2014):

 Para calcular la tasa de reposición de efectivos, el porcentaje máximo a que se refiere el apartado anterior se aplicará sobre la diferencia resultante entre el número de empleados fijos que, durante el ejercicio presupuestario de 2013, dejaron de prestar servicios en cada uno de los sectores, ámbitos, cuerpos o categorías, previstos en el apartado anterior y el número de empleados fijos que se hubieran incorporado en los mismos en el referido ejercicio, por cualquier causa, excepto los procedentes de ofertas de empleo público, o reingresado desde situaciones que no conlleven la reserva de puestos de trabajo. A estos
efectos, se computarán los ceses en la prestación de servicios por jubilación, retiro, fallecimiento, renuncia, declaración en situación de excedencia sin reserva de puesto de trabajo, pérdida de la condición de funcionario de carrera o la extinción del contrato de trabajo o en cualquier otra situación administrativa que no suponga la reserva de puesto de trabajo o la percepción de retribuciones con cargo a la Administración en la que se cesa.


Evolución de la Tasa de Reposición de efectivos en los últimos años.

Una vez que tenemos claro cual es el significado de la tasa de reposición de funcionarios, es interesante ver cual ha sido su evolución, según lo reflejan los Presupuestos Generales del Estado, para ver cómo se ha empleado este concepto como medida de recorte y contención del gasto público, con el objetivo de reducir el déficit público del estado español.


  • De 1997 a 2002, la tasa de reposición de funcionarios fue del 25 %.
  • Desde el año 2003, hasta el año 2008 la tasa de reposición de efectivos fue del 100%.
  • En el año 2009 la tasa de reposición fue del 30%.
  • En 2010, la tasa de reposición fue del 15 %.
  • En 2011, 2012, 2013 y 2014 la tasa de reposición fue del 10%, pero ¡Solo para aquellos colectivos y sectores de actividad de la administración marcados como prioritarios! Estos sectores prioritarios eran sanidad, educación, y cuerpos de seguidad del estado.
  • En 2015, al igual que en los años anteriores de la década, la norma general es que no se permite la reposición, pero para los sectores identificados como prioritarios se eleva la tasa de reposición del 10% al 50%.
  • Y finalmente, para el año 2016, el de salida de la crisis (o quizás, por haber sido un año electoralmente convulso, con elecciones autonómicas y generales, repetidas por cierto) se establece una tasa de reposición como norma general del 50%, elevándose al 100% para sectores prioritarios.
¿Cuales son estos sectores prioritarios, para los que se ha fijado una tasa del 100%?

  • Cuerpos de funcionarios docentes.
  • Plazas de hospitales y centros de salud del Sistema Nacional de Salud.
  • Fuerzas y Cuerpos de Seguridad del Estado, Autonómicos y Policia Local.
  • Militares de carrera y de complemento.
  • Cuerpos de lucha contra el fraude fiscal, laboral, de seguridad social, o fraude en general.
  • Otros cuerpos y sectores como seguridad nacional, catedráticos de Universidad, etc.

Conclusión: tasa de reposición y sueldo de los funcionarios. Merma en la calidad de los servicios públicos.



La evolución de esta tasa ha pasado a ser del 100% en el año 2007, al 30% en el año 2008 (ya entrados en la crisis económica, aunque no todos se dieron cuenta a tiempo de que estábamos en una crisis), directamente del 0% salvo excepciones hasta el año 2015.

Es decir, durante 7 años, por cada 10 funcionarios que se han ido, solo ha entrado a trabajar 1 en la Administración.

Si sumamos esta medida a la de la bajada del sueldo de los funcionarios no se entiende que el Gobierno no haya conseguido bajar el déficit público del 5%...

a no ser que a lo mejor es que en este pais el problema no era que sobraran funcionarios o que ganasen tanto dinero.

Porque de la Administración Paralela, y de los numerosos chiringuitos que mantienen nuestros políticos para colocar a los suyos, se ha hablado poco.

¿Y cómo ha afectado esto a la calidad de los servicios públicos?

 Esta situación me recuerda mucho a la que nos tocó vivir a los profesionales del sector de las TIC en el año 2001, con el estallido de la burbuja de las puntocom.

De repente, las empresas empezaron a despedir gente, muchísima gente.

Lo hacían las empresas que pasaban por dificultades, y también las que no tanto, pero aprovechaban para hacer purga, o directamente pretendían beneficiarse del incremento de "oferta" que había en el mercado laboral para buscar profesionales más baratos.

Y a los que tuvimos la fortuna de conservar nuestro puesto de trabajo, la única opción que nos quedó es volver a los tiempos de la revolución industrial, y tener jornadas laborales de 12 horas en "picos" de trabajo que se convertían en cordilleras, durante meses y meses, cobrando como si trabajase 8 por supuesto.

En aquel momento fue cuando llegué a la conclusión de que la industria de las TIC en nuestro país (o el menos el del desarrollo de software, en el que yo trabajaba) estaba muy degradada, y que prefería trabajar para el sector público en la Administración.

Esta convicción se vió incrementada cuando ví que los sueldos de los funcionarios eran unos sueldos competitivos, comparados con los sueldos del sector privado.

Diez años después, nos encontramos la misma situación, las mismas variables en la ecuación. Si de cada diez funcionarios que se jubilan, solo entra uno nuevo, quedan dos opciones: Rebajar los objetivos que se le marquen a ese nuevo funcionario, o que éste funcionario trabaje con "picos" de 12 horas.

Pero claro, uno no trabaja doce horas cobrando ocho a no ser que le amenacen con el despido (y lo hace si tiene cargas familiares, y mientras busca otro trabajo), y esto no puede pasar si eres funcionario. Así que para que la ecuación tenga solución...


¿Estamos los ciudadanos dispuestos a rebajar los servicios públicos de los que disfrutamos?

Hay otra solución. Que el ahorro que en los presupuestos de ingresos se haga del capítulo II (Gastos de Personal) se convierta en gasto en capítulo VI (Gastos de Inversión). Es decir, externalización (si no privatización) de los servicios públicos.



Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.

Herramientas CASE. Temario de las Oposiciones de Informática y Telecomunicaciones.

En esta entrada trataremos el tema "Herramientas CASE. Tipos. Estructura. Prestaciones" del temario de las oposciones de Informática y Telecomunicaciones (múltiples administraciones).

Introducción

CASE es el acrónimo de Computer Aided Software Engineering, es decir, ingeniería del software asistida por ordenador. 

Este término en su día tuvo sentido, puesto que se diseñaba software de forma manual: los ordenadores no tenían las capacidades necesarias para ayudar en los procesos de ingeniería. Hoy en día, todos los procesos de desarrollo se realizan ayudándose en herramientas informáticas.

En este tema veremos una descripción e historia de dichas herramientas, una clasificación de las mismas, y expondré la estructura general de las herramientas CASE actuales. Por último, veremos algunos ejemplos de herramientas y de sus prestaciones.

Herramientas CASE

En los años 60-70, cuando comenzaba a desarrollarse software, los sistemas se definían basándose en un conjunto de información textual.

A finales de los años 70 surgieron las técnicas de desarrollo estructurado, que permitían especificar el software de forma más precisa y concreta, basándose en técnicas gráficas. Sin embargo, para proyectos grandes, se generaban inconsistencias que eran difíciles de detectar. Además el volumen de documentación generado resultaba complicado de tratar de forma manual.

Estos problemas, junto con el aumento de las capacidades de los ordenadores, propicia el surgimiento de las herramientas CASE que se desarrollaron para afrontar los problemas de la calidad del software y de la documentación inadecuada. La idea de las herramientas CASE es automatizar los métodos existentes de la ingeniería del software, para mejorar la eficiencia y la calidad del proceso.

A principios de los 80, las herramientas CASE se utilizaban para la gestión de la documentación y para la creación de diagramas. A mediados de los 80 empiezan a integrarse herramientas que chequean las inconsistencias de forma automática, y se generalizan los repositorios centralizados con información del sistema. 

A finales de los 80 se comienza a generar código a partir del diseño. En los años 90 se generalizan las interfaces gráficas y se fomenta la reutilización de código como metodología de desarrollo.

Hoy en día la tendencia es a utilizar un IDE o entorno integrado de desarrollo, como pueden ser Eclipse o Visual Studio, sobre el que se instalan plugins o complementos que cubren las diferentes necesidades del proceso: integración con gestión de proyectos, con repositorios de código, documentación y diseño de diagramas, etc..

Tipos

En la clasificación de herramientas CASE pueden utilizarse muchos criterios diferentes, según el punto de vista desde el que las examinemos. Veremos aquí tres clasificaciones que consideramos son las más relevantes.

Según tipo de integración

Juegos de herramientas (Toolkits)

Los toolkits consisten en una serie de herramientas independientes entre sí, donde cada una de ellas sirve para realizar una función. Por ejemplo podría haber un compilador/depurador específico (gcc) un IDE para proporcionar una interface gráfica (Eclipse) y un sistema para gestionar las versiones (SVN). Dichos productos se integran pero son intercambiables.

Bancos de trabajo (Workbenchs)

Se trata de un conjunto de herramientas integradas que comparten una base de datos de soporte y una interface única. Están orientados a una metodología de desarrollo, y ayudan al usuario a seguir la misma. La salida de una de las fases metodológicas se puede utilizar directamente de entrada para la fase siguiente. Un ejemplo sería la herramienta Power Designer de Sybase

Según metodología utilizada

Metodología estructurada

La metodología estructurada fue la primera que se usó de forma extendida, y a la que las primeras herramientas CASE daban soporte. Las herramientas de este tipo permiten gestionar proyectos de desarrollo mediante la construcción y gestión de DFDs, modelos Entidad/Relación, Diagramas de módulos, etc..
TODO: Poner un ejemplo

Metodología orientada a objetos

La metodología orientada a objetos surgió con posterioridad, cuando ya las herramientas CASE estaban más maduras. Las técnicas de la MOO son muy diferentes, y están basadas sobre todo en el lenguaje UML y en el desarrollo iterativo basado en casos de uso. Hoy en día es más común desarrollar con esta metodología y con herramientas que la soportan.
También existen herramientas mixtas, que permiten soportar ambas metodologías.

Según etapa del ciclo de vida en que se usan

Otra forma de clasificar las herramientas es según en qué fase del ciclo de vida resultan de utilidad, aunque hay que tener en cuenta que muchas de ellas están integradas en suites y se aplican a más de una tarea (por ejemplo, creación de E/R y generación del SQL)

Gestión de proyectos y requisitos

Permiten realizar diagramas de Gantt y PERT, obtener el camino crítico de un proyecto, y gestionar los recursos del mismo. Además permiten realizar un seguimiento del trabajo realizado para controlar si deben realizarse ajustes en el plan.

Un ejemplo de estas herramientas serían MS Project u OpenProj.

Las herramientas de gestión de requisitos comienzan a cobrar fuerza en los últimos tiempos. Permiten recoger los requisitos, asegurar la coherencia de los mismos, y realizar el seguimiento de los mismos a lo largo del proceso de desarrollo (qué requisito afecta a qué artefacto: DFD, clase, etc)


Análisis y diseño

Las herramientas de análisis y diseño son muy diferentes según su metodología.

En metodología estructurada permiten realizar DFDs, descomposición modular de programas y modelos entidad/relación. Las herramientas más clásicas siguen esta metodología, aunque están adaptándose para permitir técnicas tanto estructuradas como orientadas a objetos, ya que cada vez la metodología estructurada se utiliza menos. Un ejemplo sería PowerDesigner, de Sybase, o Designer, de Oracle (herramienta por excelencia para hacer Diagramas ED y E/R.

Las herramientas de metodología orientada a objetos, debido a que el desarrollo es iterativo, suele haber una fuerte integración entre el diseño y la generación de código. 

Se puede generar a partir de un modelo de clases el código que le da soporte, normalmente en varios lenguajes de programación. Las herramientas más modernas como SDE permiten además que el modelo se actualice conforme se modifica el código. Un ejemplo de este tipo de herramientas sería el ya mencionado Smart Development Environment , Rational Rose o Enterprise Architect.

Programación

Las herramientas de programación facilitan las tareas de edición, compilación y depuración de código. Suelen estar integradas en un entorno de desarrollo o IDE (de Integrated Development Environment). Se incluyen en esta categoría, aparte de las mencionadas, herramientas como los editores de código con chequeo de sintaxis, los generadores de interface de usuario (editores de ventanas), generadores de consultas a bases de datos, etc.

Ejemplos de este tipo de herramientas serían Microsoft Visual Studio o Eclipse.

Integración y pruebas

TODO: ejemplo
TestLink, JUnit, JMeter, etc.

Soporte y mantenimiento

TODO: ejemplo

Otra posible clasificación según el ciclo de vida las divide en Upper-CASE (apoyo a las fases iniciales: análisis de requisitos, gestión de proyectos), Medium-CASE (análisis y diseño) y Lower-CASE (implementación, pruebas y mantenimieno).

Estructura

ver herramientas case-tema2 en los materiales

Prestaciones

Dado que las herramientas CASE están en continua evolución y cada empresa utiliza las que considera más adecuadas, no tendría sentido centrar este apartado en el uso profesional de las mismas. En vez de eso voy a mencionar algunas herramientas CASE que resultarían de utilidad en la práctica docente, mencionando dónde podrían resultar más apropiadas.

Modeling Software KIT (MOSKitt)

Es una herramienta CASE LIBRE, basada en Eclipse que está siendo desarrollada por la Consellería de Infraestructuras y Transporte (CIT) para dar soporte a la metodología gvMétrica (una adaptación de Métrica III a sus propias necesidades). gvMétrica utiliza técnicas basadas en el lenguaje de modelado UML.

MOSKitt se desarrolla en el marco del proyecto gvCASE, uno de los proyectos integrados en gvPontis, el proyecto global de la CIT para la migración de todo su entorno tecnológico a Software Libre.

Gestión de proyectos y requisitos
Análisis y diseño
Programación
Integración y pruebas
Soporte y mantenimiento

También pueden resultar de utilidad entornos web para el desarrollo de código. Por ejemplo, Google Code permite generar de forma sencilla un proyecto de desarrollo. Proporciona un servidor SVN para guardar el código, un Wiki para la documentación, y gestión de permisos para el acceso. Mediante Google Code puede generarse en unos minutos un entorno que permita a los alumnos trabajar de forma colaborativa en un proyecto tanto desde el centro como desde sus casas. El problema lo tendríamos con el ancho de banda, que suele ser limitado en los centros educativos.

Enlaces de interés.

Bibliografía

Ejemplo

  • Smart Development Environment http://www.visual-paradigm.com/product/sde/
  • ArgoUML, Herramienta de modelado UML escrito en Java (enlace externo)
  • BOUML, Ligera herramienta de modelado UML y generación de código C++, Java e IDL. Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial)
  • Fujaba, No solo sirve para modelar sino que puede generar código Java automáticamente. También es capaz de hacer ingeniería inversa y crear los diagramas a partir del código Java [1].
  • Dia Puede ser usado para modelar varios tipos de diagramas UML (enlace externo)
  • gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el navegador), que permite generar código Action Script 2.0 Compatible (enlace externo)
  • MonoUML Herramienta CASE para la plataforma mono (Sitio Oficial)
  • Papyrus, Herramienta gráfica basada en Eclipse para el modelado con UML2, es de código abierto y se ofrece bajo licencia EPL (Sitio Oficial)
  • StarUML Herramienta de modelado para Windows desarrollada en Delphi. Bastante estable y utilizable (enlace externo)
  • TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de diagramas incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial)
  • Umbrello Herramienta para modelado UML para el entorno KDE (enlace externo)
  • UMLet Herramienta para modelado rápido de UML también escrita en Java (enlace externo)
  • Netbeans módulo UML -> no acepta UML2.0
  • Existen varios programas libres para hacer diagramas de Gantt:
  • GanttProject: quizás uno de los más extendidos, está programado en Java por lo que es multiplataforma. Me parece algo lento y además la navegación por el timeline es poco intuitiva, pero viene bien para salir del paso.
  • TaskJuggler: cuenta con una inferfaz CLI y una GUI, pero parece algo complejo si sólo se quieren hacer cosas básicas. Además para cambiar una tarea el editor gráfico muestra el fichero de texto para editarlo directamente.
  • KPlato: forma parte de la suite KOffice de KDE. Parece algo verde, además no he podido ni cambiar la duración de una tarea de manera fácil.
  • OpenWorkbench: la alternativa a Microsoft Project, está programado en Java pero de momento sólo funciona en entornos windows así que no lo he podido probar, pero tiene buena pinta. Port para GNU/Linux en camino.
  • OpenProj: también desarrollado en Java y multiplataforma, es el programa que más me ha convencido. No tiene unas barras espectaculares pero es muy sencillo y intuitivo crear tareas y modificar su duración y fechas de inicio/fin y además cuenta con varias vistas del proyecto interesantes. Es un programa open-source pero no libre, pero tiene hasta paquetes debian para su descarga.
  • Planner: un gestor de projectos para el entorno GNOME desarrollado con las librerías GTK+, simple pero efectivo.

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.

El sueldo de un funcionario en 2016.

¿Cúanto cobra un funcionario?


En estos últimos 6 años, el sueldo de los funcionarios han sido un osito de peluche del que han echado mano nuestros políticos para cuadrar las cuentas públicas.


Esta es una de las primeras preguntas que toda persona que empieza a preparar una oposición se hace. Cual es es el sueldo que gana un funcionario.

Y la única respuesta es que depende. Depende de muchos factores.

El salario de los funcionarios depende de la titulación, pues no es igual el sueldo de un funcionario del grupo A1 que el de un funcionario del grupo A2 o el sueldo de un funcionario del grupo C1.

Depende también de la responsabilidad del puesto, de la dificultad del tipo de trabajo a realizar, y de la antigüedad del funcionario en el puesto de trabajo.

El salario de un funcionario depende de la Administración para la que trabaja.

Paradójicamente, los funcionarios de entidades locales han venido ganado más dinero que los de las administraciones autónomicas, y estos más que los funcionarios de la administración general del estado, que han sido siempre los peor pagados, al menos en conceptos fijos.

Está claro que quien decide preparar una oposición no lo hace por dinero. La motivación que hace falta para recorrer el duro camino de opositar no se consigue solo pensando en alcanzar un determinado nivel retributivo.

No nos engañemos, si lo que buscas es ganar dinero te has equivocado de camino. En mi opinión,  trabajando por cuenta ajena, no nos engañemos, por muy bien que te paguen el dinero lo ganarán otros.

Ahora bien, sí es cierto que el trabajo de funcionario te permite alcanzar un adecuado equilibro entre retribución, seguridad y estabilidad, independencia de pensamiento, autonomía y calidad de vida.

No obstante, una pregunta típica de aquel que se plantea opositar, sobretodo si tiene un puesto de trabajo en la empresa privada es ¿Cuanto gana un funcionario TIC? 

Es lógico y natural que quieras saber una de las variables de la ecuación que con tanto esfuerzo e interés estás tratando de resolver, la ecuación de ser funcionario.

Evolución del sueldo de los funcionarios en los últimos 6 años (2010 - 2016).


La primera versión de esta entrada la publicamos en el año 2009, y desde entonces, sigue siendo una de las páginas más visitadas del blog.

Para proporcionar la información más actualizada posible a los lectores del blog, he decidido actualizarla para que refleje todos los cambios que han experimentado las retribuciones de los funcionarios en los últimos 7 años, con tres hitos de gran importancia:
  1. el tijeretazo de ZP del año 2010.
  2. la supresión de la paga extra por Rajoy en 2012, y posterior devolución por etapas (no en todos los sitios).
  3. la subida del 1% del año 2016.

El tijeretazo del gobierno de Zapatero, en el año 2010, supuso la primera bajada de la historia del salario de los funcionarios españoles. La medida se vendió con muchísima demagogia (5 % de media, cuando a un grupo A1 se le bajó objetivamente casi un 8%).

Además, tal y como se implementó la bajada de sueldo, vino a romper el esquema salarial de 14 pagas iguales de los funcionarios (una reivindicación histórica de los funcionarios, que solo estuvo vigente durante un año). Para tratar de impactar lo mínimo el consumo, se hizo que la bajada de sueldo fuese más fuerte en las pagas extra, de tal forma que en las pagas ordinarias fue menor.

La supresión de la paga extraordinaria de Diciembre de 2012 por parte del gobierno de Rajoy fue profundizar el corte sobre la herida hecha. Vino a cargarse el consumo, en un momento crítico como la navidad, en mitad de una crisis brutal. Y supuso otro 7% de bajada de sueldo (15% acumulado para un grupo A1, sin tener en cuenta el efecto de la inflacción de esos dos años, que pudo ser de un 6% adicional).

En otras administraciones, como las de la Junta de Andalucía (gobernada por una coalición de izquierdas PSOE - IU), se siguió haciendo uso de la demagogia, afeándole a Rajoy el recorte, cuando ellos en los dos años siguientes (2013 y 2014) suprimieron el equivalente a otra paga extra completa (dos medias pagas, que quedaron reducidas al sueldo base).

Inolvidable el ejercicio de cinismo político de Susana Díaz, cuando dijo "Yo a los funcionarios andaluces les voy a devolver lo que Rajoy les ha quitado", sin decir nada de las dos pagas extras adicionales que ella les quitó en 2013 y 2014.



A estos tres hitos se suma el runrún que existe con los presupuestos generales del estado de 2016. El actual gobierno en funciones del PP, ha filtrado que en caso de conseguir la investidura, una de sus primeras medidas sería aprobar la ley de presupuestos generales del estado para 2017, en la que se incluiría una subida de otro 1% del sueldo de los funcionarios.

Cuales son los conceptos retributivos del sueldo de los funcionarios.

Las retribuciones de un funcionario vienen establecidas por el Estatuto Básico del Empleado Público (EBEP)(y antes de éste, por la legislación vigente con carácter básico sobre función pública en el estado español). 

Estas retribuciones se actualizan anualmente en el BOE, pues deben incluir las revisiones anuales salariales pactadas con los sindicatos (desde el año 2010, mucho pacto con los sindicatos no ha habido, simplemente se les ha ido informando de las bajadas y las congelaciones que se han ido aplicando sobre el sueldo de los funcionarios).

Los conceptos retributivos considerados por el EBEP son:

  • Retribuciones básicas: sueldo base y trienios

  • Retribuciones complementarias: el EBEP dice que cada Administración deberá desarrollar una ley que las establezca, para premiar el esfuerzo, dificultad, dedicación etc del puesto desarrollado. Como esto todavía no ha sucedido, se siguen aplicando las de la ley anterior: complemento de destino y complemento específico.


El sueldo base.


Según el artículo 23 del Estatuto Básico del Empleado Público, las retribuciones básicas son "las que retribuyen al funcionario según la adscripción de su cuerpo o escala a un determinado Subgrupo o Grupo de clasificación profesional, en el supuesto de que éste no tenga Subgrupo, y por su antigüedad en el mismo".

De este modo, una parte esencial del sueldo de un funcionario (el sueldo base) viene determinada por el grupo de clasificación profesional al que pertenece.

Y la principal característica de los grupos de clasificación profesional definidos por el Estatuto Básico del Empleado Público es la titulación académica oficial requerida para poder acceder a dicho grupo.

El EBEP establece la siguiente clasificación profesional de los funcionarios públicos:

  • Grupo A: Dividido en dos Subgrupos, A1 y A2. En la práctica, el grupo A1 es el equivalente al antiguo grupo A, y el A2 el equivalente al antiguo grupo B.
  • Grupo B. Para el acceso a los cuerpos o escalas del Grupo B se exigirá estar en posesión del título de Técnico Superior.
  • Grupo C. Dividido en dos Subgrupos, C1 y C2, según la titulación exigida para el ingreso.
    • C1: Título de Bachiller o Técnico.
    • C2: Título de Graduado en Educación Secundaria Obligatoria.


La ley de presupuestos generales del estado vigente, para el año 2016, establece las siguientes asignaciones económicas para el sueldo base de cada uno de los grupos profesionales de funcionarios públicos:

  • Grupo A1. El total del sueldo base bruto anual es de 14.824,22 euros. 13.440 en doce pagas ordinarias, y 690 euros en cada paga extra.
  • Grupo A2. 13.035,60 euros brutos anuales.
  • Grupo C1. 11.623,42 euros brutos anuales.
  • Grupo D1. 9.983,82 euros brutos anuales.
  • Grupo D2. 8.462,46 euros brutos anuales.
  • Grupo E. 7.755,44 euros brutos anuales.
Como se puede observar en la tabla salarial publicada en el BOE, el sueldo base de una mensualidad de paga extra es sensiblemente inferior al sueldo base de una mensualidad normal. 

El motivo es cómo se implementó la bajada de sueldo del año 2010 por el gobierno del PSOE de Zapatero. En lugar de aplicar una bajada proporcional a las 14 pagas, de tal forma que todas resultasen iguales, aplicó una bajada muy inferior en las pagas normales, y una bajada muy superior en las pagas extra. 

El sueldo base de una paga normal de un funcionario del grupo A1 es de 1.120 euros, mientras que el sueldo base de la paga extra es de 690 euros (sic). Para el grupo A2, la bajada es de 968 a 700, y así para el resto de grupos.

Los trienios.


La antigüedad se retribuye mediante los trienios, que es una cuantía fija, publicada en la ley de presupuestos generales del estado de cada año. Dentro de ellas están comprendidas los componentes de sueldo y trienios de las pagas extraordinarias.

Aquí nuevamente podemos apreciar los efectos de la bajada de sueldo "asimétrica" de Zapatero. Un trienio de paga normal suele suponer aproximádamente el doble que un trienio de paga extraordinaria.

También se producen anomalías curiosas, como la de que un trienio de paga extra de un funcionario del grupo A1 sean 26,58 euros, para el grupo A2 sea de 25,61 euros, y para el grupo C1 de 26,65 euros (¡un trienio de grupo C1 es superior al trienio de un grupo A1!).

En mi opinión, en la administración hay grupos C1 que se merecen ganar lo mismo o más que muchos grupos A1 (el factor principal para determinar la retribución debería ser la productividad, no la titulación que se posee).

Pero esto no quita a que parezca absurdo que el trienio del grupo C1 sea superiro al del A1.


Las retribuciones complementarias: complemento específico y complemento de destino.


Os preguntareis ¿qué es eso del complemento de destino? Es una cantidad del salario que depende del nivel de la plaza que desempeña un funcionario. A más nivel, más complemento. Es decir, el complemento de destino de un nivel 30 (subdirector general) evidentemente será mucho más alto que el de un funcionario de nivel 12 (auxiliar administrativo). Puede haber más de 10.000 euros de diferencia entre uno y otro.

¿Y el complemento específico? En este caso, lo que se trata de retribuir es la dificultad o penosidad concreta de un puesto de trabajo concreto (por eso lo de "específico"). Este es el factor de más peso en el nivel retributivo de un funcionario. Como veremos con algunos ejemplos, dos funcionarios de igual grupo y prácticamente igual nivel pueden tener grandes diferencias salariales por este complemento.

 Un funcionario de nivel 30 puede tener más de 20000 euros de complemento específico, por los 2000 euros de un funcionario de nivel 14.

Llegados a este punto, posiblemente sigais sin tener claro cuanto gana un funcionario TIC. Al fin y al cabo, esto de los complementos está muy bien, pero uno lo que entiende de verdad es lo que le llega al bolsillo mes a mes (o en todo caso, una cantidad bruta anual). 


La trampa semántica: no es lo mismo un complemento que un 'plus'.

Como hemos visto, el sueldo de un funcionario se compone de sueldo base, trienios, y complementos.

Aquí la palabra "complemento" la he visto empleada con muy mala leche, especialmente por los medios de comunicación afines a los gobiernos de turno que han ido aplicando las sucesivas bajadas y recortes.

Estos medios (sin paños calientes: El País, El Mundo, La Razón, ABC, Canal Sur) han sustituido la palabra "complemento" por "plus", dando a entender que son conceptos variables, sujetos a condiciones como la consecución de superavits, o determinados logros de productividad.

Nada más lejos de la verdad: son conceptos retributivos, por los que se cotiza, y que vienen a recompensar determinadas características del puesto de trabajo que desempeña un funcionario.

El sueldo base no es el sueldo del funcionario, es la parte del sueldo que solo tiene en cuenta el grupo de clasificación profesional al que pertenece.

El complemento de destino no es un "plus", es la parte del sueldo de un funcionario que mide su nivel de responsabilidad.

Y el complemento específico tampoco es un plus, es la parte que mide la especial dificultad, dedicación, incompatibilidad, etc del puesto de trabajo.

Lo mismo que a los imputados ahora se les llama "investigados", a los complementos deberíamos empezarlos a llamar "conceptos retributivos".


Conceptos variables: gratificaciones extraordinarias y complemento de productividad.


Hasta que entren en vigor las Leyes de Función Pública que desarrollen el E.B.E.P. las retribuciones complementarias seguirán siendo el complemento de destino, el complemento específico, el complemento de productividad y las gratificaciones por servicios extraordinarios.

El complemento de productividadretribuirá el especial rendimiento, la actividad y dedicación extraordinarias y el interés o iniciativa con que se desempeñen los puestos de trabajo.

Cada Departamento determinará, dentro del crédito total disponible, las cuantías parciales asignadas a sus distintos ámbitos orgánicos, territoriales, funcionales o de tipo de puesto.

Las gratificaciones por servicios extraordinarios se concederán dentro de los créditos asignados a tal fin, tendrán carácter excepcional y solamente podrán ser reconocidas por servicios extraordinarios prestados fuera de la jornada normal de trabajo.


Sueldo del funcionario del grupo A1 (antiguo grupo A).

Como hemos visto con anterioridad, el sueldo base de un grupo A1 se actualiza todos los años en la ley de presupuestos generales del Estado (a menos que se prorrogue dicha ley, como puede suceder para el año 2017, en cuyo caso se mantendrían).

Para el año 2016, un funcionario del grupo A1 tendrá un sueldo base de 14.824,22 euros (12 pagas de 1.120 euros, 2 pagas de 691 euros).

El complemento de destino se asigna mediante una escala de niveles, que comprende desde el nivel 1 al nivel 30. Los funcionarios del grupo A1 pueden desempeñar puestos entre los niveles 22 y 30.

Un funcionario cuya plaza tenga un nivel 22 ganará 7.209,16 euros brutos anuales en concepto de complemento de destino. Para el resto de niveles, la retribución bruta anual por concepto del complemento de destino sería:
  • Nivel 22. 7.209,16 euros
  • NIvel 23. 7.726 euros
  • Nivel 24. 8.242,50 euros
  • Nivel 25. 8.759 euros
  • NIvel 26. 9.872 euros
  • Nivel 27. 11.253,34 euros.
  • Nivel 28. 11.770 euros.
  • Nivel 29. 12.286 euros.
  • Nivel 30. 13.698 euros.
El complemento específico tiene una mayor variabilidad. Dos plazas del mismo nivel pueden tener complementos específicos diferentes. Depende de las características en sí del puesto (no es lo mismo ser subdirector nivel 30 de un organismo pequeñito, que subdirector de la Agencia Tributaria) o de la propia administración (AGE, comunidad autónoma).

Podemos tener complementos específicos que oscilan entre 29.000 euros brutos anuales y poco más de 3000 (los grupos A1, obviamente, tendrán complementos más altos).


Sueldo del funcionario del grupo A2 (antiguo grupo B).

Para el año 2016, el sueldo base de un funcionario del grupo A2 (antiguo grupo B) es de 13.035 euros brutos anuales (unos 1.800 euros inferior al del grupo A1). Un grupo A2 puede ocupar puestos de trabajo con niveles comprendidos entre el 18 y el 26. La siguiente tabla muestra el sueldo bruto anual de un funcionario del grupo A2 en concepto de complemento de destino.

  • Nivel 18. 5582,16 euros
  • NIvel 19. 5900 euros
  • Nivel 20. 6217,50 euros
  • Nivel 21. 6693 euros
  • NIvel 22. 7200 euros
  • Nivel 23. 7726,34 euros.
  • Nivel 24. 8200 euros.
  • Nivel 25. 8760 euros.
  • Nivel 26. 9850 euros.
Los complementos específicos se encontrarán dentro del rango también válido para el grupo A1 (entre 3 mil y 30.000 euros).

No obstante, lo normal es que estén un escalón por debajo (un nivel 26 difícilmente ganará 30.000 euros de específico, es más normal que ronde por los 12.000 - 15.000 euros)

El sueldo de un funcionario TIC (telecomunicaciones e informática). 


A continuación os pongo los niveles retributivos de algunas plazas TIC de las dos administraciones de las que tengo más conocimiento: Administración General del Estado y Junta de Andalucía. Como vereis, hay importantes diferencias retributivas entre una administración y otra. Si conoceis de más casos (otras administraciones autonómicas, diputaciones, ayuntamientos) por favor, hacednoslo llegar a través de los comentarios de esta entrada o al correo info@oposicionestic.es

Comunidad Autónoma Andaluza.Fuente: relación de puestos de trabajo de la Consejería de Presidencia. Web del empleado público.

Grupo A1
coordinador/subdirector 30
jefe de servicio de informatica nivel 28 complemento especifico 20.961
adjunto al jefe de servicio 27 18.867,96
departamento de desarrollo y mantenim. 26 15.738,00
titulado superior 22 5300

Grupos A1/A2
tecnico de sistemas 25 15008,40
jefe de proyecto 25 13263,40
asesor tecnico 25 12905
analista funcional 23 9500
titulado medio 18 5038

Grupos A2/C1
asesor tecnico microinformatica 20 8787
programador 20 8787
ayudante tecnico 15 4500

C1/C2
operador de consola 16 7800
grabador de datos 15 5400


Hablando en sueldo neto mensual, un Coordinador (N30) viene a ganar unos 3100 euros al mes. Un jefe de servicio de informática (N28) en torno a los 2800 euros, y un adjunto/jefe de gabinete (N27) unos 2600. Un jefe de departamento (N26) sobre los 2400, y un técnico de sistemas (N25) unos 2300 si es grupo A1, y en torno a los 2100 si es grupo A2. Un analista funcional (N23) viene a ganar unos 1850 euros si es grupo A1, y 1700 euros si es grupo A2. Un titulado superior (grupo A1 base, N22) gana sobre los 1600 euros al mes y un titulado de grado medio (grupo A2 básico, N18) en torno a 1400 euros al mes. Un ayudante técnico (C1 N15) gana unos 1200 euros largos, pudiendo desempeñar puestos de analista funcional (1600 euros largos).


Administración General del Estado. Fuente: nombramientos en el BOE tanto para nuevo ingreso como para concursos de provisión de puestos.

B
5.793,90 ANALISTA PROGRAMADOR NIVEL 18
7074,00 TECNICO GRADO MEDIO 18
4100,00 TECNICO N18 NIVEL 18
5793 TECNICO DE REDES INFORMATICAS NIVEL 18

A
10964,00 26 TECNICO SUPERIOR PROYECTO INFORMATICO
13564,00 26 TECNICO SUPERIOR INFORMATICO ENTRADA AEAT

25536,00 30 jefe de unidad informatica en muface
20,500 29 adjunto jefe de ud. informatica

C
4730,00 17 PROGRAMADOR DE PRIMERA
2949,00 15 TECNICO AUXILIAR
3400,00 15 PROGRAMADOR DE SEGUNDA
4000,00 16 OPERADOR ESPECIALISTA

Un jefe de servicio (N26) viene a ganar en torno a los 2250 euros al mes si es grupo A1, doscientos euros menos si es grupo A2. Si llega a subdirector (N30) rondará los 3000 euros (más productividades). Un grupo A2 base (analista / programador N18) gana sobre los 1300 euros al mes, y un grupo C1 base (N15) los 1100 largos.

Como podreis apreciar, en este caso los complementos específicos son sensiblemente más bajos (en torno a 6000 euros menos por puesto) en el Estado frente a la Junta de Andalucía.

En contrapartida, en el Estado se cobra un mayor número de conceptos variables (con el peligro de que exista arbitrariedad en su asignación).  Estos conceptos son el complemento de productividad y las gratificaciones extraordinarias.

El complemento de productividad es una partida limitada. A la hora de elaborar los presupuestos, cada centro dispone de una cantidad al año, que se puede distribuir de diversas maneras (café para todos, solo cobran productividad unos pocos de mi confianza, etc.).

Lo habitual es que su percepción esté ligada a trabajar una, dos o tres tardes a la semana. En Madrid la gran mayoria de funcionarios TIC de la AGE que lo deseen pueden cobrar productividad. En ocasiones es obligatorio.

Esta cantidad puede oscilar desde 100 euros hasta más de 1000 (no os hagais ilusiones, yo solo he visto cobrar 1000 euros de productividad a cargos directivos como Secretarios Generales).

Las gratificaciones extraordinarias son algo parecido.  Un amigo que trabajó en la Agencia Tributaria de grupo A2 me comentaba que allí cobraban 300 euros al mes de productividad (ligados a trabajar dos tardes) y 400 euros cada tres meses de gratificación extraordinaria.  Yo eso no lo he disfrutado nunca (sí es cierto que la Agencia Tributaria es uno de los centros con mayor presupuesto TIC).

Otro ejemplo de gratificación extraordinaria (este yo si lo he "catado") es la bufanda. Consiste en una segunda paga adicional que se da en Navidad (de ahí lo de "bufanda"), en concepto de gratificación. La cuantía suele variar (como la de la productividad). Yo cobré 150 euros un año, 600 otro (según lo contentos que estén tus jefes contigo).

RESUMIENDO. CUANTO COBRAN LOS FUNCIONARIOS.


Salario de un funcionario de la Administración General del Estado.

De un modo aproximado, en la Administración General del Estado (que engloba todos los ministerios, organismos autónomos, delegaciones provinciales, seguridad social, INEM, etc.) los rangos salariales vienen a ser los siguientes:

  • Grupo A1: entre los 2100 largos de un nivel 26 (técnico superior o jefe de servicio) y los 3000 largos de un nivel 30 (subdirector general). Evidentemente, muy pocos llegarán al nivel 30 (y casi exclusivamente en Madrid). A modo de ejemplo, en la Agencia Tributaria hay 5 subdirecciones generales de Informática.
  • Grupo A2: entre los 1300 largos de un nivel 18 (analista programador o técnico de grado medio) y los 2000 largos de un nivel 26 (jefe de servicio). A igual nivel que un grupo A1, un grupo A2 viene a cobrar entre 100 y 180 euros menos al mes.
  • Grupo C1: entre los 1000 euros largos de un nivel 15 y los 1500 euros largos de un nivel 22.


A todas estas cantidades, habría que sumar los conceptos variables: gratificaciones y complemento de productividad.

No todo el mundo las cobra, y su cuantía depende del centro y del nivel (no cobra la misma productividad un nivel 26 que un 15). Además, suelen estar sujetos a la obligación de trabajar dos o tres tardes a la semana.

Salario de un funcionario TIC de una comunidad autónoma.


En las comunidades autónomas se puede cobrar de 150 a 300 euros más de sueldo fijo, pero los conceptos variables son totalmente testimoniales.

Sueldo de un funcionario TIC de las Entidades Locales.

En los ayuntamientos, esto es otro cantar. Dependerá del ayuntamiento en cuestión: en unos los sueldos serán altísimos, en otros más modestos (en general, la transparencia del mecanismo de ingreso en las administraciones local es muy mejorable).

Además, las administraciones locales han sido las grandes golpeadas por la crisis. Ahí nos podemos encontrar de todo, hasta funcionarios que llevan meses sin cobrar su nómina por trabajar en ayuntamientos quebrados (como los de Jerez o Jaén).

CUANTO GANA UN FUNCIONARIO Y EL COSTE DE LA VIDA EN LA CIUDAD DONDE TRABAJA.


Otro factor muy a tener en cuenta es el del coste de la vida en la ciudad donde finalmente te destinen.

Por poner un ejemplo: en Madrid un grupo C1 entraría cobrando de partida 1100 euros al mes...si consigues una plaza de maestro en un pueblo de Ciudad Real de 400 habitantes, en el que el alquiler de una casa (sin comillas) te puede costar 250 euros al mes, entras ganando 1500 euros largos.

Que cada cual eche sus propias cuentas.

Como podeis ver, el sueldo de un funcionario TIC es un sueldo competitivo (sobretodo si se tiene en cuenta el factor sueldo/horas trabajadas, o sueldo/presión), si bien no es ni mucho menos un sueldo puntero dentro del rango de salarios de puestos equivalentes.

Por poner un ejemplo, un subdirector de una PYME gana seguramente mucho más que un funcionario de N30 (que tiene muchísimas personas a su cargo, y la presión de poder ser cesado en cualquier momento). Conforme bajamos en el escalafón, el sueldo del funcionario se va haciendo cada vez más competitivo si comparamos con la privada.

Arquitectura cliente servidor


ARQUITECTURA CLIENTE/SERVIDOR

Actualizado con fecha 17 de Octubre de 2016.

En esta entrada haremos una introducción a la arquitectura cliente servidor, con el objetivo de preparar los exámenes de test y de desarrollo de las oposiciones de informática y telecomunicaciones.

Han pasado más de 4 años desde la publicación de la entrada original, por lo que hemos decidido actualizar su contenido como parte del proceso general de actualización de los contenidos del blog Oposiciones TIC, orientados a la preparación de las oposiciones de informática y telecomunicaciones de diversas administraciones españolas.

ARQUITECTURA CLIENTE - SERVIDOR. DEFINICIÓN.

¿En qué consiste la arquitectura cliente - servidor?

La estructura cliente - servidor es una arquitectura de computación en la que se consigue un procesamiento cooperativo de la información por medio de un conjunto de procesadores, de tal forma que uno o varios clientes, distribuidos geográficamente o no, solicitan servicios de computación a uno o más servidores.

De esta forma, y gracias a esta arquitectura, la totalidad de los procesadores, clientes y servidores, trabajan de forma cooperativa para realizar un determinado tratamiento de la información.

Atendiendo a esta visión descentralizada, la arquitectura cliente - servidor  consiste  en una arquitectura distribuida de computación, en la que las tareas de cómputo se reparten entre distintos procesadores, obteniendo los usuarios finales el resultado final de forma transparente, con independencia del número de equipos (servidores) que han intervenido en el tratamiento. Se puede decir por tanto que la arquitectura cliente - servidor es un tipo de arquitectura distribuída, posiblemente la más extendida.

ELEMENTOS QUE FORMAN PARTE DE UNA ARQUITECTURA CLIENTE - SERVIDOR.


Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes características:
  • Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.
  • Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos.
  • Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente.
  • Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar.
  • Independencia de la plataforma HW y SW que se emplee.
  • Sistemas débilmente acoplados. Interacción basada en envío de mensajes.
  • Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente.
  • Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores).
  • Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento.
En el modelo usual Cliente/Servidor, un servidor, (daemon en la terminología sajona basada en sistemas UNIX/LINUX, traducido como "demonio") se activa y espera las solicitudes de los clientes.

Lo normal es que los servicios de un mismo servidor puedan ser utilizados por múltiples clientes distintos. Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores.

ESQUEMA DE FUNCIONAMIENTO DE UN SISTEMA SEGÚN LA ARQUITECTURA CLIENTE - SERVIDOR.


El Esquema de funcionamiento de un Sistema Cliente/Servidor sería:
  1. El cliente solicita una información al servidor.
  2. El servidor recibe la petición del cliente.
  3. El servidor procesa dicha solicitud.
  4. El servidor envía el resultado obtenido al cliente.
  5. El cliente recibe el resultado y lo procesa.

COMPONENTES DE LA ARQUITECTURA CLIENTE - SERVIDOR

El modelo Cliente/Servidor es un modelo basado en la idea del servicio, en el que el cliente es un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Además esta relación está establecida en función del intercambio de mensajes que es el único elemento de acoplamiento entre ambos.

De estas líneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e implantan los sistemas Cliente/Servidor: el proceso cliente que es quien inicia el diálogo, el proceso servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder intercambiar mensajes.
Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma:

  • Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.
  • Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
  • Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.
  • Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.
Este modelo de descomposición en niveles, como se verá más adelante, permite introducir más claramente la discusión del desarrollo de aplicaciones en arquitecturas de hardware y software en planos.

ELEMENTOS PRINCIPALES

CLIENTE

Un cliente es todo proceso que reclama servicios de otro. Una definición un poco más elaborada podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor. Se lo conoce con el término front-end.

Éste normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de la red. Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
  • Administrar la interfaz de usuario.
  • Interactuar con el usuario.
  • Procesar la lógica de la aplicación y hacer validaciones locales.
  • Generar requerimientos de bases de datos.
  • Recibir resultados del servidor.
  • Formatear resultados.
La funcionalidad del proceso cliente marca la operativa de la aplicación (flujo de información o lógica de negocio). De este modo el cliente se puede clasificar en:

  • Cliente basado en aplicación de usuario. Si los datos son de baja interacción y están fuertemente relacionados con la actividad de los usuarios de esos clientes.
  • Cliente basado en lógica de negocio. Toma datos suministrados por el usuario y/o la base de datos y efectúa los cálculos necesarios según los requerimientos del usuario.

SERVIDOR

Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las principales funciones que lleva a cabo el proceso servidor se enumeran a continuación:
  • Aceptar los requerimientos de bases de datos que hacen los clientes.
  • Procesar requerimientos de bases de datos.
  • Formatear datos para trasmitirlos a los clientes.
  • Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.
Puede darse el caso que un servidor actúe a su vez como cliente de otro servidor. Existen numerosos tipos de servidores, cada uno de los cuales da lugar a un tipo de arquitectura Cliente/Servidor diferente.
El término "servidor" se suele utilizar también para designar el hardware, de gran potencia, capacidad y prestaciones, utilizado para albergar servicios que atienden a un gran número de usuarios concurrentes. Desde el punto de vista de la arquitectura cliente/servidor y del procesamiento cooperativo un servidor es un servicio software que atiende las peticiones de procesos software clientes.

MIDDLEWARE

El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con varias fuentes de información que se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el cliente y el servidor y se ejecuta en ambas partes.
La utilización del middleware permite desarrollar aplicaciones en arquitectura Cliente/Servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo. Los primeros * monitores de teleproceso* de los grandes sistemas basados en tecnología Cliente/Servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos cuando el concepto de middleware toma su máxima importancia. El middleware se estructura en tres niveles:
  • Protocolo de transporte.
  • Network Operating System (NOS).
  • Protocolo específico del servicio.
Las principales características de un middleware son:
  • Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios.
  • Permite la interconectividad de los Sistemas de Información del Organismo.
  • Proporciona mayor control del negocio al poder contar con información procedente de distintas plataformas sobre el mismo soporte.
  • Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.

Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria para que puedan funcionar.

COMUNICACIÓN ENTRE LOS ELEMENTOS (NOS)

Como se ha comentado en el apartado anterior, el middleware es un conjunto de aplicaciones encargadas de enlazar al cliente con el servidor. Para ello se estructura en tres capas diferentes:
  • Protocolo de transporte: comunes a otras aplicaciones.
  • Network Operating System (NOS).
  • Protocolo específico del servicio: especiales para distintos tipos de sistemas Cliente/Servidor.
Este apartado se centra en el Network Operating System por ser la parte central de toda la comunicación entre el cliente y el servidor.
El NOS es el encargado de proporcionar una apariencia de sistema único a un sistema Cliente/Servidor. Se trata pues, de una extensión del Sistema Operativo:

  • El cliente realiza una llamada a un servicio como si fuera local.
  • El NOS:
    • Intercepta la llamada.
    • Redirige la llamada al servidor apropiado.
    • Devuelve la contestación.
El NOS debe proporcionar transparencia a los procesos Cliente/Servidor con respecto a:
  • Localización: Los recursos sólo se conocen por su nombre. El sistema en el que se ejecutan es irrelevante.
  • Espacio de nombres: Las convenciones de los nombres de los recursos deben ser iguales, independientemente del sistema que los soporte.
  • Conexión: Un único usuario y contraseña para todo el sistema.
  • Replicación: No se debe diferenciar entre copias de un mismo recurso.
  • Acceso local / remoto: El acceso a un recurso se debe realizar como si estuviera localizado en el mismo sistema que el programa cliente.
  • Tiempo: Los relojes de todos los elementos del sistema deben estar sincronizados.
  • Fallos: El sistema debe proporcionar servicios de detección de fallos, redundancia y reconexión tras un fallo.
  • Administración: Un único sistema de gestión de todos los recursos.
  • Protocolos: Idéntica interfaz de programación para todos los protocolos de transporte.

ELEMENTOS DEL NOS

  • SERVICIOS DE TRANSPORTE. Entre los servicios de transporte que utiliza el NOS cabe destacar estos tres:
    • Comunicaciones Peer to Peer (P2P). Son comunicaciones síncronas. Sus principales APIs son: Sockets, NetBios, Named Pipes, IPX/SPX, APPC.
    • Colas de mensajes (MOM): Se trata de un proceso asíncrono.
      • Conectividad Cliente/Servidor no permanente y costosa.
      • El cliente no puede esperar a la respuesta para continuar el proceso.
      • Proceso de mensajes con prioridades (no FIFO).
      • Workflow: envío de mensajes en cadena de aplicaciones.
    • Remote Procedure Calls (RPC). La ejecución del servicio en el cliente se realiza del mismo modo que una llamada a una función local. Existen varios tipos de problemas de transparencia:
      • Paso de parámetros: No es posible pasar parámetros por referencia.
      • Semántica de la llamada (problemas con el comportamiento de la llamada): Tras un TimeOut no se sabe si la llamada se ha ejecutado, Distintos tipos de operaciones: las idempotentes se pueden ejecutar cualquier número de veces; y las no idempotentes son las que el resultado varía con el número de veces que se ejecutan, Representación de los distintos tipos de datos: Se hace necesario un método de representación de datos independiente del sistema, Rendimiento de las llamadas, Seguridad.
  • SERVICIOS DE APLICACIÓN. Cabe destacar, entre los servicios de aplicación del soporte de comunicaciones de un sistema Cliente/Servidor, los siguientes:
    • Servicios de directorio global
      • Refleja la composición del sistema Cliente/Servidor en todo momento.
      • Encargado de resolver la transparencia de ubicación.
      • Se puede implementar como estructura plana o jerárquica (directorios DAP, LDAP, etc).
      • Cada entrada contiene todos los datos asociados al elemento: dirección, estado, otras variables…
      • Un claro ejemplo de los servicios de directorio global son los espacios de nombres (namespaces).
    • Servicios de tiempo (fecha y hora):
      • Mantienen consistente la información de tiempo (timestamp) de todos los componentes de un sistema Cliente/Servidor.
      • Sincronizan periódicamente cada ordenador de la red.
      • Mantienen un componente de inexactitud en cada ordenador, en el que cada agente conoce las desviaciones esperadas del sistema en el que residen y lo resincronizan cuando la desviación es mayor que un umbral determinado.
      • Uno o más servidores deben estar conectados a un proveedor externo de información de tiempo (time ticks) y el resto de servidores realizan consultas para sincronizar sus relojes.
    • Servicios de seguridad: Los sistemas Cliente/Servidor plantean nuevos problemas de seguridad sobre los sistemas centrales tradicionales. Deben reconocer a los ordenadores de la red y permitir el acceso a los usuarios adecuados, así como garantizar que el ordenador es quien dice que es.

      • Confidencialidad en la transmisión de datos en la red. Se utilizan varios métodos de cifrado: cifradores de bloques, intercambio de claves, algoritmos de clave pública, autentificación de usuarios, firma digital, certificados…

TIPOS DE ARQUITECTURA CLIENTE / SERVIDOR.

Uno de los aspectos claves para entender la tecnología Cliente/Servidor, y por tanto contar con la capacidad de proponer y llevar a cabo soluciones de este tipo, es llegar a conocer la arquitectura de este modelo y los conceptos o ideas asociados al mismo.

 Más allá de entender los componentes cliente/middleware/servidor, es preciso analizar ciertas relaciones entre éstos, que pueden definir el tipo de solución que se ajusta de mejor forma a las estadísticas y restricciones acerca de los eventos y requerimientos de información que se obtuvieron en la etapa de análisis de un determinado proyecto.

De hecho el analista deberá conocer estos eventos o restricciones del proyecto para que a partir de ahí, se puedan hacer las consideraciones y estimaciones de la futura configuración, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la información, tiempo de respuesta, tamaños de registros, tamaño de bases de datos, estimaciones del tráfico de red, distribución geográfica tanto de los procesos como de los datos, etc.

En tal sentido se presenta, en primer lugar, un esquema de clasificación basado en los conceptos de Fat Client/Thin Client, Fat Server/Thin Server, es decir, basado en el tamaño de los componentes. En segundo lugar tenemos una clasificación según la naturaleza del servicio que nos ofrecen.

TIPOS DE ARQUITECTURA CLIENTE - SERVIDOR POR TAMAÑO DE COMPONENTES.

Este tipo de clasificación se basa en los grados de libertad que brinda el modelo Cliente/Servidor para balancear la carga de proceso entre los niveles de presentación, aplicación y base de datos.

Dependiendo de qué segmento de las capas de software tenga que soportar la mayor o menor carga de procesamiento, se habla de Fat Client (Thin Server) o Fat server (Thin Client).

Consideraciones de este tipo son importantes en el momento de decidir una plataforma de desarrollo, al mismo tiempo que pueden definir la viabilidad o no de las mismas para enfrentar un cierto número de restricciones impuestas por una problemática a resolver.

FAT CLIENT (THIN SERVER)

En este esquema de arquitectura el peso de la aplicación es ejecutada en el cliente, es decir, el nivel de presentación y el nivel de aplicación corren en un único proceso cliente, y el servidor es relegado a realizar las funciones que provee un administrador de base de datos.

En general este tipo de arquitectura tiene mejor aplicación en sistemas de apoyo de decisiones (DSS: Decision Support System) y sistemas de información ejecutiva (EIS: Executive Information System), y como se concluirá más adelante, tiene pocas posibilidades de aplicarse en sistemas de misión crítica.

FAT SERVER (THIN CLIENT)

Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la interfaz de usuario, mientras que el peso de la aplicación corre por el lado del servidor de aplicación.

En general este tipo de arquitectura presenta una flexibilidad mayor para desarrollar una gran variedad de aplicaciones, incluyendo los sistemas de misión crítica a través de servidores de transacciones.

TIPOS DE ARQUITECTURA CLIENTE - SERVIDOR SEGÚN LA NATURALEZA DE SERVICIO PROPORCIONADO.

SERVIDORES DE FICHEROS

Con un servidor de archivos, un cliente lo que hace es requerimientos de los mismos sobre una red. Esta es una forma muy primitiva de servicios de datos, la cual necesita intercambio de muchos mensajes sobre una red para hallar el dato requerido.

Los servidores de archivos usan recursos compartidos sobre la red y son necesarios para crear repositorios de documentos, imágenes y archivos grandes sobre la red.

SERVIDORES DE BASES DE DATOS

Este análisis está elaborado desde el punto de vista del modelo Cliente/Servidor, y está directamente relacionado con la arquitectura en dos planos, que se describirá en el apartado siguiente.

Obviamente la creación de aplicaciones Cliente/Servidor está asociada a la utilización de servidores de bases de datos relacionales SQL, y dependiendo de los requerimientos y restricciones se debe elegir entre una arquitectura dos o tres planos.

 Pero para una arquitectura centrada en un servidor de bases de datos, cualquiera de las modalidades dos planos, permite que un proceso cliente solicite datos y servicios directamente a un servidor de bases de datos. Según las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso compartido a los datos con los mecanismos de protección necesarios, así como proveer mecanismos para seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro en procesos de comunicación.

El servidor debe también proveer mecanismos de concurrencia, seguridad y consistencia de datos, basado principalmente en el concepto de transacción en el que todo se realiza, y por lo tanto se hace permanente, o todo falla, anulándose la transacción en tal caso.

Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones propias de cada proveedor. Por ejemplo casi todas las bases de datos están provistas con:
  • Procedimientos almacenados (stored procedures): Una de las posibilidades de implementar de mejor forma un sistema Cliente/Servidor en dos planos (two-tier), sin olvidar todas sus restricciones y limitaciones, es a través de procedimientos almacenados, que son funciones que agrupan un conjunto de instrucciones y lógica de procedimientos SQL, los cuales son compilados y almacenados en la misma base. El rol principal de los procedimientos almacenados es proveer la parte servidora de la lógica de una aplicación Cliente/Servidor, es decir vendría a reemplazar al servidor de aplicaciones en una arquitectura tres planos (three-tier).
  • Desencadenantes (triggers): Son mecanismos que permiten realizar acciones automáticamente sobre los datos, las cuales están asociadas a algún evento definido. Normalmente son implementados a través de procedimientos almacenados. Los eventos a los cuales se hace referencia están asociados a las actualizaciones de tablas mediante sentencias delete, insert o update, y son llamados implícitamente al suceder cualquiera de estos eventos, a diferencia de los procedimientos almacenados que son llamados explícitamente por un proceso cliente.
  • Restricciones (constraints): Al igual que los desencadenantes, son acciones que se realizan asociadas a algún evento determinado y están orientadas a llevar a cabo validaciones más simples de datos. Los tipos de eventos son los mismos que para los desencadenantes.

SERVIDORES DE TRANSACCIONES

Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades Cliente/Servidor en dos o tres planos, pero incorporan un elemento principal sobre el cual se elabora y basa toda la fortaleza de este modelo, el concepto de transacción.

Con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos que residen en el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de aplicaciones.

 Lo importante es que el intercambio a través de la red se realiza mediante un único mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad lógica llamada transacción; evitando así el intercambio a través de la red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas Cliente/Servidor dos planos, implementados a través de SQL remoto.

Estas aplicaciones denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los procedimientos y reglas de los sistemas de misión crítica.

En la actualidad muchas aplicaciones tienen la necesidad de ser desarrolladas con la ayuda de transacciones, véase el ejemplo de los cajeros automáticos: imaginemos que queremos sacar dinero. Introducimos la cantidad adecuada y pulsamos el botón de enviar. El cajero manda una solicitud al banco para que descuente dicha cantidad de la cuenta del cliente, y recibe la respuesta. Si diera la casualidad que la respuesta del banco se perdiera en medio de la red, el cajero volvería a realizar la petición, por lo que el banco volvería a descontar dicha cantidad de la cuenta bancaria asociada. Este problema tan común se soluciona con la ayuda de las transacciones.

El modelo de comunicación más usado entre el cliente y el servidor a la hora de realizar transacciones planas distribuidas es el Two-Phase-Commit, el cual funciona de la siguiente manera:
  • Caso 1: Todas las operaciones en los distintos sistemas han sido correctas.
    • Fase 1: El nodo gestor envía prepare to commit a todos los nodos subordinados. Devuelven al nodo gestor ready to commit.
    • Fase 2: El nodo gestor envía commit a todos los nodos subordinados. Los nodos subordinados finalizan la transacción y devuelven al nodo gestor complete.
  • Caso 2: Algún sistema no puede finalizar la transacción.
    • Fase 1: El nodo que no puede realizar correctamente la transacción contesta refuse al prepare_to_commit del nodo gestor.
    • Fase 2: El nodo gestor envía rollback a todos los nodos subordinados. Los nodos subordinados deshacen la transacción y devuelven al nodo gestor complete.
La parte central de cualquier servidor de transacciones es el TP Manager. El núcleo del TP consta de diferentes partes:
  • Gestor de transacciones (Transaction Manager):
    • Arranque de la transacción.
    • Registro de Gestores de Recursos que participan.
    • Gestión Commit/Rollback.

  • RPCs transaccionales: Permiten garantizar la integridad de la transacción cuando no se ejecuta en un solo ordenador.
    • RPCs con un identificador de transacción asociado, asignado por el TM.
  • Gestor de registro de modificaciones (Log Manager). Graba los cambios realizados por los Gestores de Recursos. Permite reconstruir una versión consistente de todos los recursos.
  • Gestor de bloqueos (Lock Manager). Proporciona mecanismos para regular el acceso concurrente a lso recursos.

SERVIDORES DE OBJETOS

Con un servidor de objetos, las aplicaciones Cliente/Servidor son escritas como un conjunto de objetos que se comunican. Los objetos cliente se comunican con los objetos servidores usando un Object Request Broker (ORB). El cliente invoca un método de un objeto remoto. El ORB localiza el método del objeto en el servidor, y lo ejecuta para devolver el resultado al objeto cliente. Los servidores de objetos deben soportar concurrencia. La parte central de la comunicación en los servidores de objetos es el ORB:
  • Elemento central y principal de esta arquitectura.
  • Bus de objetos. Permite la comuniación entre ellos.
  • Middleware avanzado: Permite llamadas estáticas y dinámicas a objetos.
  • Lenguaje de descripción de interfaces independiente del lenguaje de programación.

SERVIDORES WEB

La primera aplicación cliente servidor que cubre todo el planeta es el World Wide Web. Este nuevo modelo consiste en clientes simples que hablan con servidores Web. Un servidor Web devuelve documentos cuando el cliente pregunta por el nombre de los mismos. Los clientes y los servidores se comunican usando un protocolo basado en RPC, llamado HTTP. Este protocolo define un conjunto simple de comandos, los parámetros son pasados como cadenas y no provee tipos de datos. La Web y los objetos distribuidos están comenzando a crear un conjunto muy interactivo de computación Cliente/Servidor.

MODELOS CLIENTE/SERVIDOR

Una de las clasificaciones mejor conocidas de las arquitecturas Cliente/Servidor se basa en la idea de planos (tier), la cual es una variación sobre la división o clasificación por tamaño de componentes.

Esto se debe a que se trata de definir el modo en que las prestaciones funcionales de la aplicación serán asignadas, y en qué proporción, tanto al cliente como al servidor. Dichas prestaciones se deben agrupar entre los tres componentes clásicos para Cliente/Servidor: interfaz de usuario, lógica de negocios y los datos compartidos, cada uno de los cuales corresponde a un plano. Ni que decir tiene que la mala elección de uno u otro modelo puede llegar a tener consecuencias fatales.

Dentro de esta categoría tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier) y multi-planos (multi-tier). Dado que este término ha sido sobrecargado de significados por cuanto se lo utiliza indistintamente para referirse tanto a aspectos lógicos (Software) como físicos (Hardware), aquí se esquematizan ambas acepciones.

A NIVEL DE SOFTWARE

Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques modernos, dado que se fundamenta en los componentes lógicos de la estructura Cliente/Servidor y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física sobre la cual pueden operar uno o más servidores de aplicaciones.

MODELO CLIENTE/SERVIDOR 2 CAPAS

Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:
IMPLEMENTADO CON SQL REMOTO
En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el resultado de cada instrucción SQL es devuelto por la red, no importando si son uno, diez, cien o mil registros. Es el mismo cliente quien debe procesar todos los registros que le fueron devueltos por el servidor de base de datos, según el requerimiento que él mismo hizo. Esto hace que este tipo de estructura se adecue a los requerimientos de aplicaciones orientadas a los sistemas de apoyo y gestión, pero resultan inadecuados para los sistemas críticos en que se requieran bajos tiempos de respuesta.

Ventajas:
  • Presenta una estructura de desarrollo bastante simple ya que el programador maneja un único ambiente de desarrollo (es más simple respecto al Cliente/Servidor en tres planos, puesto que reduce una capa de programación, como se verá más adelante).
Inconvenientes:
  • La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.
  • Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a la construcción de sistemas no críticos.
IMPLEMENTADO CON PROCEDIMIENTOS ALMACENADOS
En este esquema el cliente envía llamadas a funciones que residen en la base de datos, y es ésta quien resuelve y procesa la totalidad de las instrucciones SQL agrupadas en la mencionada función.

Ventajas: Presenta las mismas ventajas de una arquitectura dos planos con procedimientos almacenados, pero mejora considerablemente el rendimiento sobre ésta, dado que reduce el tráfico por la red al procesar los datos en la misma base de datos, haciendo viajar sólo el resultado final de un conjunto de instrucciones SQL.

Inconvenientes: Si bien la complejidad de desarrollo se ve disminuida, se pierde flexibilidad y escalabilidad en las soluciones implantadas. Obliga a basar el peso de la aplicación en SQL extendido, propios del proveedor de la base de datos que se elija. Debiera considerarse que sí bien los procedimientos almacenados (stored procedures), los desencadenantes (triggers) y las reglas (constraint) son útiles, en rigor son ajenos al estándar de SQL

MODELO CLIENTE/SERVIDOR 3 CAPAS

Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de software, más la capa correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y según las decisiones de diseño que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de aplicación.
En este esquema el cliente envía mensajes directamente al servidor de aplicación el cual debe administrar y responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud, quien accede y se conecta con la base de datos.
Ventajas:
  • Reduce el tráfico de información en la red por lo que mejora el rendimiento de los sistemas (especialmente respecto a la estructura en dos planos).
  • Brinda una mayor flexibilidad de desarrollo y de elección de plataformas sobre la cual montar las aplicaciones. Provee escalabilidad horizontal y vertical.
  • Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones.
  • Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace más exportables las aplicaciones entre plataformas.
  • Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos de alta fiabilidad.
  • El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de distribuirlos en la capa de interfaz de usuario, permite reducir el impacto de hacer mantenimiento, cambios urgentes de última hora o mejoras al sistema.
  • Disminuye el número de usuarios (licencias) conectados a la base de datos.
Inconvenientes:
  • Dependiendo de la elección de los lenguajes de desarrollo, puede presentar mayor complejidad en comparación con Cliente/Servidor dos planos.
  • Existen pocos proveedores de herramientas integradas de desarrollo con relación al modelo Cliente/Servidor dos planos, y normalmente son de alto costo.

A NIVEL DE HARDWARE

Esta clasificación del modelo Cliente/Servidor se basa igualmente en la distribución de los procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el que la administración de la interfaz gráfica se asocia a los clientes PC y la seguridad e integridad de los datos quedan asociados a ambientes mainframe o por lo menos a servidores locales y/o centrales.

MODELO CLIENTE / SERVIDOR 2 CAPAS

Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual, dependiendo de la aplicación puede dar acceso a los datos administrados por él.

MODELO CLIENTE / SERVIDOR 3 CAPAS

Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual a su vez se comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento dual, dado que actúa como cliente o servidor en función de la dirección de la comunicación.

MODELOS CLIENTE / SERVIDOR SEGÚN EL REPARTO DE FUNCIONES ENTRE CLIENTE Y SERVIDOR.

Separación de funciones.

Las distintas arquitecturas cliente/servidor presentan variaciones acerca de cómo son distribuidas las diferentes funciones de las aplicaciones de sistemas entre el cliente y el servidor, sobre la base de los conceptos de los tres componentes generales de cualquier SI:
  • La lógica de acceso a datos. Funciones que gestionan todas las interacciones entre el SW y los almacenes de datos (archivos, bases de datos, etc.) incluyendo recuperación/consulta, actualización, seguridad y control de concurrencia.
  • La lógica de presentación. Funciones que gestionan la interfaz entre los usuarios del sistema y el SW, incluyendo la visualización e impresión de formas y reportes, y la posibilidad de validar entradas del sistema.
  • La lógica de negocio o lógica de la aplicación. Funciones que transforman entradas en salidas, incluyendo desde simples sumas hasta complejos modelos matemáticos, financieros, científicos, de ingeniería, etc.
Según cómo se distribuyan las funciones correspondientes a estas tres lógicas o funciones de un sistema entre cliente, middleware y servidor (los principales componentes de un sistema con arquitectura distribuída) nos podemos encontrar con los siguientes tipos de arquitectura cliente / servidor (conforme a la célebre clasificación hecha por el Gartner Group):
  • Presentación Distribuida.
  • Presentación remota.
  • Acceso a datos remoto.
  • Lógica o procesamiento distribuídas.
  • Bases de datos distribuídas.
La importancia de esta clasificación radica en que permite jugar con el ancho de banda de la red y con la capacidad de proceso de los componentes hardware del sistema para repartir entre ellos la carga de proceso de las lógicas de la aplicación. Seguidamente entraremos en más detalle sobre estos tipos de arquitectura.
arquitecturas-cliente-servidor.gif

Presentación distribuída.


El cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor dedicados a esta tarea. El resto de funciones de la aplicación (negocio, acceso a datos) residen en el servidor.
Esta arquitectura se utiliza para construir emuladores de terminal, aplicaciones de control remoto, front ends gráficos de aplicaciones que residen en un host, etc. Algunos ejemplos de productos que siguen esta filosofía son VLC, Microsoft Terminal Server, Cytrix Metaframe, emulador de host para sistemas operativos modernos como Windows, etc.
La gran ventaja de esta arquitectura es que permite revitalizar sistemas antiguos. Así, las aplicaciones antiguas que funcionaban en entornos host pueden ser empleadas desde modernas estaciones de trabajo Windows o Microsoft (que solamente hacen la función de términal del host incrustada en un entorno de trabajo de escritorio moderno).
El principal problema es que no se elimina la dependencia del host, no siendo posible la aplicación de los conceptos de downsizing o rightsizing.

Presentación remota.

Toda la lógica de negocio y acceso a datos se ejecuta en el servidor, que en esta ocasión no realiza ninguna función relacionada con la presentación. Todas las funciones de presentación son ejecutadas en el cliente. Un ejemplo de este tipo de aplicaciones son las aplicaciones web, las de los terminales de cajeros automáticos, etc.
La principal ventaja es que la interfaz de usuario se adapta bien a las capacidades del entorno cliente (en la presentación distribuída el servidor tenía que ejecutar funciones dentro de un entorno que podría no ser el más apropiado para el cliente). La principal desventaja es que toda la información necesaria para la presentación tiene que circular por la red desde el servidor al cliente.

Lógica o proceso distribuído.

La lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información de forma que los papeles de cliente y servidor sean intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.

La principal ventaja de esta arquitectura es que cada uno de los nodos/servidores puede especializarse en un área determinada, de forma que cada proceso se ejecutará en el nodo más apropiado. Además, se pueden reutilizar los sistemas ya existentes (es una especie de antesala del concepto de SOA).
En contrapartida, este tipo de sistemas son más dificiles de diseñar, de mantener y de probar.

Acceso a datos remoto.

El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota.
La principal ventaja de esta arquitectura radica en su sencillez de uso, y su proliferación al ser adaptada por lenguajes de cuarta generación (como Oracle Forms). La desventaja es la latencia de red introducida. Al descargarse toda la lógica de proceso en los aplicativos clientes, estos necesitan descargar los datos necesarios (entradas al proceso) que circulan por la red.

Bases de datos distribuídas.

Este modelo es similar al de Acceso a Datos Remoto, pero además el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.

La principal ventaja de este modelo es que facilita el acceso a los datos desde entornos heterogéneos. Los componentes de acceso a datos ubicados en el cliente permiten independizar la base de datos del entorno en el que corren las aplicaciones cliente. Además, permite implementar la "transparencia de ubicación". Este sistema presenta dos importantes inconvenientes:
  • Las bases de datos distribuídas son más difíciles de implementar, y son dependientes del gestor de base de datos (siempre que no existan acuerdos y estándares)
  • La integridad de los datos puede verse comprometida.
clienteservidorgartnert.JPG

BIBLIOGRAFÍA

Bibliography
1. John Wiley: Introduction to Client / Server Systems: A Practical Guide for Systems Professionals.
2. Tanenbaum, A.: Sistemas Distribuidos.

3. Morgan Kaufmann: Transaction Processing Concepts and Techniques.



Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.