Вы находитесь на странице: 1из 11

5.

1 Lenguajes de Mercado Un Lenguaje de marcado o lenguaje de marcas se puede definir como una forma de codificar un documento donde, junto con el texto, se incorporan etiquetas, marcas o anotaciones con informacin adicional relativa a la estructura del texto, su presentacin. Los lenguajes de marcado se pueden clasificar en: Procedimental: Describen operaciones tipogrficas Estructural: Describen la estructura lgica de un documento, pero no su tipografa Hbrido: Combinacin de ambos Las hojas de estilo o lenguajes de transformacin permiten la traduccin de anotaciones de tipo estructural a anotaciones de carcter tipogrfico. Otra posible clasificacin sera: De presentacin: Indica el formato del texto (informacin para el maquetado). De procedimientos: Orientado tambin a la presentacin pero, en este caso, se indican los procedimientos que deber realizar el SW de representacin. Descriptivo o semntico: Describen las diferentes partes en las que se estructura el documento pero sin especificar cmo deben representarse. Algunos lenguajes de marcado especficos: Documentacin electrnica RTF TeX

Wikitexto DocBook Tecnologas de internet HTML, XHTML RDF (recurso-propiedad(relacin)-valor) RSS Otros lenguajes especializados MathML VoiceXML SVG MusicXML

5.2 Tecnologas para implementacin de interfaces de usuario. En el contexto del proceso de interaccin persona-ordenador, la interfaz grfica de usuario, es el artefacto tecnolgico de un sistema interactivo que posibilita, a travs del uso y la representacin del lenguaje visual, una interaccin amigable con un sistema informtico. La interfaz grfica de usuario (en ingls GraphicalUser Interface, GUI) es un tipo de interfaz de usuario que utiliza un conjunto de imgenes y objetos grficos para representar la informacin y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulacin directa para facilitar la interaccin del usuario con la computadora. Surge como evolucin de la lnea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno grfico. Como ejemplo de interfaz grfica de usuario podemos citar el escritorio o desktop del sistema operativo Windows y el entorno X-Windows de Linux. Algunas Interfaces grficas (GUIs) son: * GPA

Intenta ser la interfaz de usuario grfica estndar de Gnu PG. GPA se hospeda en este sitio. * K Gpg Es una interfaz de usuario de KDE para Gnu PG. * Seahorse Es una interfaz de usuario de GNOME para Gnu PG. * XAP

5.3 Programacin La creacin de las interfaces de usuario ha sido un rea del desarrollo de software que ha evolucionado dramticamente a partir de la dcada de los setentas. La interfaz de usuario es el vnculo entre el usuario y el programa de computadora. Una interfaz es un conjunto de comandos o mens a travs de los cuales el usuario se comunica con el programa. Esta es una de las partes ms importantes de cualquier programa ya que determina que tan fcilmente es posible que el programa haga lo que el usuario quiere hacer. Un programa muy poderoso con una interfaz pobremente elaborada tiene poco valor para un usuario no experto. La elaboracin de una interfaz de usuario, bien diseada, exige una gran dedicacin pues generalmente las interfaces son grandes, complejas y difciles de implementar, depurar y modificar. Hoy en da las interfaces de manipulacin directa (tambin llamadas interfaces grficas de usuario, GUI por sus siglas en ingls) son prcticamente universales. Las interfaces que utilizan ventanas, conos y mens se han convertido en estndar en los materiales computacionales La interfaz representa el punto de encuentro entre el usuario y la computadora. En esta interaccin, el usuario juzga la utilidad de la interfaz; el hardware y el software se convierten en simples herramientas sobre los cuales fue construida la interfaz. La definicin de interfaz en si misma es un tanto arbitraria, aunque esto depende de la naturaleza de la tarea que se tiene enfrente. Existen muchos tipos de software para la creacin de interfaces de usuario. El sistema de ventanas permite la divisin de la pantalla en diferentes regiones rectangulares, llamadas ``ventanas''. El sistema de ventanas XWindows para Unix divide la funcionalidad de la ventana en dos capas: el sistema de ventanas, el cual es la interfaz funcional, y el administrador de ventanas. El sistema de ventanas provee de procedimientos que permiten a la aplicacin el dibujar figuras en la

