Issue link: https://axway.uberflip.com/i/1300495
2 axway.com.br SOA: Uma ideia revolucionária que ficou num impasse À medida que a popularidade da Internet aumentou na década de 1990, demonstrando o poder de mercado sem precedentes de padrões abertos como HTML e HTTP, as pessoas começaram a se perguntar se o mesmo efeito poderia ser obtido com o próprio software. Os aplicativos poderiam alavancar padrões abertos para quebrar barreiras de integração e interoperação do mesmo modo que os padrões Web que impulsionaram a Internet para fora dos laboratórios e na economia? Os arquitetos de software se perguntavam se seria muito difícil estabelecer softwares que invocassem funções de outros aplicativos de modo tão simples que os consumidores poderiam avançar de um site a outro. Por exemplo, como um site financeiro do consumidor poderia aproveitar vários feeds de um registrador de cotações sem a codificação personalizada, muito custosa e que consome muito tempo, exigida no momento? Até esse ponto, a conexão de aplicativos tinha envolvido o uso de middleware proprietário e links codificados personalizados que exigiam configurações de firewall específicas para funcionar. No início do novo milênio, as maiores empresas de tecnologia surpreenderam o setor ao concordar em trabalhar juntas em um cenário compartilhado de padrões abertos que permitiria uma integração de aplicativos gratuita e com base na Internet. Esses eram os padrões de "Arquitetura Orientada a Serviços" ou SOA. Com base na linguagem XML, eles abrangiam SOAP (Protocolo Simples de Acesso a Objetos), WSDL (Linguagem de Descrição de Serviço Web) e vários outros. Esses padrões formaram a base para novas plataformas significativas, como o Microsoft .NET, BEA (posteriormente, Oracle) WebLogic, a nova geração de servidores IBM WebSphere, SAP NetWeaver e Oracle Fusion Middleware. O conceito SOAP era viável. Com todas as partes importantes de acordo, muitas empresas embarcaram em programas ambiciosos para criar arquiteturas orientadas a serviços. Esse esforço envolveu funcionalidade de software disponível como serviços Web com base em SOAP que poderiam se conectar facilmente, via HTTP, com WebServices SOAP dentro e fora da empresa. Novos conceitos como ESB (Barramento de Serviços Corporativo) emergiram, possibilitando que as organizações colocassem seus serviços Web em estruturas de software fáceis de integrar em novos aplicativos. A SOA funcionou até um ponto. Muitos êxitos ofereceram aos usuários um nível de conveniência raramente proporcionado antes. Grandes aplicações para ERP e logística lançaram novas edições com centenas de funções disponíveis como WebServices. Os desenvolvedores descobriram uma nova agilidade à medida que vincularam aplicativos e criaram novas experiências do usuário. Novos "aplicativos compostos" criados usando WebServices possibilitaram mais personalização para os requisitos do usuário. No entanto, o experimento SOA começou a fracassar após alguns anos. Embora revolucionário por sua acessibilidade e nível não usual de cooperação entre provedores de tecnologia concorrentes em seu uso, a SOA ainda era uma tecnologia difícil. Os ESBs eram custosos e difíceis de manter. A suposição era que o valor de negócios seria visto quando o projeto de SOA estivesse finalizado, mas parecia que o trabalho nunca acabava. O valor de negócios desejado das arquiteturas SOA bem organizadas, com diretórios intuitivos de WebServices que poderiam ser reutilizados em vários aplicativos, era muito difícil de ser obtido. Em vez disso, o que progrediu durante a primeira década do século XXI foi um ambiente decididamente misto. Ele incluía alguns programas de SOA organizados, uma boa quantidade de arquiteturas orientadas a ESB, muitas empresas com WebServices desorganizados e dispersos e várias que ainda estavam muito atrasadas na curva de adoção SOA. Era necessária uma abordagem nova e mais simples.