Pregunta de arquitectura n capas

Es la primera vez que leo que un lenguaje OO es de mucho mas bajo nivel
que SQL.
:-((

Mira... ya varios hemos advertido lo mismo.
Para ellos "alto nivel" es lo que maneja datos directamente aunque este sea
interno y acoplado a un SGBD especifico. Ellos me recuerdan a los
programadores viejos cuando aprendieron a usar DBase III plus.
Alfredo una vez pretendió comparar a C# con T-SQL como si fuesen lenguajes
comparables o similares.
Para mi ellos no pasan de un cursito de administracion de base de datos
porque de programacion y objetos no saben absolutamente nada.
Son pura teoria y palabreria vacía de la gente que se cree sabelotodo y no
sabe ni siquiera explicarse.

Aunque te animaste a discutir con gente psicorrigida y ortodoxa, debo
decirte que es excelente y muy grafico tu ejemplo de los bancos.
Pero, no insistas, eso es demasiado para ellos. ;-)
Ellos solo conocen sistemas monoliticos y de una sola plataforma, igual que
hace 20 años.

Saludos

Carlos


"Daniel A. Calvin" escribió en el
mensaje news:

Hola Carlos

Creo que una parte de lo que dices totalmente cierta:
Lo que se llaman 'reglas de negocio' (constraints

de integridad), son (deben ser!) comunes a todas las aplicaciones
en el sistema, y por tanto se tienen que centralizar y compartir.

Pero otra es totalmente arbitraria:

A nivel de sistema esta centralización se realiza en un SGBD.

En cuanto a:

son (deben ser!) comunes a todas las aplicaciones

Nadie dice que eso debe ser implementado en un SGBD.

Te voy a dar un claro ejemplo de esto, un cajero automático.
Creo que muchos de nosotros no hemos creado el software para una red de
cajeros, pero seguramente muchos de nosotros si hemos retirado dibero,
efectuado pagos, consultado saldos utilizando un cajero automatico.

Bueno, todas esas operaciones están centralizadas en el operador de la
Red,
en Argentina tenemos la Red BAPRO, Link, Banelco y algunas otras.

Las operaciones de cajero se realizan centralizadas en la Red,
descentralizadas por cada banco afilido a la red.
En este ejemplo no existe un SGBD, las reglas de negocio se implementan en
el administrador de las redes, los cajeros automaticos manejan
transacciones
recurriendo a servicios centralizados en los administradores de las redes
respectivas y es alli donde se ejecutan las reglas de negocio.

Es una arquitectura orientada a servicios en donde cada Banco participante
de cada Red consume servicios para atender a clientes de otros Bancos y
brinda servicios para Clientes de otros Bancos que utilizan los cajeros
automaticos propios.

En los bancos encontrarás muchos ejemplos de este tipo.
Otro ejemplo concreto, la contabilidad de un banco.
Toda la operatoria bancaria las oficinas administrativas y las operaciones
efectuadas en sucursales deben ser contabilizadas.
Imagina la cantidad e sistemas que interactuan con la contabilidad:

Compras
Creditos personales
Creditos de todo tipo
Operaciones de cambio en moneda extranjera
Cuentas de cheques
Depositos
Etc, etc

Bueno esos sistemas tambien se ejecutan en forma descentralizada.
Como se contabiliza todas esas operatorias?

El core contable del Banco expone servicios contables
Esos servicios contables son consunidos por las aplicaciones especificas
de
cada operatoria.
Algunas de esas aplicaciones por supuesto tienen y utilizan algun SGBD,
pero
sin embargo la contabilidad no se registra en esos repositorios.

Las reglas de negocio puedes implementarlas donde gustes, SGBD si te gusta
y
te sirve, una capa de negocios orientada a objeto, o cualquier otra cosa.

Volviendo a:

A nivel de sistema esta centralización se realiza en un SGBD.

Creo que das opiniones como verdades biblicas :-))
Tal vez sea bueno que comprendas que hay otra forma de hacer las cosas y
esa
forma existe como fruto de la necesidad de resolver problemas que no se
pueden resolver con tecnologia o arquitecturas tradicionales.

