Arquitecturas Basadas en Componentes

8/7/2019 Arquitecturas Basadas en Componentes

1/10


2/10

2 | P g i n a

Independiente. Los Componentesestn diseados para tener una

dependencia mnima de otros

componentes. Por lo tanto los

componentes pueden ser instalados

en el ambiente adecuado sin afectar

otros componentes o sistemas.

Beneficios

Los siguientes son los principales beneficios

del estilo de arquitectura basado en

componentes:

Facilidad de Instalacin. Cuando unanueva versin est disponible, usted

podr reemplazar la versin

existente sin impacto en otroscomponentes o el sistema como un

todo.

Costos reducidos. El uso decomponentes de terceros permite

distribuir el costo del desarrollo y del

mantenimiento.

Facilidad de desarrollo. Loscomponentes implementan un

interface bien definida para proveer

la funcionalidad definida

permitiendo el desarrollo sinimpactar otras partes del sistema.

Reusable. El uso de componentesreutilizables significa que ellos

pueden ser usados para distribuir el

desarrollo y el mantenimiento entre

mltiples aplicaciones y sistemas.

Mitigacin de complejidad tcnica.Los componentes mitigan la

complejidad por medio del uso de

contenedores de componentes y sus

servicios. Ejemplos de servicios de

componentes incluyen activacin de

componentes, gestin de la vida de

los componentes, gestin de colas de

mensajes para mtodos del

componente y transacciones.

Ejemplos

Tipos comunes de componentes usados en

aplicaciones incluyen:

Componentes de interfaz de usuario,como grillas, botones, etc.,

generalmente conocidos como

controles.

Componentes de ayuda que exponenun conjunto especfico de funciones

usados por otros componentes.

Componentes que se no se usan conmucha frecuencia o son intensivos

en recursos y deben ser actividades

usando una aproximacin de solo en

el momento justo (Just in Time (JIT)).

Estos son comunes en escenarios decomponentes distribuidos o en

componentes remotos.

Componentes encolados, aquelloscuyos mtodos pueden ser

ejecutados de forma asncrona

usando colas de mensajes del tipo

almacenamiento, entrega.

CORBA

CORBA (Common Object Request Broker

Architecture arquitectura comn de

intermediarios en peticiones a objetos); es

un estndar que establece una plataforma

de desarrollo de sistemas distribuidos

facilitando la invocacin de mtodos

remotos bajo un paradigma orientado a

objetos.

CORBA fue definido y est controlado por elObject Management Group (OMG) que

define las APIs, el protocolo de

comunicaciones y los mecanismos necesarios

para permitir la interoperabilidad entre

diferentes aplicaciones escritas en diferentes

lenguajes y ejecutadas en diferentes


3/10

3 | P g i n a

plataformas, lo que es fundamental en

computacin distribuida.

En un sentido general, CORBA "envuelve" el

cdigo escrito en otro lenguaje, en un

paquete que contiene informacin adicional

sobre las capacidades del cdigo que

contiene y sobre cmo llamar a sus mtodos.

Los objetos que resultan, pueden entonces

ser invocados desde otro programa (u objeto

CORBA) desde la red. En este sentido CORBA

se puede considerar como un formato de

documentacin legible por la mquina,

similar a un archivo de cabeceras, pero con

ms informacin.

CORBA utiliza un lenguaje de definicin de

interfaces (IDL) para especificar las interfacescon los servicios que los objetos ofrecern.

CORBA puede especificar a partir de este IDL,

la interfaz a un lenguaje determinado,

describiendo cmo los tipos de dato CORBA

deben ser utilizados en las implementaciones

del cliente y del servidor. Implementaciones

estndar existen para Ada, C, C++, Smalltalk,

Java, Python, Perl y Tcl.

Al compilar una interfaz en IDL se genera

cdigo para el cliente y el servidor (elimplementador del objeto). El cdigo del

cliente sirve para poder realizar las llamadas

a mtodos remotos. Es el conocido como

stub, el cual incluye un proxy (representante)

del objeto remoto en el lado del cliente. El

cdigo generado para el servidor consiste en

unos skeletons (esqueletos) que el

desarrollador tiene que rellenar para

