Cintillo Institucional
Diferencias entre las revisiones 1 y 2
Versión 1 con fecha 2008-08-11 22:03:28
Tamaño: 29047
Editor: ssole
Comentario:
Versión 2 con fecha 2008-08-20 19:41:09
Tamaño: 29869
Editor: lcaballero
Comentario:
Los textos eliminados se marcan así. Los textos añadidos se marcan así.
Línea 1: Línea 1:
||<tablewidth="98%" tablestyle="text-align: left;"style="border: medium none ;"> ||
||||<bgcolor="#ffffcc" style="text-align: center;">.: [[SAID|Inicio]] | [[said/que_es_said|¿Qué es SAID?]] | [[said/quien_usa_said|¿Quién usa SAID?]] | [[said/requerimientos|Requerimientos]] | [[said/recursos|Recursos]] | [[said/descargas|Descargas]] | [[said/paticipa|¡Participa!]] | [[said/licencia|Licencia]]:. ||
Línea 277: Línea 280:


||<tablewidth="98%" tablestyle="text-align: left;"style="border: medium none ;"> ||
||||<bgcolor="#ffffcc" style="text-align: center;">.: [[SAID|Inicio]] | [[said/que_es_said|¿Qué es SAID?]] | [[said/quien_usa_said|¿Quién usa SAID?]] | [[said/requerimientos|Requerimientos]] | [[said/recursos|Recursos]] | [[said/descargas|Descargas]] | [[said/paticipa|¡Participa!]] | [[said/licencia|Licencia]]:. ||

.: Inicio | ¿Qué es SAID? | ¿Quién usa SAID? | Requerimientos | Recursos | Descargas | ¡Participa! | Licencia:.

Propuesta para la nueva arquitectura y el lenguaje de programación del proyecto derivado del SAID

Estatus actual del SAID

SAID es una excelente herramienta computacional que nace para respuesta al problema de falta de software libre administrativo en la Administración Pública Nacional (APN), debido al crecimiento de la aplicación y exigencias de los entes, que cada día lo utilizan, han surgido una serie de problemas técnicos que impiden su evolución: Desarrollado en un lenguaje de programación sin soporte completo para la orientación a objetos. Diseño de la aplicación sin uso de patrones de diseño de programación. El servidor es totalmente monolítico y construido bajo un esquema procedural. Por ser procedural, no contiene clases ni objetos. No tiene la posibilidad de que otra aplicación pueda ser conectada al SAID. Todos estos factores hacen que SAID sea una aplicación difícil de mantener a nivel de código, y cause demoras en la publicación de sus nuevas versiones, además de que la corrección de los errores encontrados sea un poco lenta y se puede dar respuesta efectiva a nuevas funcionalidades requeridas por los entes que la utilizan. La interoperabilidad entre sistemas administrativos se hace imposible con este enfoque y es una de las preocupaciones actuales de la APN.

Proyecto derivado del SAID

Las aplicaciones para gestionar recursos empresariales (tipo ERP) representan una necesidad para la industria nacional, donde se utiliza exclusivamente software privativo para la automatización de procesos de gestión empresarial.

Requerimientos del proyecto

  • Debe ser un sistema distribuido y modular.
  • Totalmente orientado a objetos.
  • Aplicación con clientes WEB y clientes de escritorio.
  • Aplicar el paradigma de programación Modelo-Vista-Controlador (MVC).
  • Basada en arquitectura orientada a servicios.
  • Debe ser Software Libre.

SOA (Arquitectura Orientada a Servicios)

SOA [1] es un estilo de arquitectura de sistemas de computación que permite crear y usar procesos empaquetados como servicios. SOA define y proporciona la infraestructura que permite que distintas aplicaciones intercambien datos y participen en diferentes procesos. Los servicios están débilmente acopladas con los sistemas operativos y lenguajes de programación que están detrás de las aplicaciones.

Un servicio consta de una implementación que provee lógica de negocio y datos, un contrato de servicio que especifica las operaciones y las pre-condiciones y post-condiciones, y una interfaz que expone la funcionalidad físicamente.

