PORTAFOLIO DE EVIDENCIAS

La escalabilidad

La escalabilidad es en telecomunicaciones y en ingeniería informática, es la propiedad anhelada de una red, sistema, o proceso, que muestra su destreza para operar el incremento continuo de trabajo con fluidez, o muestra la preparación que tiene para crecer manteniendo su calidad en todos los servicios. Generalmente podemos definir la escalabilidad como la capacidad que tiene un sistema informático de modificar su configuración o su tamaño, para ajustarse a los cambios. Podemos citar el ejemplo de una empresa cualquiera que tienen una red de usuarios vía Internet, es lógico que la empresa quiera tener un sistema que le permita trabajar con los clientes actuales, pero también con los posibles clientes, teniendo la oportunidad de cambiar la configuración si así fuese oportuno hacerlo.

Al tratar de definir la escalabilidad como una propiedad de los sistemas, resulta un poco complicado, específicamente se hace necesaria la definición de algunos requerimientos particulares de la escalabilidad en las dimensiones que se considere de gran importancia. Es un ejemplar bastante significativo en las bases de datos, los sistemas electrónicos, redes y ruteadores. A un sistema pasa a ser lo que se le llama escalable cuando su rendimiento es mejorado, al sumarle capacidad hardware y este mejora en proporción a la capacidad añadida.

• Dimensiones. La escalabilidad de un sistema se puede medir en distintas dimensiones.
• Escalabilidad en carga. Esto se hace más fácil mediante un sistema distribuido, podemos ampliar y reducir los recursos con mayor facilidad para adecuar las cargas ya sean pesadas o ligeras según sea necesario.
• Escalabilidad geográfica. Un sistema es escalable geográficamente cuando su uso y sus ventajas se conservan sin que afecte la distancia de los usuarios.
• Escalabilidad administrativa. Este debe de manejarse con facilidad sin importar las organizaciones que necesiten compartir un solo sistema distribuido.
• Escalada verticalmente. También se dice escala hacia arriba, quiere decir que en un solo nodo del sistema es donde se han agregado más recursos. Ejemplo, añadir memoria a un disco duro de una computadora.
• Escalada horizontalmente. Quiere decir que se agregan más nodos a un sistema. Ejemplo, agregar una nueva computadora a un programa de aplicación para espejo

Ejemplos