Saudos

Daniel A. Calvin
MCP


"Carlos M. Calvelo" wrote:

On 6 mrt, 14:41, "Eugenio Serrano" wrote:
> Cuando dices:
>
> >Pues para mi está claro que sí hay mejores y peores formas
> >de hacer las cosas. Que a veces pueda ser difícil determinar
> >que es mejor o peor, lo que parecen implicar estas discusiones,
> >es otra questión.
>
> Todo depende del contextoCosas que pueden ser malas bajo
> determinadas
> caracteristicas pueden ser buenas en otra.

Se está hablando de sistemas de información. Ese es el contexto.

>
> Se pueden hacer aplicaciones datacentricas, con toda la logica en el
> motor
> de base de datos y que funcionen tan bien como otra 100% orientada a
> objetos
> donde la logica se maneje en una capa creada para eso.

El contenido de mi mensage tenía tres aspectos:
1) estabas confundiendo aplicación con sistema de información,
2) me pareció que también estás confuso con lo que es un
sistema monolítico y
3) sí hay formas mejores y peores de hacer las cosas.

Tengo que reacionar entonces al punto 3 ? Grrrrr!

>
> Con que criterio dices que uno es malo y el otro es bueno ?
> Bien dices que "para ti" esta claro que es mejor o que es peor.

El 'para mi' era solo una actitud 'de diplomacia' que...

>
> Pero lo que para ti puede ser malo, para otro puede ser muy bueno. Es
> que
> son maneras diferentes de encarar un problema.

vista esta reacción, solo da lugar a embrollos.


Si se está hablando de sistemas de información (ese es el contexto)
las aplicaciones que forman parte del sistema son por definición
datacéntricas. Lo que se llaman 'reglas de negocio' (constraints
de integridad), son (deben ser!) comunes a todas las aplicaciones
en el sistema, y por tanto se tienen que centralizar y compartir.
A nivel de sistema esta centralización se realiza en un SGBD.
Una eventual 'capa donde se maneja la lógica' lo que hace
desde el punto de vista del sistema es encapsular el SGBD original.
Conceptualmente entonces, a nivel de sistema, esta capa *es* el SGBD.

Orientación a objectos tiene su aplicación en el diseño y
programación de los distintos componentes del sistema.
Una aplicación puede haber sido diseñada con OO *y la otra no*,
(repito *y la otra NO*), un middelware puede haber sido diseñado
con OO o no, un SGBD puede haber sido diseñado con OO o no, etc.
Al final forman todos parte de un sistema de información y a ese
nivel las técnicas de diseño y programación de los subsistemas
son totalmente irrelevantes.

Y claro que distintas formas de hacer las cosas pueden funcionar.
Pero eso es decir poco mas que nada.
Puede haber por ejemplo diferencias enormes en escalabilidad.
Está preparado el sistema para aceptar nuevas aplicaciones? p.e.
Una capa de negocio obliga a nuevas aplicaciones a usar las
mismas técnicas y métodos de acceso a los datos que la primera
aplicación ha creido convenientes. Pero lo que para la primera se
haya considerado conveniente no tiene por que serlo para las demás.
Por eso he hecho hincapié arriba en lo de que una aplicación puede
se OO y la otra no. Es mas, estas aplicaciones no tienen ni por que
ser conscientes unas de la existencia de las otras. Estas técnicas
que deberían ser solo relevantes a nivel de subsistema se imponen
entonces en un nivel mas alto a otras partes del sistema lo que
reduce la escalabilidad.

Todo esto aparte de que un capa de negocios al encapsular el SGBD,
también hace desaparecer una interfaz flexible: la estructura
lógica de los datos y un lenguaje de acceso como SQL. En su lugar
nos ofrece otra interfaz de mucho mas bajo nivel: lenguaje
de programación precedimental/OO sin mecanismos para gestionar
datos, donde los programadores de aplicaciones puede 'disfrutar
de los placeres' de navegar por estructuras de datos por medio
de punteros, haciendo la aplicación mas complicada y cara de lo
necesario. Era ese el método de gestionar datos en las aplicaciones
cuando se trabajaba con bases de datos basadas en los modelos de
red y jerárquico, que para repetirlo otra vez más, ha sido
desechado hace décadas.

