este blog descreve os passos SOA uma organização deve tomar antes que ele pode ser verdadeiramente bem sucedido na realização dos benefícios de custo e agilidade oferecidos pela arquitetura orientada a serviços empresariais. Ele discute o que SOA representa e as várias etapas da adoção SOA, descrevendo as tecnologias, processos e melhores práticas disponíveis para ajudar as empresas a ter sucesso em suas iniciativas de arquitetura orientada a serviços.
o que é SOA?
Arquitetura Orientada a serviços (SOA) é um tipo de arquitetura usada no design de software que suporta orientação de serviço, em que os Serviços são fornecidos a outros componentes por meio de um protocolo de comunicação em uma rede.
o que SOA representa?
A definição de SOA, conforme fornecida pela Wikipedia:
Arquitetura Orientada a serviços (SOA) é um estilo de design de software onde os Serviços são fornecidos aos outros componentes por componentes de aplicativos, por meio de um protocolo de comunicação em uma rede. Os princípios básicos da arquitetura orientada a serviços são independentes de fornecedores, produtos e tecnologias. Um serviço é uma unidade discreta de funcionalidade que pode ser acessada remotamente e executada e atualizada de forma independente, como recuperar um extrato de cartão de crédito online.
um serviço tem quatro propriedades de acordo com uma das muitas definições de SOA:
- representa logicamente uma atividade comercial com um resultado especificado.
- é independente.
- é uma caixa preta para seus consumidores.
- pode consistir em outros serviços subjacentes.
diferentes serviços podem ser usados em conjunto para fornecer a funcionalidade de um grande aplicativo de software, um princípio SOA compartilha com programação modular. A arquitetura orientada a serviços integra componentes de software distribuídos, mantidos e implantados separadamente. É habilitado por tecnologias e padrões que facilitam a comunicação e a cooperação dos componentes em uma rede, especialmente em uma rede IP.
isso fornece uma resposta concisa ao que SOA significa, mas não descreve as razões pelas quais uma organização gostaria de avançar para a arquitetura orientada a serviços, ou os benefícios da SOA.
também da Wikipedia sobre o que SOA significa:
alguns arquitetos corporativos acreditam que SOA pode ajudar as empresas a responder de forma mais rápida e econômica às mudanças nas condições do mercado.Esse estilo de arquitetura promove a reutilização no nível macro (serviço) em vez do nível micro (classes). Ele também pode simplificar a interconexão e o uso de ativos de TI (legados) existentes.
em alguns aspectos, SOA poderia ser considerado como uma evolução arquitetônica e não como uma revolução. Ele captura muitas das melhores práticas de arquiteturas de software anteriores. Em sistemas de comunicação, por exemplo, pouco desenvolvimento de soluções que usam ligações verdadeiramente estáticas para conversar com outros equipamentos na rede ocorreu. Ao adotar uma abordagem SOA, esses sistemas podem se posicionar para enfatizar a importância de interfaces bem definidas e altamente operáveis.
analisando esses conceitos, podemos ver que existe um conjunto de recursos básicos necessários para alcançar os benefícios potenciais do SOA. A Wikipedia discute vários desses princípios orientadores, entre os quais estão:
- Reutilização – a capacidade de encapsular e expor de granulação grossa funções de negócio como serviços
- baixo acoplamento – assegurar que os consumidores de serviço são suficientemente captada a partir da implementação física de um serviço de
- Identificação e categorização (descoberta), certificando – se que os potenciais consumidores podem encontrar os serviços que eles precisam
Não importa o que SOA definição de uso, estes princípios fundamentais levar a uma ordem natural das atividades de uma organização deve concluir de forma incremental a perceber os benefícios de service-oriented arquitectura.
veja por que a Akana tem um forte desempenho no relatório Forrester Wave™: API Management Solutions, Q3 2020.
relatório de Download
quais são as sete etapas SOA?
existem sete passos SOA:
- Criar/Expor Serviços
- Registrar Serviços
- Serviços Seguros
- Gerenciar (monitor) Serviços
- Mediar e Virtualizar os Serviços
- Regem o SOA
- SOA Integração Com ESB
SOA passos 2 a 6 descrevem cross-enterprise preocupações que devem ser abordadas com um centralizada da infra-estrutura SOA plataforma. As etapas 1 e 7 atendem a necessidades específicas e geralmente são entregues como parte de uma pilha de aplicativos corporativos existente. Seguir essas etapas levará uma organização ao caminho certo para perceber os benefícios do SOA. Continue lendo para aprofundar cada etapa SOA.
criar / expor Serviços
o primeiro passo para mover uma organização para SOA é óbvio. Não pode haver nenhum aplicativo SOA sem Serviços, portanto, o primeiro passo deve ser expor ou criar serviços que possam ser facilmente consumidos por aplicativos habilitados para serviços da Web.
há uma série de decisões interessantes que as empresas enfrentam quando iniciam esse processo, não menos importante, é a decisão de reconstruir aplicativos existentes usando um paradigma orientado a serviços ou expor a lógica de aplicativos existente como um conjunto de serviços. Esta não é uma decisão binária, é claro, e a maioria das organizações criará novos serviços do zero, geralmente usando J2EE e/ou.NET, e também exporá serviços de mainframe existente e outros aplicativos de negócios.
há uma ampla gama de soluções diferentes para empresas que procuram expor aplicativos existentes como serviços, incluindo a SOLA líder de mercado da Akana, permitindo que os aplicativos mainframe CICS exponham e consumam serviços confiáveis, seguros e de alto desempenho.Qualquer empresa com um investimento significativo (mais de 1000 MIPS de acordo com o Gartner) em mainframe deve estar investigando maneiras de aproveitar melhor as vantagens desta plataforma e deve usar serviços da Web para integrar facilmente seus aplicativos de mainframe com sistemas modernos. A SOLA da Akana é comprovada em produção em clientes como a Merrill Lynch, onde está processando mais de 2 milhões de transações por dia de mais de 600 serviços da Web. SOLA é o único produto que oferece aos programadores de mainframe uma interface fácil de usar e baseada na Web para expor e consumir serviços de aplicativos CICS. Ele inclui suporte integrado para recursos avançados de serviços da Web, como WS-Security, XML-Encryption e XML-Signature.
a maioria das empresas tradicionais de integração de aplicativos corporativos (EAI) também está fornecendo versões de seus adaptadores que expõem os Serviços da Web em vez de seus protocolos proprietários tradicionais. Na verdade, muitas dessas plataformas EAI estão ressurgindo como produtos de barramento de Serviços Corporativos. O ESB aborda vários problemas diferentes, um dos quais é a funcionalidade de tipo de serviços de dados de commodities usada para expor interfaces de serviços da Web de adaptadores tradicionais.
o que é um serviço Web?
Da Wikipédia:
em relação aos Serviços da web W3C, o W3C definiu um serviço da web como: “um serviço da web é um sistema de software projetado para oferecer suporte à interação máquina-a-máquina interoperável em uma rede. Ele tem uma interface descrita em um formato processável por máquina (especificamente WSDL). Outros sistemas interagem com o serviço da web de uma maneira prescrita por sua descrição usando mensagens SOAP, normalmente transmitidas usando HTTP com uma serialização XML em conjunto com outros padrões relacionados à web.”
esta definição é interessante de uma perspectiva técnica, mas realmente não chega ao cerne do valor que pode ser derivado do SOA e dos serviços da Web. Um aspecto fundamental dos serviços da Web é que eles devem expor a lógica de negócios por meio de uma interface baseada em padrões. Um aspecto importante de expor ou criar um serviço é sua granularidade. Existem muitas escolas de pensamento diferentes sobre o que constitui um serviço (Veja acima), mas a maioria dos arquitetos corporativos concordaria que, para ser útil em um SOA, um serviço deve ser suficientemente grosseiro para ser útil para várias aplicações diferentes.
isso, é claro, geleia com um dos princípios fundamentais dos serviços no SOA – para que um serviço seja reutilizado; deve ser geralmente útil e utilizável. Um exemplo de um serviço geralmente útil pode ser um serviço “getCustomerInfo” que retornará detalhes sobre um cliente de um identificador de cliente. Um serviço mais refinado que pode não ser geralmente útil pode ser algo específico para um aplicativo específico, “setApplicationState”, por exemplo.
é importante considerar a granularidade dos serviços tanto na construção de novos serviços quanto na exposição da lógica de negócios existente como serviço. Por exemplo, seria fácil tomar uma transação CICS e expor vários serviços diferentes para definir e obter vários parâmetros, enquanto a realidade é que mais de granulação grossa serviço que expõe toda a transação como um único serviço pode ser muito mais utilidade geral, e, portanto, valioso.
leitura relacionada: descubra como a API de Mainframe SOLA da Akana fornece aos clientes um processo rápido e fácil para expor aplicativos de mainframe como serviços da web seguros e permite que aplicativos de mainframe consumam serviços da web.
Register
Ok, então você tem um ou mais serviços disponíveis em sua empresa. E agora?
para que um serviço seja usado, muito menos reutilizado, arquitetos de aplicativos e desenvolvedores que possam se beneficiar desse serviço precisam saber que ele existe. É aqui que entra um registro. Em seu nível mais simples, um registro nada mais é do que um índice de biblioteca que ajuda usuários em potencial de serviços a encontrar serviços nos quais possam estar interessados. O registro deve oferecer interfaces de pesquisa e navegação e deve ser organizado logicamente para facilitar a descoberta rápida e precisa de serviços.
no SOA de hoje, o padrão aceito para serviços básicos de registro é UDDI (Universal Discover, Description e Integration). A especificação UDDI fornece um modelo de dados e um conjunto de interfaces (todos os próprios serviços da Web) para publicação e descoberta de serviços, bem como um conjunto adicional de interfaces para gerenciar o próprio servidor de registro.
muitos fornecedores de registro levaram o conceito original de registro um pouco mais longe e estão usando tecnologias de registro como base para um repositório mais completo. Os fornecedores de registro também estão adicionando filtros baseados em” políticas “às suas ferramentas de publicação e oferecendo”soluções de governança em tempo de design”.
Akana considera o registro um bloco de construção fundamental do SOA. Todos os nossos produtos aproveitam a UDDI como uma única loja central para obter informações confiáveis sobre os Serviços em um SOA. Os produtos podem funcionar com qualquer registro compatível com UDDI, e a Akana inclui seu próprio servidor de registro UDDIv3 com seu produto Service Manager para empresas que ainda não possuem um registro. A este respeito, o registro está preenchendo a função de SOA que o LDAP preencheu para soluções de gerenciamento de identidade e acesso.
os produtos da Akana se concentram na governança em tempo de execução e aproveitam o registro como um local central para encontrar políticas em tempo de execução para implementar e aplicar. Claro, o registro incorporado é um servidor UDDIv3 totalmente funcional e, portanto, também faz um repositório de serviço de tempo de design ideal.
Beyond registry é todo o conceito de serviços de política e metadados que fornecem repositórios abrangentes para todos os artefatos de tempo de design e tempo de execução para os serviços no SOA. Este conceito é abordado com mais detalhes no whitepaper da Akana, o modelo SOA Infrastructure Reference.
seguro
o mundo dos SOA e dos serviços da Web não é todo Vinho e rosas. Supondo que você tenha concluído as etapas um e um passo, dê um passo para trás e considere o que você fez. Supondo que você está indo para o valor máximo de negócios, é provável que você tenha tomado aplicativos de missão crítica, dividiu-os em pedaços grosseiros granulados de funcionalidade, expôs essa funcionalidade como serviços e, em seguida, publicou esses serviços para um registro universalmente acessível.
tudo isso pode parecer uma coisa boa e, na maioria dos casos, é uma coisa ótima, mas você pode ter inadvertidamente criado algumas falhas de segurança em sua organização e exposto informações confidenciais ou transações de alto valor para qualquer pessoa com habilidades rudimentares de serviços da Web. Garantir a segurança dos serviços significa criar uma camada de aplicação da segurança nos provedores de serviços e uma camada de implementação da segurança nos consumidores de serviços.
uma boa maneira de entender os riscos de segurança com os Serviços da Web é pensar em aplicativos tradicionais de mainframe de tela verde. A única segurança exigida por esses aplicativos era a segurança de login, se você pudesse acessar o aplicativo, você estava em. Esses aplicativos continham as mesmas peças básicas de um aplicativo moderno (interface, lógica de Negócios, Serviços de dados), mas apenas a interface era acessível fora do aplicativo. No mundo dos serviços da Web, é provável que alguns dos principais serviços de dados sejam expostos como serviços, parte da lógica de negócios certamente deve ser exposta e o aplicativo não foi escrito com nenhum desses pontos de acesso em mente. Isso significa que é fundamental proteger os serviços que você expõe individualmente, você não pode confiar nos internos do aplicativo para garantir sua própria segurança.
então, o que significa proteger um serviço da Web? O mesmo 5 princípios de segurança que se aplicam a outros aplicativos também se aplicam aos serviços da Web:
- Autenticação – certifique-se que sabe a identidade do solicitante de serviço (e também garantir que o solicitante conhece a identidade do serviço que está a contactar). Existem vários padrões diferentes de serviços da Web para autenticar solicitações, desde abordagens simples como Autenticação Básica http até mecanismos mais complexos como SAML ou assinatura X. 509. Uma boa ferramenta de segurança de serviços da Web deve suportar todas essas várias opções.Autorização-certifique-se de que o solicitante está autorizado a acessar o serviço ou operação que está solicitando. A autorização é uma questão complexa e há vários produtos de decisão política disponíveis. A maioria das grandes empresas terá uma solução existente para autorização (Ca SiteMinder, IBM tam, etc), e uma boa solução de segurança de serviços da Web deve ser capaz de se integrar a elas, além de fornecer seus próprios recursos de autorização.Privacidade-certifique-se de que as mensagens de solicitação e resposta não possam ser lidas por terceiros não autorizados. É aqui que padrões como a criptografia XML são próprios, mas para usar com sucesso a criptografia XML, a solução de segurança de serviços da Web deve fornecer recursos eficazes de gerenciamento e distribuição de chaves e certificados e, idealmente, algumas ferramentas do lado do cliente para ajudar os desenvolvedores do consumidor.
- não repúdio-certifique-se de que o solicitante não pode negar o envio de uma solicitação e certifique-se de que o serviço não pode negar o envio de sua resposta. Este é o papel da assinatura XML, com a mesma provisão de gerenciamento e distribuição de chave que para a privacidade.Auditoria-garantir que o sistema possa manter um registro preciso e oportuno de solicitações e Respostas conforme necessário.
uma questão interessante, e ponto de debate, que surge em torno da segurança dos serviços da Web é onde essa segurança deve ser aplicada. Alguns fornecedores argumentarão que a segurança deve ser uma função central imposta por meio de um cluster de proxies implantados centralmente, enquanto outros argumentarão que deve ser exclusivamente o domínio do provedor de serviços ou contêiner. A realidade, é claro, está em algum lugar entre essas duas posições. Há certamente um papel importante para um proxy (ou cluster de proxies) no fornecimento de serviços de autenticação e detecção de ameaças na borda da rede para proteger contra ameaças externas. Há também um papel igualmente importante para a segurança baseada em Provedor ou contêiner para garantir a segurança do serviço até a última milha.Muitas empresas tendem a ignorar a pesquisa que mostra que a maioria das ameaças de segurança são internas à empresa, não externas e, portanto, delegam segurança a um tipo de solução de firewall. A Akana oferece um proxy de alto desempenho que executa funções de segurança centralizadas ou de borda de rede e uma ampla gama de agentes de contêiner para garantir a segurança da última milha dos serviços implantados.
proteger serviços da Web requer:
- Implantar totalmente funcional em recipiente de agentes para garantir a última milha de segurança e de distribuir a carga de operações criptográficas
- Implantar rede de alto desempenho de intermediários para roteamento e segurança de borda de rede de imposição
- abrangente de chave e certificado de gestão e de distribuição, para garantir que o prestador de serviços e consumidor, os desenvolvedores podem implementar com sucesso as necessárias políticas de segurança
- Fornecer consumidor developer kits de ferramentas para abstrair consumidor desenvolvedores da complexidade da descoberta e implementação de segurança da empresa Políticas
leitura relacionada: Saiba mais sobre as melhores práticas de segurança da API.
Gerenciar
três etapas na abordagem de 7 etapas do SOA e estamos começando a fazer algum progresso para alcançar o valor real do SOA corporativo. Temos alguns serviços, eles são publicados em um registro e podem ser descobertos por usuários em potencial, e garantimos que eles sejam seguros. O que mais poderíamos precisar?
para responder a esta pergunta, devemos primeiro olhar para um cenário de desastre potencial. O que acontece quando meus serviços se tornam vítimas de seu próprio sucesso? Seja. um serviço tornou-se tão popular que existem várias (dezenas, centenas ou milhares) aplicações diferentes consumindo-o e ele começa a fivela sob a carga. De repente, temos dezenas, centenas ou milhares de aplicativos que estão falhando ou com um desempenho ruim e não sabemos por quê ou como pará-lo.
precisamos monitorar nossos serviços para que saibamos se eles estão funcionando dentro dos parâmetros operacionais normais e para que possamos ver possíveis problemas antes que ocorram implementando modelos de planejamento de capacidade.
a solução de monitoramento que implantamos deve ser capaz de monitorar serviços para disponibilidade básica, desempenho (tempo de resposta), taxa de transferência e até mesmo estender ao conteúdo e monitoramento baseado no usuário. Deve ser capaz de monitorar e alertar sobre limites específicos de SLA e deve ser capaz de aplicar diferentes SLAs a diferentes usuários do mesmo serviço ou operação.Muitos Fornecedores definem essa categoria de produto como uma solução de gerenciamento de serviços da Web, embora muitos analistas concordem que o gerenciamento é muito mais amplo do que uma solução de monitoramento simples e deve incluir grande parte da funcionalidade descrita na próxima etapa.
idealmente, é claro, não devemos implantar soluções separadas para segurança e monitoramento, porque cada vez que interceptamos mensagens por meio de um agente ou intermediário, adicionamos outro gargalo de desempenho. É por isso que o Gerente de serviços da Akana se combina com o diretor de rede para fornecer uma plataforma abrangente de segurança, monitoramento e gerenciamento de SOA em uma solução única, de alto desempenho e fácil de implantar.
alguns fornecedores de gerenciamento de serviços da Web (monitoramento) posicionam suas soluções como plataformas de monitoramento de atividades de negócios (Bam), embora o BAM seja uma solução complexa que requer integração com muitos sistemas e bancos de dados de back e front – office. O monitoramento de interações de serviços da Web para conteúdo não deve ser considerado como uma alternativa a uma solução BAM corporativa.
Leitura Relacionada: Saiba mais sobre a solução de gerenciamento de API de ponta a ponta da Akana.
5. Mediar e virtualizar
neste ponto, parece que nosso SOA está pronto para o horário nobre. E assim é, por um tempo, pelo menos…
o próximo conjunto de desafios ocorre à medida que sua SOA amadurece. Você precisa introduzir novas versões de serviços, ou aumentar a capacidade de um serviço executando várias instâncias dele, você precisa provisionar aplicativos para usar instâncias específicas de serviços, e você precisa oferecer serviços que exponham uma gama mais ampla de diferentes tipos de interface.
é aqui que entra a virtualização de serviços. A virtualização parece complexa, mas a realidade é bastante simples. Um serviço virtual é um serviço inteiramente novo, definido por seu próprio WSDL, com seu próprio endereço de rede e parâmetros de transporte. Ele não implementa nenhuma lógica de negócios; ele simplesmente atua como um proxy para um ou mais serviços físicos, roteamento, balanceamento de carga, transformação e mediação entre diferentes tipos e padrões de mensagens de solicitação.
embora simples na superfície, o conceito de virtualização é extremamente poderoso. Ele fornece a capacidade de abstrair totalmente os consumidores de serviços de qualquer conhecimento direto do serviço físico. Por exemplo, por meio de um serviço virtual, um cliente.NET usando uma implementação da Microsoft de um protocolo de mensagens confiável com SOAP sobre http poderia consumir um serviço XML antigo simples exposto por meio da série IBM WebSphere MQ de um aplicativo mainframe. O cliente. NET acreditaria que era uma comunicação com um serviço http que suportava seu protocolo de mensagens confiável, enquanto o aplicativo mainframe acreditaria que estava sendo consultado por outro aplicativo nativo da série MQ.
serviços Virtuais oferecem uma ampla gama de funcionalidades:
- Eles podem usar transformação de XML tecnologias para permitir que os consumidores possam continuar a utilizar uma versão antiga de um serviço que não existe mais, transformando mensagens de solicitação e resposta entre a versão antiga e a nova versão que foi implantado.
- eles podem selecionar operações específicas de vários serviços diferentes e combiná-las em um único WSDL funcional para uma classe específica de Aplicação consumidora.
- eles podem fornecer diferentes requisitos de política para diferentes classes de usuário (ou seja, usuários internos com um conjunto de políticas e outra implementação do serviço que impõe um conjunto de políticas diferente para consumidores externos).
- eles podem fornecer Ponte de transporte para serviços e consumidores em transportes incompatíveis (por exemplo, http e JMS). * Eles podem mediar entre diferentes padrões de implementação ou até mesmo versões de padrões.
- eles podem mediar entre diferentes estilos de mensagens-RSS, SOAP, REST, POX (XML Antigo simples).
- eles podem fornecer roteamento poderoso baseado em conteúdo ou contexto para fornecer recursos avançados de balanceamento de carga e alta disponibilidade.
o resultado final com serviços virtuais é que eles são necessários para qualquer roteamento ou outros serviços da Web avançados e rapidamente se tornarão uma parte essencial de qualquer SOA empresarial.
governar
com 5 de 7 etapas concluídas, o SOA empresarial está praticamente pronto para ser executado. Agora você tem serviços seguros e gerenciados que estão disponíveis para um público amplo de maneira confiável e balanceada de carga e são facilmente detectáveis.
o próximo passo é unir todos os recursos entregues através dos primeiros 5 passos com uma estrutura de governança. A governança é um trabalho usado em excesso e muito mal utilizado, então vamos examinar brevemente uma definição de governança. Novamente da Wikipedia:
o termo governança lida com os processos e sistemas pelos quais uma organização ou sociedade opera. Freqüentemente, um governo é estabelecido para administrar esses processos e sistemas.
o ponto-chave para tirar dessa definição é que a governança é sobre processos e sistemas. No caso da governança SOA, estamos discutindo processos organizacionais como um conselho de revisão de arquitetura e sistemas como as tecnologias de registro, segurança e gerenciamento discutidas neste blog.
a governança para SOA é frequentemente dividida em duas partes separadas, governança em tempo de projeto e governança em tempo de execução. Em tempo de design, as organizações querem controlar (governar) os tipos de serviços que podem ser publicados, quem pode publicá-los, que tipos de esquema e mensagens esses serviços Podem Aceitar e uma série de outras regras sobre serviços. Em tempo de execução, as organizações precisam garantir a segurança, a confiabilidade e o desempenho de seus serviços e garantir que os serviços estejam em conformidade com as políticas corporativas definidas. A governança em tempo de Design é interessante e ajuda a garantir uma SOA organizada e bem projetada, mas empalidece em insignificância quando comparada ao controle ativo da SOA em tempo de execução.
o Service Manager da Akana é a principal plataforma de governança em tempo de execução do setor, oferecendo uma solução abrangente para segurança, monitoramento, gerenciamento, mediação e registro. A governança em tempo de execução fornece essencialmente uma estrutura única para controlar e monitorar a aplicação das várias etapas do SOA descritas neste documento. Ele fornece uma única solução abrangente que fornece supervisão no registro de Serviços, Segurança, Gerenciamento e mediação. Uma boa solução de governança em tempo de execução se manifestará como uma forma de bancada de trabalho que fornece ferramentas para todos os participantes ativos em um SOA.
- Desenvolvedor De Serviços: ferramentas para publicar, categorizar, definir meta-dados, o download de “agente”, virtualizar, versão, escolha política, escolher a visibilidade/direitos de acesso, participação no planejamento de capacidade e fluxo de trabalho do access
- Consumidor do Serviço: Ferramentas para facilitar o serviço de descoberta, seleção e fluxo de trabalho do access
- a Equipe de Operações: Ferramentas para monitorar o desempenho do serviço, solução de problemas, o monitor de dependências de versão de serviços, virtualização, gerenciamento de proxy
- a Equipe de Segurança: Ferramentas para gerenciamento de políticas, política de relatórios, verificação de conformidade, a auditoria de segurança
- Enterprise Architect: Ferramentas para monitoramento de aplicativos, gestão de relacionamento, design política de validação e definição, o serviço de gerenciamento de versão, o serviço de proxy da atribuição, serviço de virtualização
- Empresa de Gestão de TI: a Reutilização de métrica de gerenciamento, serviço de reutilização de métricas, SOA estatísticas
SOA Integração Com ESB
Olhando para os resultados dos últimos 6 passos em direção a um SOA, ficamos nos perguntando o que mais pode possivelmente ser. Até agora, temos um conjunto de serviços que são publicados em um registro, seguro, gerenciado, confiável e fracamente acoplado, tudo envolto em um design sólido e Solução de governança em tempo de execução.
a etapa final para algumas empresas é implantar uma ou mais implementações de barramento de Serviços Corporativos (ESB) para integrar serviços em serviços compostos ou orquestrados de nível superior. Esses ESBs geralmente serão entregues como parte de um conjunto de aplicativos mais amplo, como Oracle eBusiness applications ou SAP. Alguns ESBs especializados podem ser usados para criar serviços compostos complexos e se estenderão ao Domínio do gerenciamento de processos de negócios (BPM).
leitura relacionada: Saiba mais sobre as soluções de integração da Akana.
Enterprise Service Bus (ESB) é um conceito cada vez mais popular. Originalmente concebido como a evolução das soluções de middleware orientado a mensagens e EAI (enterprise application integration), o ESB significa coisas muito diferentes para diferentes organizações. À medida que analistas, fornecedores e clientes chegam a um acordo com a ideia de um ESB, parece que um ESB encapsula 3 conceitos funcionais; Adaptadores retirados de uma ferramenta EAI para garantir conectividade com aplicativos legados, serviços de mensagens retirados de uma plataforma de middleware orientada a mensagens para garantir entrega confiável e orquestração de processos para construir aplicativos ágeis.
o consenso entre os analistas é que a maioria das organizações acabará com várias plataformas ESB de vários fornecedores, fornecendo serviços em seu próprio contexto. Nesse ambiente, é fundamental que os ESBs usem uma infraestrutura central SOA para garantir a conformidade consistente com as Políticas de segurança e mensagens para os serviços que expõem e consomem.
os produtos Service Manager e Network Director da Akana se combinam para fornecer uma solução completa para governança e mediação entre várias instâncias do ESB em uma empresa.
agora que você sabe mais sobre o que SOA representa e as principais etapas SOA, confira Akana em ação!
Iniciar O Teste