1. Un sistema de procesamiento y transacción en línea o un sistema administrador de base de datos escalable se puede actualizar para procesar más servicios sumándole dispositivos y almacenamiento, que pueden implementarse con facilidad por medio de los procesadores nuevos.
2. Un protocolo enrutador se considera como escalable con relación al tamaño de la red, si el tamaño de la tabla enrutadora, aumenta en cada nodo, como una cota superior asintótica (Log N).
3. Una aplicación de software se llama escalable, si cuando se aumentan los procesadores donde se confecciona, aumenta su rendimiento proporcionalmente. [ Equipo arquitectura y construcción de ARQHYS.com ].
   
   
   

   La escalabilidad debe formar parte del proceso de diseño porque no es una característica separada que se pueda agregar después. Al igual que con otras funciones de aplicación, las decisiones que se tomen durante las primeras fases de diseño y codificación determinarán en gran medida la escalabilidad de la aplicación.

   La escalabilidad de una aplicación requiere una pertenencia equilibrada entre dos dominios distintos, software y hardware. Puede avanzar grandes pasos que aumenten la escalabilidad de un dominio sólo para sabotearlos cometiendo errores en el otro. Por ejemplo, la creación de un grupo de servidores Web con equilibrio de carga no beneficiará una aplicación Web que se ha diseñado para ejecutarse un solo equipo. De igual modo, el diseño de una aplicación altamente escalable y su implementación en equipos conectados a una red con poco ancho de bada no controlará bien las cargas pesadas cuando se sature el tráfico en la red.

   Puesto que la escalabilidad no es un problema de diseño de las aplicaciones independientes, aquí se tratan las aplicaciones distribuidas. Las aplicaciones distribuidas están también un paso más allá de las tradicionales aplicaciones de cliente-servidor. Las aplicaciones distribuidas son aplicaciones que están diseñadas como aplicaciones de n niveles. La arquitectura de estas aplicaciones distribuidas favorece el diseño de aplicaciones escalables compartiendo recursos, como bases de datos y componentes empresariales.

   Escalar en vertical

   El escalado en vertical es el término que más se utiliza para lograr escalabilidad utilizando software mejor, más rápido y más caro. El escalado incluye agregar más memoria, más procesadores o procesadores más rápidos o, simplemente, migrar la aplicación a un único equipo más potente. Normalmente, este método permite un aumento en la capacidad sin requerir cambios en el código fuente. Desde el punto de vista administrativo, las cosas permanecen igual puesto que sigue habiendo un único equipo que administrar.

   Escalar en vertical

   

   Actualizar un componente de hardware en un equipo sólo mueve el limite de capacidad de procesamiento de un lado a otro. Por ejemplo, una máquina que está al 100 % de uso de la CPU podría mejorar su capacidad agregando otra CPU. Sin embargo, la limitación puede pasar de la CPU a la memoria del sistema. Agregar CPU no aporta rendimiento en un modelo lineal. En su lugar, el rendimiento va disminuyendo cada vez que se agrega un procesador adicional. Para equipos con configuraciones de varios procesadores simétricos (SMP), cada procesador adicional produce una sobrecarga del sistema. Por tanto, un equipo con cuatro procesadores no obtendrá una mejora del 400% en capacidad sobre una versión con un único procesador. Una vez que haya actualizado todos los componentes de hardware al máximo de su capacidad, llegará el momento en que alcance el límite real de la capacidad de procesamiento del equipo. Llegado ese punto, el siguiente paso es escalar en vertical para moverse a otro equipo.

   Escalar en vertical conlleva también otros posibles problemas. El uso de un único equipo en el que basar una aplicación crea un único punto de error, lo que disminuye enormemente la tolerancia de errores del sistema. Si bien algunos métodos, como varias fuentes de alimentación, pueden implementar redundancia en un sistema de un único equipo, pueden resultar costosas.

   Escalar en horizontal

   Una alternativa a escalar en vertical es escalar en horizontal. Escalar en horizontal aprovecha el ahorro que supone utilizar el hardware de PC activo para distribuir la carga de procesamiento en más de un servidor. Aunque el escalado en horizontal se logra utilizando muchos equipos, la colección funciona esencialmente como un único equipo. Al dedicar varios equipos a una tarea común, mejora la tolerancia de errores de la aplicación. Por supuesto, desde el punto de vista del administrador, escalar en horizontal presenta un desafío mayor de administración debido al mayor número de equipos.

   Escalar en horizontal

   

   Los desarrolladores y administradores utilizan una gran variedad de técnicas de equilibrio de carga para escalar en horizontal con la plataforma Windows. El equilibrio de carga permite escalar un sitio en horizontal a través de un clúster de servidores, facilitando la adición de capacidad agregando más servidores duplicados. También proporciona redundancia, concediendo al sitio capacidad de recuperación de conmutación por error, de manera que permanece disponible para los usuarios incluso si uno o más servidores fallan (o si es preciso retirarlos del servicio para realizar labores de mantenimiento). El escalado en horizontal proporciona un método de escalabilidad que no se ve mermado por limitaciones de hardware. Cada servidor adicional proporciona una mejora casi lineal de la escalabilidad.

   La clave para escalar horizontalmente una aplicación con éxito es la transparencia de ubicación. Si alguna parte del código de la aplicación depende de saber qué servidor está ejecutando el código, no se ha logrado la transparencia de ubicación y será difícil el escalado en horizontal. Esta situación se denomina afinidad de ubicación. La afinidad de ubicación requiere cambios de código para escalar una aplicación en horizontal de un servidor a varios, lo que, en pocas ocasiones, constituye una opción económica. Si diseña la aplicación con transparencia de ubicación en mente, resulta más fácil escalarla en horizontal.

Arquitectura Cliente-Servidor

CONCEPTO DE ARQUITECTURA CLIENTE / SERVIDOR.

La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales.
Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos.
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. Habitualmente, programas cliente múltiples comparten los servicios de un programa servidor común. Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores.
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.

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.

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.

Invetigaciones :Transact-SQL, MTS,Message Queue Server,Comunicación asincrónica

Transact-SQL : 

(T-SQL). Transact-SQL es una extensión del lenguaje SQL, propiedad de Microsoft  y Sybase. La implementación de Microsoft funciona en los productos Microsoft SQL Server. En tanto, Sybase utiliza el lenguaje en su Adaptative Server Enterprise, el sucesor de Sybase SQL Server.