Saludos,
Carlos

>> Lo que propongo es separar las responsabilidades del sistema asignando
>> la gestión de los datos al Sistema de Gestión de Bases de Datos, que
>> es mucho más que un "motor de bases de datos", y la presentación y
>> comunicación con los usuarios a las aplicaciones de formularios.

>Ya... Para dar un ejemplo concreto, proyecto en el que estoy
>involucrado
>ahora, debimos haber desarrollado el core del sistema de predicciones
>(que usa RN y estadisítica bayesiana) en PL-SQL, T-SQL y DB2.

DB2 puede ejecutar rutinas escritas en muchos lenguajes más como C,
C++, Java e incluso Visual Basic. SQL Server lo mismo.

Que "pueda" ejecutar rutinas no me dice absolutamente nada.
Lo que verdaderamente cuenta es cuál es el nivel de soporte
de los lenguajes y librerías y APIs con respecto al estándar y
a otros SGBD.

Mira, es que yo no escribo de gusto. Vuelve a leer. Porque cuando
dije "PL-SQL, T-SQL y DB2" es porque nuestro producto DEBE trabajar
con gestores Oracle, SQLServer y DB2.
CON CUALQUIERA DE LOS TRES.

-H.

Hola Daniel,

On 7 mrt, 03:29, Daniel A. Calvin
wrote:

Hola Carlos

Creo que una parte de lo que dices totalmente cierta:
Lo que se llaman 'reglas de negocio' (constraints

> de integridad), son (deben ser!) comunes a todas las aplicaciones
> en el sistema, y por tanto se tienen que centralizar y compartir.

Menos mal que alguien se cree eso!
Espero que no solo lo 'creas'.

Pero otra es totalmente arbitraria:

> A nivel de sistema esta centralización se realiza en un SGBD.

Es arbitrario el utilizar o no un SGBD específico y se
puede decidir a hacerlo en la famosa 'capa de negocios',
o... <pon aquí todas las posibilidades que te puedas imaginar>

No es arbitrario que es funcionalidad y resposabilidad que le
corresponde a un SGBD.

En cuanto a:

>>son (deben ser!) comunes a todas las aplicaciones

Nadie dice que eso debe ser implementado en un SGBD.

"Nadie dice que eso debe ser implementado en un SGBD."
"Nadie dice que eso no debe ser implementado en un SGBD."

Y ahora? Que hago yo ahora con estas dos afirmaciones?
Cortinas de humo.

Te voy a dar un claro ejemplo de esto, un cajero automático.

Un ejemplo claro es uno sencillo. Aunque el que pones deja sentir
mucho mejor aun lo importante que es determinar que partes
del sistema tienen que responsabilidades.
O hasta en el caso de sistemas que colaboran, que sistemas tienen
que resposabilidades en esa colaboración.

Creo que muchos de nosotros no hemos creado el software para una red de
cajeros, pero seguramente muchos de nosotros si hemos retirado dibero,
efectuado pagos, consultado saldos utilizando un cajero automatico.

Eso está claro. Yo nunca he realizado software para eso y
uso cajeros a menudo para retirar dinero o al pagar mis compras.
:)

Bueno, todas esas operaciones están centralizadas en el operador de la Red,
en Argentina tenemos la Red BAPRO, Link, Banelco y algunas otras.

Las operaciones de cajero se realizan centralizadas en la Red,
descentralizadas por cada banco afilido a la red.
En este ejemplo no existe un SGBD, las reglas de negocio se implementan en
el administrador de las redes, los cajeros automaticos manejan transacciones
recurriendo a servicios centralizados en los administradores de las redes
respectivas y es alli donde se ejecutan las reglas de negocio.

Es una arquitectura orientada a servicios en donde cada Banco participante
de cada Red consume servicios para atender a clientes de otros Bancos y
brinda servicios para Clientes de otros Bancos que utilizan los cajeros
automaticos propios.

