Sei sulla pagina 1di 14

INTRODUCCIN CORBA (Common Object Request Broker Arquitecture) es un estndar para objetos distribuidos que ha sido desarrollado por

el OMG (Object Management Group) una asociaci!n de empresas " usuarios de las mas grandes que e#isten actualmente que agrupa a unas $%% entidades que se dedican bsicamente al desarrollo " comerciali&aci!n de so't(are para sistemas in'ormticos " que en su ma"or)a se encuentran actualmente desarrollando aplicaciones que soportan este estndar o comerciali&ando productos que "a lo hacen* CORBA proporciona los mecanismos a tra+,s de los cuales los objetos hacen peticiones " reciben respuestas de'inidas como ORBs (Object Request Broker) de 'orma transparente para el sistema* -l ORB de CORBA es entonces una aplicacin que proporciona interoperabilidad entre diferentes objetos posiblemente programados en diferentes lenguajes, corriendo bajo sistemas operati os distintos ! en general en diferentes m"quinas* -ste es el punto bsico en el que se basa la arquitectura CORBA* COR#$ %&U' '( COR#$) CORBA es una arquitectura que permite a una aplicaci!n comunicarse con otra sin importar donde esta se encuentre situada ')sicamente o quien " como ha sido dise.ada* /a +ersi!n 0*0 de CORBA 'ue introducida en 0110 por el OMG quien a su +e& de'ini! un lenguaje inter'ace 23/ (2nter'ace 3e'inition /anguage) " una aplicaci!n denominada A42 (Application 4rogramming 2nter'aces) permitiendo la interacci!n entre objetos cliente5ser+idor dentro de una especi'ica implementaci!n de un ORB* CORBA 6*% adoptado en 3iciembre de 0117 especi'ica como ORBs de di'erentes 'abricantes pueden operar entre si* -l ORB es el inter'a& que establece la relaci!n cliente 8 ser+idor entre objetos* 9sando un ORB un cliente puede transparentemente in+ocar un m,todo de un objeto ser+idor el cual puede estar en la misma mquina o a lo largo de la red* -l ORB intercepta la petici!n " es responsable de encontrar un objeto que pueda cursar la petici!n pasar los parmetros in+ocar su ejecuci!n " de+ol+er los resultados* -l cliente no tiene que preocuparse donde esta situado este objeto su lenguaje de programaci!n su sistema operati+o o cualquier otro aspecto del sistema que no sea parte de la inter'a& con este objeto* 3esarrollando t)picas aplicaciones cliente ser+idor los programadores usan su propio dise.o o un estndar reconocido para de'inir el protocolo a usar entre dispositi+os* /a de'inici!n de este protocolo depende del lenguaje de implementaci!n el transporte en la red " decenas de otros 'actores* ORB simpli'ica el proceso*