implementar los mtodos del objeto.

CORBA es ms que una especificacin

multiplataforma, tambin define servicios

habitualmente necesarios como seguridad y

transacciones. Y as este no es un sistema

operativo en si, en realidad es un

middleware.

COM

Component Object Model (COM) es una

plataforma de Microsoft para componentes

de software introducida por dicha empresa

en 1993. Esta plataforma es utilizada parapermitir la comunicacin entre procesos y la

creacin dinmica de objetos, en cualquier

lenguaje de programacin que soporte dicha

tecnologa. El trmino COM es a menudo

usado en el mundo del desarrollo de

software como un trmino que abarca las

tecnologas OLE, OLE Automation, ActiveX,

COM+ y DCOM. Si bien COM fue introducido

en 1993, Microsoft no hizo nfasis en el

nombre COM hasta 1997.

Esencialmente COM es una manera de

implementar objetos neutrales con respecto

al lenguaje, de manera que pueden ser

usados en entornos distintos de aquel en

que fueron creados, a travs de fronteras

entre mquinas. Para componentes bien

creados, COM permite la reutilizacin de

objetos sin conocimiento de su

implementacin interna, porque fuerza a los

implementadores de componentes a proveer

interfaces bien definidas que estn

separados de la implementacin. Lasdiferentes semnticas de reserva de

memoria estn acomodadas haciendo a los

objetos responsables de su propia creacin y

destruccin por medio del contador de

referencias. Se puede hacer casting entre

distintas interfaces de un objeto por medio

de la funcin QueryInterface(). El mtodo

preferido de herencia en COM es la creacin

de sub objetos a los que se delegan las

llamadas a mtodos ( llamado agregacin ).

Aunque estas tecnologas han sido

implementadas en muchas plataformas, son

principalmente usadas con Microsoft

Windows. Se espera que COM sea sustituido,

al menos en un cierto grado, por

Microsoft.NET, y soporte para Web Services


4/10

4 | P g i n a

a travs de Windows Communication

Foundation (WCF). DCOM en red usa

formatos binarios propietarios, mientras que

WCF usa mensajes SOAP basados en XML.

COM tambin compite con CORBA y Java

Beans como sistema de componentes de

software.

Detalles tcnicos

Los programadores COM construyen

software usando componentes de software

COM-aware. Diferentes tipos de

componentes son identificados por tipo de

IDs (CLSIDs), los cuales son identificadores

globales nicos, o GUIDs. Cada componente

COM revela su funcionalidad por medio de

una o ms interfaces. Las diferentesinterfaces soportadas por un componente

son distinguidas las unas de las otros usando

interfaces IDs (IIDs), que son tambin GUIDs.

Las Interfaces COM tienen implementaciones

en varios lenguajes, tales como C, C++, Visual

Basic, y varios de los lenguajes de script

implementados en la plataforma Windows.

Todo acceso a los componentes se realiza a

travs de los mtodos de las interfaces. Esto

permite que tcnicas como inter-proceso,incluso programacin entre ordenadores

(este ltimo mediante el apoyo de DCOM).

Interfaces

Todos los componentes COM deben

implementar, al menos, la interfaz estndar

IUnknown, y as todas las interfaces COM son

derivadas de IUnknown. La interfaz IUnkown

consta de tres mtodos: AddRef() y Release(),

que implementan conteo de referencias ycontrol del ciclo de vida de las interfaces; y

QueryInterface(), que por especificar un IID

permite a una llamada recuperar las

referencias a las diferentes interfaces que el

componente implementa. El efecto de

QueryInterface() es similar a dynamic_cast

en C + + o casting en C # y Java.

Las interfaces de un componente COM es

necesario que muestren las propiedades

reflexiva, simtrica y transitiva. La propiedad

reflexiva se refiere a la capacidad para que la

llamada al QueryInterface(), dada una

interfaz con el ID de la interfaz, devuelva la

misma instancia de la interfaz. La propiedad

simtrica hace referencia a que cuando la

interfaz B es recuperada de la interfaz A por

el QueryInterface(), la interfaz A es asimismo

recuperable de la B. La propiedad transitiva

es similar a la simtrica, pero requiere que si