En los bancos encontrarás muchos ejemplos de este tipo.
Otro ejemplo concreto, la contabilidad de un banco.
Toda la operatoria bancaria las oficinas administrativas y las operaciones
efectuadas en sucursales deben ser contabilizadas.
Imagina la cantidad e sistemas que interactuan con la contabilidad:

Compras
Creditos personales
Creditos de todo tipo
Operaciones de cambio en moneda extranjera
Cuentas de cheques
Depositos
Etc, etc

Bueno esos sistemas tambien se ejecutan en forma descentralizada.
Como se contabiliza todas esas operatorias?

El core contable del Banco expone servicios contables
Esos servicios contables son consunidos por las aplicaciones especificas de
cada operatoria.
Algunas de esas aplicaciones por supuesto tienen y utilizan algun SGBD, pero
sin embargo la contabilidad no se registra en esos repositorios.

Las reglas de negocio puedes implementarlas donde gustes, SGBD si te gusta y
te sirve, una capa de negocios orientada a objeto, o cualquier otra cosa.

Tu mismo sabes que no vamos a ponernos a analizar este ejemplo
o concluir que porque en un caso se haya hecho las cosas asi o
asado eso prueba algo. Tanto si ha sido hecho como yo propongo
o como sea. Aunque cuanto mas compleja la situación mas claro
está la importacia que tiene el identificar quien tiene que
responsabilidades.

Yo mismo he puesto este ejemplo en otra de estas discusiones:
http://groups.google.com/group/micr...4e04b2de50

Pero por poner un ejemplo sencillo.

Supongamos que mi mujer y yo tenemos una cuenta con 1000 euros de
saldo en un banco en Bélgica. Yo me voy de vacaciones a España
y ella a Noruega. Por cosas de la casualidad ella trata de retirar
en un cajero en Oslo 800 euros y yo en Sevilla 500 y los dos le
damos al <OK> en el cajero al mismo tiempo. Si nuestro banco no
quiere que el saldo se ponga nunca en negativo nadie se escapa a
esta lógica:

*En algún punto estas dos operaciones tienen que entrar
serializadas en un proceso que tendrá que aprobar la primera
y rechazar la segunda.*

Este hecho:
"La cuenta 12345 tiene un saldo de (sum(entradas) - sum(salidas)) eur
"
(o "La cuenta 12345 tiene de saldo 1000 eur")
y esta regla:
"Para todas las cuentas el saldo tiene que ser siempre
ser mayor o igual a 0"...

mejor vayan juntitos vayan a donde vayan porque sino la regla
del banco de que el saldo nunca podrá ser negativo no se
podrá garantizar. Cuanquier aplicacion que quiere hacer algo
con esos datos (saldo, entradas, salidas), mejor se confronte
con esta regla aunque la aplicación no haya pensado en ella.
Dicho de otra forma: *cualquiera que de cualquier forma trate de
cambiar alguno de estos datos tendrá que vérselas con esa regla y
cualquiera que de cualquier forma trate de cambiar la regla
tendrá que vérselas con los datos actuales.*
Podría decirse que esos datos y esa regla *son uno*.
A esta lógica no se escapa nadie o tiene que aceptar el
riesgo de que la regla no se cumpla.

En el ejemplo de los cajeros se encontrarán muchísimas reglas
de este tipo, acuerdos entre bancos, otras actividades de
los bancos, etc, etc. Una regla como la que describo yo puede
existir p.e. solo en la región de tu banco. En otras regiones solo
podrás retirar dinero hasta cierto límite. La infrastructura de
comunicaciones no permíte quizás retirar dinero en cualquier
región y los bancos acuerdan correr ciertos riesgos, etc,etc,etc.
Todo lo complicado que tu quieras. La esencia sigue siendo la misma.
Para ciertos datos, las reglas que tienen que garantizar su
integridad mejor estén con esos datos.

Volviendo a:

>>> A nivel de sistema esta centralización se realiza en un SGBD.

Creo que das opiniones como verdades biblicas :-))

El 'hecho' y la 'regla' que puse como ejemplo, repito, mejor
vayan juntitos a todos los lados. Es evindente que el
mejor sitio a donde pueden ir es a una base de datos.

