Aplicaciones empresariales.

Buenos días a todos:

Estoy migrando (yo, no mis aplicaciones) de Visual Basic 6 a Visual
Basic .NET.

Desde hace ya un tiempo, vengo construyendo aplicaciones empresariales
en VB6 (ya sabéis, COM+, DLLs ActiveX, tres o más capas, SQL Server 2000
y esas cosas)... pues bien, ahora quiero hacer "lo mismo" pero usando el
.NET Framework. Para más info, utilizo .NET 1.1 (VS.NET 2003) sobre
Windows 2000 Server SP4.

He estado viendo que en la capa de acceso a datos, cada clase se
convierte en un componente COM+ heredando de
System.EnterpriseServices.ServicedComponent. Hasta ahí bien. Cambias ADO
por ADO.NET y "más o menos" completas dicha capa.

Mi problema surge al crear la capa de lógica de negocio. En VB6 no había
diferencia entre unas clases y otras (es decir, "hacíamos igual" la
lógica de negocio que el acceso a datos) en cuanto a su creación y uso.
Sin embargo, ahora en VB.NET la lógica de negocio es accedida como
servicio web por los clientes (que se hayan en máquinas diferentes
diseminadas por la Intranet, o incluso por Internet). Entonces, creo las
clases derivando de System.Web.Services.WebService y los métodos tienen
el atributo WebMethod.

(Dejo ahora claro que no me interesa utilizar Remoting ni el formateador
SOAP; ni siquiera haciendo uso de las facilidades de COM+ 1.5, sobre
todo porque Windows 2000 no dispone de dichas facilidades.)

Bien, mi pregunta es la siguiente, estando más relacionada con el diseño
(arquitectura) que con el código:

Dado que System.Web.Services.WebService (y derivados) no heredan de
System.EnterpriseServices.ServicedComponent, ¿pueden beneficiarse de
COM+? Antes, en VB6 (sin servicios web, claro), tanto los componentes de
lógica de negocios como los de acceso a datos podían formar parte de un
paquete COM+ "simplemente" configurando el atributo MTSTransactionMode y
creando (eso sí, a mano) el paquete MTS/COM+ y registrando dicho
componente. Ahora parece que la pertenencia a dicho paquete se consigue
mediante herencia.

Según dice la MSDN
(ms-help://MS.MSDNQTR.2003FEB.3082/cpre...rviceswebs
erviceclasstopic.htm) es teóricamente posible crear un servicio web sin
heredar de WebService si éste no accede a los objetos intrínsecos de
ASP.NET (accesibles a través de la propiedad Context). Entonces
podríamos derivar de ServicedComponent, aunque temo que esto es más un
caso muy particular que una solución general (sobre todo si quieremos
realizar algún tipo de autentificación mediante ASP.NET y código
propio).

Mi pregunta es: ¿es conveniente "dividir" la lógica de negocio en una
primera subcapa de servicios web (a modo de wrapper) que únicamente
"publiquen" los métodos de los componentes de la segunda subcapa que
realicen las tareas propias de lógica de negocio (y que éstos si serían
componentes COM+)? De ser así, no veo ventaja entre la primera subcapa
(en cuanto al rendimiento) y ponerlo todo junto (es decir, que no parece
tener demasiado sentido "separar" la lógica en dos subcapas).

Mi duda se debe, sobre todo, a si Internet Information Server (tanto 5
como 6) automáticamente se encargan de "convertir" las clases de los
servicios web en clases de componentes COM+ y, por tanto, se beneficien
del agrupamiento de objetos (object pooling), activación "just-in-time"
y todas esas cosas que tan bien les sientan a nuestros desarrollos. ;-)
(En cuanto a la "conversión", no me refiero a que publiquen dichos
componentes en el catálogo COM+, que ya sé que no lo hace, sino a que
permitan los mismos beneficios que si mis componentes ya estuviesen en
el catálogo.)

Bien, de nuevo, surge mi cuestión: ¿cuál es la mejor forma de diseñar
mis componentes de lógica de negocio, pensando principalmente en el
rendimiento? Evidentemente, toda cuestión de diseño ofrece siempre más
de una alternativa. Eso no lo pongo en duda.

Bueno, ¿sugerencias?

Muchas gracias, por anticipado, sobre todo dado el "tostón" de mensaje.


Luis María.

Comentarios en línea

Saludos desde Madrid:

Jesús López
MVP Visual Basic
Mentor Asociado Solid Quality Learning
www.solidqualitylearning.com
Profesor alhambra-eidos
www.alhambra-eidos.com



"LMCR" escribió en el mensaje
news:%
> Buenos días a todos:
>
> Estoy migrando (yo, no mis aplicaciones) de Visual Basic 6 a Visual
> Basic .NET.
>
> Desde hace ya un tiempo, vengo construyendo aplicaciones

> en VB6 (ya sabéis, COM+, DLLs ActiveX, tres o más capas, SQL Server

> y esas cosas)... pues bien, ahora quiero hacer "lo mismo" pero

> .NET Framework. Para más info, utilizo .NET 1.1 (VS.NET 2003) sobre
> Windows 2000 Server SP4.
>
> He estado viendo que en la capa de acceso a datos, cada clase se
> convierte en un componente COM+ heredando de
> System.EnterpriseServices.ServicedComponent. Hasta ahí bien. Cambias

> por ADO.NET y "más o menos" completas dicha capa.
>
> Mi problema surge al crear la capa de lógica de negocio. En VB6 no