la interfaz B puede conseguirse de la A, y la C

a su vez de la B, entonces la interfaz C

debera poder conseguirse de la A.

Una interfaz consta de un puntero a una

funcin virtual que contiene una lista de

punteros a las funciones que implementa la

funcin declarada en la interfaz, en el mismo

orden que fueron declaradas en la interfaz.

Esta tcnica de paso de punteros de funcin

de estructuras es muy parecida a la utilizada

por OLE 1.0 para comunicar con su sistema

de libreras.

COM especifica muchas otras interfaces

estndar usadas para permitir comunicacin

entre componentes. Por ejemplo, una de

ellas es IStream, que est puesta para los

componentes que tienen semntica de flujo

de datos (un componente FileStream usado

para leer y escribir archivos). Tiene los

esperados mtodos Read y Write para

realizar las lecturas y escrituras de flujo. Otra

interfaz estndar es IOleObject, que esta

puesta para componentes que esperan ser

enlazados o empotrados en un contenedor.

IOleObject contiene mtodos que permiten a

los interesados determinar el tamao de los

lmites de un componente rectngulo, si el

componente soporta operaciones como

Open, Save y as sucesivamente.


5/10

5 | P g i n a

Clases

Una clase en COM se denomina coclass, que

es la forma contrada de Component Object

class. Una coclass es la forma de COM de

definir una clase en el sentido orientado a

objetos independiente del lenguaje. Una

coclass suministra una implementacin

concreta de una o ms interfaces. En COM,

tales implementaciones concretas pueden

ser escritas en cualquier lenguaje de

programacin que soporte desarrollo de

componentes COM, como C++, Visual Basic,

etc.

Una de las mayores contribuciones de COM

al mundo de desarrollo Windows es la toma

de conciencia del concepto de separacin deinterfaz de implementacin. Esta toma de

conciencia ha influido, sin duda, en el camino

programadores al construir los sistemas de

hoy. Una extensin de este concepto

fundamental es el concepto de una interfaz,

mltiples implementaciones. Esto significa

que en tiempo de ejecucin, una aplicacin

puede elegir la instanciacin de una interfaz

de una de las diferentes implementaciones

concretas.

Lenguaje de definicin de interfaces ybibliotecas de tipos

Las bibliotecas de tipos contienen metadatos

que representan los tipos COM. Sin embargo,

estos tipos deben ser primero descritos

usando el Microsoft Interface Definition

Language. Esto es la prctica comn en el

desarrollo de un componente COM, por

ejemplo al empezar con la definicin de tipos

usando IDL. Un archivo IDL es lo queproporciona COM que permite a los

desarrolladores definir las clases orientadas

a objetos, interfaces, estructuras,

enumeraciones y otros tipos definidos por el

usuario en un lenguaje de forma

independiente. COM IDL es similar en

apariencia a las declaraciones de C / C + +

con la adicin de palabras clave como

"interface" y "library" para la definicin de

interfaces y de las colecciones de las clases,

respectivamente. IDL tambin requiere el

uso de los atributos entre corchetes antes de

las declaraciones para proporcionar

informacin adicional, como el GUID de las

interfaces y la relacin entre los parmetros

de puntero y longitud de los campos.

El archivo IDL es compilado por el

compilador MIDL en un par de formas para

utilizarlos en varios lenguajes. Para C/C++, el

compilador MIDL genera una cabecera

independiente del compilador que contiene

definiciones de estructuras que emparejan

las funciones virtuales de la declaracin deinterfaces y un archivo C que contiene

declaraciones de la interfaz GUIDs. El cdigo

fuente C++ para un modulo Proxy puede

tambin ser generado por el compilador

MIDL. Este Proxy contiene mtodos stubs

para convertir llamadas COM en RPC, esto

permitido por el DCOM.

Un archivo IDL puede tambin ser compilado

por el compilador MIDL en una librera de

tipos (archivo .TLB). Los metadatos binarioscontenidos dentro de la librera tiene

significado para ser procesados por los

compiladores del lenguaje y entornos de

tiempo de ejecucin (VB, Delphi, el .NET CLR,

etc.). El resultado final de tal procesado TLB

es que la construccin especfica de cada