%*$R$ &U+ COR#$) -l uso de una nue+a tecnolog)a siempre implica unos es'uer&os de 'ormaci!n de los desarrolladores nue+as herramientas nue+os problemas " nue+as soluciones* /a adopci!n de una nue+a tecnolog)a debe ser lle+ada a cabo tras un anlisis de los costes " las +entajas que se obtienen "a que en el 'ondo es una in+ersi!n que debe amorti&arse en el 'uturo* Con el triun'o de las redes de ordenadores " su implantaci!n las aplicaciones distribuidas son las :nicas que pueden e#plotar toda la potencia de este nue+o modelo in'ormtico* /as aplicaciones distribuidas aquellas que se caracteri&an por su ejecuci!n coordinada en di'erentes mquinas comunicadas se caracteri&an por una alta complejidad en todas las etapas de su desarrollo debido a la gran cantidad de 'actores que in'lu"en en su ejecuci!n siendo uno de los principales la gesti!n de las comunicaciones* 4or ejemplo ha" que tener en cuenta que los enlaces entre las mquinas se pueden caer " pre+er qu, hacer en esos casos " como se detectan dichas ca)das* Otro ejemplo ser)a que contra una mquina A se pueden conectar +arias " debe ser capa& esta mquina A de manejar todas las cone#iones* ; las mquinas se tienen que poder encontrar " tienen que poder locali&ar ser+icios remotos* 4odemos citar tambi,n que los entornos en red suelen ser heterog,neos ha" que comunicar di'erentes mquinas con distintas con'iguraciones so't(are " hard(are* CORBA abstrae muchos de estos detalles " hace la distribuci!n de la aplicaci!n un proceso mucho menos complejo " costoso* <e encarga de organi&ar los ser+icios que se pueden encontrar en la red a tra+,s de los inter'aces 23/* -s independiente de la plata'orma " del lenguaje de desarrollo lo que 'acilita el desarrollo en entornos heterog,neos* Gestiona las comunicaciones in'ormando a clientes " ser+idores de ca)das de los canales de comunicaci!n* =acilita la integraci!n de so't(are heredado* >an s!lo ha" que de'inir las inter'aces 23/ de este so't(are para ponerlo disponible en CORBA* 4roporciona ser+icios adicionales para por ejemplo encontrar objetos " ser+icios dentro de entornos distribuidos llegando incluso a de'inir entornos de trabajo CORBA para di'erentes disciplinas? telecomunicaci!n medicina etc* 3entro del libro publicado por OMG @CORBA =undamentals and 4rogramming@ de Aon <iegel se citan otra serie de +entajas? /os desarrolladores pueden utili&ar para sus aplicaciones todo el hard(are " so't(are que "a e#istieran gracias a la uni+ersalidad de CORBA " a su 'acilidad para integrar desarrollos heredados* /a metodolog)a orientada a objetos es una de las ms adecuadas para lograr un proceso de producci!n so't(are en pla&os robusto " que cumpla con lo que se espera* ; adems este tipo de desarrollo

'acilita la reutili&aci!n de los componentes "a desarrollados mejorando la producti+idad* 4ara los usuarios 'inales " las compa.)as* CORBA es una e#celente in+ersi!n "a que gracias a su estandari&aci!n se pueden obtener componentes CORBA de di'erentes +endedores " lograr que todos trabajen entre s)*

