UNIDAD V: LOS MODELOS DE OBJETOS DISTRIBUIDOS ACTUALES

UNIDAD IV: LA TECNOLOGÍA DE OBJETOS DISTRIBUIDOS

4.1 DE LOS MODELOS DE OBJETOS CENTRALIZADOS A LOS MODELOS DE OBJETOS DISTRIBUIDOS.

Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el rango desde los sistemas de bases de datos mono usuario ejecutándose en computadoras personales hasta los sistemas de bases de datos de alto rendimiento ejecutándose en grandes sistemas. Por otro lado, los sistemas cliente-servidor tienen su funcionalidad dividida entre el sistema servidor y múltiples sistemas clientes.

OBJETOS DISTRIBUIDOS

Definición:

En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”. El cliente

invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del

objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

Tecnologías orientadas a los objetos distribuidos:

Las tres tecnologías importantes y más usadas en este ámbito son:

1.         RMI.- Remote Invocation Method.- Fue el primer framework para crear sistemas distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) de Java permite, a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de programación Java, es decir, que permite la comunicación entre objetos creados en este lenguaje.

2.         DCOM.- Distributed Component Object Model.- El Modelo de Objeto ComponenteDistribuido, esta incluido en los sistemas operativos de Microsoft. Es un juego deconceptos e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar servicios de objetos de programa servidores en otras computadoras dentro de una red. Esta tecnología esta asociada a la plataforma de productos Microsoft.

3.         CORBA.- Common Object Request Broker Architecture.- Tecnología introducida por el Grupo de Administración de Objetos OMG, creada para establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de programación.

Ventajas de las Base de Datos Distribuidas

• Descentralización.- En un sistema centralizado/distribuido, existe un administrador que controla toda la base de datos, por el contrario en un sistema distribuido existe un administrador global que lleva una política general y delega algunas funciones a administradores de cada localidad para que establezcan políticas locales y así un trabajo eficiente.

• Economía: Existen dos aspectos a tener en cuenta.

o El primero son los costes de comunicación; si las bases de datos están muy dispersas y las aplicaciones hacen amplio uso de los datos puede resultar más económico dividir la aplicación y realizarla localmente.

o El segundo aspecto es que cuesta menos crear un sistema de pequeñas computadoras con la misma potencia que un único computador.

• Mejora de rendimiento: Pues los datos serán almacenados y usados donde son generados, lo cual permitirá distribuir la complejidad del sistema en los diferentes sitios de la red, optimizando la labor.

• Mejora de fiabilidad y disponibilidad: La falla de uno o varios lugares o el de un enlace de comunicación no implica la inoperatividad total del sistema, incluso si tenemos datos duplicados puede que exista una disponibilidad total de los servicios.

• Crecimiento: Es más fácil acomodar el incremento del tamaño en un sistema distribuido, por que la expansión se lleva a cabo añadiendo poder de procesamiento y almacenamiento en la red, al añadir un nuevo nodo.

• Flexibilidad: Permite acceso local y remoto de forma transparente.

• Disponibilidad: Pueden estar los datos duplicados con lo que varias personas pueden acceder simultáneamente de forma eficiente. El inconveniente, el sistema administrador de base de datos debe preocuparse de la consistencia de los mismos.

• Control de Concurrencia: El sistema administrador de base de datos local se encarga de manejar la concurrencia de manera eficiente.

4.2 EVOLUCIÓN DE LOS SISTEMAS DISTRIBUIDOS

Sistemas Distribuidos

Definición:

“Sistemas cuyos componentes hardware y software, que están en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo. Se establece la comunicación mediante un protocolo prefijado por un esquema cliente-servidor”.

Características:

Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red.

Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.

Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando.

Motivación

Los sistemas distribuidos suponen un paso más en la evolución de los sistemas informáticos, entendidos desde el punto de vista de las necesidades que las aplicaciones plantean y las posibilidades que la tecnología ofrece. Antes de proporcionar una definición de sistema distribuido resultará interesante presentar, a través de la evolución histórica, los conceptos que han desembocado en los sistemas distribuidos actuales, caracterizados por la distribución física de los recursos en máquinas interconectadas.

Utilizaremos aquí el término recurso con carácter general para referirnos a cualquier dispositivo o servicio, hardware o software, susceptible de ser compartido.

Tipos de sistemas

Desde una perspectiva histórica se puede hablar de diferentes modelos que determinan la funcionalidad y la estructura de un sistema de cómputo, las características del sistema operativo como gestor de los recursos, y su campo de aplicación y uso:

·         · Sistemas de lotes. Son los primeros sistemas operativos, que permitían procesar en diferido y secuencialmente datos suministrados en paquetes de tarjetas perforadas. Hoy en día, sobre sistemas multiprogramados con interfaces de usuario interactivas, el proceso por lotes tiene sentido en aplicaciones de cálculo intensivo, por ejemplo en supercomputación.

·         · Sistemas centralizados de tiempo compartido. Fue el siguiente paso, a mediados de los 60. El objetivo es incrementar la eficiencia en el uso de la CPU, un recurso entonces caro y escaso, disminuyendo los tiempos de respuesta de los usuarios, que operan interactivamente. Los recursos están centralizados y se accede al sistema desde terminales.

·         · Sistemas de teleproceso. Se diferencian del modelo anterior en que los terminales —más recientemente, sistemas personales— son remotos y acceden a un sistema central utilizando una infraestructura de red (por ejemplo la telefónica) y un protocolo de comunicaciones normalmente de tipo propietario. El sistema central monopoliza la gestión de los recursos.

Ejemplos de aplicaciones que resolvía este modelo son los sistemas de reservas y de transacciones bancarias.Sistemas personales. La motivación de este tipo de sistemas estuvo en proporcionar un sistema dedicado para un único usuario, lo que fueposible gracias al abaratamiento del hardware por la irrupción del microprocesador a comienzos de los 80. Precisamente, el coste reducido es su característica fundamental. El sistema operativo de un ordenador personal (PC) es, en un principio, monousuario: carece de mecanismos de protección. Aunque, por simplicidad, los primeros sistemas operativos eran monoprogramados (MS-DOS), la mejora del hardware pronto permitió soportar sistemas multitarea (Macintosh, OS/2, Windows 95/98), e incluso sistemas operativos diseñados para tiempo compartido, como UNIX y Windows NT1. Un sistema personal posee sus propios recursos locales. Inicialmente, éstos eran los únicos recursos accesibles, pero hoy en día la situación ha cambiado. Por otra parte, la evolución hardware ha llevado a los ordenadores personales hacia versiones móviles (PC portátiles y otros dispositivos como PDAs y teléfonos móviles).