Tal vez sea bueno que comprendas que hay otra forma de hacer las cosas y esa
forma existe como fruto de la necesidad de resolver problemas que no se
pueden resolver con tecnologia o arquitecturas tradicionales.

Tal vez sea bueno que muchos traten de comprender lo que en
realidad es un SGBD. Porque la gran mayoria no hace mas que
hablar de 'persisencia' y de capas de negocio. Para toda esta
gente SQL es un equivalente al read() y write() del file system
y una base de datos un archivo.

El tema ya esta muy desgastado!

Saludo,
Carlos

No sabia que una sola persona podia decir tantas tonterias juntas. Dice una
frase y en la siguiente se contradice.
Parece mas un juego de palabras.

Suerte Sancho, se nota que la necesitas.

X-DDDDD

"Carlos M. Calvelo" wrote in message
news:
Hola Daniel,

On 7 mrt, 03:29, Daniel A. Calvin
wrote:

Hola Carlos

Creo que una parte de lo que dices totalmente cierta:
Lo que se llaman 'reglas de negocio' (constraints

> de integridad), son (deben ser!) comunes a todas las aplicaciones
> en el sistema, y por tanto se tienen que centralizar y compartir.

Menos mal que alguien se cree eso!
Espero que no solo lo 'creas'.

Pero otra es totalmente arbitraria:

> A nivel de sistema esta centralización se realiza en un SGBD.

Es arbitrario el utilizar o no un SGBD específico y se
puede decidir a hacerlo en la famosa 'capa de negocios',
o... <pon aquí todas las posibilidades que te puedas imaginar>

No es arbitrario que es funcionalidad y resposabilidad que le
corresponde a un SGBD.

En cuanto a:

>>son (deben ser!) comunes a todas las aplicaciones

Nadie dice que eso debe ser implementado en un SGBD.

"Nadie dice que eso debe ser implementado en un SGBD."
"Nadie dice que eso no debe ser implementado en un SGBD."

Y ahora? Que hago yo ahora con estas dos afirmaciones?
Cortinas de humo.

Te voy a dar un claro ejemplo de esto, un cajero automático.

Un ejemplo claro es uno sencillo. Aunque el que pones deja sentir
mucho mejor aun lo importante que es determinar que partes
del sistema tienen que responsabilidades.
O hasta en el caso de sistemas que colaboran, que sistemas tienen
que resposabilidades en esa colaboración.

Creo que muchos de nosotros no hemos creado el software para una red de
cajeros, pero seguramente muchos de nosotros si hemos retirado dibero,
efectuado pagos, consultado saldos utilizando un cajero automatico.

Eso está claro. Yo nunca he realizado software para eso y
uso cajeros a menudo para retirar dinero o al pagar mis compras.
:)

Bueno, todas esas operaciones están centralizadas en el operador de la
Red,
en Argentina tenemos la Red BAPRO, Link, Banelco y algunas otras.

Las operaciones de cajero se realizan centralizadas en la Red,
descentralizadas por cada banco afilido a la red.
En este ejemplo no existe un SGBD, las reglas de negocio se implementan en
el administrador de las redes, los cajeros automaticos manejan
transacciones
recurriendo a servicios centralizados en los administradores de las redes
respectivas y es alli donde se ejecutan las reglas de negocio.

Es una arquitectura orientada a servicios en donde cada Banco participante
de cada Red consume servicios para atender a clientes de otros Bancos y
brinda servicios para Clientes de otros Bancos que utilizan los cajeros
automaticos propios.

En los bancos encontrarás muchos ejemplos de este tipo.
Otro ejemplo concreto, la contabilidad de un banco.
Toda la operatoria bancaria las oficinas administrativas y las operaciones
efectuadas en sucursales deben ser contabilizadas.
Imagina la cantidad e sistemas que interactuan con la contabilidad:

Compras
Creditos personales
Creditos de todo tipo
Operaciones de cambio en moneda extranjera
Cuentas de cheques
Depositos
Etc, etc

Bueno esos sistemas tambien se ejecutan en forma descentralizada.
Como se contabiliza todas esas operatorias?

