Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Planeación, cálculo y estimación de tamaño

No description
by

Lana Luna Cortes Perez

on 29 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Planeación, cálculo y estimación de tamaño

Método de estimación por puntos de función
2.6.2 Método de estimación por puntos de función
Planeación, cálculo y estimación de tamaño

1. Introducción.
2. COM / DCOM
3. CORBA
4. Common Gateway Interface (CGI)
5. Java en Computación Distribuida
6. Comparación de Arquitecturas

2.6.3 Método del componente estándar
INTRODUCCIÓN.

En las primeras épocas de la computación las computadoras operaban independientemente una de otra sin tener comunicación entre ellas. y buscando satisfacer esa necesidad de mecanismos estándar e interfaces abiertas, son tres los esfuerzos que más han sobresalido. Por un lado, Microsoft ha introducido en el mercado sus tecnologías COM, DCOM y COM+. Otro participante es Sun Microsystems, que ha presentado Java Beans. El tercero es el Object Management Group, un consorcio integrado por varias industrias importantes, que ha desarrollado CORBA (Common Request Broker Architecture).



Microsoft Distributed COM (DCOM) extiende COM (Component Object Model) para soportar comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso en Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al cliente y a la aplicación.

Como DCOM es una evolución lógica de COM, se pueden utilizar los componentes creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM maneja detales muy bajos de protocolos de red, por lo que uno se puede centrar en la realidad de los negocios: proporcionar soluciones a clientes.

Atualmente DCOM viene con los sistemas operativos Windows 2000, NT, 98 y también está disponible una versión para Windows 95 en la página de Microsoft. También hay una implementación de DCOM para Apple Macintosh y se está trabajando en implementaciones para plataformas UNIX como Solaris.

1. COM / DCOM
1.1 La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus clientes interactuan entre sí. Esta interacción es definida de tal manera que el cliente y el componente puede conectar sin la necesidad de un sistema intermedio. El cliente llama a los métodos del componente sin tener que preocuparse de niveles más complejos.
COM proporciona este tipo de comunicación de una forma transparente: intercepta las llamadas del cliente y las reenvía al componente que está en otro proceso.
Cuando el cliente y el componente residen en distintas máquinas, DCOM simplemente reemplaza la comunicación entre procesos locales por un protocolo de red. Ni el cliente ni el componente se enteran de que la unión que los conecta es ahora un poco más grande.
Las librería de COM proporcionan servicios orientados a objetos a los clientes y componentes, y utilizan RPC y un proveedor de seguridad para generar paquetes de red estándar que entienda el protocolo estándar de DCOM.

1.2 Los Componentes y su reutilización
Muchas aplicaciones distribuidas no están desarrolladas
Al existir infraestructuras de hardware, software, componentes, al igual que herramientas, se necesita poder integrarlas y nivelarlas para reducir el desarrollo y el tiempo de trabajo y coste. DCOM toma ventaja de forma directa y transparente de los componentes COM y herramientas ya existentes.. Muchos desarrolladores están familiarizados con COM y pueden aplicar fácilmente sus conocimientos a las aplicaciones distribuidas basadas en DCOM.

Cualquier componente que sea desarrollado como una parte de una aplicación distribuida es un candidato para ser reutilizado. Organizando los procesos de desarrollo alrededor del paradigma de los componentes permite continuar aumentando el nivel de funcionalidad en las nuevas aplicaciones y reducir el tiempo de desarrollo.
Diseñando para COM y DCOM se asegura que los componentes creados serán útiles ahora y en el futuro.

1.3 Independencia de la localización
Cuando se comienza a implementar una aplicación distribuida en una red real, aparecen distintos conflictos en el diseño:

• Los componentes que interactuan más a menudo deberían estar localizados más cerca.
• Algunos componentes solo pueden ser ejecutados en máquinas específicas o lugares específicos.
• Los componentes más pequeños aumentan la flexibilidad, pero aumentan el tráfico de red.
• Los componentes grandes reducen el tráfico de red, pero también reducen la flexibilidad.

Con la independencia de localización de DCOM, la aplicación puede combinar componentes relacionados en máquinas "cercanas" entre si, en una sola máquina o incluso en el mismo proceso. Incluso si un gran número de pequeños componentes implementan la funcionalidad de un gran módulo lógico, podrán interactuar eficientemente entre ellos.
1.4 Independencia del lenguaje de programación
Virtualmente cualquier lenguaje puede ser utilizado para crear componentes COM, y estos componentes puede ser utilizado por muchos más lenguajes y herramientas.

La independencia del lenguaje permite crear componentes en lenguajes de nivel superior como Microsoft Visual Basic, y después re implementarlos en distintos lenguajes como C++ o Java, que permiten tomar ventaja de características avanzadas como multihilo.

1.5 Independencia del protocolo
Los desarrolladores de aplicaciones tienen que tener cuidado de mantener la aplicación lo más independiente posible de la infraestructura de la red.
DCOM proporciona esta transparencia: DCOM puede utilizar cualquier protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un marco de seguridad a todos estos protocolos.
Los desarrolladores pueden simplemente utilizar las características proporcionadas por DCOM y asegurar que sus aplicaciones son completamente independiente del protocolo.