Sistemas distribuidos. Los recursos de diferentes máquinas en red se integran de forma que desaparece la dualidad local/remoto. La diferencia fundamental con los sistemas en red es que la ubicación del recurso es transparente a las aplicaciones y usuarios, por lo que, desde este punto de vista, no hay diferencia con un sistema de tiempo compartido. El usuario accede a los recursos del sistema distribuido a través de una interfaz gráfica de usuario desde un terminal, despreocupándose de su localización. Las aplicaciones ejecutan una interfaz de llamadas al sistema como si de un sistema centralizado se tratase, por ejemplo POSIX. Un servicio de invocación remota (por ejemplo a procedimientos, RPC, o a objetos, RMI) resuelve los accesos a los recursos no locales utilizando para ello la interfaz de red. Los sistemas distribuidos proporcionan de forma transparente la compartición de recursos, facilitando el acceso y la gestión, e incrementando la eficiencia y la disponibilidad.

El modelo de sistema distribuido es el más general, por lo que, aunque no se ha alcanzado a nivel comercial la misma integración para todo tipo de recursos, la tendencia es clara a favor de este tipo de sistemas. La otra motivación es la Hoy en día existe un hardware estándar de bajo coste, los ordenadores personales, que son los componentes básicos del sistema. Por otra parte, la red de comunicación, a no ser que se requieran grandes prestaciones, tampoco constituye un gran problema económico, pudiéndose utilizar infraestructura cableada ya existente (Ethernet, la red telefónica, o incluso la red eléctrica) o inalámbrica.

4.3 LA TECNOLOGÍA DE OBJETOS PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS

El Cliente Stub es una entidad de programa que invoca una operación sobre la implementación de un objeto  remoto a través de un Stub cuyo propósito es lograr que la petición de un cliente llegue hasta el ORB Core. Logrando el acoplamiento entre el lenguaje de programación en que se escribe el cliente y el ORB Core. El stub crea y expide las solicitudes del cliente.

Un Servidor Skeleton es la implementación de un objeto CORBA en algún lenguaje de programación, y define las operaciones que soporta una interface IDL CORBA. Puede escribirse en una gran variedad de lenguajes como C, C++, Java, Ada o Smalltalk. Y a través del skeleton entrega las solicitudes procedentes del ORB a la implementación del objeto CORBA.

La función del ORB consiste en conectar las dos partes: cliente y servidor. Presumiblemente estas partes se ejecutan sobre plataformas distintas y funcionan con diferentes sistemas operativos. Esto significa que pueden existir diferencias en tipos de datos, el orden de los parámetros en una llamada, el orden de los bytes en una palabra según el tipo de procesador, etc. Es misión del ORB efectuar los procesos conocidos como marshaling y unmarshaling. En caso de que el método invocado devuelva un valor de retorno, la función de los ORB del cliente y servidor se invierte. Éste realiza el marshaling de dicho valor y lo envía al ORB del cliente, que será el que realice el unmarshaling y finalmente facilite el valor en formato nativo.

Existe una gran variedad de implementaciones CORBA.

En las siguientes páginas web:

• http://www.puder.org/corba/matrix/

• http://adams.patriot.net/~tvalesky/freecorba.html

se encuentran implementaciones basadas en CORBA y se describen sus características, algunas son propietarias y otras más son libres.

COM/DCOM/Activex

COM (Component Object Model) es un estándar que permite la creación de objetos que ejecuten tareas que resuelven problemas específicos pero comunes a varias aplicaciones que puedan desear hacer uso de ellos. Estos pueden ser invocados por diferentes programas que los requieran, tanto OLE como ActiveX están basados en esta tecnología.

La idea es tener un mundo de objetos independientes de un lenguaje de programación. Por ello COM proporciona un estándar para las comunicaciones entre componentes, de tal forma, que una aplicación puede utilizar características de cualquier otro objeto de la aplicación, o del sistema operativo, y permite actualizar el software de un componente sin afectar a la operación de la solución global.

COM soporta comunicación entre objetos de equipos de cómputo distintos, en una LAN, WAN, o incluso en Internet.

DCOM extiende el estándar COM de objetos remotos, para su utilización en redes. Inicialmente se desarrolló para Windows NT 4.0, y posteriormente para

Solaris 2.x y Macintosh, así como para diferentes versiones UNIX.

Se encarga de manejar los detalles muy bajos de protocolos de red, por lo que el desarrollador se puede centrar en la realidad de los negocios, proporcionando así mejores soluciones a los clientes.

La arquitectura define cómo los componentes y sus clientes interactúan entre sí. Esta interacción es definida cual traduce la llamada del cliente a un formato neutro, totalmente independiente, que puede transportarse sobre cualquier medio

para el cual exista un protocolo de comunicación.

4.4 LOS ESTÁNDARES PARA EL DISEÑO DE SISTEMAS DISTRIBUIDOS CON OBJETOS

CORBA

Define servidores estandarizados a través de un modelo de referencia, los patrones de interacción entre clientes y servidores y las especificaciones de las APIs.

Con CORBA se facilita:

􀂄 El diseño de middleware de distribución que facilita el diseño de aplicaciones en plataformas heterogéneas sin necesidad de conocer los detalles de los recursos y servicios que ofrece cada elemento de la plataforma.

􀂄 La capacidad de diseñar aplicaciones desarrolladas en diferentes lenguajes de programación. Supliendo los recursos necesarios para implementar las interfaces entre ellas.

􀂄 La insteroperatividad entre aplicaciones desarrolladas por diferentes fabricantes. Para que un componente sea interoperable sólo se requiere que ofrezcan las interfaces y los patrones de interacción basados en la especificación CORBA.

Beneficios que ofrece CORBA.

Capacidad para que los clientes invoquen métodos de objetos ubicados en cualquier nudo de la plataforma.

Capacidad de invocar los métodos estáticamente (conocidos cuando se compila el cliente) y dinámicamente (desconocidos cuando se compiló el cliente).

Facilita la heterogeneidad de los lenguajes de programación. Los clientes y servidores pueden ser desarrollados en lenguajes diferentes. CORBA proporciona los recursos necesarios para compatibilizarlos.

Capacidad de incorporar información reflectiva que describe en tiempo de ejecución a los clientes las capacidades que ofrecen los servidores instalados.

Transparencia de la ubicación en las invocaciones de los objetos que se invocan.

Incorpora los mecanismos de seguridad en los acceso y de consistencia de las transacciones que se ejecutan.

Polimorfismo en las invocaciones.

Coexistencia con otras tecnologías (EJB, DCOM, etc.) a través de la especificación de los elementos puentes.

 4.5 ESTUDIO DETALLADO DE CORBA

CORBA es una arquitectura de objetos distribuidos diseñada para permitir que dichos objetos distribuidos interoperen sobre entornos heterogéneos, donde los objetos pueden estar implementados en diferentes leguajes de programación y/o desplegados sobre diferentes plataformas. CORBA se diferencia de la arquitectura Java RMI en un aspecto significativo: RMI es una tecnología propietaria de Sun Microsystems, Inc. y sólo soporta objetos que se encuentren escritos en el lenguaje Java. Por el contrario, CORBA ha sido desarrollado por OMG (Object Management Group) [corba.org, 1], un consorcio de empresas, y fue diseñado para maximizar el grado de interoperabilidad. Es importante saber que CORBA no es en sí mismo una herramienta para dar soporte a objetos distribuidos; se trata de un conjunto de protocolos. Una herramienta que dé soporte a dichos protocolos se denomina compatible con CORBA (CORBA compliant), y los objetos que se desarrollen sobre ella podrán interoperar con otros objetos desarrollados por otra herramienta compatible con CORBA.

