Asunto: Re: Sobre genericidad
Fecha: Tue Jan 11 12:49:58 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Hola, Antonio:
Antonio Ruiz Cortés wrote:
> Diego, gracias por la aclaración.
> De todas formas creo que sigue existiendo una cuestión de fondo importante.
>
Efectivamente.
>
> ¿Quién es el responsable de soportar la conectividad: el framework o el
> componente?
Este es un tema complejo y crucial. Además, depende de la visión que cada cual
tenga de los componentes. Ya en el libro de Orfali y Harkey "Distributed
Objects Survival Guide" (que puede considerarse a todas luces visionario) se
hacía una "definición" de lo que para ellos era un "supercomponente". Se le
atribuían muchas cualidades que, en principio, podría pensarse que las debe
soportar el ambiente en donde los componentes se ejecutan.
Viéndolo de este modo, y teniendo en cuenta que la disputa entre _varios_
modelos de componentes es inevitable e incluso en cierto sentido beneficiosa
(véase, por ejemplo, comentarios de este tipo en Szyperski,
"Component Software"), se podría pensar que el "empaquetado binario" del
componente podría tener la capacidad de albergar varios "interfaces" con
distintos modelos de componentes, independientes de la funcionalidad que
implementa. Esto es, podría tener "versiones" con interfaz para EJB, COM y CCM.
Estos serían unos componentes de "grano grueso".
El otro extremo, como comentas, son los frameworks de componentes que
permiten componentes de "grano fino". Así, un componente, como dices, tiene
sólo que preocuparse de su funcionalidad. El entorno de tiempo de ejecución se
encarga de hacer de pasarela, capturando las similitudes y características
comunes de los modelos de componentes que soporta. Esta última opción también
tiene sus desventajas, ya que, mientras la primera sólo necesita del soporte
"nativo" para componentes (por ejemplo, COM en el caso de Windows), esta última
necesita de un software instalado en cada plataforma y que haga de "almohada"
de servicios comunes.
El tema no está claro, aunque yo me decanto por una solución híbrida, en la
que se utiliza, por ejemplo CORBA como estándar (al fin y al cabo, CORBA se
puede ver como un "soporte universal" en todos los sentidos, ya que ofrece un
modelo de objetos clásico y es un estándar no propietario ¿qué más se puede
pedir como base ;-)?) que se puede extender para soportar componentes y la
implementación de puentes hacia los demás modelos. Así, se deberían diseñar
soportes estándar CORBA para almacenamiento y empaquetado binario de
componentes, búsqueda de componentes, etc. al estilo de CCM. Los componentes
COM, por ejemplo, no se soportarían directamente, pero sí a través de
pasarelas.
En fin, tampoco es que esté muy claro. Mi objetivo es comenzar a diseñar
una arquitectura de este tipo siendo todo lo fiel que pueda al estándar CCM. A
ver como va...
Saludos.
diego.
> Creo que los componentes solo deben preocuparse de ofrecer
> funcionalidad y no preocuparse por cuestiones de conectividad. Sería mejor
> hablar de frameworks flexibles, universales o con gran capacidad de
> conexión. Sería una extensión del principio de hollywood, no solo el
> framework se encarga de invocar a la funcionalidad de los componentes, sino
> que se encarga de adaptarse a su modelo de comunicación.
>
> ¿como lo veis?
>
> Saludos, Antonio
>
> ----- Original Message -----
> From: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
> To: Antonio Ruiz Cortés <aruiz@lsi.us.es>
> Cc: Gabriel Sanchez Gutierrez <gsg@sema.es>; Antonio Vallecillo
> <av@lcc.uma.es>; <corba@fcu.um.es>
> Sent: Thursday, December 23, 1999 1:13 PM
> Subject: Re: cuestionario sobre componentes (1/2)
>
> > Antonio Ruiz Cortés wrote:
> >
> > > >La pregunta aquí es si realmente pueden ser útiles componentes
> totalmente
> > > >genéricos o no tienen demasiado sentido.
> > >
> > > está última pregunta planteada por Vallecillo, es una discusión que se
> > > plantea en otros ambitos, por ejemplo:
> > > Se dispone de un único lenguaje de especificación( o de
> programación) o
> > > un lenguaje para cada aspecto o conjunto de aspectos a especificar.
> Osea,
> > > buscamos un único lenguaje de especificación o un conjunto de lenguajes
> > > especializados para cada aspecto.
> > >
> > > Creo que los componentes genéricos no tienen sentido, que al final lo
> más
> > > interesante es disponer de un colección de componentes fácilmente
> adaptables
> > > a las necesidades de una o varias familias de aplicaciones para un
> dominio
> > > concreto. En definitiva, algo similar a los objetos de negocio que
> plantea
> > > Orfali y compañia en su "survival guide".
> > >
> >
> > Antonio, creo que lo que Vallecillo plantea es componentes genéricos en el
> > sentido de que sean "conectables" en cualquier contenedor genérico de
> > componentes. La colección de componentes a la que te refieres es lo ideal,
> > salvo que algunos de ellos pueden ser Beans, otros componentes CORBA,
> otros
> > OLE/COM, etc. y todos se "podrían" o se "deberían" integrar sin problemas,
> ya
> > sea a través de puentes transparentes o a través de un modelo que soporte
> o de
> > cabida a todos los existentes.
> >
> > Saludos.
> > diego.
> >
> > >
> > > De nuevo, otro comentario barato.
> > >
> > > >(En fin, este es también un comentario barato, aunque mañanero :-)
> > >
> > > -----Original Message-----
> > > De: Antonio Vallecillo <av@lcc.uma.es>
> > > Para: Gabriel Sanchez Gutierrez <gsg@sema.es>
> > > CC: corba@fcu.um.es <corba@fcu.um.es>
> > > Fecha: jueves 23 de diciembre de 1999 12:20
> > > Asunto: Re: Re: cuestionario sobre componentes (1/2)
> > >
> > > >At 16.31 22/12/99 +0100, you wrote:
> > > >>...
> > > >>Es cierto q sí hay experiencias más exitosas sobre el tema (hay
> alguien
> > > >>de Valladolid? del grupo GIRO?) pero es más fácil, realista, y
> práctico
> > > >>pensar en un "mercadillo" de componentes, dentro de una organización,
> > > >>para
> > > >>una posible implantación. Creo q se aproxima más a la vida real en la
> > > >>industria.
> > > >>
> > > >>Es un simple comentario barato de después de comer :-)
> > > >>...
> > > >
> > > >Hola Gabriel,
> > > >yo en parte estoy de acuerdo contigo. Ahora mismo un mercado global de
> > > >componentes software es más un sueño que una realidad. Lo que ocurre es
> que
> > > >a mí sí que me parece bien tener a ese "sueño" como objetivo, porque
> nos
> > > >está permitiendo avanzar en muchos temas. Quizá lo del mercadillo local
> e
> > > >interno a cada empresa es lo que se puede encontrar ahora, aunque yo
> veo
> > > >cada vez más gente que trata de generar componentes para su mercadillo
> con
> > > >cierta visión de futuro, por si los pudiera "vender" a otra gente en un
> > > >futuro próximo (incluso, a otros grupos de desarrollo internos de la
> > > >empresa, ahora que todo el mundo es una "unidad de negocio").
> > > >Lo que sí parece interesante es el tema de los marcos de trabajo para
> > > >componentes (frameworks). Eso sí se pueden de alguna forma "vender", y
> lo
> > > >que me parecería interesante es el desarrollo de componentes para
> > > >frameworks existentes. En general, hacer un componente para que pueda
> ser
> > > >utilizado por cualquiera es casi una utopía, pero en el momento que el
> > > >contexto está claro, puede que haya cabida para un mercado interesante
> de
> > > >componentes que puedan "encajar" en ese contexto. Un ejemplo de alguna
> > > >forma relacionado con todo eso (a nivel primario) son los plugins de
> los
> > > >navegadores, o los drivers de periféricos. A un nivel más general (es
> > > >decir, dentro de los marcos de trabajo) puede que sea posible
> desarrollar
> > > >nuevos componentes competitivos que permitan extender la funcionalidad
> de
> > > >una framework, incorporar nuevos drivers, o reemplazar alguno de los
> > > >componentes de la framework para hacerla evolucionar.
> > > >Por otro lado, aquí entra un tema interesante que es el del estudio de
> > > >propiedades de los componentes. En general, es muy difícil probar y
> > > >garantizar que un componente funciona, independientemente del contexto
> en
> > > >donde se ejecute. Además, el tipo de propiedades que pueden
> establecerse
> > > >son demasiado vagas y generales. Sin embargo, dentro de un contexto las
> > > >cosas cambian. Cierto tipo de propiedades sí que pueden establecerse
> dentro
> > > >de un framework, e incluso definirse a nivel formal. Esto permite ser
> más
> > > >específico en cuanto a los requisitos que hay que exigir a sus
> componentes,
> > > >y por tanto ser más concreto en cuanto a las propiedades que definimos
> al
> > > >crear los componentes.
> > > >La pregunta aquí es si realmente pueden ser útiles componentes
> totalmente
> > > >genéricos o no tienen demasiado sentido.
> > > >
> > > >(En fin, este es también un comentario barato, aunque mañanero :-)
> > > >
> > > >Un saludo,
> > > >Antonio Vallecillo.
> > > >
> > > >
> > > >
> >
> > --
> > Diego Sevilla Ruiz -- http://www.ditec.um.es/~dsevilla/
> > Departamento de Ingeniería y Tecnología de Computadores
> > Facultad de Informática. Universidad de Murcia
> > Campus de Espinardo - 30080 Murcia (SPAIN)
> > Tel.: +34-968-367570
> > E-mail: dsevilla@ditec.um.es
> >
> > $_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
> > "\@". "\007f". "DDq". "DD5". "\204".
> > "\@". "DT4CE". "D54E". "DD". "\244".
> > "\021". "dBDTC". "\010DD". "\200\$FD\024".
> > "GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
> > (/./g) {$q= ord$q; for(a, b){$z[$c]
> > =$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;
> >
> >
> >
> >
--
Diego Sevilla Ruiz -- http://www.ditec.um.es/~dsevilla/
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es
$_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
"\@". "\007f". "DDq". "DD5". "\204".
"\@". "DT4CE". "D54E". "DD". "\244".
"\021". "dBDTC". "\010DD". "\200\$FD\024".
"GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
(/./g) {$q= ord$q; for(a, b){$z[$c]
=$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;