Para hacer a SQL más poderoso, le fueron agregados algunas características como:
-Mejora en las declaraciones DELETE y UPDATE.
-Variables  locales.
-Soporte de varias funciones para el procesamiento de cadenas, datos, matemática, etc.
-Un lenguaje de control de flujos.

Para el lenguaje de control de flujos utiliza palabras claves como BEGIN y END, BREAK, CONTINUE, GOTO, IF y ELSE, RETURN, WAITFOR y WHILE.

Para las variables locales utiliza DECLARE para declararlas y SET para proveerles un valor.

En tanto las mejoras en las declaraciones DELETE Y UPDATE se debe a que ambas permiten una cláusula FROM.

Los críticos de Transact-SQL dicen que las caracterísitcas adicionales rompen la compatibilidad con el SQL estándar. También critican que lo que Transact-SQL hace es posible implementarse a través de los lenguajes de programación y SQL embebido.

 MTS

MTS nace con el objetivo de facilitar el desarrollo y gestión de componentes que llevan a cabo trabajos en el ámbito de transacciones. Pongámonos, en el lugar de un desarrollador que crea una aplicación que utiliza componentes COM para realizar tareas coordinadas. Supongamos que estas tareas deben realizarse todas concertadamente para conseguir que el resultado sea el esperado. Parece evidente que de la propia naturaleza de las citadas operaciones va a resultar poco menos que imprescindible definir transacciones que involucren a los citados componentes. ?Quién coordina esas transacciones, cuando los elementos de software que realizan las tareas (los componentes) son módulos independientes que posiblemente desconozcan por completo la existencia de los otros? La respuesta es que es necesario un servidor que cuide de estos aspectos:

Transaction Server.

Toda aplicación que utilice este modelo cliente servidor puede definirse como una entidad que tiene un cierto estado (por ejemplo los stocks y la facturación en un negocio) y que permite su modificación mediante una serie de operaciones definidas por la propia aplicación. Los componentes en un servidor suelen llevar a cabo todas estas operaciones que permiten que los citados datos sean coherentes, accesibles al tiempo que facilitan su actualización y consulta.

Estas reglas de coherencia, las reglas de negocio, requieren de una cierta lógica de aplicación que es el trabajo de los programadores diseñar. Este es el cuerpo del código de los componentes. El trabajo de MTS es descargar a los programadores de todos los aspectos tangenciales que no sean estrictamente la implementación de las reglas de negocio y, especialmente, de los posibles conflictos que unos componentes puedan provocar sobre los otros. Cuando un componente está controlado durante su ejecución por MTS todas sus operaciones son susceptibles de enmarcarse en transacciones. MTS se ocupa de resolver todos los problemas de concurrencia, en memoria, en lógica de programa y en gestión de recursos.

El modelo de operaciones en MTS

Bien, hemos dicho que nuestro objetivo es crear una aplicación que se ubique en un servidor (o varios colaborando entre ellos) y que sea accedida por clientes que van a consultar, actualizar o gestionar los datos que conforman el estado de la citada aplicación. Las operaciones sobre el estado de la aplicación, la lógica de negocio, van a implementarse con componentes COM cuyos aspectos transaccionales van a ser controlados y gestionados por Microsoft Transaction Server.

Los componentes MTS

Cada uno de los componentes de la aplicación, que en principio es un componente COM cualquiera, se convierte en un componente MTS. Un componente MTS es un componente COM constituido como una DLL, y que se ejecuta en el entorno de Transaction Server. Para ello los componentes deben cumplir un conjunto de características avanzadas que no vamos a exponer aquí.

Del mismo modo que una instancia de un componente COM es un objeto COM, toda instancia de un componente MTS es un objeto MTS. Cuando creamos un ejemplar de un componente MTS el servidor crea automáticamente un objeto asociado de contexto (Context Object) que contiene información sobre quién originó la creación del objeto y cómo se está ejecutando, principalmente desde el punto de vista de las transacciones en las que el objeto está inmerso.

Message Queue Server: 

Message Queue Server (también llamado MSMQ) es una infraestructura de mensajería y una herramienta de desarrollo para crear aplicaciones de mensajería distribuida para los sistemas operativos de Windows® de Microsoft®.