CORBA proporciona un conjunto de protocolos muy rico [Siegel, 4], y el abordar todos ellos está más allá del ámbito de este libro. Sin embargo, se centrará en los conceptos clave de CORBA que estén relacionados con el paradigma de objetos distribuidos. También se estudiará una herramienta basada en CORBA: Interface Definition Language (IDL) de Java.

Arquitectura básica

La Figura 10.0 muestra la arquitectura básica de CORBA [omg.org/gettingstarted, 2]. Como arquitectura de objetos distribuidos, guarda una gran semejanza con la arquitectura RMI. Desde el punto de vista lógico, un cliente de objeto realiza una llamada a un método de un objeto distribuido. El cliente interactúa con un proxy – un stub – mientras que la implementación del objeto interactúa con un proxy de servidor – un skeleton. A diferencia del caso de Java RMI, una capa adicional de software, conocida como ORB (Object Request Broker) es necesaria. En el lado del cliente, la capa del ORB actúa con intermediaria entre el stub y la red y sistema operativo local del cliente. En el lado del servidor, la capa del ORB sirve de intermediaria entre el skeleton y la red y sistema operativo del servidor. Utilizando un protocolo común, las capas ORB de ambos extremos son capaces de resolver las diferencias existentes en lo referente a lenguajes de programación, así como las relativas a las plataformas (red y sistema operativo), para de esta forma ayudar a la comunicación entre los dos extremos. El cliente utiliza un servicio de nombrado para localizar el objeto.

Referencias a objetos CORBA

También como en el caso de Java RMI, un objeto distribuido CORBA se localiza por medio de una referencia a objeto. Ya que CORBA es independiente de lenguaje, una referencia a un objeto CORBA es una entidad abstracta traducida a una referencia de objeto específica de cada lenguaje por medio del ORB, en una representación elegida por el desarrollador del propio ORB.

Por interoperabilidad, OMG especifica un protocolo para referencias abstractas de objetos, conocido como protocolo Interoperable Object Reference (IOR). Un ORB que sea compatible con el protocolo IOR permitirá que una referencia a objeto se registre y se obtenga desde un servicio de directorio compatible con IOR. La referencias a objetos CORBA representadas en este protocolo se denominan también IOR (Interoperable Object References).

4.6 LA CONFLUENCIA DE CORBA Y EL WEB

DESARROLLO WEB

Caso particular de los sistemas Cliente-Servidor con representación remota. En donde se dispone de un protocolo estándar: HTTP y un Middleware denominado WebServer. En la actualidad la aplicación de sistemas informáticos basados en Internet, es una herramienta fundamental para las organizaciones que desean tener cierta presencia competitiva.

Tecnologías de la lógica de la aplicación en el servidor web:

• CGI: Common Gateware Interface..- Son programas que se ejecutan en el servidor, pueden servir como pasarela con una aplicación o base de datos o para generar documentos html de forma automática. Cada petición http ejecuta un proceso, el cual analiza la solicitud y genera un resultado. Son independientes del SO, y presentan la ventaja de que, dado un programa escrito en un lenguaje cualquiera, es fácil adaptarlo a un CGI. Entre los lenguajes que se usan para CGIs, el más popular es el Perl.

• Servlets: Pequeños programas en Java que se ejecutan de forma persistente en el servidor, y que, por lo tanto, tienen una activación muy rápida, y una forma más simple de hacerlo. Estos programas procesan una petición y generan la página de respuesta.

• ASP (Active Server Pages): Una página ASP es un fichero de sólo texto que contiene las secuencias de comandos, junto con el HTML necesario, y que se guarda con la extensión “.asp”. Al ser llamado por el navegador, el motor ASP del

IIS (Internet Information Server) se encarga automáticamente de ejecutarlo como se suele hacer con un programa cualquiera, pero cuya salida siempre será a través del navegador que le invoca. Es un entorno propietario de Microsoft y el lenguaje de secuencia de comandos predeterminado del IIS es el VBScript, aunque puede cambiarse.

• JSP (Java Server Pages), que consisten en pequeños trozos de código en Java que se insertan dentro de páginas web, de forma análoga a los ASPs. Ambas opciones, hoy en día, son muy populares en sitios de comercio electrónico. Frente

a los ASPs, la ventaja que presentan es que son independientes del sistema operativo y del procesador de la máquina.

• PHP es un lenguaje cuyos programas se insertan también dentro de las páginas web, al igual que los ASPs y JSPs; es mucho más simple de usar, y el acceso a bases de datos desde él es muy simple. Es tremendamente popular en sitios de comercio electrónico con poco tráfico, por su facilidad de desarrollo y rapidez de implantación.

Consideraciones a tomar en el desarrollo de un sistema WEB

a. Separar la lógica de la aplicación de la interfase de usuario.

b. Utilizar métodos estándar de comunicación entre la lógica de aplicación y la

interfase de usuario.

c. Herramientas que permitan una fácil adaptación de las aplicaciones a los nuevos dispositivos que irán apareciendo.

d. Definir el coste en comunicaciones que debe asumir la organización.

e. Tener en cuenta los procesos de réplica, periodicidad y el ancho de banda que

consuman.

f. Replantear la idoneidad de la ubicación de cada proceso.

g. Extremar las pruebas al diseñar e implementar los protocolos de comunicación.

El concepto de servicio Web

El servicio Web se ha definido como un componente de software reutilizable y distribuido que ofrece una funcionalidad concreta, independiente tanto del lenguaje de programación en que está implementado como de la plataforma de ejecución. Se puede considerar como aplicaciones autocontenidas que pueden ser descritas, publicadas, localizadas e invocadas sobre la Internet (o cualquier otra red) y basada en estándares del W3C (especialmente XML).

Arquitecturas actuales de sistemas WEB.

A continuación se muestran algunas arquitecturas que se presentan en nuestros días al momento de desarrollar una aplicación distribuida sobre la Web.

 4.7 JUSTIFICACIÓN DE UNA ARQUITECTURA CON OBJETOS DISTRIBUIDOS PARA EL WEB

Las necesidades y aplicaciones de negocios del mundo de hoy requieren de un conjunto de componentes distribuidos cada vez más complejos a través de las redes de telecomunicaciones. Aunque la complejidad estriba en el software/hardware que ponen a funcionar a esos componentes, todo esto va enfocado a facilitar a los usuarios sus diversas actividades diarias.

Sin que seamos conscientes de ello, en Internet navegan dos tipos de entes muy distintos: las personas que visitan páginas web o acceden a servicios interactivos, y las aplicaciones distribuidas. En la web hay miles de programas que conversan entre sí, intercambiándose datos de forma automática, sin mediación humana.

