Globedia.com

×
×

Error de autenticación

Ha habido un problema a la hora de conectarse a la red social. Por favor intentalo de nuevo

Si el problema persiste, nos lo puedes decir AQUÍ

×
cross

Suscribete para recibir las noticias más relevantes

×
Recibir alertas

¿Quieres recibir una notificación por email cada vez que Sal Aguilar escriba una noticia?

Azure, aplicaciones multi-capa utilizando Service Bus

11/04/2012 07:50 0 Comentarios Lectura: ( palabras)

Nuestra empresa, KOM-1, quiere aprovechar al máximo el potencial de los sistemas en ‘la nube’. Se nos ha solicitado desarrollar una solución que nos permita manejar grandes cantidades de información para poder tomar decisiones y mantener nuestra ventaja competitiva. Tenemos que ser capaces de procesar información de múltiples proveedores.

Como parte de la primera etapa para el desarrollo de la solución, creamos 2 nuevos servicios en Azure, uno que soporta una aplicación WEB que permite importar datos de proveedores y otro que publica servicios de datos WCF.

A continuación, utlizamos estos servicios de datos WCF como entidades de datos remotas para nuestra aplicación principal, una tercera aplicación WEB ya existente. Aquí, en la capa de dominio del negocio, creamos objetos y métodos que nos permiten importar los datos de los proveedores en nuestra aplicación principal.

En esta primera etapa tenemos entonces una aquitectura como sigue:

imageEste esquema funcionaba correctamente cuando la cantidad de información a ser importada desde los servicios WCF era relativamente pequeña (decenas de miles de registros). Por cierto, la eficiencia de transferencia de datos, con WCF Data Services, es excelente, dentro de Azure y entre diferentes servicios instalados en diferentes subscripciones y accesando diferentes bases de datos en diferentes servidores Azure. Como comparación, los métodos para importar datos desde archivos Excel, Azure BLOB y luego base de datos SQL Azure, toman como el doble de tiempo, aproximadamente, del que toma leer datos desde WCF Data services y luego escribir en otra base de datos.

Ocurrió que un buen día que a la Gerencia se le ocurrió probar con un nuevo proveedor (ejem y el área de desarrollo respondió con iniciativa, por supuesto…) que, para manejarlo, tenemos que procesar mayor cantidad de información. Ahora son centenas de miles de registros (250K registros cada vez!). En este caso, la arquitectura de etapa 1 no nos sirvió de mucho: podíamos importar la información desde los archivos enviados por el proveedor e incluso podíamos publicar estos datos utilizando los servicios WCF pero al momento de leer estos datos desde nuestra aplicación principal (o Back-office), teníamos errores de ‘timeout’ y el WEB role soportando esta aplicación principal sufría en cuanto a su funcionamiento, afectando otros procesos del mismo, incluyendo aquellos relacionados a interfaz de usuario.

Consultando la información de desarrollo en MSFT, encontramos el artículo ‘Multi-tier application using Service BUS Queues‘. Aplicamos dicho artículo a nuestra situación, adaptandolo a una aplicación .Net Web forms como es la nuestra (si, todavía no hemos migrado a MVC, aunque ya estamos trabajando en ello!). Nuestra arquitectura queda:

imageEste esquema funciona muy bien, la diferencia es que agregamos una nueva aplicación (servicio) de tipo Azure Worker Role más los objetos y métodos necesarios para utilizar el Service Bus y sus colas (queues) desde la apliación Back-office. Ahora el nuevo servicio se encarga de leer desde los servicios WCF (que por cierto no eran el problema ya que funcionan perfectamente, aún para los casos de 250K registros o más).

Ya sea que el el proceso se automatice para ser ejecutado cada cierto tiempo, desde dentro del servicio Worker Role o que se active por el usuario desde la apliacación principal (o Back-office) este funciona muy bien, eficiente y sin problemas. Los siguientes pasos son los de optimizar el servicio Worker Role. En Azure es posible agregar recursos de cómputo de manera dinámica (y retirar cuando ya no se necesiten).

Algo del código en back-office app (omitiendo información confidencial, por supuesto):

public class PurchaseRateQueueConnector
    {

        public static QueueClient PurchaseRateQueueClient;
        //Name of the queue.
        public const string QueueName = "MyQueue";
        //BUS account information.
        public const string Namespace = "MyNamespace";
        public const string IssuerName = "owner";//Issuer.
        public const string IssuerKey = "MyKey";

        public static NamespaceManager CreateNameSpaceManager()
        {
            var uri = ServiceBusEnvironment.CreateServiceUri(
                "sb", Namespace, string.Empty);
            var tP = TokenProvider.CreateSharedSecretTokenProvider(
                IssuerName, IssuerKey);
            return new NamespaceManager(uri, tP);
        }
        public static void Initialize()
        {
            ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
            var namespaceManager = CreateNameSpaceManager();
            //Create queue if it does not exists already.
            if (!namespaceManager.QueueExists(QueueName))
            {
                namespaceManager.CreateQueue(QueueName);
            }
            //Get a client to the queue.
            var messagingFactory = MessagingFactory.Create(
                namespaceManager.Address, 
                namespaceManager.Settings.TokenProvider);
            QueueClient = messagingFactory.CreateQueueClient(Queuename);
        }

        public void SubmitToQueue(DeckMessage _objId)
        {
            var namespaceManager = QueueConnector.CreateNameSpaceManager();
            var queue = namespaceManager.GetQueue(QueueConnector.QueueName);

            var message = new BrokeredMessage(_objId);

            QueueConnector.QueueClient.Send(message);
        }
    }

Y código en el worker role:

public class WorkerRole : RoleEntryPoint

{

public override void Run()

{

Trace.WriteLine(‘$projectname$ entry point called’, ‘Information’);

int i = 1;

int j = 0;

int trunkId = 0;

while (true)

{

//Receive the message from queue.

BrokeredMessage receivedMessage = QueueConnector.QueueClient.Receive();

if (receivedMessage != null)

{

Log.LogExecution(‘Starting import process.’,

this, MessageType.Information);

try

{

DeckMessage purch =

receivedMessage.GetBody();

trunkId = purch.TrunkId;

ManageUpdate importManageClassInstance = new ManageUpdate();

j = importManageClassInstance.CheckDeckUpdate(Id);

//Remove message from queue.

}

catch (MessagingException ex)

{

receivedMessage.Abandon();

Log.LogExecution(ex, this);

}

Log.LogExecution

(‘Ending import process from MyDataservices. Records updated= ’ +

Convert.ToString(j) +

‘. Id: ’ + Convert.ToString(Id),

this, MessageType.Information);

}

else

{

Thread.Sleep(10000);

}

}

}

public override bool OnStart()

{

// Set the maximum number of concurrent connections

ServicePointManager.DefaultConnectionLimit = 12;

//Initializing queue connector.

QueueConnector.Initialize();

return base.OnStart();

}

}


Sobre esta noticia

Autor:
Sal Aguilar (221 noticias)
Fuente:
tecnologico.com.ni
Visitas:
2681
Tipo:
Reportaje
Licencia:
Creative Commons License
¿Problemas con esta noticia?
×
Denunciar esta noticia por

Denunciar

Comentarios

Aún no hay comentarios en esta noticia.