lenguaje estn producidas a lo que

representa la clase COM definida en la .TLB

(y en definitiva el que se defini en el archivo

de origen IDL).

Conteo de referencias

La ms importante de todas las interfaz COM,

es decir, IUnknown (de la que todas las

interfaces COM debe ser derivadas), admite

dos conceptos principales: la exploracin


6/10

6 | P g i n a

caractersticas a travs del mtodo

QueryInterface, y la gestin del ciclo de vida

del objeto mediante la inclusin de AddRef ()

y Release (). Conteo de referencias y

exploracin de caracterstica que se aplican a

los objetos (no a cada interfaz de un objeto)

y, por tanto, debe tener una implementacin

centralizada.

Las especificaciones COM requieren de una

tcnica llamada conteo de referencias para

garantizar que los distintos objetos estn

vivos mientras haya clientes que han

adquirido el acceso a uno o ms de sus

interfaces y, por el contrario, que el mismo

objeto est correctamente eliminados

cuando todo cdigo que usa el objeto haya

terminado con l y ya no lo requiere. Unobjeto COM es el responsable de la

liberacin de su propia memoria una vez que

su contador de referencias se reduce a cero.

Para su ejecucin, un objeto COM

generalmente mantiene un valor que se

utiliza de referencia para el conteo. Cuando

es llamado AddRef () a travs de cualquiera

de las interfaces del objeto, este valor se

incrementa. Cuando se llama a Release(),

este nmero entero se decrementa. AddRef() y Release () son los nicos medios por los

que un cliente de un objeto COM es capaz de

influir en su ciclo de vida. El valor interno

sigue siendo un miembro privado del objeto

COM y nunca ser accesible directamente.

DCOM

Distributed Component Object Model

(DCOM), en espaol Modelo de Objetos de

Componentes Distribuidos, es una tecnologapropietaria de Microsoft para desarrollar

componentes software distribuidos sobre

varios ordenadores y que se comunican

entre s. Extiende el modelo COM de

Microsoft y proporciona el sustrato de

comunicacin entre la infraestructura del

servidor de aplicaciones COM+ de Microsoft.

Ha sido abandonada en favor del

framework .NET

La adicin de la "D" a COM fue debido al uso

extensivo de DCE/RPC, o ms

especficamente la versin mejorada de

Microsoft, conocida como MSRPC.

En trminos de las extensiones que aade a

COM, DCOM tena que resolver los

problemas de

Aplanamiento - Serializar y deserializarlos argumentos y valores de retorno de

las llamadas a los mtodos "sobre el

cable".

Recoleccin de basura distribuida,asegurndose que las referencias

mantenidas por clientes de las

interfaces sean liberadas cuando, por

ejemplo, el proceso cliente ha cado o

la conexin de red se pierde.

Uno de los factores clave para resolver estos

problemas es el uso de DCE/RPC como el

mecanismo RPC subyacente bajo DCOM.

DCE/RPC define reglas estrictas en cuanto al

aplanamiento y a quin es responsable deliberar la memoria.

DCOM fue uno de los mayores competidores

de CORBA. Los defensores de ambas

tecnologas sostenan que algn da seran el

modelo de cdigo y servicios sobre Internet.

Sin embargo, las dificultades que supona

conseguir que estas tecnologas funcionasen

a travs de cortafuegos y sobre mquinas

inseguras o desconocidas, signific que las

peticiones HTTP normales, combinadas con

los navegadores web les ganasen la partida.

Microsoft, en su momento intent y fracas

anticiparse a esto aadiendo un transporte

extra HTTP a DCE/RPC denominado

"ncacn_http" (Connection-based, over HTTP).


7/10

7 | P g i n a

JAVA RMI

RMI (Java Remote Method Invocation) es un

mecanismo ofrecido por Java para invocar un

mtodo de manera remota. Forma parte del

entorno estndar de ejecucin de Java yproporciona un mecanismo simple para la

comunicacin de servidores en aplicaciones

distribuidas basadas exclusivamente en Java.

Si se requiere comunicacin entre otras

tecnologas debe utilizarse CORBA o SOAP en

lugar de RMI.

RMI se caracteriza por la facilidad de su uso