Usando servicios web, un programador puede implementar aplicaciones basándose en rutinas y datos proporcionados desde un servidor distante.

Así, por ejemplo, existen servidores que proporcionan rutinas que permiten conocer la previsión meteorológica de una localidad o las cotizaciones en bolsa de una empresa, etc.

Esas rutinas pueden ser usadas, por ejemplo, para simplemente mostrar información en una página web, o pueden ser usadas como los datos de entrada en un programa de predicción o de ayuda a la toma de decisiones. Si el acceso a dichas rutinas y a los datos que generan se hace usando ciertos protocolos estandarizados, entonces es cuando hablamos de servicio web.

De esta manera inicia el estudio a los servicios web topando temas como su surgimiento, conceptos, ciclo de vida, arquitectura, ventajas, etc.

La década de los 80′s fue marcada por el surgimiento de la PC y de la interfase grafica. En la década de los 90′s Internet permitió conectar computadoras en una escala global. En principio la conexión fue entre PCs y servidores por medio del explorador de Internet. A comienzos de este siglo es clara la necesidad de permitir a las computadoras conectadas a Internet comunicarse entre ellas.

Desde entonces se va dando forma al nuevo modelo de computación distribuida llamado servicios Web basados en XML. El objetivo es permitir comunicarse entre sí a sistemas heterogéneos dentro y fuera de una empresa. Esta comunicación es independiente del sistema operativo, lenguaje o modelo de programación.

La simplicidad de las interacciones en el modelo de programación Web posibilita construir sistemas incrementalmente. A diferencia del acoplamiento fuerte de RPC y de los sistemas de objetos distribuidos, que requieren la implantación de todas las piezas de una aplicación de una vez, podemos añadir tantos clientes y servidores a sistemas basados en Web como necesitemos. Podemos establecer fácilmente conexiones a aplicaciones nuevas de un modo descentralizado, sin ninguna coordinación central más allá del registro de nombres DNS, y con un grado de interoperabilidad, escalabilidad y capacidad de gestión extraordinariamente alto.

SERVICIO WEB

Definiciones.-

“Aplicaciones de negocio modulares y autocontenidas que tienen interfaces abiertos, orientados a Internet y basados en interfaces estándares”.

Consorcio UDDI .

“Una aplicación software identificada por un URI, cuyas interfaces se pueden definir, describir y descubrir mediante documentos XML. Un servicio Web soporta interacciones directas con otros agentes software utilizando mensajes XML intercambiados mediante protocolos basados en Internet”.

“Una forma estándar de integrar aplicaciones basadas en Web utilizando los estándares abiertos XML, SOAP, WSDL y UDDI. XML se utiliza para etiquetar los datos, SOAP para transferir los datos, WSDL para describir los servicios disponibles y UDDI para listar que servicios están disponibles”.

Los servicios web (SW) son colecciones de funciones u objetos distribuidos que son presentados como una sola entidad la cual es anunciada en la red para ser usada por otros programas. Con un interfaz definido y conocido, al que se puede acceder a través de Internet, al igual que una página web está definida por un URL (Uniform Resource Locator), un servicio web está definido por un URI (Uniform Resource Identification) y por su interfaz, a través del cual se puede acceder a él.

El concepto de servicio web es un paradigma de la computación distribuida que consiste en un conjunto de protocolos de comunicación que permiten el intercambio de datos entre aplicaciones remotas.

Los Servicios WEB son componentes de software reutilizables, ligeramente acoplados que semánticamente encapsulan funcionalidades discretas que son distribuidas y accesibles a nivel de programación a través de protocolos de Internet.

 4.8 ASIMILACION DE UNA IMPLEMENTACION DE CORBA: VISIBROKER FOR JAVA

Visibroker es un ORB que cumple con todos los requerimientos de CORBA. Visibroker se compone de lo siguiente (Los nombres de servicio entre comillas son los nombres de la implementación de Visibroker en particular):

•          Librerías de CORBA.

Las librerías de CORBA le ayudan a los programas a exponer métodos CORBA y a utilizar los métodos desde los programas Clientes.

Las librerías de CORBA pueden ser de dos tipos:

1.         ORB

El ORB es el exportador e importador de interfases. Todos los clientes y servidores deben inicializar el ORB y utilizarlo para obtener interfases. Básicamente el ORB es el que interpreta los punteros de interfases y los traduce a mensajes de red, o recibe llamadas de red y los traduce a punteros locales para su ejecución.

2.         Adaptador de Objetos Básico (BOA)

El adaptador de Objetos Básico (Basic Object Adaptor) es la librería que le ayuda a exportar el puntero de interfase. Se utiliza en el servidor.

Nota: En computación distribuida, los términos “servidor” y “cliente” pueden resultar intercambiables, ya que el cliente puede implementar objetos y exportarlos al servidor. En estos casos, los clientes también necesitan usar el BOA (pero solo si exportan interfases). Esto será mas claro en los ejemplos, pero recuerde que “cliente” y “servidor” son rolesque puede jugar un ejecutable en cualquier momento.

•          Servicio de Nombres “SmartAgent”

El servicio SmartAgent le ayuda a exportar un objeto para su utilización en una red local. Si usted tiene el código de interfase I.O.R. en específico, usted no necesita un servicio de nombres.

•          Servicio de Activación “OAD”

Cuando usted escribe un programa COM que exporta interfases, Windows utiliza uno de sus servicios internos (TODO:Averiguar Nombre del Servicio) para ejecutar el archivo (.exe, .dll, etc) donde la interfase “vive”. CORBA no es una tecnología que dependa en el sistema operativo, así que el servicio de activación tiene una lista de las interfases y los nombres de sus ejecutables para poder iniciar automáticamente el ejecutable. Note que si usted comienza el ejecutable por sí mismo, no necesita registrarlo en el OAD. De esta manera, usted puede tener varios servicios en su AUTOEXEC.BAT (o lista de servicios en Windows NT) que aceptarán peticiones de los clientes.

•          Compilador de IDL

IDL es un lenguaje “neutral” para definición de interfases. Como tal, tiene declaraciones pero no tiene sintaxis de control (for, do while, etc). Bajo CORBA, usted describe su interfase utilizando IDL y utiliza el compilador de IDL para crear clases de apoyo a su implementación, y clases auxiliares para que los clientes puedan crear instancias del objeto.

Visibroker y Delphi

La versión de Visibroker que viene con Delphi 4 es:

prompt> vbver oad.exe Information for: /Program Files/Borland/vbroker/Bin/oad.exe Product Name: VisiBroker for C++ Version: 03.02.00.C2.02 Copyright: (C) 1996, 1998 Company: Visigenic Software, Inc. Build Date: 03/02/1998 11:57:32

Como podrá ver, Delphi 4 utiliza una versión de Visibroker para C++. Como es el caso con todas las librerías de C++, las llamadas han sido traducidas a archivos .PAS para su uso en Delphi.

 4.9 EL WEB DE OBJETOS CON VISIBROKER