El core contable del Banco expone servicios contables
Esos servicios contables son consunidos por las aplicaciones especificas
de
cada operatoria.
Algunas de esas aplicaciones por supuesto tienen y utilizan algun SGBD,
pero
sin embargo la contabilidad no se registra en esos repositorios.

Las reglas de negocio puedes implementarlas donde gustes, SGBD si te gusta
y
te sirve, una capa de negocios orientada a objeto, o cualquier otra cosa.

Tu mismo sabes que no vamos a ponernos a analizar este ejemplo
o concluir que porque en un caso se haya hecho las cosas asi o
asado eso prueba algo. Tanto si ha sido hecho como yo propongo
o como sea. Aunque cuanto mas compleja la situación mas claro
está la importacia que tiene el identificar quien tiene que
responsabilidades.

Yo mismo he puesto este ejemplo en otra de estas discusiones:
http://groups.google.com/group/micr...4e04b2de50

Pero por poner un ejemplo sencillo.

Supongamos que mi mujer y yo tenemos una cuenta con 1000 euros de
saldo en un banco en Bélgica. Yo me voy de vacaciones a España
y ella a Noruega. Por cosas de la casualidad ella trata de retirar
en un cajero en Oslo 800 euros y yo en Sevilla 500 y los dos le
damos al <OK> en el cajero al mismo tiempo. Si nuestro banco no
quiere que el saldo se ponga nunca en negativo nadie se escapa a
esta lógica:

*En algún punto estas dos operaciones tienen que entrar
serializadas en un proceso que tendrá que aprobar la primera
y rechazar la segunda.*

Este hecho:
"La cuenta 12345 tiene un saldo de (sum(entradas) - sum(salidas)) eur
"
(o "La cuenta 12345 tiene de saldo 1000 eur")
y esta regla:
"Para todas las cuentas el saldo tiene que ser siempre
ser mayor o igual a 0"...

mejor vayan juntitos vayan a donde vayan porque sino la regla
del banco de que el saldo nunca podrá ser negativo no se
podrá garantizar. Cuanquier aplicacion que quiere hacer algo
con esos datos (saldo, entradas, salidas), mejor se confronte
con esta regla aunque la aplicación no haya pensado en ella.
Dicho de otra forma: *cualquiera que de cualquier forma trate de
cambiar alguno de estos datos tendrá que vérselas con esa regla y
cualquiera que de cualquier forma trate de cambiar la regla
tendrá que vérselas con los datos actuales.*
Podría decirse que esos datos y esa regla *son uno*.
A esta lógica no se escapa nadie o tiene que aceptar el
riesgo de que la regla no se cumpla.

En el ejemplo de los cajeros se encontrarán muchísimas reglas
de este tipo, acuerdos entre bancos, otras actividades de
los bancos, etc, etc. Una regla como la que describo yo puede
existir p.e. solo en la región de tu banco. En otras regiones solo
podrás retirar dinero hasta cierto límite. La infrastructura de
comunicaciones no permíte quizás retirar dinero en cualquier
región y los bancos acuerdan correr ciertos riesgos, etc,etc,etc.
Todo lo complicado que tu quieras. La esencia sigue siendo la misma.
Para ciertos datos, las reglas que tienen que garantizar su
integridad mejor estén con esos datos.

Volviendo a:

>>> A nivel de sistema esta centralización se realiza en un SGBD.

Creo que das opiniones como verdades biblicas :-))

El 'hecho' y la 'regla' que puse como ejemplo, repito, mejor
vayan juntitos a todos los lados. Es evindente que el
mejor sitio a donde pueden ir es a una base de datos.

Tal vez sea bueno que comprendas que hay otra forma de hacer las cosas y
esa
forma existe como fruto de la necesidad de resolver problemas que no se
pueden resolver con tecnologia o arquitecturas tradicionales.

Tal vez sea bueno que muchos traten de comprender lo que en
realidad es un SGBD. Porque la gran mayoria no hace mas que
hablar de 'persisencia' y de capas de negocio. Para toda esta
gente SQL es un equivalente al read() y write() del file system
y una base de datos un archivo.

El tema ya esta muy desgastado!

Saludo,
Carlos