Message Oriented Middleware

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa

Message Oriented Middleware (MOM) e é um método de comunicação entre componentes de software utilizado em sistemas distribuídos. O MOM é um tipo de middleware orientado a mensagem. Um cliente pode enviar e receber mensagens de forma assíncrona de qualquer outro cliente, conectados a um agente especial que fornece facilidades para criar, enviar, receber e ler mensagens.

O MOM permite o fraco acoplamento. Emissor e receptor não precisam estar sincronizados, nem precisam ser previamente conhecidos. É uma alternativa aos métodos distribuídos sincronizados que utilizam bloqueio durante a comunicação.

Origem[editar | editar código-fonte]

Uma história de requisitos[editar | editar código-fonte]

O caso de um grande banco fornece um bom exemplo de como middleware surgiu como um negócio exigência:

O banco tinha guardado todos os detalhes do seu cliente sobre o seu grande[Mainframe computador | mainframe] desde 1960. Este mainframe permaneceu em uso pesado e sofreu diversos melhoramentos.

Apesar de inovador em sua época, a utilidade do mainframe para o pessoal do banco diminuiu, o banco apresentou novas aplicações separadas com base em [computador pessoal] (PCs), permitindo que o pessoal do banco para oferecer aos clientes novos serviços que o mainframe poderia não suporta.

Uma situação ideal seria permitir que o aplicativo baseado em PC com link para o aplicativo de mainframe mais velhos e permitir que o mainframe e os PCs para compartilhar uns dos outros de dados. Acessando dados do mainframe oferece duas vantagens:

  1. Aplicações de PC novo front-end pode substituir os antigos terminais de mainframe pouco amigável ao usuário
  2. Sistemas baseados em PC podem utilizar os dados do mainframe em novas formas - antes impraticável devido às limitações do software do mainframe

Até o final dos anos 1980 sistema integrador s não teve jeito fácil de ligar estas aplicações diferentes juntos. [Analistas [Middleware | Desenvolvedores]] enfrentou vários desafios:

  1. O [desenvolvedor de software [| developer]] teria que construir um "adaptador" de software separando em ambos os sistemas de tradução de dados os aplicativos de código em um formato que o sistema de destino possa entender (e vice-versa').
  2. A velocidade de processamento de cada sistema obrigaria o outro sistema. Por exemplo, se o mainframe correu lentamente, o aplicativo baseado em PC teria que esperar até que o mainframe apanhados, atrasando a aplicação de PC. Por outro lado, a transformação que tinha sido transferida para servidores distribuídos por razões de custo seria executado de forma lenta e mainframe teria de esperar até que o servidor preso.
  3. comunicações programadores, seria necessário instalar um sistema de gateway de rede para formar uma ponte entre a rede do mainframe e da rede de PC, se os diferentes sistemas utilizados diferentes protocolos de rede. O gateway iria traduzir os pacotes de rede do sistema de origem e de transmiti-las ao sistema de destino usando o protocolo do sistema de destino.

Tais questões feita a integração entre aplicações difíceis. Grande parte dessa integração também necessária reengenharia cada vez duas aplicações em plataformas diferentes necessário que reúna, já que cada situação diferente, em certa medida. Ao dedicar esforço para que reúna os aplicativos em diferentes sistemas, departamentos de TI e passou a gastar uma quantia significativamente maior do que o gasto no desenvolvimento inicial, por sub-sistema.

[Analistas [Middleware | Desenvolvedores]] precisava de um pedaço de software que se sentava no meio de duas ou mais aplicações e iria lidar com todos "canalização" entre os dois sistemas. Esse tipo de software necessário a inteligência para lidar com diferentes Plataforma s, diferente linguagem de programação s, vários protocolo de rede e diversos hardware. [Analistas [Middleware | Desenvolvedores]] quis retirar-se da complexidade da computação subjacente [infra-estrutura] para que eles pudessem foco na funcionalidade em aplicações reais.

No final do middleware 1980 começaram a surgir na tentativa de abordar estas questões. ofertas de middleware inicial dirigida punhados específicas de plataformas ou idiomas e, portanto, tinha uma utilidade limitada. Ao longo do tempo, entretanto, produtos de middleware têm se tornado cada vez mais avançados, suportando múltiplas plataformas, linguagens e protocolos.

A capacidade de middleware para interligar sistemas díspares em toda a [rede heterogênea] ambiente oferece apenas um exemplo dos benefícios desta tecnologia dominante. Middleware Desde de 2006 fornece toda uma série de novas funcionalidades que amplia e aperfeiçoa as aplicações existentes que interliga.


Ícone de esboço Este artigo sobre Software é um esboço. Você pode ajudar a Wikipédia expandindo-o.