Los servicios representan grupos lógicos de operaciones relacionadas con algún concepto del negocio. Las aplicaciones front-end usan los servicios y/o los exponen, los repositorios de servicios almacenan los contratos de servicios, y el bus de servicios interconecta las aplicaciones front-end con los servicios.

Para comunicarse entre sí, los servicios se basan en una definición formal independiente de la plataforma subyacente y el lenguaje de programación, como por ejemplo WSDL [9].

Los servicios pueden clasificarse según su propósito en servicios orientados a procesos que realizan los procesos del negocio, servicios intermediarios, básicos y públicos.

elementos_soa.png

Conceptos involucrados en SOA

  • Servicio: una función sin estado, auto-contenida, que acepta llamadas y devuelve respuestas mediante su interfaz. Los servicios no dependen del estado de otras funciones o procesos.
  • Orquestación: SOA se basa en un proceso de negocio para vincular y secuenciar los servicios, este proceso es conocido como la orquestación.
  • Proveedor: La función que brinda un servicio en respuesta a una llamada o petición desde un consumidor.
  • Consumidor: La función que consume el resultado de un servicio provisto por un proveedor.

Características de SOA

SOA separa funciones en servicios que se pueden distribuir, combinar y reutilizar para crear aplicaciones. Estos servicios se comunican entre sí mediante el paso de datos desde un servicio a otro, o coordinando una actividad entre dos o más servicios. Los servicios son independientes entre si, tiene interfaces bien definidas e invocables, las cuales pueden ser llamadas en secuencias definidas para formar procesos de negocios. La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación, o de la tecnología de desarrollo.

Este estilo de arquitectura promociona la reutilización a nivel macro (servicio) más que a nivel micro (clases), también puede simplificar la interconexión a, y uso de, activos de información existentes.

SOA promociona el objetivo de separar a los usuarios de las implementaciones del servicio. En consecuencia, los servicios pueden correr en varias plataformas distribuidas y pueden ser accedidos mediante redes.

Plantea la reusabilidad e interoperatividad de las aplicaciones obtenidas. Los servicios pueden ser pasos, subprocesos y procesos de la organización como se muestra en la figura Nº 2.

servicios_soa.png

Una arquitectura orientada a servicios permite diseñar sistemas de software que dan servicio a otras aplicaciones a través de interfaces públicas y detectables, y donde los servicios pueden ser invocados a través de una red. La clave de SOA es la independencia de los servicios.

Cuando se implementa una arquitectura orientada a servicio usando tecnología de servicios web, se crea una nueva forma de construir aplicaciones dentro de un modelo de programación más flexible. SOA es ambas cosas, una arquitectura y un modelo de programación. La clave es que la interacción entre los servicios es especificada por los desarrolladores de las aplicaciones de una manera ad hoc.

El diseño de una arquitectura orientada a servicios permitirá que sistemas existentes puedan ser integrados a la arquitectura, y con el tiempo puedan ser convertidos en componentes o reemplazados con otros proyectos.

¿Como implantar SOA?

La Arquitectura orientada a servicio no está condicionada a una tecnología especifica. Ésta puede ser implementada usando un amplio rango de tecnologías, incluyendo SOAP [5], RPC, DCOM [11], CORBA [12], Servicios Web o WCF. SOA puede ser implementado usando uno a más de estos protocolos. Los servicios web pueden ser utilizados para implementar una arquitectura orientada a servicios. Uno de los principales objetivos de los servicios web en una arquitectura orientada a servicios, es hacer de la construcción de bloques funcionales accesibles a través de protocolos estándar de Internet que son independientes de plataformas y lenguajes de programación.

Selección de una arquitectura orientada a servicios