2. CORBA
es un Middeware o marco de trabajo estándar y abierto de objetos distribuidos que permite a los componentes en la red interoperar en un ambiente común sin importar el lenguaje de desarrollo, sistema operacional, tipo de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser invocados “transparentemente” en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker). Además del objetivo básico de ejecutar simplemente métodos en objetos remotos, CORBA adiciona un conjunto de servicios que amplían las potencialidades de éstos objetos y conforman una infraestructura sólida para el desarrollo de aplicaciones críticas de negocio.
2.1 Servicios Middleware
se encuentran en una capa intermedia, por encima del sistema operativo y del software de red y por debajo de las aplicaciones de los usuarios finales

Un servicio middleware es un servicio de propósito general que se ubica entre plataformas y aplicaciones. Por plataformas se entiende el conjunto de servicios de bajo nivel ofrecidos por la arquitectura de un procesador y el conjunto de API´s de un sistema operativo. Como ejemplos de plataformas se pueden citar: Intel x86 y Win-32, SunSPARCStation y Solaris, IBM RS/6000 y AIX, entre otros.
Un servicio middleware está definido por las API´s y el conjunto de protocolos que ofrece. Pueden existir varias implementaciones que satisfagan las especificaciones de protocolos e interfaces. Los componentes middleware se distinguen de aplicaciones finales y de servicios de plataformas específicas por cuatro importantes propiedades:
 Son independientes de las aplicaciones y de las industrias para las que éstas se desarrollan.
 Se pueden ejecutar en múltiples plataformas.
 Se encuentran distribuidos.
 Soportan interfaces y protocolos estándar.

2.2 Arquitectura de CORBA
CORBA define una arquitectura para los objetos distribuidos. El paradigma básico de CORBA es el de un pedido servicios de un objeto distribuido. Todo definido por el OMG está en términos de este paradigma básico.
Los servicios que un objeto proporciona son dados por su interfaz . Los interfaces se definen en la lengua de la definición de interfaz de OMG (IDL). Los objetos distribuidos son identificados por las referencias del objeto, que son mecanografiadas por los interfaces de IDL.

2.3 CORBA como estándar para los objetos distribuidos
Una de las metas de la especificación de CORBA es que los clientes y las puestas en práctica del objeto son portables. agregó interoperabilidad como meta en la especificaciones. El detalle de En, CORBA 2,0 definen el protocolo del un de la red, llamado IIOP (el Internet Enterrar-orbe protocolo), permite del que un clientes usando un productos de CORBA del cualquier vendedor para comunicarse hacen trampas el los objetos usando un producto de CORBA del vendedor de otro de cualquier. El trabaja de IIOP un del del través Internet, el o más exacto, un través de la cualquier puesta en práctica de TCP/IP.
2.4 CORBA y el desarrollo basado en componentes
los componentes deben encapsular su implementación e interactuar con otros componentes a través de interfaces bien definidas. Un componente no es un objeto. A diferencia de los objetos, los componentes no tienen estado. Esto quiere decir que un componente no puede distinguirse de una copia de sí mismo. Un componente puede tomar la forma de un archivo ejecutable o una biblioteca dinámica que usualmente cobra vida a través de objetos, pero no es este un requisito indispensable. De hecho, los primeros componentes conocidos (aunque en su momento no se los haya definido así) fueron las bibliotecas de prodecimientos. Sin embargo, los objetos, con sus características de encapsulación y polimorfismo, facilitan la construcción e integración de componentes.
Y al hablar de objetos vale la pena distinguir aquí los objetos de las clases. Una clase es una definición de propiedades y funcionalidades ha ser provistas por los objetos.
2.5 CORBA Services
Los CORBA Services proveen servicios a nivel de aplicación fundamentales para las aplicaciones orientadas por objetos y componentes en entornos distribuidos. La OMG ha definido alrededor de 15 servicios de objetos. Los cuales son:


• Nombres • Trader • Notificación • Eventos
• Transacciones • Seguridad • Ciclo de vida • Propiedades
• Persistencia • Consulta • Relaciones • Concurrencia
• Externalizació • Licenciamiento • Tiempo • Colección
De éstos 15 se destacan los siguientes servicios clave:
• Acceso a referencias de objetos a través de la red, soportada por el servicio de Nombres y de Trader.
• Notificación de eventos importantes o cambios de estado en un objeto, soportado por el servicio de Eventos y de Notificación.
• Soporte para semántica transaccional (two-phase commit y rollback) soportado por el servicio de Transacciones.
• Soporte para seguridad, soportada por el servicio de Seguridad.
2.6 CORBA Facilities Horizontales
Esta facilidades CORBA tanto horizontales como verticales, son diseñadas para completar la arquitectura entre los Servicios básicos de CORBA y las aplicaciones especificas de industria. Con una arquitectura completa. Las facilidades representan un punto medio entre una aplicación particular y los servicios y ORB.