en la programacin por estar

especficamente diseado para Java;

proporciona paso de objetos por referencia

(no permitido por SOAP), recoleccin de

basura distribuida (Garbage Collector

distribuido) y paso de tipos arbitrarios

(funcionalidad no provista por CORBA).

A travs de RMI, un programa Java puede

exportar un objeto, con lo que dicho objeto

estar accesible a travs de la red y el

programa permanece a la espera de

peticiones en un puerto TCP. A partir de ese

momento, un cliente puede conectarse e

invocar los mtodos proporcionados por elobjeto.

La invocacin se compone de los siguientes

pasos:

Encapsulado (marshalling) de losparmetros (utilizando la funcionalidad

de serializacin de Java).

Invocacin del mtodo (del clientesobre el servidor). El invocador se

queda esperando una respuesta. Al terminar la ejecucin, el servidor

serializa el valor de retorno (si lo hay) y

lo enva al cliente.

El cdigo cliente recibe la respuesta ycontina como si la invocacin hubiera

sido local.

Contexto

Desde la versin 1.1 de JDK, Java tiene su

propio ORB: RMI (Remote Method

Invocation). A pesar de que RMI es un ORB

en el sentido general, no es un modelo

compatible con CORBA. RMI es nativo de

Java, es decir, es una extensin al ncleo del

lenguaje. RMI depende totalmente del

ncleo de la Serializacin de Objetos de Java,

as como de la implementacin tanto de la

portabilidad como de los mecanismos de

carga y descarga de objetos en otros

sistemas, etc.

El uso de RMI resulta muy natural para todo

aquel programador de Java ya que ste no

tiene que aprender una nueva tecnologacompletamente distinta de aquella con la

cual desarrollar. Sin embargo, RMI tiene

algunas limitaciones debido a su estrecha

integracin con Java, la principal de ellas es

que esta tecnologa no permite la interaccin

con aplicaciones escritas en otro lenguaje.

RMI como extensin de Java, es una

tecnologa de programacin, fue diseada

para resolver problemas escribiendo y

organizando cdigo ejecutable. As RMIconstituye un punto especfico en el espacio

de las tecnologas de programacin junto con

C, C++, Smalltalk, etc.

Arquitectura

La arquitectura RMI puede verse como un

modelo de cuatro capas.

Primera capa

La primera capa es la de aplicacin y se

corresponde con la implementacin real de

las aplicaciones cliente y servidor. Aqu

tienen lugar las llamadas a alto nivel para

acceder y exportar objetos remotos.

Cualquier aplicacin que quiera que sus


8/10

8 | P g i n a

mtodos estn disponibles para su acceso

por clientes remotos debe declarar dichos

mtodos en una interfaz que extienda

java.rmi.Remote. Dicha interfaz se usa

bsicamente para "marcar" un objeto como

remotamente accesible. Una vez que los

mtodos han sido implementados, el objeto

debe ser exportado. Esto puede hacerse de

forma implcita si el objeto extiende la clase

UnicastRemoteObject (paquete

java.rmi.server), o puede hacerse de forma

explcita con una llamada al mtodo

exportObject() del mismo paquete.

Segunda capa

La capa 2 es la capa proxy, o capa stub-

skeleton. Esta capa es la que interactadirectamente con la capa de aplicacin.

Todas las llamadas a objetos remotos y

acciones junto con sus parmetros y retorno

de objetos tienen lugar en esta capa.

Tercera capa

La capa 3 es la de referencia remota, y es

responsable del manejo de la parte

semntica de las invocaciones remotas.

Tambin es responsable de la gestin de lareplicacin de objetos y realizacin de tareas

especficas de la implementacin con los

objetos remotos, como el establecimiento de

las persistencias semnticas y estrategias

adecuadas para la recuperacin de

conexiones perdidas. En esta capa se espera

una conexin de tipo stream (stream-

oriented connection) desde la capa de

transporte.

Cuarta Capa

La capa 4 es la de transporte. Es la

responsable de realizar las conexiones

necesarias y manejo del transporte de los

datos de una mquina a otra. El protocolo de

transporte subyacente para RMI es JRMP

(Java Remote Method Protocol), que