En base a las características ofrecidas por SOA, se plantea que el proyecto derivado de SAID sea desarrollado bajo este enfoque, donde las diferentes funcionalidades de la aplicación sean servicios que puedan ser utilizados por otras aplicaciones dentro de CENDITEL. Con la finalidad de usar eficientemente la Arquitectura orientada a servicios se deben tener en cuenta los siguientes requerimientos:

  • Interoperabilidad entre los diferentes sistemas y lenguajes de programación. Esta característica representa la base para la integración de aplicaciones en diferentes a través de protocolos de comunicación.
  • Distribución de recursos: los servicios en SOA pueden encontrase de manera distribuida y por lo tanto se debe establecer y mantener un flujo de datos a un meta repositorio de datos que contenga información sobre los servicios: localización física, restricciones técnicas, etc.

Arquitectura planteada para la nueva versión del SAID

La arquitectura de software [14] de un sistema es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos. La arquitectura de software es importante por las siguientes razones:

  • Las representaciones de la arquitectura de software facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema.
  • La arquitectura destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software que se construirá, y es tan importante en el éxito final del sistema como una entidad operacional.
  • La arquitectura constituye un modelo relativamente pequeño y comprensible de como está estructurado el sistema y de como trabajan juntos sus componentes.

La arquitectura que se plantea para el desarrollo del proyecto derivado del SAID es una Arquitectura Cliente/Servidor [2]. La arquitectura Cliente/Servidor describe la relación entre dos programas, en el que un programa: el cliente, hace una solicitud de servicio a otro programa: el servidor, donde se espera que el servidor cumpla con la petición. En una red, el modelo cliente/servidor provee una manera conveniente para interconectar programas que se distribuyen de manera eficiente en diferentes lugares. La mayoría de las aplicaciones de Internet, como el correo electrónico, el acceso a la Web y acceso a bases de datos, se basan en el modelo cliente/servidor.

Características de la arquitectura cliente/servidor

  • Permite distribuir los roles y las responsabilidades de un sistema de computación entre varias computadoras independientes.
  • Todos los datos son almacenados en el servidor.
  • El mantenimiento de aplicaciones se centraliza en la actualización del servidor.
  • Los servidores pueden controlar de mejor manera el acceso y los recursos, para garantizar que sólo aquellos clientes con la permisología apropiada puedan acceder y cambiar datos.

El diseño de la arquitectura planteado se hace en inspirado en la revisión de la arquitectura del sistema de gestión empresarial libre TinyERP. Seguidamente se describe la arquitectura propuesta:

align="center", height="300",width="300"

Descripción de la Arquitectura

1.Arquitectura del Servidor

Núcleo de la aplicación:

En general el núcleo de la aplicación debería asegurar los siguientes aspectos:

  • Personalización: El sistema debe ser lo suficientemente flexible para ser personalizado fácilmente y a la vez pueda ser usado como un framework para desarrollo de módulos propios. Ademas de las oportunidades de personalización un sistema flexible significa que se puedan desarrollar módulos, plugins e interfaces agregables basadas en el mismo sistema. El sistema debe proveer varios niveles de personalización:
    • Personalización a alto nivel: personalización a través de la edición de metadatos. Lo que significa que el sistema debe ser personalizable mediante la edición de datos fácilmente legibles y entendibles. De esta manera expertos en la lógica deberían ser capaces de personalizar el sistema sin tener un conocimiento profundo de programación.
    • Personalización a bajo nivel (aplicación como un framework): orientado a aquellos desarrolladores que quieren introducirse en los detalles o necesitan mayor flexibilidad del sistema. El sistema debería poder usarse como un framework de desarrollo de la aplicación.
  • Actualización: El sistema debe proveer mecanismos de actualización que no tengan impacto en la personalización. Actualizar, por ejemplo, el núcleo de la aplicación no debe implicar nuevas adaptaciones de la personalización o información almacenada en la base de datos.
  • Localización: El sistema debe soportar múltiples idiomas y esquema de múltiples cuentas. Una forma simple de internacionalización es proveer traducciones para la interfaz de usuario y esquemas de cuentas locales. El lenguaje es definido a nivel de usuario. Podría diferenciarse entre traducción de partes estáticas de la interfaz gráfica del usuario (menús, campos, etc), partes dinámicas de la interfaz gráfica (flujo de trabajo, estados..), y contenidos (nombre de artículos, etc). Es muy importante para sistemas basados en software libre proveer internacionalización o localización, pues proporcionar la flexibilidad para soporte de varios países e idiomas contribuye a tener una base de usuarios mas amplia, reduciendo así la posibilidad de que se haga un fork[13] del proyecto, lo que significa dividir el código base de sistema en otros proyectos lo que genera una fragmentación de la comunidad y menos colaboración.
  • Usabilidad: La interfaz de usuario debe ser diseñada de acuerdo a la información necesaria para una tarea. Una tarea simple no debe requerir navegar a través de muchas pantallas. Para tareas rutinarias atajos de teclado y de interfaz deben ser proporcionados.
  • Escalabilidad: Debe garantizarse que el sistema soportará todos los usuario futuros. el sistema debería soportar grandes volúmenes de transacciones con constantes tiempos de respuesta.
  • Seguridad: mecanismos de seguridad basado en roles o usuarios permiten definir diferentes niveles de acceso. Así los usuarios tiene permitido ver y modificar solo los datos que se necesitan para su trabajo.
  • Independencia del SO: independencia del sistema operativo permite correr el sistema en varias plataformas. es una característica necesaria para el lado del cliente, si los usuarios tienen diferentes sistemas operativos.
  • Independencia de base de datos: Implica usar características comunes proporcionadas por todas las base de datos soportadas. Es importante tener en cuenta quela base de datos tiene una gran influencia en la escalabilidad del sistema.
  • Interfaces: el sistema debe poder conectarse con otros sistemas y poder intercambiar información.

Para satisfacer todos los aspectos anteriormente expuestos y para garantizar un sistema flexible y extensible se propone un núcleo de arquitectura genérico que no contiene ninguna funcionalidad y permita agregar o engranar componentes.

  • Luego el núcleo de la aplicación estaría formado por la agregación de algunos componentes básicos como los siguientes: Unidades de Medida.
  • Monedas
  • Idiomas
    • Selección de Idioma
    • Exportar Idioma
    • Importar Idioma
  • Usuarios: Usuarios y Grupos
  • Roles
  • Seguridad
    • Definición de acceso por items de menú: Se puede definir el menú mediante un árbol por niveles, asi podría manejarse el acceso tanto a un nivel detallado de items de menú asi como a nivel global, a nivel de módulo, etc.
  • Administración de Módulos:
    • Instalación y desinstalación de módulos.

En este sentido, el núcleo genérico podría utilizarse para desarrollar cualquier tipo de aplicación mediante la agregación de componentes que definan la naturaleza de la aplicación, sean sistemas administrativos, ERP, gestores de contenidos, blogs, páginas, web, etc.

Objetos del Negocio

Son vistos como los datos de la aplicación: reportes personalizados, usuarios, compras, etc. Los objetos del negocio serán descritos usando la técnica de mapeo objeto/relacional (ORM). Al adoptar el enfoque SOA se plantea que los diferentes objetos del negocio puedan encontrarse de manera distribuida y de esta manera obtener las ventajas que brinda este enfoque.

Generador de Reportes:

Se propone que los reportes puedan ser generados de dos formas:

  • Reportes establecidos y que podrán ser generados desde la interfaz de usuario
  • Reportes personalizados: reportes específicos que podrán ser creados por el usuario de acuerdo a sus necesidades utilizando alguna herramienta para generar reportes.

Servicios Web:

Se ofrecerá un interfaz común para los servicios web: SOAP, XML. Los servicios web permitirán la comunicación entre el cliente y el servidor.

Mapeo Objeto/Relacional:

Esta técnica de programación, conocida por sus siglas en inglés ORM, permite convertir datos entre sistemas con incompatibilidad de tipos en bases de datos relacionales y lenguajes de programación orientados a objetos. Esto crea una “base de datos orientada a objetos” de forma virtual y luego el lenguaje de programación puede utilizarla. El uso de esta técnica puede verse como un intento de resolver el lado equivocado del problema de no coincidencia entre el enfoque relacional y el de objetos. El correcto mapeo en el modelo relacional es entre el objeto y su tipo. El estado del arte de las bases de datos orientadas a objetos no es muy avanzado en software libre por lo que se plantea utilizar ORM para solventar esta brecha entre modelos relacionales y orientados a objetos.

SAFET:

Como gestor de flujo de trabajo se utilizará el Sistema Automatizado para la Firma Electrónica y Estampado de Tiempo (SAFET) desarrollado por equipo de seguridad de CENDITEL, éste permitirá la incorporación de la Firma Electrónica y el Estampado de Tiempo en la gestión de los documentos electrónicos dentro del SAID.

2.Arquitectura del Cliente

La Arquitectura planteada para el cliente está formada por los siguientes componentes:

  • Interfaz Web/Escritorio: Se plantea una interfaz para un sistema web, así como también una interfaz para una aplicación de escritorio.
  • Ventanas
  • Acciones
  • Reportes
  • Asistentes (wizards): Se propone desarrollar asistentes que permitan, por ejemplo, la instalación de módulos funcionales.

Lenguaje de programación

Existen una gran cantidad de lenguajes de programación que se pueden utilizar para el proyecto derivado del SAID, no obstante se proponen lenguajes interpretados que garantizan la portabilidad en diferentes sistemas operativos porque fueron diseñados para ser ejecutados por medio de un intérprete. Los lenguajes propuestos son:

  • Perl, es un lenguaje de propósito general originalmente desarrollado para la manipulación de texto y que ahora es utilizado para un amplio rango de tareas incluyendo administración de sistemas, desarrollo web, programación en red, desarrollo de GUI y más.
  • Ruby, lenguaje de programación reflexivo y orientado a objetos, combina una sintaxis inspirada en Python, Perl. Ruby está diseñado para la productividad y la diversión del desarrollador, siguiendo los principios de una buena interfaz de usuario, sostiene que el diseño de sistemas necesita enfatizar las necesidades humanas más que las de la máquina.
  • Python, habitualmente se compara con TCL, Perl, Scheme, Java y Ruby. Python es considerado como la oposición leal a Perl, lenguaje con el cual mantiene una rivalidad amistosa. Los usuarios de Python consideran a éste mucho más limpio y elegante para programar.

Algunas estadísticas de los lenguajes de programación

Ohloh, permite encontrar proyectos opensource (código libre) clasificados por etiquetas ó tags. Cada proyecto incluye informaciones sobre el tiempo que el proyecto lleva existiendo y el crecimiento que ha sufrido en los últimos años en cuanto a participación se refiere, este sitio permite hacer una comparación de proyectos por lenguaje de programación. Entre los lenguajes de programación que estamos proponiendo obtuvimos el siguiente gráfico.

ppr.png

SourceForge, Es una central de desarrollos de software que controla y gestiona varios proyectos de software libre y actúa como un repositorio de código fuente. Realizando una búsqueda de proyectos registrados por nombre de lenguaje de programación, se pudo obtener los siguientes resultados:

  • Perl = 3435
  • Ruby = 650
  • Python = 3974

TIOBEdeclara a Python el lenguaje del 2007, El índice TIOBE que mide la popularidad de los lenguajes de programación actuales basándose mensualmente en la disponibilidad mundial de ingenieros, cursos, vendedores de software, búsquedas populares en Google, MSN, Yahoo! y YouTube.

Este reconocimiento se otorgó porque Python logró aumentar en un 58 % su popularidad durante el año pasado, ubicándolo en un sólido 6o lugar y por fin logrando superar al venerable Perl.

TIOBE también afirma que Python se ha convertido en el “lenguaje de pegamento por defecto”siendo .especialmente amado por los administradores de sistemas y los build managers”.

tpci_trends.png