En 1989, los altos ejecutivos de varias compañías (desde compañías de Software hasta Bancos) se reunieron para hablar acerca de interfases, y de la importancia que éstas tendrían en el futuro. Estas empresas (que forman el llamado “Open Management Group”) decidieron que, dada la enorme importancia que las interfases tendrían, sería muy util especificar un estándar para que todos los lenguajes de programación pudieran exponer interfases, sin importar el lenguaje, el sistema operativo o el vendedor de servicios de objetos.

CORBA es el resultado de muchos años de trabajo de varias compañías para definir un estándar que satisfaga a todos los lenguajes de todos los sistemas operativos. COM fué el primer transporte de interfases soportado por Delphi, pero CORBA es una tecnología mucho más madura y sólida para tranporte de interfases, por el simple y sencillo motivo de que CORBA ha estado funcionando por mucho tiempo en varios sistemas operativos y lenguajes.

Así que la primera diferencia entre COM y CORBA es que COM nos limita a tecnologías Windows, mientras CORBA nos abre las puertas a la posibilidad de usar e implementar interfases en Unix, Linux, Mainframes de IBM, Solaris, Sillicon Graphics, Windows, etcétera, en lenguajes tan dispares como Java, C, Delphi, COBOL, SmallTalk, FORTRAN, LISP y muchos otros.

Independencia de Lenguaje

¿Cómo se logra la independencia entre lenguajes? Tal como vimos en el capítulo 9, Las interfases CORBA se representan en un Lenguaje unificado llamado IDL (Interface Definition Language). Cada lenguaje (Delphi, Java, C, etc.) cuenta con un traductor (también llamado “compilador”) de IDL, que traduce las sentencias de la definición de la interfase al lenguaje adecuado.

Cuando usted compra librerías de CORBA (también llamadas ORBs) para su lenguaje, las librerías normalmente vienen con programas llamados “idl2XXX”, donde “XXX” es el nombre de su lenguaje. De esta manera, un ORB para java viene con un compilador de IDL llamado “idl2java”, mientras que C++ vendría con un compilador llamado “idl2cpp”. En delphi tenemos un caso especial, porque Delphi puede leer IDL directamente en el editor de librerías de tipos y traducirlo a PAS automáticamente (así que el compilador de IDL viene integrado en las versiones Client/Server y Enterprise).

Independencia de Sistemas Operativos y Lenguajes

Como ORB no es dominado por una sola compañía sino por un grupo, mientras uste pueda compilar su programa para un sistema operativo X y pueda comprar unas librerías ORB para el mismo sistema operativo (y que funcionen con su lenguaje), usted puede hablar con cualquier otro servicio en la red que exponga un ORB, sin importar qué sistema operativo o qué marca de ORB está ejecutándose en la máquina que expone el ORB.

CORBA es una Especificación

Tal como lo hicimos en las interfases, hay que ver lo que CORBA no es:

•          CORBA NO ES un producto

CORBA es una especificación de como debe funcionar un set de librerías específicas para llamarse un ORB. Decir “yo sé usar CORBA” no es suficiente; usted normalmente debe decir cosas como “yo sé CORBA usando Visigenics”, o “yo sé CORBA usando IONA”. Visigenics e IONA son dos productos que implementan la tecnología CORBA. Los productos que implementan CORBA se llaman ORBs.

•          CORBA NO ES un lenguaje

De la misma manera, Visigenics (un ORB) está disponible para varios lenguajes bajo varias plataformas (Visigenics for C++/Linux, Visigenics for C++/Windows, Visigenics for Java). Pero CORBA en sí mismo no es un lenguaje, sino una serie de librerías y servicios. Así que recuerde que cuando explique a otra persona que usted puede programar en CORBA, recuerde que debe decirlo de forma “Yo programo CORBA usando Visibroker para Delphi bajo Windows”, o “Yo programo CORBA usando Visibroker para Java”, etcétera.

UNIDAD III: LA TECNOLOGÍA DEL WEB

UNIDAD II: LAS APLICACIONES TRADICIONALES DE INTERNET

 2.1    EL DISEÑO  DE SISTEMAS  CLIENTE/SERVIDOR

El concepto de cliente/servidor proporciona una forma eficiente de utilizar todos estos recursos de máquina de tal forma que la seguridad y fiabilidad que proporcionan los entornos mainframe se traspasa a la red de área local. A esto hay que añadir la ventaja de la potencia y simplicidad de los ordenadores personales. 

La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. 

Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario. Los clientes realizan generalmente funciones como: Manejo de la interfaz de usuario. Captura y validación de los datos de entrada. Generación de consultas e informes sobre las bases de datos. 

Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestión de periféricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de área local o extensa. 

Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste le responde proporcionándolo. Normalmente, pero no necesariamente, el cliente y el servidor están ubicados en distintos procesadores. 

Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo. 

Entre las principales características de la arquitectura cliente/servidor se pueden destacar las siguientes: 

•       El servidor presenta a todos sus clientes una interfaz única y bien definida. 

•       El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa. 

•       El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo. 

•       Los cambios en el servidor implican pocos o ningún cambio en el cliente.

2.2    DEPENDENCIA  ENTE EL SISTEMA  UNIX  Y LAS APLICACIONES DE INTERNET

UNIX: Se trata de un sistema operativo de los más utilizados y con más futuro debido a que son muchos organismos oficiales y particulares los que defienden su utilización, así como muchas firmas de fabricación y comercialización de computadoras que lo incorporan en sus productos. Podemos citar el ejemplo de la Comunidad Económica Europea, que impone el sistema operativo UNIX en todas las aplicaciones que se desarrollan bajo sus auspicios.

Es un sistema operativo de tiempo compartido, controla los recursos de una computadora y los asigna entre los usuarios. Permite a los usuarios correr sus programas. Controla los dispositivos de periféricos conectados a la máquina. Esta formado por una serie de elementos que pueden representarse en forma de capas concéntricas donde, en primer lugar alrededor del hardware, aislando a este de los usuarios, además de adaptar el resto del sistema operativo a la maquina debido a la portabilidad que existe en el mismo.

El sistema operativo UNIX como ya dije es un sistema operativo de tiempo compartido y por lo tanto, multiusuario, en el que existe la portabilidad para la implementación de distintas computadoras.

UNICS: En las décadas de 1940 y 1950 todas las computadoras eran personales, al menos en el sentido de que el modo de usar una computadora era reservar una hora y apoderarse de toda la maquina en ese tiempo. Esas maquinas eran enormes y solo una persona podía usarla en un momento dado.

ESTANDAR UNIX: Es un sistema de intercambio de segmentos de un proceso entre memoria principal y memoria secundaria, llamado swapping lo que significa que se debe mover la imagen de un proceso al disco si éste excede la capacidad de la memoria principal, y copiar el proceso completo a memoria secundaria. Es decir, durante su ejecución, los procesos son cambiados de y hacia memoria secundaria conforme se requiera.