-n de'initi+a CORBA presenta unas +entajas enormes en el desarrollo de so't(are distribuido " es una herramienta sin la cual ser)a mu" complicado lle+ar a cabo un pro"ecto en unos pla&os adecuados " con unos resultados robustos* %C,O (' D'($RRO--$ CON COR#$) -l desarrollo con CORBA tiene una serie de pasos adicionales a los desarrollos de so't(are clsicos " una serie de 'actores a tener en cuenta a la hora de desarrollar la aplicaci!n* -n la 'ase de anlisis poco cambia respecto a la metodolog)a que se utili&a en los pro"ectos so't(are clsicos* -n la 'ase de dise.o s) que se pueden optar por unas soluciones basadas en CORBA "a que CORBA o'rece unas tecnolog)as que pueden hacer 'actibles soluciones que de otra 'orma ser)an mu" complejas de desarrollar* -n la 'ase de dise.o debern generarse las inter'aces 23/ de los di'erentes m!dulos del sistema algo que 'acilita mucho la transmisi!n de los resultados del dise.o a los desarrolladores* ;a en la 'ase de desarrollo cada equipo de desarrollo de un m!dulo recibir la inter'a& 23/ para que la implemente en el lenguaje que considere ms adecuado recibiendo tambi,n las inter'aces 23/ de los ser+icios que +a"a a utili&ar su m!dulo* 3e nue+o el uso de estos ser+icios se puede hacer en el lenguaje que seleccionen los desarrolladores siendo para ellos transparente en qu, tipo de hard(are " en qu, lenguaje se desarroll! la implementaci!n de dichos ser+icios* Bueda claro que la modularidad que proporciona CORBA 'acilita mucho los desarrollos paralelos " modulares algo que en la 'ase de pruebas tambi,n se agradecer mucho "a que ser ms sencillo detectar los 'allos " dar respuesta a ellos* Bui&s cabe aqu) resaltar la escalabilidad de esta 'orma de desarrollo* -l insertar un nue+o ser+icio dentro del sistema es un proceso poco traumtico* Cabr)a que de'inir su 23/ " ponerla disponible para aquellos ser+icios que "a e#isten que la quisieran utili&ar* /os pro"ectos heredados tambi,n se pueden integrar en los nue+os sistemas de'iniendo los inter'aces 23/ que o'recen " a'ectando de 'orma m)nima a la nue+a arquitectura CORBA que se desarrolla* >odo el so't(are que "a e#iste por lo tanto es per'ectamente utili&able " su posible sustituci!n se puede reali&ar de 'orma progresi+a " bajo demanda*

D' -$ INT'R.$/ ID- $ -$ I,*-','NT$CIN -l proceso a seguir para implementar una inter'a& 23/ " poner disponible est 'uncionalidad en CORBA es el siguiente? <e dise.a el ser+icio " se crea la inter'a& 23/ <e elige la plata'orma " el lenguaje de implementaci!n " se busca la herramienta CORBA para esa plata'orma " ese lenguaje* /a herramienta CORBA debe tener un compilador 23/ que a partir de la inter'a& 23/ generar los cabos que permiten enganchar la implementaci!n de la inter'a& con la arquitectura CORBA* 2mplementamos la inter'a& 23/ en el lenguaje elegido* Creamos un ser+idor CORBA que se encargue de registrar la nue+a 'uncionalidad en CORBA utili&ando la implementaci!n reali&ada por nosotros " los cabos generados a partir de la inter'a& 23/* /os nue+os ser+icios "a estn disponibles en CORBA a la espera de la llegada de clientes que los quieran utili&ar*

-sta es la metodolog)a a aplicar siempre independientemente del entorno en el que nos mo+amos* >anto si es /inu# como Microso't Dindo(s o <olaris de <un los desarrolladores deben de seguir este proceso* *RO.UNDI/$NDO 'N COR#$ 4asamos a pro'undi&ar un poco ms en CORBA " su arquitectura* /o que sigue es qui&s la secci!n ms te!rica de este documento pero su conocimiento es indispensable* COR#$ 0 Common Object Request #ro1er $rquitecture Como "a dijimos en la de'inici!n CORBA es una herramienta que nos +a a 'acilitar el desarrollo de aplicaciones distribuidas en entornos heterog,neos* ; como all) dijimos son estos entornos precisamente los ms complejos a los que se tiene que en'rentar cualquier desarrollador* Eamos a anali&ar como CORBA +a proporcionando mecanismos " herramientas que nos permiten sal+ar las grandes barreras que hasta ahora e#ist)an en este tipo de entornos* Fo podemos ol+idar que en todos los entornos de 'uncionamiento "a e#isten aplicaciones que resuel+en gran +ariedad de problemas aplicaciones que tienen un gran +alor para el proceso de producci!n de nuestra empresa* ; OMG tu+o esto mu" en cuenta al estar 'ormado por empresas comerciales* 3e esta 'orma " gracias a 23/ las aplicaciones heredadas son mu" 'ciles de integrar dentro de CORBA* >an s!lo ha" que desarrollar para ellas un peque.o recubrimiento 23/ que e#porte la 'uncionalidad que o'rece este sistema* ; claro necesitamos que la aplicaci!n est, desarrollada en un lenguaje aceptado en CORBA pero como +eremos la ma"or)a de lenguajes importantes se pueden utili&ar en CORBA* Gracias a los cabos que se generan a partir de las inter'aces 23/ podemos enchu'ar estos sistemas heredados a nuestra arquitectura CORBA*

9n primer esquema modular de CORBA se puede obser+ar en la siguiente 'igura?

Arquitectura CORBA 'l OR# de COR#$ -n el siguiente gr'ico perteneciente al estndar de CORBA podemos obser+ar los di'erentes elementos de CORBA entre ellos el ORB*

Arquitectura CORBA -l ORB es posiblemente la parte ms importante de CORBA* -s lo que se conoce como el bus de los objetos* -l ORB se encarga de poner en contacto a los clientes " a los objetos de 'orma transparente con respecto a la distribuci!n* <us responsabilidades principales son? Mecanismos para que el cliente encuentre la 2mplementaci!n de la 2nter'a& 4reparaci!n de la 2mplementaci!n de la 2nter'a& para que pueda recibir in+ocaciones remotas Comunicaci!n de los datos que hacen posible la petici!n (argumentos de la 'unci!n " parmetros de retorno) Cuando el cliente quiere hacer una petici!n a la 2mplementaci!n de la 2nter'a& puede utili&ar dos caminos di'erentes? utili&ar un cabo OMG 23/ tal o utili&ar la inter'a& de in+ocaci!n dinmica (322)* /os detalles sobre estos m!dulos se desarrollarn a continuaci!n*

In ocaciones remotas desde el cliente 4ara que el cliente pueda reali&ar una in+ocaci!n sobre un objeto debe tener una Re'erencia del Objeto (2OR) " conocer el tipo de objeto " la operaci!n que desea in+ocar* -l cliente puede iniciar la petici!n a tra+,s de un cabo 23/ o bien constru"endo la in+ocaci!n de 'orma dinmica utili&ando el 322* -l ORB se encarga de encontrar el c!digo de la implementaci!n apropiada transmitir los parmetros " trans'erir el control a la 2mplementaci!n de la 2nter'a& a tra+,s del esqueleto 23/ o a tra+,s del esqueleto dinmico (322)*

Invocacin del cliente /as in+ocaciones pueden producir e#cepciones de di+ersa )ndole* 4or ejemplo la re'erencia 2OR al objeto puede "a no ser +lida o la inter'a& 23/ del objeto ha podido cambiar* -l ORB se encargar de in'ormarnos de todas estas posibles e#cepciones " nuestro c!digo deber de estar preparado para gestionar estas e#cepciones* -a interfa2 de in ocacin din"mica -l 322 (3"namic 2n+ocation 2nter'ace) es una inter'a& que nos permite la construcci!n dinmica de in+ocaciones para un determinado objeto* -sto nos permite en +e& de utili&ar una llamada a una 'unci!n determinada de un objeto concreto que el cliente puede especi'icar el objeto la in+ocaci!n " los parmetros a pasar a la in+ocaci!n a tra+,s de una llamada o conjunto de llamadas* 3e cara al ser+idor la in+ocaci!n es id,ntica a una que llega a tra+,s de la inter'a& esttica pero dentro del cliente se logra una 'le#ibilidad 'undamental en arquitecturas complejas " dinmicas*

9na in+ocaci!n dinmica se compone de una re'erencia al objeto una operaci!n " una lista de parmetros* >odos estos datos se obtiene del Repositorio de 2nter'aces (2R) un nue+o elemento de la arquitectura que pasamos a detallar* -l Repositorio de 2nter'aces (2R) -l Repositorio de 2nter'aces (2R) es un ser+icio que o'rece objetos persistentes que representan la in'ormaci!n 23/ de los inter'aces disponibles en CORBA de una 'orma accesible en tiempo de ejecuci!n (run8time)* -sta in'ormaci!n puede ser utili&ada por el ORB para reali&ar peticiones* ; adems el programador de aplicaciones puede utili&ar esta in'ormaci!n para acceder a objetos cu"a inter'a& no se conoc)a en tiempo de compilaci!n o para determinar que operaciones son +lidas en un objeto* -a Implementacin de los Objetos /as implementaciones de los objetos reciben las in+ocaciones como llamadas hacia arriba (up8call) desde el ORB hacia la 2mplementaci!n de la 2nter'a&*

Invocacin sobre objeto. -sta llamada puede +enir de un cliente que ha utili&ado los cabos 23/ o bien la 322* /os esqueletos de la inter'a& 23/ son espec)'icos de cada inter'a& " del adaptador de objetos que e#ista en la implementaci!n de CORBA* Cuando la in+ocaci!n ha sido completada el control " los +alores de retorno son de+ueltos al cliente* /a 2mplementaci!n de la 2nter'a& puede utili&ar los ser+icios que proporciona el adaptador de objetos e incluso los que proporciona el ORB mientras procesa la petici!n que ha recibido del cliente* /a 2mplementaci!n de la 2nter'a& puede elegir un Adaptador de Objetos entre un conjunto de ellos una decisi!n que estar basada en la clase de ser+icios que pueda requerir la 2mplementaci!n de la 2nter'a&* 2nicialmente OMG propuso como adaptador de objetos el BOA pero debido a sus limitaciones los 'abricantes introduc)an muchas

e#tensiones propietarias* 4ara solucionarlo en CORBA 6*6 se introdujo 4OA el adaptador de objetos estndar dentro de CORBA 6*6* 4OA es un m!dulo 'undamental " se intentar cubrir en pro'undidad en 'uturas entregas del curso* 'l Repositorio de Implementaciones 3IR4 -l Repositorio de 2mplementaciones contiene in'ormaci!n que permite al ORB locali&ar " acti+ar la implementaci!n de los objetos* Formalmente la instalaci!n de implementaciones " el control de las pol)ticas para la acti+aci!n " ejecuci!n de las implementaciones de los objetos se reali&a a tra+,s de operaciones en el 2R* 4or ejemplo los permisos por usuario para acceder e in+ocar los objetos son especi'icados aqu)* /a introducci!n de 4OA en CORBA 6*6 ha supuesto que la in'ormaci!n que se almacena en el 2R sea menor "a que por ejemplo las pol)ticas de acti+aci!n " ejecuci!n se locali&an ahora dentro de 4OA en el propio c!digo del ser+idor* 'l $daptador de Objetos -l Adaptador de Objetos (OA) es el m!dulo que permite a las implementaciones de los objetos acceder a ser+icios o'recidos por el ORB como la generaci!n de re'erencias para los objetos* -l adaptador de objetos e#porta una inter'a& p:blica para su uso por la implementaci!n del objeto " una inter'a& pri+ada para su uso por el esqueleto del objeto que depende de la implementaci!n del adaptador de objetos* /as 'unciones que debe reali&ar el adaptador de objetos son? 0* 6* G* 7* $* H* Generaci!n e interpretaci!n de las re'erencias a objetos 2n+ocaci!n de m,todos <eguridad en las interacciones Acti+aci!n " desacti+aci!n de objetos e implementaciones >raducci!n de re'erencias a objetos a sus correspondientes implementaciones Registro de las implementaciones

<i bien la in+ocaci!n de los m,todos se reali&a a tra+,s del esqueleto de la inter'a& impl)citamente tambi,n se utili&a al adaptador de objetos en 'unciones tales como la acti+aci!n de la implementaci!n o la autenticaci!n de la in+ocaci!n* -l Adaptador de Objetos de'ine la ma"or)a de los ser+icios que la implementaci!n de los objetos pueden obtener del ORB* <eg:n la implementaci!n el ORB podr o'recer unos ser+icios u otros* <eg:n la clase de adaptador que se implemente se debern o'recer los ser+icios asociados a dicha clase* 3ebido a que las implementaciones de los objetos dependen del Adaptador de Objetos se deben de'inir los menos adaptadores de objetos di'erentes posibles teniendo en cuenta que el Adaptador de Objetos 4ortable (4OA) que est incluido dentro del estndar de CORBA est dise.ados para cubrir la 'uncionalidad necesaria en un amplio rango de implementaciones de objetos*

O#5'CT ,$N$6','NT $R&UIT'CTUR' 3O,$4 -l OMG describi! antes del lan&amiento de la primera +ersi!n de CORBA un modelo de gesti!n de objetos denominado OMA en 011%* /a estructura de la arquitectura OMA se de'ine en el gr'ico siguiente " es la base de la actual arquitectura CORBA*
INT'R.$C'( D' $*-IC$CION'( INT'R.$C'( D' DO,INIO .$CI-ID$D'( CO,UN'(

OBA-C> R-B9-<> BROI-R (ORB)

('R7ICIO( $ O#5'TO(

OMA (OBJECT MANAGEMENT ARCHITECTURE) Object Request #ro1er 3OR#4 -l componente central de la especi'icaci!n CORBA es el ORB* -l ORB permite a objetos comunicarse con otros a tra+,s de sistemas heterog,neos* -l cliente no necesita saber como el ORB establece la comunicaci!n o como los objetos son acti+ados o guardados* /a comunicaci!n es totalmente transparente para el cliente* -l ORB o'rece una amplia gama de inter'aces de ser+icios distribuidos* -#isten bastantes caracter)sticas del ORB de CORBA que hacen este producto mejor que otras aplicaciones e#istentes entre otras o'rece +arios m,todos estticos " dinmicos para solicitar ser+icios a la red puede trabajar con cualquier lenguaje de programaci!n que se escoja " la comunicaci!n con estos objetos es 'actible gracias a un lenguaje inter'ace neutral denominado 23/* Cada uno de los objetos in+ocados es bien conocido gracias a la 2R (inter'ace repositor") un archi+o donde el objeto es almacenado " sus parmetros son re'erenciados* /a in'ormaci!n guardada en el 2R es creada automticamente mediante un precompilador 23/* Adems el ORB de CORBA trata tambi,n con conceptos de seguridad " 'acilidades de transmisi!n de datos haciendo 'iable " segura su utili&aci!n* -n resumen ORB es la columna +ertebral de CORBA todas las comunicaciones entre objetos son mantenidas por el ORB que conoce donde se encuentra situado cada uno de ellos*

(er icios a objetos CORBA o'rece una colecci!n de ser+icios para gestionar objetos aumentar sus posibilidades " complementar sus caracter)sticas " comportamiento* /os ser+icios de CORBA son componentes incluidos en la arquitectura que pueden ser heredados por otras clases de componentes* Ob+iamente cada tipo de ser+icio tiene su propia inter'ace de 23/ que le permite integrarse dentro del sistema CORBA* -stos ser+icios proporcionan un gran abanico de posibilidades para mejorar los objetos " sus posibilidades* CORBA ha estandari&ado 00 ser+icios " se encuentra desarrollando otros nue+os* /os e#istentes hasta ahora son los siguientes? Life cycle service: 9n objeto requiere operaciones tales como crear copiar mo+er " borrar datos de si mismo* -ste ser+icio inclu"e todo este bucle de operaciones* Namin service: Mediante esta aplicaci!n los objetos pueden locali&arse unos a otros por el nombre* !ersis"en" service: Almacena componentes en determinadas 'ormas dependiendo del tipo de ser+idor con el que trabajemos ( 'icheros normales R3BM< O3MM< **) Even" service: 4roporciona un canal e+entual a los objetos que puede ser usado por sus componentes para registrarse o intercambiar datos de ser+icios requeridos* C#nc$rrency c#n"r#l service: =unciona como manager de la red en cuanto a transacciones e intercambios entre objetos* Transac"i#n service: 4ermite a los componentes e'ectuar las transacciones entre ellos* Rela"i#ns%i& service: 4ermite el establecimiento de relaciones entre objetos que no tienen nada que +er unos con otros sin necesidad de modi'icar ninguno de ellos o sus inter'aces* '$ery service: 4odemos de'inir un petici!n de b:squeda de objetos dependiendo de las necesidades que necesitemos* -ste ser+icio gestiona estas peticiones* E("ernali)a"i#n service: -ste ser+icio permite la lectura " la escritura de datos en un componente* Licensin service: 9sando este ser+icio los componentes pueden ser usados de 'orma compensada* !r#&er"ies service: 4ermite asignar o asociar dinmicamente propiedades a un componente por ejemplo una 'echa o un titulo* .acilidades comunes -stas 'acilidades son componentes especi'icados en las inter'aces del 23/ que proporcionan ser+icios para ser usados directamente por las aplicaciones* /a di'erencia entre 'acilidades " ser+icios se encuentra en que estos :ltimos de'inen la base para operaciones generales lo que por una parte es importante para las aplicaciones pero por otro lado no pueden ser usados sin trabajar bajo una implementaci!n de CORBA*

-#isten dos clases de 'acilidades comunes? .acilidades H#ri)#n"ales: <e clasi'ican en? inter'a& de usuario ser+icios de in'ormaci!n para la gesti!n <er+icios para la gesti!n del sistema Aplicaciones del sistema ( por ejemplo e8mail)* .acilidades *er"icales: 4roporcionan inter'aces para soportar mercados tales como 'inan&as salud etc* Interfaces de aplicacin -ste tipo de inter'aces son componentes espec)'icos creados por el usuario siguiendo el 'ormato 23/ (si se pretenden usar bajo la arquitectura CORBA)* 4ueden encontrarse situadas en di'erentes mquinas pues su situaci!n ')sica no es rele+ante para su 'uncionamiento pueden comunicarse entre ellas " encontrarse unas a otras dentro del sistema CORBA todo de manera transparente* Interfaces de dominio -stas inter'aces desarrollan 'unciones similares a los ser+icios a objetos " a las 'acilidades comunes pero estn orientadas hacia aplicaciones con dominios espec)'icos* INT'R.$/ ID'l interfa2 de objetos interrelacionados 23/ es un producto de la OMG creado para escribir los inter'aces de objetos* CORBA se caracteri&a principalmente por su agilidad compatibilidad " carcter auto descripti+o* >odas estas caracter)sticas son posibles gracias al inter'a& 23/* Cada componente debe estar descrito con su correspondiente inter'a& 23/* Aunque pare&ca ser inicialmente un trabajo e#tra ahorraremos mucha energ)a " se con+ertir en una gran colecci!n de +entajas las cuales sern necesarias para crear " apo"ar una arquitectura cliente5ser+idor como CORBA* 4or medio de su inter'a& un componente se describe como lo hacen todos los otros componentes en el sistema* As) el entendimiento entre todos los componentes integrados es posible* -n pocas palabras los inter'aces 23/ permiten una interoperati+idad total* Fo importa con que lenguaje de programaci!n est escrito un componente "a que 23/ no est condicionado por esto* -l enlace entre el inter'a& " su componente est hecho con enlaces de lenguaje estandari&ados* /a OMG ha estandari&ado enlaces para C CJJ <malltalk " Aa+a pero

cualquier lenguaje puede ser usado creando enlaces adecuados* Ob+iamente puede haber problemas cuando el lenguaje a enla&ar no o'rece todas las posibilidades que son proporcionadas por 23/* 23/ es un lenguaje declarati+o puro (no se necesita implementaci!n en el inter'a&)* /as !rdenes de 23/ son una subcolecci!n de CJJ con !rdenes adicionales para soportar objetos distribuidos* -l 23/ para CORBA es completo " conciso* -a estructura del ID- para COR#$ 9n esquema de un inter'a& 23/ es mostrado debajo? mdulo 8identificador9 : 8declaraciones de tipo9; 8declaraciones de contantes9; 8declaraciones de e<cepciones9; intefa2 8identificador9 =08in>eridad9? : 8declaraciones de tipo9; 8declaraciones de contantes9; 8declaraciones de e<cepciones9; 8declaraciones de atributos9; =8op@tipo9?8identificador938par"metros94 =e<cepciones?; AAAA B AAAA B 2remos +iendo los principales elementos mencionados? ,dulos0 -l principal prop!sito de un m!dulo es introducir un ni+el e#tra de jerarqu)a agrupando una colecci!n de inter'aces* -s identi'icado por la palabra cla+e module " tiene un complemento en el nombre que consiste en uno o ms identi'icadores que son cadenas con+encionales* Interfaces0 3e'ine una colecci!n de m,todos (operaciones de la OMG)* -s el equi+alente de la de'inici!n de clases en CJJ pero sin implementaci!n* 9n inter'a& puede ser inherido desde clases KpadreL las cuales deben ser tambi,n indicadas en su estructura* 9n inter'a& puede declarar e#cepciones las cuales son aumentadas cuando una operaci!n no se reali&a con ,#ito* >ambi,n pueden ser declarados atributos en un inter'a& por los cuales operaciones de obtenci!n o poner sern automticamente creadas por la implementaci!n* 9n atributo

puede ser declarado como Ks!lo lecturaL* -n este caso s!lo una operaci!n de obtener puede ser creada* Operaciones0 /as operaciones pueden ser in+ocadas por clientes potenciales* -n su estructura una operaci!n inclu"e su nombre o identi'icador el tipo de su +alor de retorno (opMtipo) " sus parmetros los cuales deber)an indicar sus tipos* Adems cada parmetro tiene un modo* Ca" tres di'erentes modos? KinL (el +alor es pasado desde el cliente al ser+idor) KoutL (el contrario el +alor es pasado desde el ser+idor al cliente) " KinoutL (el +alor puede ser pasado en ambas direcciones)* Opcionalmente una operaci!n puede indicar las e#cepciones que aumentan si no se reali&ara la operaci!n correctamente " una e#presi!n conteniendo un conjunto de +alores de atributo que describen un conte#to de cliente* Tipos de datos0 <on los +alores de parmetros atributos e#cepciones " +alores de retorno aceptados por CORBA* CORBA especi'ica dos tipos de +alores? bsico " compuestos* /os tipos bsicos son? corto largo largo sin signo corto sin signo 'lotante doble carcter booleano " octeto (short long unsigned long unsigned short 'loat double char boolean " octet)* 4or otro lado los tipos compuestos son? enum string struct (dejan crear tipos de datos deseables usando tipos de de'inicion 8t"pede's8) arra" union sequence (dejan psar un +ector de objectos de tama.o +ariable especi'icando un m#imo n:mero de elementos para ser colocados) an" (puede representar cualquier tipo de dato 23/)* Cada tipo de dato 23/ es mapeado al correspondiente tipo de dato por medio de los enlaces de lenguaje por los lenguajes de programaci!n apropiados* -stos tipos 23/ de CORBA llamados objetos CORBA son usados a tra+,s de m:ltiples lenguajes sistemas operati+os " ORBs* 'NTR$D$( C '(&U'-'TO( -l mecanismo CORBA 'unciona utili&ando pro#ies* /a utili&aci!n de pro#ies es actualmente el patr!n de dise.o gu)a para resol+er los problemas complejos asociados con el paso de datos entre objetos distribuidos* 9n pro#" se asienta en el lado del cliente " en el del ser+idor " hace que a ambos les pare&ca que se estn comunicando con procesos locales* -l ORB gestiona entonces todos los detalles complicados que tienen que ocurrir entre los pro#ies (por ejemplo organi&aci!n comunicaci!n de red etc*)* -sta arquitectura como se muestra en la siguiente 'igura o'rece a los desarrolladores de un cliente o ser+idor CORBA alguna protecci!n relacionada con el transporte de detalles a bajo ni+el " les permite centrarse en implementar correctamente sus soluciones de negocio espec)'icas* -n t,rminos de CORBA el pro#" que representa al ser+idor con el que se comunica un cliente se llama una entrada " el pro#" que representa al cliente en el lado del ser+idor se llama esqueleto*

Un es+$ema sim&lifica,# ,e la ar+$i"ec"$ra CORBA-

Potrebbero piacerti anche