Lenguaje de programación seleccionado

En función de hacer una aplicación totalmente nueva, construida a partir de la experiencia obtenida de la versión actual del SAID y que pueda dar respuesta a los requerimientos expresados se propone el lenguaje de programación Python, a continuación se listan las características de dicho lenguaje.

  • Permite dividir el programa en módulos reutilizables desde otros programas Python.
  • Tiene una gran librería estándar, usada para una diversidad de tareas.
  • Su sintaxis simple, clara y sencilla.
  • Es un lenguaje interpretado, lo que ahorra un tiempo considerable en el desarrollo del programa, pues no es necesario compilar ni enlazar.
  • Fue diseñado para ser leído con facilidad, utilizando la indentación. Esto hace que la misma sea obligatoria, ayudando a la claridad y consistencia del código escrito (incluso entre varios desarrolladores).
  • Todo es un objeto (incluso las clases). Las clases, al ser objetos, son instancias de una metaclase. Python además soporta herencia múltiple y polimorfismo.
  • Posee una licencia de código abierto, denominada Python Software Foundation License , que es compatible con la licencia GPL.
  • Tiene distintos framework de desarrollo; Django, Zope, Turbogears, Pylons.

Algunas razones para la selección

  • Los estudios de ERP analizados a nivel medio por el equipo están basados en Python (TinyERP, ERP5.).
  • La posibilidad de obtener formación en Python es mas alta que con los otros lenguajes propuestos.
  • La información y documentación de Python es bastante amplia.
  • Su sencillez y facilidad de aprendizaje, garantiza que el equipo de desarrollo pueda adoptarlo de una manera mas rápida.
  • SAID actualmente cuenta con scripts implementados en Python.
  • Por ser un lenguaje de programación sencillo tiene mas posibilidades para la integración de nuevos desarrolladores en el proyecto.
  • Cuenta a nivel de librerías y módulos con los necesarios para desarrollar SAID.
  • Existe la posibilidad de que el proyecto se base en el núcleo o utilice código de los ERP (TiNyERP ó ERP5).

Librerías ó módulos de interés en Python

  • SOA
    • xmlrpc
    • soappy
  • Pruebas Unitarias
    • unit
    • nose
  • Encriptamiento y Seguridad
    • crypto
    • gpg
    • gnupginterface
  • Base de Datos
    • pygresql
    • pgsql
    • mysqldb
    • psycopg
    • ldap
  • Gráficos y Imágenes
    • gd
    • gdchart
    • pychart
    • imaging
  • Mensajería y Comunicaciones
    • jabber
    • email
    • irclib
  • Documentación y Documentos
    • docutils
    • epydoc
    • gendoc
    • libxml
    • xml

Resumen de los aspectos relacionados a la nueva arquitectura

  • Se plantea que el proyecto derivado del SAID sea una aplicación con arquitectura cliente/servidor
  • El lenguaje de programación propuesto es Python
  • Se propone una base de datos objeto relacional PostgreSQL
  • Los objetos del negocio serán modelados con un sistema de mapeo objeto/relacional