UNIX PD-11, BERKELEY: Las primeras distribuciones de Unix de los laboratorios Bell en los años 70 incluían el código fuente del sistema operativo, permitiendo a los desarrolladores de las universidades modificar y extender Unix. El primer sistema Unix en Berkeley fue el PDP-11, que fue instalado en 1974, y fue utilizado desde entonces por el departamento de ciencia computacional para sus investigaciones.

Otras universidades empezaron a interesarse en el software de Berkeley, y por ello en 1977 Bill Joy, entonces un estudiante de grado en Berkeley, construyó y envió cintas del primer Berkeley Software Distribución (BSD).

SHEL DE UNIX: También llamado Núcleo, es un programa escrito casi en su totalidad en lenguaje C, con excepción de una parte del manejo de interrupciones, expresada en el lenguaje ensamblador del procesador en el que opera. Proporciona una interfaz entre el núcleo y el usuario, el shell controla recursos como los periféricos (pantalla, impresora, etc.), además recursos del computador como el procesador, tarjetas (sonido, vídeo, etc.).

También controla las utilidades (programas de aplicación) que son los programas utilizados por los usuarios Word, Excel, juegos, etc., además controla la forma en la cual se almacena y se organiza la información (archivos).

CARACTERISTICAS UNIX:

•                     Es un sistema operativo multiusuario, con capacidad de simular multiprocesamiento y procesamiento no interactivo.

•                     Está escrito en un lenguaje de alto nivel: C.

•                     Dispone de un lenguaje de control programable llamado SHELL

•                     Ofrece facilidades para la creación de programas y sistemas y el ambiente adecuado para las tareas de diseños de software.

•                     Emplea manejo dinámico de memoria por intercambio o paginación.

•                     Tiene capacidad de interconexión de procesos.

•                     Permite comunicación entre procesos.

•                     Emplea un sistema jerárquico de archivos, con facilidades de protección de archivos, cuentas y procesos.

•                     Tiene facilidad para re direccionamiento de Entradas/Salidas.

•                     Garantiza un alto grado de portabilidad.

SISTEMA DE ARCHIVO UNIX: la estructura básica del sistema de archivos es jerárquica, lo que significa que los archivos están almacenados en varios niveles. Se puede tener acceso a cualquier archivo mediante su trayectoria, que especifica su posición absoluta en la jerarquía, y los usuarios pueden cambiar su directorio actual a la posición deseada. Existe también un mecanismo de protección para evitar accesos no autorizados.

Los directorios contienen información para cada archivo, que consiste en su nombre y en un número que el Kernel utiliza para manejar la estructura interna del sistema de archivos, conocido como el nodo-i. Hay un nodo-i para cada archivo, que contiene información de su directorio en el disco, su longitud, los modos y las fechas de acceso, el autor, etc. Existe, además, una tabla de descriptores de archivo, que es una estructura de datos residente en el disco magnético, a la que se tiene acceso mediante el sistema mencionado de E/S por bloques.

ADMINISTRACION DE PROCESOS Y SUB PROCESOS UNIX: Si congelamos el estado del procesador y del proceso que esta en ejecución en un determinado momento, obtendríamos lo que se conoce como imagen estática del programa. En caso de producirse una interrupción o cambio en el proceso, se almacena la imagen del que esta en ejecución en ese mismo instante.

Cada proceso se reconoce dentro del sistema por un numero que lo identifica unívocamente y que se conoce como identificador del proceso (PID).

Todos los procesos excepto el proceso 0, son creados por otro proceso, es decir, el sistema de creación y gestión de procesos en el sistema operativo UNIX es jerárquico.

ADMINISTRACION DE MEMORIA UNIX: La gestión de memoria en el sistema operativo UNIX se basa en el intercambio (swapping) y paginación. La paginación de la memoria se lleva a cabo si el hardware de la computadora la soporta. La política de carga y descarga de un proceso en la memoria depende del tiempo que lleve en la misma, de su actividad y del tamaño. Dependiendo de la computadora en la que se ejecute, UNIX utiliza dos técnicas de manejo de memoria: swapping y memoria virtual.

ADMINISTRACION DE SISTEMA UNIX: En computadoras que funcionan bajo el sistema operativo UNIX, existe un usuario que se distingue de los demás por ser el encargado de realizar la administración del sistema. Las funciones propias del administrador del sistema son:

•                     Actualización y mantenimiento del sistema:

•                     Mantenimiento del sistema de archivos.

•                     Determinación de altas y bajas de archivos.

•                     Control de periféricos.

•                     Realización periódica de copias de seguridad (Backups)

•                     Suministros de soporte técnico al resto de los usuarios.

•                     Gestión de los recursos de la computadora Etc.

En el sistema operativo UNIX existe un directorio de uso exclusivo del administrador del sistema donde se encuentran una serie de comandos para la realización de dichas funciones, que no pueden ser utilizadas por el resto de los usuarios.

CALENDARIZACIÓN EN UNIX: Unix siempre ha sido un sistema multiprogramado, su algoritmo de calendarización se desarrollo desde un principio de modo que respondiera bien a procesos interactivos. El algoritmo tiene 2 niveles, el nivel bajo escoge entre los procesos que están en la memoria y listo para ejecutarse, el proceso que se ejecutara a continuación. El algoritmo de nivel mas alto traslada procesos entre la memoria y el disco para que todos tengan oportunidad de estar en la memoria y ejecutarse

LINUX: Linux fue creado originalmente por Linus Torvald en la Universidad de Helsinki en Finlandia, siendo él estudiante de informática. Pero ha continuado su desarrollado con la ayuda de muchos otros programadores a través de Internet.

Linux originalmente inicio el desarrollo del núcleo como su proyecto favorito, inspirado por su interés en Minix, un pequeño sistema Unix desarrollado por Andy Tannenbaum. Él se propuso a crear lo que en sus propias palabras seria un “mejor Minix que el Minix”.

El 5 de octubre de 1991, Linux anuncio su primera versión oficial de Linux, versión 0.02. Desde entonces, muchos programadores han respondido a su llamada, y han ayudado a construir Linux como el sistema operativo completamente funcional que es hoy.

SISTEMA MULTITAREA: En Linux es posible ejecutar varios programas a la vez sin necesidad de tener que parar la ejecución de cada aplicación.

SISTEMA MULTIUSUARIO: Varios usuarios pueden acceder a las aplicaciones y recursos del sistema Linux al mismo tiempo. Y, por supuesto, cada uno de ellos puede ejecutar varios programas a la vez (multitarea).

SHELLS PROGRAMABLES: Un shell conecta las ordenes de un usuario con el Kernel de Linux (el núcleo del sistema), y al ser programables se puede modificar para adaptarlo a tus necesidades. Por ejemplo, es muy útil para realizar procesos en segundo plano.

INDEPENDENCIA DE DISPOSITIVOS: Linux admite cualquier tipo de dispositivo (módems, impresoras) gracias a que cada una vez instalado uno nuevo, se añade al Kernel el enlace o controlador necesario con el dispositivo, haciendo que el Kernel y el enlace se fusionen. Linux posee una gran adaptabilidad y no se encuentra limitado como otros sistemas operativos.