La OMG ha definido como Facilidades horizontales las siguientes:
• Interface de usuario
• Administración de información
• Administración de sistemas
• Administración de tareas

Hoy en día estas especificaciones han sido adheridas a ORBOS (ORB y Servicios) y ya no esta como un grupo aparte.

Específicamente a nivel de facilidades verticales la OMG ha definido las siguientes:
• Especificación para la administración de sistemas XCMF.
• Facilidad para colar de impresión.

2.7 CORBA Facilities Verticales o de Dominio
Se ha creado el Domain Technology Committee (DTC) y esta a su vez esta organizada en una serie de Domain Task Forces (DTF) los cuales escriben documentos de requerimientos (RFI y RFP) para nuevas especificaciones y evalúan y recomiendan especificaciones candidatas. Basados en las recomendaciones de los DTF, el DTC conduce un proceso formal de votación para asegurar que cumple todos los requerimientos del sector y no solo de quien haya propuesto. Posteriormente estas recomendaciones requieren ser enviadas a la Junta de Directores de la OMG para hacerla una especificación oficial. Actualmente hay 8 DTF:

• Objetos de negocio • Finanzas y seguros • Comercio Electrónico • Manufactura
• Salud o Medicina • Telecomunicaciones • Transportes • Investigación de ciencias de la vida

También bajo la OMG pero que no tienen DTF se encuentran dos Grupos de Interés Especial:
• Utilities (principalmente energía eléctrica)
• Estadística

Seis especificaciones ya han sido adoptadas oficialmente como estándares de dominio vertical, ellos son:

• Facilidad Currency del DTF de Finanzas
• Un conjunto de Habilitadores para la administración de datos de productos, del DTF de manufactura.
• Servicio de Identificación de Personas (PIDS) de CORBAMed
• Servicio de Consulta Lexicon de CORBAMed
• Control y Administración de flujos de Audio/Vídeo, del DTF de telecomunicaciones
• Servicio de Notificación, del DTF de Telecomunicaciones.

2.8 Nuevas especificaciones de CORBA
Integracion de una serie de nuevas especificaciones que unidas dan una nueva dimensión a CORBA. Esta nuevas especificaciones están divididas en tres categorías:
• Integración con Internet.
• Control de Calidad de Servicio
• Arquitectura de componentes CORBA
Por otro lado, han aumentado las especificaciones de mercados verticales, o lo que en CORBA se conoce como Dominios Verticales y mediante la utilización de IDL,
2.9 Integración con Internet
CORBA Components [Omg00d] extiende el modelo de objeto de la OMG para incluir un número de características importantes en un sistema distribuido. La noción de componente puede no corresponder al modelo uno a uno ni de un objeto CORBA, esta centrado más en la relación de un Componente con un conjunto de interfaces.

Los componentes de CORBA no solo serán trasladados a los lenguajes ya soportados, sino también a otros modelos de componentes como los Java Beans. Igualmente se esta trabajando en una especificación para un lenguaje de scripting que facilite el nivel de usuario la utilización de componentes.
3. Common Gateway Interface (CGI)
Common Gateway Interface es una interfaz al servidor Web que permite extender la funcionalidad de éste. Con CGI se puede interactuar con los usuarios que acceden a un sitio en particular. En un nivel teórico, los CGI permiten extender las capacidades del servidor para interpretar las entradas obtenidas del browser (navegador) y regresar la información apropiada de acuerdo a la entrada del usuario. En un nivel práctico, CGI es una interfaz que facilita la escritura de programas para que se comuniquen fácilmente con el servidor.
4. Java en Computación Distribuida
Java es una arquitectura neutral, orientada a objetos, portable y un lenguaje de programación de alto desempeño que proporciona un ambiente de ejecución dinámica, distribuida, robusta, segura y multi-hilos. La principal ventaja de Java para computación distribuida radica en la capacidad de descargar el ambiente. En términos de una arquitectura de objeto distribuido totalmente nueva, Java proporciona las siguientes opciones: Java Remote Method Invocation (RMI), Java IDL y la empresa JavaBEan. La especificación RMI es un API que nos permite crear objetos escritos puramente en lenguaje de programación Java, cuyos métodos se invocan de una Máquina Virtual Java diferente (JVM Java Virtual Machine).
4.1 Java RMI
Básicamente RMI proporciona la capacidad para llamadas a métodos sobre objetos remotos, los cuales convierten al componente de transporte del objeto en arquitectura de objeto distribuido. También proporciona mecanismos para el registro y persistencia del objeto.
La siguiente ilustración representa una aplicación distribuida RMI que utiliza el registro para obtener una referencia a un objeto remoto. El servidor llama al registro para asociar (o ligar) un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y entonces invoca un método sobre él. La ilustración también muestra que el sistema RMI utiliza un servidor Web para cargar los códigos en bytes de las clases, del servidor al cliente y del cliente al servidor, para los objetos cuando se les necesita.


5. Comparación de Arquitecturas
HECHO POR:
Greta May Urbano Cortes
David Pedro Velasco
Oscar Sabino Perez
Tomas lozano Florez
Full transcript