Conceptos Relacionados

  • Servicio web [3]: definido por la W3C como “un sistema de software diseñado para soportar interacción interoperable entre máquinas sobre una red”. Los servicios web frecuentemente son sólo API2s Web que pueden accederse sobre una red, tal como Internet, y ejecutada en un sistema remoto que aloja los servicios requeridos. Esta definición involucra muchos sistemas diferentes, pero comúnmente el término se refiere a clientes y servidores que se comunican usando mensajes XML que siguen el estándar SOAP.
  • XML-RPC [4]: es un protocolo de llamada a procedimientos remotos que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes. Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tiene una documentación extensa y requiere considerable soporte de software para su uso.
  • SOAP [5]: es un protocolo para intercambiar mensajes basados en XML sobre redes de computadoras, usando generalmente HTTP/HTTPS. SOAP conforma la capa base de la pila de protocolos para servicios web (transporte,mensajería, descripción y descubrimiento) que proporcionan un marco de mensajería básica sobre el cual se pueden construir capas abstractas. Hay distintos tipos de patrones de mensajería en SOAP, pero el más común de todos es el patrón RPC, en el que un nodo de la red (el cliente) envía un mensaje de petición a otro nodo (el servidor) y el servidor inmediatamente envía un mensaje de respuesta al cliente. SOAP es el sucesor de XML-RPC, aunque toma prestado algunas de sus características.
  • WSDL [9]: son las siglas de Web Services Description Language (Lenguaje de Descripción de Servicios Web), un formato XML que se utiliza para describir servicios Web. WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. WSDL se usa a menudo en combinación con SOAP y XML Schema. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar que funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL.
  • Wizards [10]: son herramientas usadas por el usuario para la creación de objetos y controles en accesos. Son elementos de interfaz de usuario donde éste es presentado con una secuencia de cuadros de diálogo. A través de estos cuadros de dialogo, el usuario es llevado a través de una serie de pasos, realizando tareas en una secuencia especifica.
  • Widget [7][8]: aplicación o programa, presentada en archivos o ficheros pequeños que son ejecutados por un motor de widgets. Dan fácil acceso a funcionalidades frecuentemente usadas y proveen información visual, como relojes de pantalla, notas, calculadoras, calendarios, ventanas con información del tiempo. Estos pueden ser creados en XML, Java Script, Perl. Los Widgets son fragmentos de código portables que se puede instalar y ejecutar en cualquier página web basada en HTML por un usuario final sin necesidad de compilación adicional.

Bibliografía

  1. Wikipedia en Español, http://en.wikipedia.org/wiki/Service-oriented_architecture

  2. Wikipedia en Español, http://en.wikipedia.org/wiki/Client_server

  3. Wikipedia, http://en.wikipedia.org/wiki/Web_services

  4. Wikipedia en Español, http://es.wikipedia.org/wiki/XML-RPC

  5. Wikipedia , http://en.wikipedia.org/wiki/SOAP

  6. Wikipedia en Español, http://es.wikipedia.org/wiki/Artilugio

  7. Wikipedia, http://en.wikipedia.org/wiki/GUI_widget

  8. Wikipedia, http://en.wikipedia.org/wiki/Web_widget

  9. Wikipedia en Español, http://es.wikipedia.org/wiki/WSDL

  10. Wikipedia, http://en.wikipedia.org/wiki/Wizard_%28software%29

  11. Wikipedia en Español, http://es.wikipedia.org/wiki/Distributed_Component_Object_Model

  12. Wikipedia en Español, http://es.wikipedia.org/wiki/CORBA

  13. Wikipedia, http://en.wikipedia.org/wiki/Fork_%28software_development%29

  14. Pressman, R. (2002). Ingeniería del Software: Un enfoque práctico. Madrid , McGraw-Hill.

  15. Channabasavaiah, K., Holley, K., Tuggle, E (2003). Migrando a una arquitectura orientada a servicios. Parte I.
  16. Delgado, A. Desarrollo de Software con enfoque en el Negocio. instituto de computación, Facultad de Ingenieria, Universidad de la República, Montevideo, Uruguay.
  17. Sitio Python, http://www.python.org/

  18. Wikipedia en Español, http://es.wikipedia.org/wiki/Perl

  19. Wikipedia en Español, http://es.wikipedia.org/wiki/Ruby

  20. Wikipedia en Español, http://es.wikipedia.org/wiki/Python

  21. Ohloh - Buscador Proyectos Opensource, http://www.ohloh.net

  22. SorceForge, http://sourceforge.net

  23. VivaLinux, http://www.vivalinux.com.ar/eventos/python-lenguaje-del-2007.html

.: Inicio | ¿Qué es SAID? | ¿Quién usa SAID? | Requerimientos | Recursos | Descargas | ¡Participa! | Licencia:.

said/documentos/propuesta (última edición 2008-08-20 19:41:09 efectuada por lcaballero)