COMUNICACIONES: Linux es el sistema más flexible para poder conectarse a cualquier ordenador del mundo. Internet se creó y desarrollo dentro del mundo de Unix, y por lo tanto Linux tiene las mayores capacidades para navegar, ya que Unix y Linux son sistemas prácticamente idénticos. Con linux podrá montar un servidor en su propia casa sin tener que pagar las enormes cantidades de dinero que piden otros sistemas.

APAGADO DE SISTEMA EN LINUX: Un sistema Linux nunca se puede apagar por las buenas. Antes le hemos de advertir al S.O. de que vamos a apagarlo o reiniciarlo. La razón de que esto deba ser así es para que al sistema le dé tiempo de escribir en disco todos los datos que tuviera pendientes de escribir, salir ordenadamente de todas las aplicaciones que tuviera arrancadas y desmontar todas las unidades que tuviera montadas

CALENDARIZACIÓN EN LINUX: La calendarización es una de las pocas áreas en la que linux en la que linux emplea un algoritmo distinto al de unix. Los subprocesos de linux son subprocesos del kernel, así la calendarización se basa en subprocesos no en procesos.

Linux describe 3 clases de subprocesos para fines de calendarización:

•                     Fifo en tiempo real

•                     Turno circular en tiempo real

•                     Tiempo compartido

2.3    PROCESOS CONCURRENTES   EN UN ENTORNO  DE RED

En UNIX, la unidad de concurrencia es el proceso y para especificar la ejecución concurrente se utilizan las sentencias \fork” y \join”, cuyo formato se verá más adelante.

Procesos

Un proceso, como ya se ha dicho anteriormente, es la ejecución de un programa secuencial. En UNIX, un proceso consiste en un conjunto de bytes que un procesador interpreta como código, datos o pila. Todas las operaciones que están relacionadas con los procesos están controladas por una porción del sistema operativo que se llama el núcleo.

El núcleo planifica la ejecución de los procesos de forma que parece que hay más de un proceso que se ejecuta al mismo tiempo, cada proceso puede ser la ejecución de un programa diferente o diferentes ejecuciones del mismo programa. Cada proceso ejecuta las instrucciones de su propio código y no puede acceder a las de otros procesos, aunque sean instancias del mismo programa; para comunicarse, los procesos tienen que utilizar llamadas al sistema.

Cada proceso se ejecuta dentro de su contexto. Cuando el núcleo decide que debe ejecutar otro proceso, realiza un cambio de contexto, de forma que el nuevo proceso se ejecutara dentro de su propio contexto. Cuando se realiza un cambio de contexto, el núcleo guarda toda la información necesaria para volver más tarde al estado del primer proceso y continuar a su ejecución.

Como ya se ha explicado en el capitulo anterior, durante la vida de un proceso, este pasa por diversos estados. La siguiente lista enumera los posibles estados de un proceso en el sistema UNIX:

1. El proceso se ejecuta en modo usuario.

2. El proceso se ejecuta en modo núcleo.

3. El proceso no se está ejecutando pero está listo para ejecutarse.

El proceso está dormido en memoria principal.

5. El proceso está listo para ser ejecutado, pero el proceso 0 debe llevarlo a memoria principal antes que el núcleo pueda preparar su ejecución.

Para ejecutar una llamada \fork”, el núcleo realiza la secuencia de operaciones que  se especifica a continuación:

1. Asigna una posición de la tabla de procesos al nuevo proceso.

2. Asigna un identificador (PID) al proceso hijo, este PID es único para cada proceso.

3. Hace una copia \lógica” del contexto del proceso padre para el proceso hijo.

4. Incrementa el contador de ¯cheros y la tabla de descriptores para los ficheros asociados al proceso.

5. Devuelve el número de PID del proceso hijo al padre y devuelve 0 al proceso hijo.

Terminación de procesos

El UNIX, todos los procesos para terminar ejecutan la llamada del sistema ext. Un proceso que ejecuta esta llamada pasa al estado zombie liberando todos sus recursos y solo mantiene su posición en la tabla de procesos. La sintaxis de la llamada \exit” es: exit (estado); El valor de \estado” se devuelve al proceso padre para que este pueda examinarlo ya que su valor puede servir al padre para saber cómo termino el hijo, el valor de \estado” indica de que manera termino el proceso, por convenio se considera que si un proceso termina correctamente el valor de \estado” es 0 y si su valor es distinto de 0 entonces el proceso termino de forma anómala. Un proceso puede realizar la llamada \exit” explícitamente o hacerlo implícitamente del programa. Por otra parte, el nucleo puede ejecutar internamente un \exit” en un proceso como respuesta a una señal de interrupción que no ha sido captada; en este caso, el valor de \estado” es el numero de la señal que causa la interrupción.

Sincronización de procesos

Un proceso puede sincronizar su ejecución con la terminación de un proceso hijo a través de la llamada del sistema wait. La sintaxis de la llamada es: pid = wait (dir_est); El valor de \pid” es el PID de un hijo \zombie”, de esta forma el proceso padre sabe cuál de sus hijos ha muerto y \dir est” contiene una dirección en la memoria del Usuario donde está almacenado el código \estado” de la llamada \exit” del hijo, para que el padre pueda saber la causa de la muerte de su hijo. Cuando se ejecuta un \wait”, el nucleo busca un hijo \zombie” del proceso; si no hay hijos, devuelve un error; si por el contrario encuentra un hijo \zombie”, saca su PID y el parámetro de la llamada \exit” del hijo y los devuelve como resultado de la llamada. Si elproceso que ejecuta la llamada \wait” tiene hijos pero ninguno de estos es \zombie”, el proceso queda dormido hasta que le llega una señal indicando que ha muerto un hijo.

2.4    LA MODELACION DE SISTEMAS DE LOS SISTEMAS  DE COMPUTO EN INTERNET

El cambio desde una visión funcional a una visión de proceso plantea nuevos requerimientos respecto a la forma en que se especifican y diseñan Sistemas. Ya no será suficiente con descomponer funcionalmente la lógica de una aplicación, manteniéndola separada de los datos sobre los que actúa. Lo que se necesita es un enfoque en la creación de modelos que pueda ser utilizado tanto para la conversión desde el soporte de una función comercial a soportar un flujo de trabajo o workflow a lo largo de un proceso comercial. Los sistemas workflow convencionales, que intentan orquestar el trabajo entre aplicaciones monolíticas y tareas manuales, no podrán en última instancia ofrecer la flexibilidad que requieren las iniciativas BPR. En contraste, los Sistemas creados utilizando objetos están fundados inherentemente en un modelo workflow explícito que anima a los diseñadores de Sistemas a distribuir el trabajo entre múltiples objetos que actúan en cooperación.

La tecnología de orientación a objetos ofrece técnicas de modelización que permiten definir objetos y relacionarlos de manera que puedan desarrollarse tanto procesos comerciales como Sistemas de información. Como existe un lenguaje uniforme para expresar procesos comerciales y procesos de información es posible establecer una relación entre ambos.