solamente es "comprendido" por programas

Java.

Elementos

Toda aplicacin RMI normalmente se

descompone en 2 partes:

Un servidor, que crea algunos objetosremotos, crea referencias para

hacerlos accesibles, y espera a que el

cliente los invoque.

Un cliente, que obtiene una referenciaa objetos remotos en el servidor, y los

invoca.

JAVABEANS

Los JavaBeans son un modelo de

componentes creado por Sun Microsystems

para la construccin de aplicaciones en Java.

Se usan para encapsular varios objetos en un

nico objeto (la vaina o Bean en ingls), para

hacer uso de un solo objeto en lugar de

varios ms simples.

La especificacin de JavaBeans de Sun

Microsystems los define como

"componentes de software reutilizables que

se puedan manipular visualmente en una

herramienta de construccin".

A pesar de haber muchas semejanzas, los

JavaBeans no deben confundirse con los

Enterprise JavaBeans (EJB), una tecnologa

de componentes del lado servidor que esparte de Java EE.


9/10

9 | P g i n a

Convenciones JavaBean

Para funcionar como una clase JavaBean, una

clase debe obedecer ciertas convenciones

sobre nomenclatura de mtodos,

construccin, y comportamiento.

Estas convenciones permiten tener

herramientas que puedan utilizar, reutilizar,

sustituir, y conectar JavaBeans.

Las convenciones requeridas son:

Debe tener un constructor sinargumentos.

Sus propiedades deben ser accesiblesmediante mtodos get y set que

siguen una convencin de

nomenclatura estndar.

Debe ser serializableEstructura

Dentro de un JavaBean podemos distinguir

tres partes:

Propiedades: Los atributos quecontiene.

Mtodos: Se establecen los mtodosget y set para acceder y modificar los

atributos.

Eventos: Permiten comunicarnos conotros JavaBeans

JAVA RPC

El RPC (del ingls Remote Procedure Call,

Llamada a Procedimiento Remoto) es un

protocolo que permite a un programa de

ordenador ejecutar cdigo en otra mquina

remota sin tener que preocuparse por las

comunicaciones entre ambos. El protocolo es

un gran avance sobre los sockets usados

hasta el momento. De esta manera el

programador no tena que estar pendiente

de las comunicaciones, estando stas

encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro del

paradigma cliente-servidor. Siendo el cliente

el que inicia el proceso solicitando al servidor

que ejecute cierto procedimiento o funcin y

enviando ste de vuelta el resultado de dicha

operacin al cliente.

Hay distintos tipos de RPC, muchos de ellos

estandarizados como pueden ser el RPC de

Sun denominado ONC RPC (RFC 1057), el RPC

de OSF denominado DCE/RPC y el Modelo de

Objetos de Componentes Distribuidos de

Microsoft DCOM, aunque ninguno de estoses compatible entre s. La mayora de ellos

utilizan un lenguaje de descripcin de

interfaz (IDL) que define los mtodos

exportados por el servidor.

Hoy en da se est utilizando el XML como

lenguaje para definir el IDL y el HTTP como

protocolo de red, dando lugar a lo que se

conoce como servicios web. Ejemplos de

stos pueden ser SOAP o XML-RPC.

CONCLUSIONES

En mi opinin, de las 6 arquitecturas basadas

en componentes que se revisaron, el que es

ms factible para utilizar es el protocolo

JAVA RPC ya que permite que un programa

de ordenador ejecutarse en otra mquina y

no requiere estarse preocupando por el

factor de la comunicacin entre las mquinas

implicadas.

REFERENCIA

http://www.juanpelaez.com/Blog/CommentView,guid,bb1210d3-404c-466b-

b1cd-3933d73685cc.aspx


10/10

10 | P g i n a

http://es.wikipedia.org/wiki/CORBA http://es.wikipedia.org/wiki/Compone

nt_Object_Model

http://es.wikipedia.org/wiki/Distributed_Component_Object_Model

http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation

http://es.wikipedia.org/wiki/JavaBean http://es.wikipedia.org/wiki/RPC

Arquitecturas Basadas en Componentes

Documents

Transcript of Arquitecturas Basadas en Componentes