> diferencia entre unas clases y otras (es decir, "hacíamos igual" la
> lógica de negocio que el acceso a datos) en cuanto a su creación y

> Sin embargo, ahora en VB.NET la lógica de negocio es accedida como
> servicio web por los clientes (que se hayan en máquinas diferentes
> diseminadas por la Intranet, o incluso por Internet). Entonces, creo

> clases derivando de System.Web.Services.WebService y los métodos

> el atributo WebMethod.
>

La capa de negocio no tiene por qué ser necesariamente un servicio

podría ser perfectamente una aplicación COM+ de servidor u objetos

ejecutándose en un servicio windows por ejemplo.


> (Dejo ahora claro que no me interesa utilizar Remoting ni el

> SOAP; ni siquiera haciendo uso de las facilidades de COM+ 1.5, sobre
> todo porque Windows 2000 no dispone de dichas facilidades.)
>
> Bien, mi pregunta es la siguiente, estando más relacionada con el

> (arquitectura) que con el código:
>
> Dado que System.Web.Services.WebService (y derivados) no heredan de
> System.EnterpriseServices.ServicedComponent, ¿pueden beneficiarse de
> COM+? Antes, en VB6 (sin servicios web, claro), tanto los

> lógica de negocios como los de acceso a datos podían formar parte de

> paquete COM+ "simplemente" configurando el atributo

> creando (eso sí, a mano) el paquete MTS/COM+ y registrando dicho
> componente. Ahora parece que la pertenencia a dicho paquete se

> mediante herencia.
>
> Según dice la MSDN
>

> erviceclasstopic.htm) es teóricamente posible crear un servicio web

> heredar de WebService si éste no accede a los objetos intrínsecos de
> ASP.NET (accesibles a través de la propiedad Context). Entonces
> podríamos derivar de ServicedComponent, aunque temo que esto es más

> caso muy particular que una solución general (sobre todo si

> realizar algún tipo de autentificación mediante ASP.NET y código
> propio).
>

Yo opino que aunque es teóricamente posible no es práctico

> Mi pregunta es: ¿es conveniente "dividir" la lógica de negocio en

> primera subcapa de servicios web (a modo de wrapper) que únicamente
> "publiquen" los métodos de los componentes de la segunda subcapa que
> realicen las tareas propias de lógica de negocio (y que éstos si

> componentes COM+)? De ser así, no veo ventaja entre la primera

> (en cuanto al rendimiento) y ponerlo todo junto (es decir, que no

> tener demasiado sentido "separar" la lógica en dos subcapas).
>

Efectivamente, desde el punto de vista del rendimiento no tiene ningún
sentido poner un servicio web delante de la aplicación COM+. El

adquiere cuando los clientes van a acceder a la aplicación a través de
Intenet, ya que estos clientes no pueden acceder diréctamente a la
aplicación COM+ y sí al servicio web.

> Mi duda se debe, sobre todo, a si Internet Information Server (tanto

> como 6) automáticamente se encargan de "convertir" las clases de los
> servicios web en clases de componentes COM+ y, por tanto, se

> del agrupamiento de objetos (object pooling), activación

> y todas esas cosas que tan bien les sientan a nuestros desarrollos.

> (En cuanto a la "conversión", no me refiero a que publiquen dichos
> componentes en el catálogo COM+, que ya sé que no lo hace, sino a

> permitan los mismos beneficios que si mis componentes ya estuviesen

> el catálogo.)
>

Un servicio web puede beneficiarse de las transacciones de COM+, basta

decorar el método web con el atributo WebMethod y establecer la

TransactionOption. Por ejemplo:

<WebMethod( TransactionOption:=TransactionOption.RequiresNew)> Public

MiMetodo()

Sin embargo la única opción que tiene sentido es RequiresNew ya que el
contexto COM+ no se propaga a un servicio web.
Los servicios web son "por definición" Just In Time Activation, pero

pueden hacer uso de los demás servicios de COM+ porque no son

COM+ y no lo pueden ser.


> Bien, de nuevo, surge mi cuestión: ¿cuál es la mejor forma de

> mis componentes de lógica de negocio, pensando principalmente en el
> rendimiento? Evidentemente, toda cuestión de diseño ofrece siempre

> de una alternativa. Eso no lo pongo en duda.
>
> Bueno, ¿sugerencias?
>



Teniendo en cuenta que COM+ es más eficiente que los servicios web y

proporcionan una serie de servicios adicionales, yo te sugeriría que

pusieras toda la lógica de negocio en una aplicación COM+ de servidor

que necesitas usar los servicios de COM+. Los clientes que vayan a

la aplicación desde la intranet podrían hacerlo directamente a dicha
aplicación COM+ sin pasar por la sobrecarga adicional de un servicio

lo único que haría sería disminuir el rendimiento. Además crearía
un servicio web que no sería más que un envoltorio de la aplicación

para que los clientes pudieran acceder a la aplicación a través de

A la hora de realizar la aplicación cliente, supuestamente una

Windows, sería conveniente añadir una capa de abstración que ocultara

acceso a la capa de negocio (servicio web o COM+ directo). Esta capa

abstración (una librería de clases) permitiría a la aplicación cliente
configurarse indistintamente para usar el servicio web o la aplicación

Así no habría que escribir dos aplicaciones Windows diferentes.

> Muchas gracias, por anticipado, sobre todo dado el "tostón" de

>
>
> Luis María.
>
>

De nada