Así, los procesos comerciales pueden actuar interactivamente con objetos software, y el modelo de workflow puede establecerse explícitamente de manera que muestre los cambios entre tareas manuales y automáticas.

La utilización de técnicas de modelización para describir empresas y actividades comerciales no es nueva, y ya se han utilizado técnicas de modelización de datos tradicionales para crear modelos de empresa. Sin embargo, a diferencia de los enfoques tradicionales, las técnicas orientadas a objetos no obligan a quienes crean los modelos de procesos comerciales a dividir sus modelos artificialmente en datos y procesos, sino que los objetos contienen todos los aspectos de los datos y de su comportamiento, y pueden utilizarse para representar entidades comerciales estáticas, como departamentos, tareas comerciales como aprobaciones de créditos, y subprocesos como tramitación de pedidos. Una consecuencia importante de esta aproximación de modelado uniforme es que, con el tiempo, el ajuste entre el funcionamiento comercial y los Sistemas de Información se mejorará. Es este aspecto de reconfigurabilidad el que está posicionando a los proyectos BPR como una ventaja comercial progresiva, en lugar de como los puntos de revolución aislados que eran percibidos hasta ahora.

2.5    LAS APLICACIONES  TRADICIONALES DE INTERNET: CORREO ELECTRONICO , TRANSFERENCIA DE ARCHIVOS, SERVICIOS DE LOS SISTEMAS OPERATIVOS.

Web application, webapp). Una aplicación web es cualquier aplicación que es accedida vía web por una red como internet o una intranet.

En general, el término también se utiliza para designar aquellos programas informáticos que son ejecutados en el entorno del navegador (por ejemplo, un applet de Java) o codificado con algún lenguaje soportado por el navegador (como JavaScript, combinado con HTML); confiándose en el navegador web para que reproduzca (renderice) la aplicación.

Características de las aplicaciones web

* El usuario puede acceder fácilmente a estas aplicaciones empleando un navegador web (cliente) o similar.

* Si es por internet, el usuario puede entrar desde cualquier lugar del mundo donde tenga un acceso a internet.

* Pueden existir miles de usuarios pero una única aplicación instalada en un servidor, por lo tanto se puede actualizar y mantener una única aplicación y todos sus usuarios verán los resultados inmediatamente.

* Emplean tecnologías como Java, JavaFX, JavaScript, DHTML, Flash, Ajax… que dan gran potencia a la interfaz de usuario.

Interfaz gráfica de las aplicaciones web
La interfaz gráfica de una aplicación web puede ser sumamente completa y funcional, gracias a las variadas tecnologías web que existen: Java, JavaScript, DHTML, Flash, Silverlight, Ajax, entre otras.

Prácticamente no hay limitaciones, las aplicaciones web pueden hacer casi todo lo que está disponible para aplicaciones tradicionales: acceder al mouse, al teclado, ejecutar audio o video, mostrar animaciones, soporte para arrastrar y soltar, y otros tipos de tecnologías de interacción usuario-aplicación.

CORREO ELECTRONICO

Correo electrónico (correo-e, conocido también como e-mail), es un servicio de red que permite a los usuarios enviar y recibir mensajes y archivos rápidamente (también denominados mensajes electrónicos o cartas electrónicas) mediante sistemas de comunicación electrónicos. Principalmente se usa este nombre para denominar al sistema que provee este servicio en Internet, mediante el protocolo SMTP, aunque por extensión también puede verse aplicado a sistemas análogos que usen otras tecnologías. Por medio de mensajes de correo electrónico se puede enviar, no solamente texto, sino todo tipo de documentos digitales.

TRANSFERENCIAS DE ARCHIVOS

Protocolo para la transferencia de archivos o de protocolo de transferencia de archivos es una convención o una norma que controla o permite la transferencia de archivos entre dos computadoras.

Hay 2 tipos de transferencias de archivos:

•                     Transferencia de archivos “Pull-based”: El receptor inicia una solicitud de transmisión de ficheros.

•                     Transferencia de archivos “Push-based”:El emisor inicia una solicitud de transmisión de ficheros.

La transferencia de archivos puede tener lugar sobre una variedad de niveles:

•                     Transferencias de archivos transparentes a través sistemas de archivos de red.

•                     Transferencia de archivos explícitos desde servicios de transferencia de archivos dedicados como FTP o HTTP.

•                     Transferencia de archivos distribuidas entre redes punto a punto.

•                     Transferencia de archivos en los sistemas de mensajería instantánea.

•                     Transferencia de archivos entre ordenadores y dispositivos periféricos.

•                     Transferencia de archivos sobre vínculos directos módem o serie (null modem), como XMODEM, YMODEM y ZMODEM.

SERVICIO DE LOS SITEMAS OPERATIVOS

•                     Registro de sucesos   Este servicio permite ver en el Visor de sucesos los mensajes de registros emitidos por los servicios de Exchange y otros programas y componentes de Windows. Este servicio no puede detenerse.

•                     Proveedor de compatibilidad con seguridad LM de Windows NT  Este servicio proporciona seguridad a los programas que utilizan llamadas a procedimiento remoto (RPC) y transportes distintos a canalizaciones con nombre para iniciar sesión en la red mediante el protocolo de autenticación NTLM.

•                     Llamada a procedimiento remoto (RPC)   Este servicio permite al asignador de puntos finales RPC admitir conexiones RPC con el servidor. Este servicio sirve también como Modelo de objetos componentes (COM).


RPC y las llamadas a procedimiento remoto ligeras (LRPC) son mecanismos de comunicación entre procesos importantes. Las LRPC son versiones locales de las RPC. Las LRPC se utilizan entre el almacén de Exchange y los componentes de servidor que dependen de MAPI y sus API relacionadas para las comunicaciones, como por ejemplo conectores de mensajería para sistemas de mensajería que no son de Exchange. Las RPC normales, en cambio, se utilizan cuando los clientes deben comunicarse con los servicios de servidor a través de la red

Es importante comprender que las RPC son un mecanismo de comunicación de capa de aplicación, lo que significa que las RPC utilizan otros mecanismos de comunicación de red, como NetBIOS, canalizaciones con nombre o Windows Sockets, para establecer la ruta de comunicación. Para crear una conexión, es necesario el asignador de puntos finales RPC, ya que el cliente debe determinar en primer lugar el punto final que se tiene que usar. De manera predeterminada, los servicios de servidor RPC utilizan puntos finales de conexión dinámica. En una red TCP/IP, el cliente se conecta al asignador de puntos finales RPC a través del puerto TCP número 135, consulta el puerto TCP actual de un servicio concreto (por ejemplo, el puerto de Interfaz de proveedor de servicios con nombre (NSPI) de Active Directory), obtiene este puerto TCP del asignador de puntos finales, y finalmente utiliza el puerto para establecer la conexión RPC con el servidor RPC real. La figura siguiente ilustra la función del asignador de puntos finales RPC.