Message Queue Server resulta interesante para los administradores de sistemas (en la instalación y administración de infraestructuras) y para los programadores de software (en la creación de aplicaciones de mensajería). Esta documentación se ha redactado para los administradores de sistemas y trata sobre la administración de la infraestructura proporcionada por Message Queue Server. No se habla del desarrollo de aplicaciones.

En esta documentación, el término servidor de Message Queue Server hace referencia a un equipo de la familia Windows Server 2003 en el que se ha instalado Message Queue Server. El término cliente de Message Queue Server hace referencia tanto a un cliente independiente como a un cliente dependiente. Ambos términos se utilizan para describir servidores de Message Queue Server en los que se han instalado componentes concretos de Message Queue Server.

Comunicación asincrónica: 

La comunicación asincrónica es aquella comunicación que se establece entre dos o más personas de manera diferida en el tiempo, es decir, cuando no existe coincidencia temporal. Un ejemplo antiquísimo de comunicación asincrónica es la carta de papel; actualmente es un tipo de la comunicación desarrollada mediante ordenadores o computadores. Ejemplos actuales de la comunicación asincrónica son el mail o correo electrónico y foros.

Elementos de la comunicación asincrónica

En la comunicación asincrónica observamos que algunos de elementos típicos de la comunicación presentan unas características específicas y diferenciales:

Emisor: El emisor envía la información sabiendo que no obtendrá una respuesta inmediata.

Receptor: Este será consciente de la llegada del mensaje solo cuando acceda al canal específico.

Canal: Es el medio físico acordado por ambas partes por el que se transmite el mensaje, debe ser perdurable en el tiempo ya que el mensaje se almacena allí durante un tiempo indefinido.

Código: No puede ser efímero y debe poder almacenarse en un soporte físico.

Situación o contexto: La disponibilidad del emisor o receptor es incierta y marca de forma importante el contexto de la comunicación.

Arquitectura SMP y MPP

Arquitectura SMP
El multiprocesamiento simétrico tiene un diseño simple pero aun así efectivo. En smp, múltiples procesadores comparten la memoria ram y el bus del sistema. Este diseño es también conocido como estrechamente acoplado (tightly coupled), o todo compartido (shared everything).

Debido a que smp comparte globalmente la memoria ram, tiene solamente un espacio de memoria, lo que simplifica tanto el sistema físico como la programación de aplicaciones. Este espacio de memoria único permite que un sistema operativo con multiconexión (multithreaded operating system) distribuya las tareas entre varios procesadores, o permite que una aplicación obtenga la memoria que necesita para una simulación compleja. La memoria globalmente compartida también vuelve fácil la sincronización de los datos.
Smp es uno de los diseños de procesamiento paralelo más maduro. Apareció en los supercomputadores cray x-mp y en sistemas similares hace década y media (en 1983).
Sin embargo, esta memoria global contribuye al problema más grande de smp: conforme se añaden procesadores, el tráfico en el bus de memoria se satura. Al añadir memoria caché a cada procesador se puede reducir algo del tráfico en el bus.

El bus generalmente se convierte en un cuello de botella al manejarse alrededor de ocho o más procesadores. Smp es considerada una tecnología no escalable.
Si bien los primeros componentes utilizados con la tecnología smp fueron procesadores
Risc, en la actualidad, debido a su bajo costo, los procesadores cisc avanzados como pentium y p6 son empleados con relativa frecuencia. En el mercado se encuentran sistemas pentium, pentium pro y pentium ii de dos vías (two-way pentium, pentium pro y pentium ii); además de pentium pro y pentium ii de cuatro y ocho vías (four-way, eight-way pentium pro y pentium ii). Dos vías, cuatro vías y ocho vías significan dos, cuatro y ocho procesadores conectados en paralelo.

 Arquitectura MPP

Una máquina MPP presenta una serie de consideraciones importantes derivadas de su arquitectura, que se deben tomar en cuenta al escribir programas que pretendan aprovechar su naturaleza multiprocesador. Obviamente la característica más importante es el hecho de que, en cada nodo, cada procesador opera básicamente como una computadora independiente, ejecutando su propio código independiente de los demás procesadores, y teniendo un área de memoria con datos también independientes.

