8/28/2003 José Alves Marques
Filas de Mensagens
Message Oriented Middleware - MOM
Departamento de Engenharia Informática
Emissor
Emissor
Emissor
Emissor
Receptor
Receptor
Receptor
Receptor
fila
fila
fila
fila
Rede
Canal com fila de mensagens
Modelo do RPC ou de ligação de
transporte
8/28/2003 José Alves Marques
Integração por Mensagens – Message Oriented
Middleware
•
A integração é feita através do encaminhamento de informação (mensagens) entre os
sistemas.
•
As aplicações recebem e enviam as mensagens para um servidor central (broker).
•
As mensagens uma vez recebidas pelo broker podem ser reformatadas, combinadas ou
modificas por forma a serem entendidas pelo sistema de destino.
•
Normalmente não é necessário modificar os sistemas envolvidos. Os Message Brokers
fornecem adaptadores para as aplicações mais comuns (SAP, Baan, PeopleSoft, etc.).
Departamento de Engenharia Informática
Positivo
Negativo
Mensagens Directas
(mecanismo de
transportes)
•
As API são muito simples. • Qualquer tipo de dados pode ser transmitido.• Total separação entre os dados e o código das aplicações que tratam as mensagens
•Tudo o que está acima + • Funcionamento assíncrono permite distribuir carga e ganhar eficiência
• Permite um funcionamento desconectado da rede.
• Permite 1 para muitos e muitos para muitos.
•
As aplicações tem de fazer manualmente a codificação e a descodificação dos dados•Tudo o que está acima +
• As formas mais úteis de comunicação requerem mecanismos de queuing • A maioria dos produtos de queuing não interoperam bem
• O assincronismo torna a programação mais difícil (programação por eventos).
Filas de Mensagens Message queuing
Comparação de canais com e sem fila de
mensagens
8/28/2003 José Alves Marques
Características Message Oriented Middleware (I)
• Store Forward
– A mensagem deve ser aceite pelo serviço de mensagens e e armazenada
até que o receptor ou receptores estejam disponíveis para a receberem
– O emissor deve ser imediatamente desbloqueado depois da mensagem ter
sido aceite para envio (funcionamento assíncrono)
– As Mensagens são armazenadas de forma persistente pelo middleware
• Broker de mensagens
– Para além de uma comunicação ponto-a-ponto, o sistema efectua a
distribuição de mensagens permitindo o envio de mensagens de uma
aplicação para um conjunto de outras que se executam em diversos
sistemas.
• Subscrição e Publicação
– Os receptores interessados subscrevem o tópico e recebem todas as
mensagens ou aplicam um filtro de selecção
Departamento de Engenharia Informática
Características MOM (II)
• Garantia de entrega
– O mecanismo deve garantir a entrega da mensagem ao receptor(es)
– A entrega deve ser exactamente uma vez (não pode ser duplicada)
– Se a aplicação que envia a mensagem tem esta garantia de
qualidade de serviço, não necessita de verificar a entrega
• Sequência das mensagens
– A sequência de envio das mensagens de um emissor deve ser
respeitada, garantido a ordenação dos acontecimentos que as
mensagens representam.
– Evita que as aplicações se preocupem com a ordem.
• Routing simbólico
– O endereçamento das mensagens baseia-se em nomes simbólicos
virtualizando a rede de comunicações
8/28/2003 José Alves Marques
Características MOM (III)
• Pedido-resposta
– Muitas interacções baseiam-se num pedido e numa resposta.
Comportamento que á a base da chamada remota de procedimentos
– O emissor poderia especificar o endereço de resposta mas este estaria
dependente da organização da rede. A infraestrutura pode encarregar-se de
fazer o emparelhamento, permitindo que a resposta provenha de uma outra
aplicação
• Eventos
– Assinalam acontecimento que podem ter origem dentro ou fora do sistema
– Permitem alterar o fluxo dos processos
• Transformação de mensagens
– Possibilidade de aceitar mensagens com formatos predefinidos e
transformá-las para o formato do receptor.
– Permite que as integrações não estejam dependentes de um formato de
aplicações herdadas
Departamento de Engenharia Informática
Características MOM (IV)
• Resolução de excepções
– A infraestrutura deve tentar tratar os erros habituais como os de
comunicação
– Deve assinalar os acontecimentos que envolvam quebra da semântica:
impossível de entregar, “exactamente –uma-vez” na entrega não
respeitado, etc.
• Transferência de ficheiros
– A maioria das mensagens devem ser relativamente pequenas, contudo a
infra-estrutura deve poder enviar ficheiros de dimensão grande entre
aplicações porque muitas integrações são feitas com ficheiros
• Segurança
– A segurança tem de ser considerada a dois níveis
• Dentro da organização – típico Enterprise Application Integration
• Com sistemas externos – típico Business to Business
8/28/2003 José Alves Marques
Exemplo de MOM
Java Messages
Departamento de Engenharia Informática
Java Messaging Service - JMS
• Elementos da infraestrutura
– Filas de mensagens - queues
– Envio e recepção de mensagens
– Mensagens ponto a ponto
– Subscrição e publicação de mensagens
– Formato das Mensagens
8/28/2003 José Alves Marques
Envio e Recepção de Mensagens
• As aplicações falam com o message broker através de uma connection.
• Dentro de uma connection um processo pode ter várias sessions para
cada uma das suas tarefas (threads)
• Depois estar ligado ao message broker associa-se ou cria uma queue
• Cria um message sender ou message receiver para aceder à queue
• Um processo pode enviar mensagem ou receber mensagens de uma
queue através das funções do objecto queue
• A recepção pode ser síncrona ou assíncrona
• As mensagens podem ser:
– Stream – sequência de tipos básicos de Java
– Texto – na qual se incluem documentos XML
– Objectos – objectos Java serializados
– Bytes
Departamento de Engenharia Informática
8/28/2003 José Alves Marques
Filas de mensagens e transacções
• O tratamento de erros e a garantia de entrega é assegurada pelas filas
de mensagens serem persistentes
-
durable
• Para assegurar o exactamente-uma–vez as JMS sessions podem
opcionalmente ser transaccionais (transacted) através de um parâmetro
na criação da sessão
• O transaccional existe quer do lado do envio quer da recepção.
– No envio a mensagem só é considerada como estando na fila até aplicação
fazer commit
– Na recepção, se a aplicação ou o commit falham a mensagem permanece
na fila
• Uma Session está sempre associada a uma transacção corrente, não há
begin; commit e rollback porque uma transacção automaticamente
começa outra
• Nota: As transacções são locais entre o processo e o message broker.
O JMS não implementa transacções distribuídas
Departamento de Engenharia Informática
Envio das Mensagens
• Ponto a Ponto (a designação pode confundir)
– Quer dizer que a aplicação define a queue para onde envia a
mensagem.
– A aplicação pode obter a referência para a queue através de um
serviço de nomes (JNDI)
– O sistema passa automaticamente a referência para a queue de
resposta
• Publicar e Subscrever
– Neste modo as mensagens não são enviadas para um destinatários
mas para um tópico
– As mensagens podem ser consideradas eventos
– O subscritor (queue receiver) pode ser durable
, caso em que as
mensagens são armazenadas enquanto está inactivo
8/28/2003 José Alves Marques
Envio das Mensagens (II)
Departamento de Engenharia Informática
Formato da Mensagem
• O JMS não define uma
norma para o formato
das mensagens pelo
que produtos do tipo
JMS podem ter
formatos diferentes
• Mas define um
formato de mensagem
abstracto que define a
informação que deve
existir numa
8/28/2003 José Alves Marques
API do JMS
• Modelo de objectos que considera:
– Queue connection factory – abstracção que encapsula os detalhes da
ligação a um JMS provider (semelhante ao driver JDBC)
– Queue Connection – canal de comunicação com o JMS provider – socjets,
RMI, etc.
– Queue session – uma para cada thread e representa uma conversação ou
um conjunto de transacções
• Modelo
• Encontrar uma ConnectionFactory através do JNDI
• Encontrar uma Destination através do JNDI
• Usar a Connection Factory para criar uma Connection
• Usar a Connection para criar uma ou mais Sessions
• Usar a Session e a Destination para criar o MessageProducer e
MessageConsumer
• Iniciar a Connection
Departamento de Engenharia Informática Application Queue ConnectionFactory ConnectionQueue SessionQueue MessageText Queue Sender ReceiverQueue
createQueueConnection createQueueSession createSender (queue) createReceiver (queue) Start() creatTextMessage () setText(messagetext) Send(message) Receive()
8/28/2003 José Alves Marques
Exemplo JMS(I)
public class Hello {
public static void main(String[] args) {
try {
/* Declaração das variáveis JMS */
QueueConnectionFactory queueConnectionFactory = null; QueueConnection queueConnection = null;
Queue queue = null;
QueueSession queueSession = null; QueueSender queueSender = null; QueueReceiver queueReceiver = null; TextMessage textMessage = null; Message message = null;
/* Declaração de variáveis para argumentos da linha de comando */ final String MQ_HOST_NAME;
final String MQ_HOST_PORT;
/* Validação dos argumentos recebidos na linha de comando */ if ( args.length < 2 ) {
Departamento de Engenharia Informática
Exemplo JMS(II)
System.out.println("Usage: java Hello <mq_host_name> <mq_host_port>"); System.exit(1);
}
MQ_HOST_NAME = args[0]; MQ_HOST_PORT = args[1];
System.out.println("Message queue host is " + MQ_HOST_NAME + ":" + MQ_HOST_PORT);
/* Instanciação de uma fábrica de ligações */
/* Instancia-se directamente a classe Sun MQ para poder usar os métodos para definir nome e porto do servidor de mensagens */
com.sun.messaging.QueueConnectionFactory sunQueueConnectionFactory = new com.sun.messaging.QueueConnectionFactory();
sunQueueConnectionFactory.setProperty("JMQBrokerHostName", MQ_HOST_NAME); sunQueueConnectionFactory.setProperty("JMQBrokerHostPort", MQ_HOST_PORT);
queueConnectionFactory = sunQueueConnectionFactory;
/* Criação de uma ligação ao servidor de mensagens */
queueConnection = queueConnectionFactory.createQueueConnection();
8/28/2003 José Alves Marques
Exemplo JMS(III)
queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
/* Instanciação de uma fila de mensagens com o nome especificado */ /* A fila é criada implicitamente no servidor, caso não exista */ queue = new com.sun.messaging.Queue("world");
/* Criação do produtor de mensagens */
queueSender = queueSession.createSender(queue); /* Criação e envio de uma mensagem */
textMessage = queueSession.createTextMessage(); textMessage.setText("Hello World");
System.out.println("Sending Message: " + textMessage.getText()); queueSender.send(textMessage);
/* Neste exemplo muito simples é o mesmo programa a enviar e a receber a mensagem */
/* Criação de um consumidor de mensagens a partir da fila */ queueReceiver = queueSession.createReceiver(queue);
Indica que a Session não é Transaccional
Departamento de Engenharia Informática
Exemplo JMS(IV)
/* Reiniciação da ligação */ queueConnection.start();
/* Recepção de mensagem e análise do conteúdo */ message = queueReceiver.receive();
if (message instanceof TextMessage) { textMessage = (TextMessage) message;
System.out.println("Read Message: " + textMessage.getText()); }
/* Fecho da sessão e da ligação */ queueSession.close();
queueConnection.close();
} catch (Exception e) {
/* À falta de melhor tratamento de erro, é conveniente imprimir a excepção */ System.out.println("Exception occurred : " + e.toString()); }
System.out.println("Finished"); }
8/28/2003 José Alves Marques
Exemplo: receptor Assíncrono (I)
public class AsynchReceiver {
public static void main(String[] args) {
int exitResult = 0;
String queueName = null;
/* Declaração das variáveis JMS */
QueueConnectionFactory queueConnectionFactory = null; QueueConnection queueConnection = null;
QueueSession queueSession = null; Queue queue = null;
QueueReceiver queueReceiver = null; TextListener textListener = null;
/* Declaração de variáveis para argumentos da linha de comando */ final String MQ_HOST_NAME;
final String MQ_HOST_PORT;
/* Validação dos argumentos recebidos na linha de comando */ if (args.length != 3) {
System.out.println("Usage: java AsynchReceiver <mq_host_name> <mq_host_port> <queue_name>");
System.exit(1);
Departamento de Engenharia Informática
Exemplo: receptor Assíncrono (II)
MQ_HOST_NAME = args[0]; MQ_HOST_PORT = args[1];
System.out.println("Message queue host is " + MQ_HOST_NAME + ":" + MQ_HOST_PORT);
queueName = new String(args[2]);
System.out.println("Queue name is " + queueName);
/* Criar uma fábrica de ligações, criar uma ligação,
criar uma sessão a partir da ligação (false indica que não é transaccional), criar uma fila de mensagens */
try { com.sun.messaging.QueueConnectionFactory sunQueueConnectionFactory = new com.sun.messaging.QueueConnectionFactory(); sunQueueConnectionFactory.setProperty("JMQBrokerHostName", MQ_HOST_NAME); sunQueueConnectionFactory.setProperty("JMQBrokerHostPort", MQ_HOST_PORT); queueConnectionFactory = sunQueueConnectionFactory; queueConnection = queueConnectionFactory.createQueueConnection(); queueSession = queueConnection.createQueueSession(false,
8/28/2003 José Alves Marques
Exemplo: receptor Assíncrono (III)
} catch (Exception e) {
System.out.println("Connection problem: " + e.toString()); if (queueConnection != null) {
try {
queueConnection.close(); } catch (JMSException ee) { }
}
System.exit(1); }
/* Criar consumidor de mensagens,registar o tratamento de mensagens (TextListener) e iniciar a recepção de mensagens.
O 'listener' escreve as mensagens obtidas. O programa fica bloqueado até o 'listener' receber a mensagem final e efectuar o desbloqueio. */
try {
queueReceiver = queueSession.createReceiver(queue); textListener = new TextListener();
queueReceiver.setMessageListener(textListener);
/* Iniciar a ligação */ queueConnection.start();
/* Aqui o programa está livre para ir fazer qualquer outra coisa
Departamento de Engenharia Informática
Exemplo: receptor Assíncrono (IV)
/* Quando não houver mais nada para fazer,
vai bloquear-se para esperar o fim da recepção de mensagens */ textListener.monitor.waitTillDone();
} catch (JMSException e) {
System.out.println("Exception occurred: " + e.toString()); exitResult = 1; } finally { if (queueConnection != null) { try { queueConnection.close(); } catch (JMSException e) { exitResult = 1; } } } System.out.println("Finished"); System.exit(exitResult); } }
8/28/2003 José Alves Marques
Função que trata as mensagens assíncronas
public class TextListener implements MessageListener {
final DoneLatch monitor = new DoneLatch();
/** método invocado no Listener de mensagens quando chega uma mensagem nova */ public void onMessage(Message message) {
if (message instanceof TextMessage) { TextMessage msg = (TextMessage) message; try {
System.out.println("Reading message: " + msg.getText());
} catch (JMSException e) {
System.out.println("Exception in onMessage(): " + e.toString()); }
} else {
/* A mensagem que não é de texto indica o fim da sequência. Acorda quem esteja à espera */
monitor.allDone(); }
} }
Departamento de Engenharia Informática
8/28/2003 José Alves Marques
EAI baseado em Filas de Mensagens
•
Agregam as funcionalidades dos message
brokers com a possibilidade de execução
de processos de negócio transversais às
várias aplicações, dentro e fora de uma
organização.
•
A arquitectura integração por camadas
típica compreende serviços comuns
(segurança, repositório, etc.), um bus de
mensagens, adaptadores, transformação
de mensagens, gestão de processos e
portais de informação.
Departamento de Engenharia Informática
Funcionalidade “típica” de um EAI
• Armazenamento de mensagens – Guarda persistentemente as
mensagens que chegam ao message broker. Dá suporte a mining de
mensagens, armazenamento de mensagens e auditorias.
• Transformação de mensagens – Converte uma mensagem de entrada
para um formato que permita ser enviada para outro sistema.
• Processamento de regras – Permite definir regras utilizadas no
processamento e encaminhamento das mensagens.
• Re-encaminhamento inteligente – Capacidade de re-enviar uma
mensagem de acordo com o seu conteúdo e a sua origem.
• Serviços de repositório – Mantém informação sobre as aplicações de
origem e destino das mensagens.
• Adaptadores – Camada de software que faz a ligação entre o message
broker e as aplicações mais habituais
8/28/2003 José Alves Marques
Integração Business-to-Business (B2B)
• Permite que os parceiros de negócio partilhem informação que suporta
os processos de negócio comuns.
• Complementa a Integração de Sistemas Empresariais (EAI).
• É mais complicado integrar dois sistemas de empresas diferentes do
que dentro da mesma empresa.
• É necessário dar mais ênfase a factores como a segurança,
disponibilidade, qualidade do serviço.
M i d d le w a r e B 2 B E m p r e s a A
E m p r e s a B
E m p r e s a C
Departamento de Engenharia Informática
8/28/2003 José Alves Marques
BizTalk Server 2004 (BTS 2004)
Departamento de Engenharia Informática
Plataforma Integração Microsoft
Infraestrutura tecnológica
Standards
Uso ferramentas que já conhecidas
z Definir processos negócio
z Definir regras negócio
z Acesso tempo real dados
Office (InfoPath, Excel)
z Ambiente desenvolvimento Integrado
z Colaborar efectivamente com Information Workers
(Visual Studio .NET)
Developers
Developers
Information Workers
Information Workers
z Ferramentas para: zDeployment zGestão\Administração zMonitorização Windows (MMC)Administradores
Administradores
8/28/2003 José Alves Marques
Arquitectura do BPMS no BTS 2004
Departamento de Engenharia Informática
Biztalk
•
BizTalk Server usa XML para definir as estruturas de dados dos documentos
de negócio transmitidos nas mensagens
•
Usa protocolos Internet como Hypertext Transfer Protocol (HTTP) e Simple
Mail Transfer Protocol (SMTP) para transmitir os documentos, permitindo a
interoperação com varias aplicações desde que em ambientes que suportam
Internet standards.
•
O BizTalk Server transacciona documentos formatados como Extensible
Markup Language (XML), EDI, ou flat files.
•
Serviços Biztalk:
– Sending,
– Receiving,
– Parsing,
– Tracking documents;
– receipt generation and correlation;
– Data mapping,
– Integrity,
– Security.
8/28/2003 José Alves Marques Technology Adapter Technology Adapter
Messaging Bus
Messaging Bus
Routing Services
Routing Services
Declarative RoutingDeclarative Routing Content BasedContent Based Publish/SubscribePublish/Subscribe
Application Adapter Application Adapter
Architectural Overview
Receive Services
Receive Services
HTTPHTTP SMTPSMTP MSMQMSMQ MQSeriesMQSeries File File WebWeb Service
Service
Application A
Application A Application BApplication B Application CApplication C
Application D
Application D Application EApplication E Application FApplication F
Application Adapter Application Adapter
Delivery Services
Delivery Services
Business
Business
Process
Process
Transformation Services
Transformation Services
XMLXML EDIEDI FlatFlat CustomCustom
Departamento de Engenharia Informática
Biztalk
•
Biztalk Editor – facilmente define e edita documentos esquematizados para
qualquer tipo de documento estruturado como XML, EDI e “flat files”.
•
Biztalk Mapper – Constrói documentos de transformação que permitem
aplicações e parceiros de negócio que utilizam diferentes definições de
documentos comunicarem entre si.
•
Biztalk Orchestration Designer – Define e constrói visualmente processos de
negócio robustos e distribuídos.
•
Biztalk Messaging Manager – Define relações entre parceiros de negócio e
fluxos de negócio.
•
Suporte para XML Web Services – Através do Biztalk Adapter for Web
Services, permite integrar web services com os processos de negócio.
•
Suporte para UN/EDIFACT e ANSI X12 EDI – sustentação de
especificações de documentos standards para usar em EDI VANS
(Value-Added Network Service) e aplicações
8/28/2003 José Alves Marques
Ferramentas - Implementação
• Visual Studio .NET (Solução .NET)
– Biztalk Editor - Editor de esquemas “Schemas”
• Suporta XSD, XDR, DTD, Flat-file, EDI
– Biztalk Mapping – Editor de ligações de estruturas (esquemas) entre
sistemas, possibilitando o mapeamento recorrendo a “functoids”:
• Bases Dados; Agregação;
• Cientifico; Datas; Lógica; Matemática; Texto; Avançado (scripting)
Departamento de Engenharia Informática
Create the documents involved in the
application/process as well as their respective
schema definitions.
This is
accomplished in
the Schema
Editor, a
BizTalk Server
module
accessed from
within Visual
Studio .NET.
8/28/2003 José Alves Marques
Create and define the transformation
requirements for any document interchanges.
•
In applications that are composed of loosely coupled interactions
between XML objects, document transformation becomes a
functionally exposed mapping subprocess. In BizTalk Server this
subprocess is created in BizTalk Server Mapper.
Departamento de Engenharia Informática
Specify the business logic governing event
execution
•If the business logic is
simple, it can be embedded
as an expression directly
within a BizTalk Server
orchestration decision step.
•If the business logic is
complex, the BizTalk
Server Rules Composer can
be used to create and
process the sophisticated
rule sets.
•Each rule set (or “Policy”)
drives a specific activity or
function and becomes a
resource object embedded
into a BizTalk Server
8/28/2003 José Alves Marques
Determine and implement requirements for
message preprocessing and post-processing
•This is accomplished in the
BizTalk Server Pipeline
Designer module.
•Accessed through the BizTalk
Server orchestration workspace,
the Pipeline Designer module is
used to implement the
interchange requirements for
encryption, authentication, and
data format conversion with
external applications and parties.
Departamento de Engenharia Informática
Compose and orchestrate the application/process
steps
8/28/2003 José Alves Marques
Biztalk e SOA
•
Functionally transparent and isolated, each object property within the solution
(orchestrations, schemas, maps, and so forth) is accessible from the host Visual Studio
.NET environment or directly through its XML representation.
•
The completed orchestration can generate a Business Process Execution Language
(BPEL) document of the entire process.
•
Because a BPEL instruction set is an XML representation of a process with a precise
language and grammar structure, it provides a readable and understandable instruction
set for documenting a process.
•
The process shapes in Orchestration Designer symbolize basic and structured BPEL
elements such as receive, invoke, sequence, flow, role, link, and source.
•
A process developed in BizTalk Server Orchestration Designer can be exported as a
BPEL document and be imported into any other BPEL-compliant application.
Conversely, a BPEL document can be imported into BizTalk Server Orchestration
Designer to generate an orchestration diagram. The standardized interchange of process
instructions can potentially facilitate collaborative business process development
between business partners.
•
XML and XML Schema have enabled the creation of the Web services protocols
SOAP and WSDL.
Departamento de Engenharia Informática
8/28/2003 José Alves Marques
Expor um Processo via Web Services
ER
P
ER
P
ve
rifi
ca
ve
rifi
ca
Sto
ck
Sto
ck
Cliente
Cliente
verifica
verifica
Stock
Stock
Departamento de Engenharia Informática
Agregação de Web Services
Verific ar Verific ar Status Status Cliente Cliente no ERP no ERP Verificar
8/28/2003 José Alves Marques
Segurança
• A nível da mensagem
– Autenticação de parceiros:
• Validação de assinatura digital
• Resolução parceiro
• Autenticação obrigatória
• Autenticação “trust”
• Recebe autorização
– Encriptação e signing das mensagens:
• Assinar certificados
• Encriptar certificados
• S/MIME
• A nível de autenticação (utilizadores)
– Sigle Sign-On – Mapeia credenciais utilizador de windows para non-windows – Assinatura Digital
– Windows
Departamento de Engenharia Informática
Escalabilidade
• O Biztalk é quase todo “stateless”
• Load Balancing e Fail over
• Permite fazer o “scale-out” de:
– Parsing mensagens; conversão; extracção de
propriedades, assim como transporte
• Excepções existentes num layer dedicado:
– Orquestração: persistência (transacções “long-running”)
– Correlação mensagens para a máquina correcta
– Protocolos baseados em sessão (eg. MSMQT)
– Excepções não são um problemas para “scale-out”
8/28/2003 José Alves Marques