pantalla y sirve como medio de entrada de las acciones del usuario. El administrador de ventanas le permite al usuario final el mover las ventanas por la pantalla, y es el responsable de desplegar las lneas de ttulo, bordes e conos alrededor de las ventanas. La parte central de un sistema de ventanas es el conjunto de herramientas (toolkit), el cual contiene los objetos grficos (widgets ms empleados tales como mens, botones, barras de scroll, y campos para entrada de texto. Eltoolkit generalmente se conecta a los programas de aplicacin a travs de una serie de procedimientos definidos por el programador. La funcin de estos procedimientos es el decidir la forma en que se comportarn los objetos grficos. 5.3.1 Del Lado del Cliente Con la programacin del lado del cliente se pueden validar algunos de los datos en la mquina cliente antes de enviarlos al servidor. Esto proporciona a los usuarios informes de error inmediatos, mientras siguen en esa pgina de formulario y sin necesidad de volver atrs tras recibir un mensaje de error. Puede resultar necesario acceder a una base de datos para validar determinados valores, mientras que no suele disponer de un acceso directo a la base de datos en la mquina del cliente, aunque ese acceso a la base de datos es factible. Los clientes tambin se pueden mejorar con otras tcnicas. Por ejemplo, podemos usar controles ActiveX y Applets de Java. Aunque estas tecnologas son bastantes diferentes, el resultado final es similar: la interfaz del cliente puede hacer cosas que no puede hacer normalmente con HTML. De momento, la diferencia principal entre ambas es que los controles ActiveX slo funcionan en IE. Las Applets de Java funcionan tanto en IE como en Navigator, aunque no todos los Applets funcionan igual de bien en ambos exploradores. 5.3.1 Del Lado del Servidor La programacin del lado del servidor es una tecnologa que consiste en el procesamiento de una peticin de un usuario mediante la interpretacin de un script en el servidor web para generar pginas HTML dinmicamente como respuesta Los primeros servidores web permitan visualizar exclusivamente informacin esttica. Esto present pronto una limitacin; sobre todo desde el momento en el que la actividad publicitaria y comercial comenz a concentrarse tambin en Internet. La primera solucin tcnica realizada fue la posibilidad de que el servidor web ejecutase programas residentes en la mquina de servicio. Esta tecnologa,

conocida como Common Gateway Interface (CGI) permita lanzar programas escritos principalmente en C o Perl. Si bien la tecnologa CGI resolva el problema de la presentacin exclusiva de informacin esttica, al mismo tiempo presentaba dos limitaciones importantes: el problema de seguridad que poda representar el hecho de que mediante una peticin se pudiesen ejecutar programas indeseados en el servidor y la carga del servidor (si una pgina que lanzaba un programa era llamada desde 100 clientes simultneamente, el servidor ejecutaba 100 procesos, uno por cada cliente que solicitaba dicha pgina). Para resolver estos problemas, se busc desarrollar una tecnologa que permitiera ejecutar, en un nico proceso del servidor, todos los pedidos de ejecucin de cdigo sin importar la cantidad de clientes que se conectaban concurrentemente. As surgieron los denominados servlets, basados en la tecnologa Java de Sun Microsystems, y los filtros ISAPI de Microsoft. stos permitan ejecutar cdigo en un nico proceso externo que gestionaba todas las llamadas realizadas por el servidor web, impidiendo al mismo tiempo que el servidor web pueda ejecutar programas del sistema operativo. No obstante, de este modo se limitaron los problemas de prestacin y seguridad de la tecnologa CGI, y no se resolvi el problema representado por un desarrollo demasiado costoso en trminos de tiempo. Asimismo, se hizo necesario que dos figuras profesionales distintas trabajen en un nico proyecto: el programador (que conoce el lenguaje de programacin utilizado del lado del servidor) y el diseador web (que conoce la parte grfica y el lenguaje HTML). Para resolver estas limitaciones, fueron desarrollados lenguajes que pueden ser incluidos al interno de archivos HTML. Estos comandos pueden ser interpretados (como por ejemplo las pginas ASP o PHP) o precompilados (como en las pginas JSP o ASP.NET). Con la utilizacin de esta tecnologa se buscaba, tambin, desarrollar aptitudes de diseador web en los programadores y de programador en los diseadores (se esperaba con ello el hacer ms fcil y veloz el desarrollo de scripts del lado del servidor).

UNIDAD 6 INTEGRACIN DE APLICACIONES DISTRIBUIDAS. 6.1 Asignacin de las Partes de la Aplicacin Una vez realizada la identificacin de las partes, la valoracin de la sensibilidad nos lleva a darle un valor y a evaluar que tan crticos son: la informacin y los dems elementos de la organizacin como el software, hardware, y el valor de los

servicios que provee la aplicacin. Cuando hablamos de valor debemos tener claro que a la informacin y a los servicios de red se les debe asociar un monto simblico, mientras el software y el hardware se evalan en dinero, de acuerdo a los criterios que se describen a continuacin. * Confidencialidad La cual se refiere al servicio prestado para proteger la informacin principalmente de accesos no autorizados. Por ejemplo si hay un circuito virtual entre dos sistemas, este servicio debera ser capaz de proteger la "revelacin" de la informacin que viaja por dicho circuito de un tercer atacante que intenta capturar dichos datos. Informacin del personal, investigaciones y reportes de desarrollo son algunos de los ejemplos de informacin que necesita confidencialidad. * Integridad El servicio de integridad es el que permite que la informacin sea adecuada, completa y autntica en el momento de ser procesada, presentada, guardada o transmitida. Por ejemplo si uno transmite datos de control de cualquier tipo por una red, mnimo desea que estos no lleguen daados o defectuosos porque las consecuencias finales podran ser desastrosas (e.g. datos que controlen un mecanismo de armas). En algunos casos mantener y garantizar esta caracterstica es ms importante que la confidencialidad. * Disponibilidad Como su nombre lo indica la disponibilidad incluye todos los servicios de red que se pueden tener y prestar en determinado momento. Un esquema tpico con el cual se maneja la disponibilidad es el de dos dominios donde el primero coloca un valor a la informacin que se puede destruir completamente y nunca ms podr ser consultada, el segundo dominio coloca valores en tiempo de disponibilidad por ejemplo: el servicio de impresora no est disponible por 1 hora, 2 horas o lo contrario est disponible solo por 3 horas, etc; este ltimo dominio conocido como "over time" sirve para encontrar umbrales de disponibilidad; por ejemplo, "si despus de 2 horas no est disponible el servidor de la base de datos de empleados hay que programar un procedimiento manual". 6.2 Distribucin de la Aplicacin Cada aplicacin considera el nodo local como una cache de los recursos disponibles en todo el sistema distribuido. En el caso de aplicaciones centralizadas, stas se limitan a utilizar dicha cache ignorando la ubicacin de los recursos (pensando que son locales). En cambio, las distribuidas pueden solicitar la asignacin de recursos en las ubicaciones que deseen y controlar la revocacin

de tal modo que se mantengan en el nodo local (en la cache) los recursos convenientes (revocando primero aquellos recursos que sea ms barato traer al nodo local, y no aquellos que sea costoso volver a obtener debido a su ubicacin u otros factores). En este sentido es crucial que el kernel permita a las aplicaciones escoger las unidades de recurso que han de revocarse, de otro modo el sistema escogera l mismo las unidades a revocar y ello sin tener una idea exacta de para qu se emplea cada una de ellas. El kernel permite que peticiones locales al sistema puedan operar con recursos remotos, eso es todo lo que hace. Por un lado, una aplicacin centralizada se puede distribuir ``automticamente'' interponiendo entre ella y el sistema un algoritmo distribuido de asignacin y revocacin de recursos. De este modo la distribucin ser como sigue: * Ante una peticin de recursos, el algoritmo de asignacin puede solicitar recursos remotos (o locales) al kernel. * La aplicacin realizar peticiones al sistema empleando dichos recursos de manera transparente. Sean stos locales o remotos, el kernel atender las peticiones. * Ante una eventual revocacin, el algoritmo de revocacin empleado puede optar por eliminar primero los recursos que sean mas ``baratos'' en trminos de posicin y uso. Por otro lado, una aplicacin distribuida puede emplear algoritmos especficos de asignacin y revocacin sin necesidad de conformarse con un algoritmo general que funcione bien en el caso medio. Cuando el sistema ve que el recurso es remoto es la propia implementacin del servicio la que contacta con el nodo remoto usando protocolos especficos de cada aplicacin (esto es, realizando una up-call). Esto no es lo mismo que emplear una IPC distribuida que alcanza un ncleo remoto sin que el local se entere de ello. Si se distribuyen slo las IPCs podemos tener problemas en el uso de referencias a memoria de usuario en las llamadas al sistema (una referencia local no es vlida en el nodo remoto). Estas pueden ocasionar mensajes extra en la red o el envi de datos innecesarios. 6.3 Instalacin de los Componentes Se ha convertido en un principio ampliamente aceptado en el diseo de aplicaciones distribuidas la divisin de la aplicacin en componentes que ofrezcan servicios de presentacin, institucionales y de datos. Los componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos estn organizados en forma de apilamiento para que los componentes que

se encuentran por "encima" de una capa determinada utilicen los servicios proporcionados por sta, y un componente especifico utilizar la funcionalidad proporcionada por otros componentes de su propia capa, y otras capas "inferiores", para realizar su trabajo. Esta visin dividida de una aplicacin tambin se puede aplicar a los servicios. Desde un punto de vista de alto nivel, se puede considerar que la solucin basada en servicios est formada por varios servicios, los cuales se comunican entre s pasando mensajes. Desde el punto de vista conceptual, los servicios se pueden considerar como componentes de la solucin global. Sin embargo, internamente el servicio est formado por componentes de software, al igual que cualquier otra aplicacin, los cuales se pueden agrupar de forma lgica en servicios de presentacin, institucionales y de datos. 6.4 Configuracin de los Componentes Las aplicaciones requieren datos de configuracin para funcionar tcnicamente. Los valores que modifican el comportamiento de las directivas (seguridad, administracin operativa y comunicaciones) se consideran datos de configuracin. Los datos de configuracin se conservan en los archivos de configuracin de .NET a nivel de usuario, equipo y aplicacin. La configuracin personalizada almacenada aqu se puede definir con cualquier esquema y se puede tener fcil acceso mediante el uso de la clase ConfigurationSettings en su aplicacin. Es muy importante tener en cuenta la confidencialidad de seguridad de la conexin; por ejemplo, no debe almacenar cadenas de conexin SQL en texto no cifrado en los archivos de configuracin XML, especialmente si contienen credenciales SQL. Debera limitar el acceso a la informacin de seguridad a los operadores adecuados y a fin de disponer de una mayor seguridad, debera considerar la firma digital de la informacin para asegurarse de que los datos de configuracin no se han modificado. Los datos de configuracin se pueden almacenar en varios lugares, cada uno de ellos con sus ventajas e inconvenientes: Archivos de configuracin XML: el almacenamiento de los datos de configuracin aqu permite a los clientes de su aplicacin trabajar sin conexin y este modelo resulta fcil de implementar. Con aplicaciones de cliente enriquecido, este enfoque puede suponer un aumento en los costos de administracin de los cambios, ya que requiere que todos los clientes dispongan de la misma informacin de configuracin.

SQL Server o el almacn de datos de la aplicacin: se trata de la ubicacin de almacenamiento normal para los datos de configuracin administrados por la aplicacin, pero an ms para los metadatos de las aplicaciones. Si almacena aqu la configuracin, se recomienda que guarde los metadatos en una base de datos de SQL Server distinta de la de los datos empresariales. El acceso a la base de datos supone a menudo una mejora en el rendimiento, por lo que debera considerar el almacenamiento en cach. Active Directory: dentro de una organizacin, puede decidir almacenar los metadatos de la aplicacin en Active Directory. De este modo, los clientes del dominio pueden disponer de los metadatos. Tambin puede asegurar la informacin en Active Directory con ACL de Windows, asegurando que slo los usuarios y las cuentas de servicio autorizadas podrn tener acceso al mismo. Cadenas del constructor: si utiliza componentes basados en Enterprise Services, puede agregar datos de configuracin a la cadena del constructor para los componentes. Otras ubicaciones para casos especiales: stas incluyen el Registro de Windows, el almacn de Windows Local Security Authority (LSA) y las implementaciones personalizadas. Se utilizan en casos muy especiales y agregan requisitos para los privilegios de aplicaciones en el equipo y los mecanismos de implementacin. Soluciones de administracin de configuracin de terceros que pueden proporcionar tambin caractersticas de control de versiones e implementacin. 6.5 Configuracin de la Aplicacin Los componentes de proceso de usuario generalmente requieren los siguientes valores de configuracin: Informacin de la ubicacin para llegar a los componentes de procesos empresariales y los componentes de acceso a datos. Datos de conexin (como una cadena de conexin o una ruta de archivo) para el recurso que controla los datos de procesos de usuario persistentes para procesos de larga ejecucin. Configuracin en agentes de servicios Los agentes de servicios necesitan disponer de informacin de configuracin para conectarse al servicio externo a travs de los servicios Web, colas de mensajes u otros medios. El esquema y los datos de configuracin dependen del servicio especfico al que se est teniendo acceso.

Configuracin en los componentes de acceso a datos Los componentes de acceso a datos normalmente necesitan lo siguiente: Necesitan tener la capacidad de asignar nombres de orgenes de datos lgicos a parmetros de la conexin fsica (por ejemplo, para asignar la base de datos "Ventas" a una cadena de conexin real). Si los componentes de acceso a datos realizan un enrutamiento dinmico de datos, necesitar contar con datos de configuracin que expresen los parmetros (por ejemplo, regin del cliente), algoritmos (por ejemplo, hash) y destinos del enrutamiento (por ejemplo, cadenas de conexin para las bases de datos). Es comn incluir la lgica del enrutamiento dinmico de datos en un componente de utilidad distinto. 6.6 Evaluar Desempeo Los sistemas informticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podran producir resultados incorrectos o podran pararse antes de terminar la computacin que estaban realizando. El diseo de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre s: Redundancia hardware (uso de componentes redundantes) y recuperacin del software (diseo de programas que sean capaces de recuperarse de los fallos). En los sistemas distribuidos la redundancia puede plantearse en un grano mas fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operacin continuada de aplicaciones crticas. La recuperacin del software tiene relacin con el diseo de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo. Los sistemas distribuidos tambin proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporcin de tiempo que est disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podra desplazarse a otra estacin de trabajo; un proceso servidor podra ejecutarse en otra mquina.

El trmino 'recurso' es bastante abstracto, pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos. La idea de comparticin de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clsicos desde siempre han provisto comparticin de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automticamente los beneficios de la comparticin de recursos. Los recursos en un sistema distribuido estn fsicamente encapsulados en una de las computadoras y slo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la comparticin de recursos sea efectiva, sta debe ser manejada por un programa que ofrezca un interfaz de comunicacin permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente. Surge el trmino genrico de gestor de recursos. 6.7 Optimizacin del Desempeo Un gestor de recursos es un modulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas polticas y mtodos especficos junto con requisitos comunes para todos ellos. stos incluyen la provisin de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localizacin; la traslacin de nombre de recurso a direcciones de comunicacin y la coordinacin de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia. Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos.

Вам также может понравиться