Desde luego, para que esta organización redunde en un mayor desempeño, se requiere colaboración entre los nodos. Como se mencionó, una máquina MPP debe contar con un canal que permita a los nodos comunicarse entre sí, a fin de intercambiar datos y coordinar sus operaciones. Ya que el objetivo principal de una máquina MPP es obtener alto rendimiento, se busca que este canal de comunicaciones sea lo más eficiente posible, en términos tanto de ancho de banda como de tiempo de latencia. En la mayoría de los casos este canal será un bus propietario, diseñado por el fabricante del equipo MPP.

Para tener acceso a información fuera de su propia área de memoria, los nodos se comunican entre sí, regularmente empleando un esquema de paso de mensajes. Esto resuelve el problema de saturación del bus de comunicaciones, pues éste sólo se emplea cuando se está realizando comunicación entre los nodos. De esta manera se tiene una arquitectura que puede escalarse a varios cientos o miles de procesadores (las máquinas MPP más grandes en la actualidad tienen alrededor de 10 mil procesadores).

Sin embargo el tener varias secciones de memoria independientes complica la programación en este tipo de arquitecturas. En una arquitectura MPP la distribución de trabajo entre los nodos es una consideración vital al diseñar cualquier aplicación. Se debe tomar en cuenta la sincronización de datos entre los nodos, y en toda comunicación entre ellos debe realizarse explícitamente por medio de llamadas al mecanismo de paso de mensajes. 

Reporte de Analisis y costo

ANALISIS COSTO

Al realizar un pequeña visita a la presidencia municipal de ixmiquilpan nos percatamos de que esta institución no cuenta con los recursos necesarias para brindar un buen servicio a los ciudadanos, ya que  esta institución solo cuenta con un aproximado de 105 computadoras las cuales están en distribuidas en sus distintas secretarias con las que cuenta la presidencia municipal, comparten lo que son las impresoras las cuales solo cuentan con 30 impresoras que igual están una en cada secretaria y las cuales doto el personal comparten impresoras y manejan lo que es archivo físico porque no cuenta con un servidor propio cuenta con lo que es una página web la cual la tiene almacenada en un servidor en el cual pagan lo que es la renta de este servidor por mantener alojada aquí su página web.

Al obtener esta información nos dios cuenta que la presidencia municipal no cuenta con la organización suficiente para brindar un mejor servicio a la sociedad  también necesita modernizar lo que son sus equipos de cómputo para tener su información con la cual cuenta en mejores condiciones.

De acuerdo con un análisis de la información brindada se llego a la conclusión de que sería recomendable, primero que nada que la Presidencia tuviera una buena comunicación y organización entre el personal que labora ahí, para que con ello se logre brindar un mejor servicio a la gente,  además deberían tener una servidor propio ya que el rentar el servicio a largo plazo es más caro el rentar y la información podría tener riesgo de ser modificada y o infiltrada.

Tener personal capacitado para el manejo de equipos de cómputo como del mantenimiento de los mismos, a fin de que solo ellos puedan manejar su información y sea mucho más seguro.

El uso de las impresoras para la generación de archivos físicos resulta muy costosa, para ello lo más conveniente en este caso pude ser que los archivos que generen los almacenen ya sea en un disco duro o en los equipos de cómputo disponibles, para  que así si posteriormente se requieren hacer cambios en el documento no tenga que volver a imprimir y así evitar el desperdicio de insumos.

Tipo de arquitectura

Esta institución no cuenta con ningún tipo de arquitectura ya que no cuentan con un servidor  y solo manejan lo que son archivos físicos y sus computadoras no cuentan ni con un cable de red para que puedan compartir información entre ellos.

Les recomendamos utilizar la estructura  SMP  ya que esta estructura  cuenta con varios procesadores que comparten todos los demás recursos del sistema como memoria principal, almacenador secundario  periféricos de entrada y salida además de que esta arquitectura comparte una sola memoria  o procesador ya que esto puede ejecutar varios programas y aplicaciones a su vez , como conclusión esta  arquitectura les sería indispensable para la presidencia ya necesitan tener en orden sus archivos y programas.

Reporte Instalacion de SQL Server 2008 en Windows Server 2003

UNIVERSIDAD TECNOLOGICA DEL VALLE DEL MEZQUITAL

PROGRAMA EDUCATIVO: Tecnologías dela Información y la Comunicación.

ASIGNATURA: ADMINISTRACION DE BASE DE DATOS.

