8/7/2019 Arquitecturas Basadas en Componentes
1/10
8/7/2019 Arquitecturas Basadas en Componentes
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
8/7/2019 Arquitecturas Basadas en Componentes
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
8/7/2019 Arquitecturas Basadas en Componentes
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.
8/7/2019 Arquitecturas Basadas en Componentes
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
8/7/2019 Arquitecturas Basadas en Componentes
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).
8/7/2019 Arquitecturas Basadas en Componentes
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/7/2019 Arquitecturas Basadas en Componentes
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.
8/7/2019 Arquitecturas Basadas en Componentes
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
8/7/2019 Arquitecturas Basadas en Componentes
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
Top Related