FACILITADOR: Jacobo Morales.

NOMBRES:

Miguel Ángel Lozano Acosta.

Isamar Gonzalez Guerrero.

Jairo Esau Martinez Avalos.

Miguel Angel Jeronimo Martinez Nogal.

Brenda Martinez Silis.

Rigoberto Hernandez Hernandez.

Luis Antonio Isidoro Ramirez.

Maria Fernanda Garcia Hernandez.

CUATRIMESTRE: Cuarto.

GRUPO: “E”.

PERIODO: Septiembre – Diciembre 2012 FECHA: 19 de Septiembre del 2012.

INTRODUCCION
La recomendación para cuando vamos a probar software nuevo es usar máquinas de laboratorio o también usar máquinas virtuales. En nuestro caso, trabajamos con una máquina virtual ejecutada por Virtual Box.
En términos generales, Windows Server 2003 se podría considerar como un Windows XP modificado para labores empresariales, no con menos funciones, sino que estas están deshabilitadas por defecto para obtener un mejor rendimiento y para centrar el uso de procesador en las características de servidor por lo que sólo se utiliza la interfaz clásica de Windows.
El lenguaje de consulta estructurado o SQL es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas. Una de sus características es el manejo del álgebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar de forma sencilla información de interés de bases de datos, así como hacer cambios en ella.
El uso y la compatibilidad de estos dos softwares son una convinacion muy efectiva para el uso de bases de datos y su manejo. Demuestra la confiabilidad por la cual puede ser usada en el ambito laboral, empresarial y técnica.





Reporte
Instalación de Windows server 2003
&
SQL SERVER 2008
Para instalar Windows server 2003 ocupamos Virtual Box y crear nuestra maquina virtual.

Paso1: abrir virtual box

Paso 2: damos clic en crear nueva imagen

Paso 3: seleccionas el origen de la imagen a montar

Paso 4: una ves seleccionada, damos clic en montar y después damos doble clic sobre la imagen para iniciar.

Iniciamos la instalación carga el sistema Windows server 2003 a la maquina virtual ocupando una imagen .ISO

Paso 5: ya una ves creada la imagen y haber sido

Montada, da inicio y se abre la imagen de la maquina virtual.

Paso 6: y es donde da inicio la instalación del sistema operativo 

el cual es Microsoft Windows Server 2003.

Paso 7: en este paso es donde se selecciona cuantas particiones se van a realizar en la instalación.

Paso 8: continuamos con el proceso de instalación y los demás pasos que siguen.

Paso 9: este paso es donde se decidió cuantas particiones se van a realizar.

Paso 10: en este paso empieza a copiar archivos antes de formatear.

Paso 11: en este paso empieza a formatear, esto siempre y cuando se halla completado el paso anterior.

Paso 12: aquí es donde ya empieza el asistente de instalación y configuración de WINServer2003

Paso 13: este paso es solo de seguir completando la instalación

Paso 14: este paso consiste en dar un nombre de usuario y asignar una compañía u organización a la que pertenezca.

Paso 15: el asistente le pide la clave de producto para la activación del sistema, en dado que caso que no se tenga este solo estará de prueba.

Paso 16: aquí es donde se ingresa la clave para la activación del producto.

Investigacion Administracion BD

CONEXION DE JAVA A SQL SERVER 2008 MEDIANTE JDBC

¿Qué es JDBC?

Una de las desventajas principales de la versión 1.0.2 de Java era que no tenía soporte alguno para el acceso a bases de datos. Esto limitó la utilidad de Java en el campo de los negocios. Sin embargo, a partir de la versión 1.1 del JDK, Java proporciona un soporte completo para bases de datos por medio de JDBC (Java Database Connectivity). JavaSoft, la subsidiaria de Sun Microsystems referente a Java, introdujo JDBC el cual permite que los programas Java se conecten a cualquier base de datos utilizando diversos controladores (conocidos también como drivers) y un conjunto de objetos y métodos de la API (Interfaz de Programación de Aplicaciones) de Java.

• Arquitecturas JDBC en dos capas
  La aplicación que accede a la base de datos reside en el mismo lugar que el driver de la base de datos. El driver accederá al servidor donde corra el motor de base de datos.
  En este caso, será el driver el encargado de manejar la comunicación a través de la red.
  En el ejemplo, una aplicación java corriendo en una máquina cliente que usa el driver también local. Toda la comunicación a través de la red con la base de datos será manejada por el driver de forma transparente a la aplicación Java.

• Arquitecturas JDBC en tres capas.
  Una aplicación o applet corriendo en una máquina y accediendo a un driver de base de datos situado en otra máquina. Ejemplos de esta situación:

1. Un applet accediendo al driver a través de un Web Server
2. Una aplicación accediendo a un servidor remoto que comunica localmente con el driver
3. Una aplicación comunicando con un servidor de aplicaciones que accede a la base de datos por nosotros.

 Para establecer una conexión de base de datos SQL Server mediante NetBeans 7.0.1 a través de JDBC habrá que seguir los siguientes pasos en un sistema operativo Windows:

1. Descargarse el driver oficial de Microsoft SQL Server JDBC .

2. Una vez descargado, hay que establecer en las propiedades de nuestro proyecto el driver (Libraries> Compile) y pulsar sobre añadir JAR/Carpeta.

3. Buscar el archivo 'sqljdbc.jar' y seleccionarlo.

En estos tres pasos habremos establecido nuestro driver sql server para nuestro proyecto, de manera que ya se podrá establecer la conexión contra SQL Server a través de JDBC:

1. Importar la librería java.sql.*;

2. Establecer la cadena de conexión y demás parámetros:

JAVA:

1. try {
2.           Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
3.           String  connectionUrl = "jdbc:sqlserver://localhost:1433;" +
4.             "databaseName=Northwind;user=sa;password=123456;";
5.           Connection  con = DriverManager .getConnection(connectionUrl);
6.         } catch (SQLException  e) {
7.             System .out.println("SQL Exception: "+ e.toString());
8.         } catch (ClassNotFoundException  cE) {
9.             System .out.println("Class Not Found Exception: "+ cE.toString());
10.         }
    
    
    
    
    
    
    CODIGO 
    
    
    
    
    public class conexion {
    
        private java.sql.Connection con=null;
        private final String url ="jdbc:sqlserver://";
        private final String serverName ="localhost";
        private final String portNumber = "1433";
        private final String databaseName = "participantes";
        private final String userName = "";
        private final String password = "";
        // Indica al controlador que debe utilizar un cursor de servidor, // lo que permite más de una instrucción activa // en una conexión.
        private final String selectMethod = "cursor";
    
        private String getConnectionUrl() {
            return url + serverName + ":" + portNumber + ";databaseName=" + databaseName + ";selectMethod=" + selectMethod + ";";
        }
    
        private java.sql.Connection getConnection() {
            try {
               Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
                con = java.sql.DriverManager.getConnection(getConnectionUrl(), userName, password);
                if (con != null) {
                    System.out.println("Conexión correcta.");
                }
            } catch (Exception e) {
                e.printStackTrace();
                System.out.println("Error de seguimiento en getConnection() : " + e.getMessage());
            }
            return con;
        }
    
        /* Mostrar las propiedades del controlador y los detalles de la base de datos */
        public void displayDbProperties() {
            java.sql.DatabaseMetaData dm = null;
            java.sql.ResultSet rs = null;
            try {
                con = this.getConnection();
                if (con != null) {
                    dm = con.getMetaData();
                    System.out.println("Información del controlador");
                    System.out.println("\tNombre del controlador: " + dm.getDriverName());
                    System.out.println("\tVersión del controlador: " + dm.getDriverVersion());
                    System.out.println("\nInformación de la base de datos ");
                    System.out.println("\tNombre de la base de datos: " + dm.getDatabaseProductName());
                    System.out.println("\tVersión de la base de datos: " + dm.getDatabaseProductVersion());
                    System.out.println("Catálogos disponibles ");
                    rs = dm.getCatalogs();
                    while (rs.next()) {
                        System.out.println("\tcatálogo: " + rs.getString(1));
                    }
                    rs.close();
                    rs = null;
                    closeConnection();
                } else {
                    System.out.println("Error: No hay ninguna conexión activa");
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
            dm = null;
        }
    
        private void closeConnection() {
            try {
                if (con != null) {
                    con.close();
                }
                con = null;
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
     public static void main(String[] args) {
          conexion myDbTest = new conexion();
            myDbTest.displayDbProperties();
        }
    
    }
    
    
    }