Implementando SOA Usando Java EE
Propaganda
Implementando SOA TM Usando Java EE Implementando SOA TM Usando Java EE B. V. Kumar Prakash Narayan Tony Ng Rio de Janeiro, 2012 Para minha mãe – Sra. M. N. Lakshmidevamma — Dr. B. V. Kumar Aos meus pais – Sr. K. N. Krishnamoorthy e Sra. Sharada Krishnamoorthy — Prakash Narayan A Kaitlyn, Tyler e Sophia — Tony Ng Sumário Prefácio de Robert Brewin ............................................................. xvii Prefácio de Raj Bala ......................................................................xviii Agradecimentos ............................................................................. xxi Sobre os Autores ........................................................................... xxiii Parte I Visão Geral ........................................................................... 1 Capítulo 1 Introdução ................................................................. 3 Produtos e Serviços Serviços Guiados por Software Web Services SOA Web Services e Oportunidades SOA Resumo Notas Finais Capítulo 2 4 4 6 8 12 13 13 Evolução das Arquiteturas TI .................................. 15 Evolução da Arquitetura no Lado Servidor Evolução da Arquitetura do Mainframe Evolução da Arquitetura Cliente/Servidor Evolução da Arquitetura Distribuída Internet e World Wide Web 16 17 19 21 26 vii viii SUMÁRIO Evolução da Arquitetura no Lado Cliente Terminais como Clientes Thick Clients Thin Clients Clientes do Navegador Clientes Móveis Arquitetura Orientada a Serviços e Web Services Web Services Chegada da Infraestrutura SOAP, WSDL e UDDI Resumo Notas Finais Capítulo 3 28 29 30 30 31 31 32 32 34 35 35 Evolução da Arquitetura Orientada a Serviços ..... 37 Arquitetura Orientada a Serviços – Descrição Primeiras Arquiteturas IMS CICS CORBA DCOM Mudanças do Paradigma Java e Java 2 Enterprise Edition Linguagem de Marcação Extensiva Web Service – XML-RPC e SOAP Chegada dos Web Services e SOA Web Services da Primeira Geração Web Services da Segunda Geração SOA Usando Web Services Vantagens e Desafios com SOA Tecnologias da Implementação SOA Tecnologias .NET da Microsoft Tecnologias Java Enterprise Edition da Sun Microsystems Resumo Notas Finais 38 38 39 40 41 41 42 43 44 44 44 45 46 46 47 47 48 48 50 50 Parte II O Básico da Arquitetura Orientada a Serviços ............... 53 Capítulo 4 Serviços Orientados a Mensagens e SOAP ............ 55 Convenções SOAP Envelope da Mensagem Regras da Codificação Convenção RPC Vinculação 56 56 56 56 57 SUMÁRIO Anatomia do SOAP Modelo SOAP Básico Modelo SOAP Detalhado 'HWDOKHVGD&RGL¿FDomR62$3 Codificação do Tipo Simples Codificação do Tipo Complexo Vinculação SOAP Para o Protocolo de Transporte Interação Usando o Protocolo SOAP Modelo de Troca de Mensagens Resposta SOAP e Mecanismo de Tratamento de Erros <Fault> do SOAP <faultcode> do SOAP <faultstring> do SOAP <faultactor> do SOAP <detail> do SOAP Diferenças e Dependências da Versão SOAP Versionamento SOAP Nova Versão SOAP Resumo Notas Finais Capítulo 5 ix 57 57 60 65 66 68 68 69 71 72 72 73 73 73 73 73 74 75 76 Web Services e Linguagem de Descrição de Web Services ..................................................... 77 WSDL – Um Vocabulário da Descrição de Web Services do XML O Triângulo Web Services Fundamentos da Chamada/Invocação de Serviços Chamada Síncrona e Fundamentos do Mecanismo RPC Chamada de Serviços e WSDL Criação do Serviço Geração da Descrição do Web Service para o Serviço Registro do Web Service Publicação do Web Service Descoberta do Web Service Compreendendo a Semântica dos Web Services Chamada do Web Service Descrevendo Web Service – O Modo XML Elementos WSDL e sua Sequência de Aparecimento Anatomia do Documento WSDL Diferenças e Dependências da Versão WSDL Resumo Notas Finais 78 78 80 81 85 86 87 87 87 87 87 88 91 92 93 100 100 101 x Capítulo 6 SUMÁRIO Registros e UDDI .................................................... 103 'H¿QLQGRR8'', Informações de Negócio Baseadas na Taxonomia Especificações e Serviços UDDI Registros Públicos Versus Registros Privados Nomenclatura UDDI Conjuntos de API do Nó Nó UDDI Registros UDDI Estrutura de Dados Modelo de Informações Núcleo do UDDI Estrutura de Dados <businessEntity> Estrutura de Dados <businessService> Estrutura de Dados <bindingTemplate> Estrutura de Dados <tModel> Publicação das Informações de Negócio Criação e Modificação das Informações de Negócios Eliminação das Informações de Negócios Descoberta dos Web Services Navegação e Recuperação de Informações Informações de Exploração Detalhadas Resumo #AP¿TULO /RQUESTRAºOE#OREOGRAkA ................................ 119 Importância do Processo de Negócio e do Fluxo de Trabalho Orquestração WS-Linguagem de Execução do Processo de Negócio Processamento BPEL &RUHRJUD¿D Orquestração e SOA &RUHRJUD¿DH62$ Resumo Notas Finais Capítulo 8 104 105 105 106 106 106 106 107 107 107 108 109 110 111 112 113 114 115 116 117 118 120 121 122 124 129 130 131 Infraestrutura de Web Services Avançados para Implementar o SOA ...................................... 133 Padrões de Troca de Mensagens WS-* — A Nova Geração WS-Endereço WS-Transação Atômica 135 136 137 137 SUMÁRIO WS-Coordenação WS-Evento WS-Troca de Metadados WS-Notificação WS-Estrutura de Política WS-Confiabilidade/WS-Mensagem Confiável WS-Segurança :6²'H¿QLomRGH7UDEDOKR Endereçamento Confiabilidade e Mensagem Confiável Segurança WS-* e SOA WS-Mensagem Confiável WS e SOA WS-Segurança e SOA 3HU¿O%iVLFR:6, Resumo Notas Finais xi 137 137 138 138 138 138 138 139 140 142 146 147 147 148 148 Parte III Plataforma Java Enterprise Edition e ESB ........................ 149 Capítulo 9 Visão Geral da Plataforma Java Enterprise Edition (JavaEE)...................................................... 151 Categorias da Tecnologia Java EE Tecnologias do Aplicativo Web Tecnologias Web Services Tecnologias do Aplicativo Comercial Tecnologias da Plataforma Comum O Que há de Novo no Java EE 5 Anotações Java Modelo POJO Produtividade do Desenvolvedor Modelo de Componente Java EE Cliente do Aplicativo Uma Aplicação Web Componentes EJB Adaptador de Recursos Qualidade do Serviço do Java EE Distribuição Integridade dos Dados Segurança Performance e Escalabilidade Disponibilidade 153 153 155 158 161 163 163 165 166 167 168 168 168 169 169 169 169 170 170 170 xii SUMÁRIO Interoperabilidade Concorrência Resumo Notas Finais Capítulo 10 Tecnologias Web no Java EE................................. 173 Java Servlet JSP %LEOLRWHFDGH7DJV3DGUmR-63 JSF Paradigma MVC no JSF Framework do Componente da Interface do Usuário Modelo de Navegação Beans Gerenciados Linguagem de Expressão Unificada Conversão e Validação de Dados Eventos JSF $ERUGDJHPGR%DFNLQJ%HDQ Resumo Nota Final Capítulo 11 174 176 178 178 179 180 182 183 184 185 187 187 Enterprise JavaBeans e Persistência .................... 189 1~FOHRGR(-%$3, Injeção de Dependência Serviços de Contêiner Interceptadores Novo JPA Classe de Entidade Relacionamentos Herança Gerenciador de Entidades Operações do Ciclo de Vida da Entidade Linguagem de Consulta Java de Persistência Mapeamento Objeto-Relacional Mapeamento dos Relacionamentos Mapeamento de Herança Resumo Capítulo 12 171 171 171 172 191 191 193 193 194 195 196 197 197 200 203 203 204 205 Visão Geral dos Web Services Java ..................... 207 Implementando um Web Service Mapeamento entre Java e WSDL 208 208 SUMÁRIO Anotações do Web Service @WebService @WebMethod @Oneway @WebParam @WebResult @HandlerChain @SOAPBinding Acessando Web Services Protocolo e Transporte Recursos Avançados no JAX-WS Estrutura da Sub-rotina Interações Assíncronas API da Mensagem Arquitetura Java para a Vinculação XML Evolução do Esquema Resumo Capítulo 13 xiii 210 210 211 211 211 211 211 212 212 213 213 213 214 215 217 220 222 Barramento de Serviço Corporativo e Integração de Negócio Java .................................................... 223 %DUUDPHQWRGH6HUYLoRH&RUSRUDo}HV ESB – Uma Perspectiva de Negócio Recursos Importantes do ESB Integração de Negócio Java – Java e ESB Resumo 224 226 227 230 Parte IV Implementando o SOA usando a Plataforma Java EE.... 231 Capítulo 14 Arquitetura Orientada a Serviços e a Camada Web ........................................................ 233 Disponibilizando Serviços Através da Camada Web Visão Geral Padrões de Projeto da Camada Web e SOA Padrões de Projeto da Camada de Apresentação Frameworks e Disponibilização de Serviços Disponibilização de Serviços Usando o JSF Decisão Sobre o Framework Correto Resumo Notas Finais 234 235 236 236 237 238 244 245 246 xiv Capítulo 15 SUMÁRIO Arquitetura Orientada a Serviços e a Camada de Negócio ............................................ 247 Disponibilizando Serviços Através da Camada de Negócio Visão Geral da Camada de Negócio Padrões de Projeto da Camada de Negócio e SOA Padrões de Projeto da Camada de Negócio Padrões de Projeto entre a Camada de Apresentação e a Camada de Negócio Padrões de Projeto de Objeto de Transparência Padrões de Projeto da Camada de Integração O Padrão Data Acess Object Padrões de Projeto da Camada Intracomercial Padrão de Projeto do Application Service Resumo Notas Finais Capítulo 16 248 248 250 251 251 252 254 255 257 258 259 260 Arquitetura Orientada a Serviços Avançados ..... 261 Padrões no SOA Padrões de Mensagens Assíncronas Padrões de Conversação Padrões de Orquestração Padrões de Fluxos de Trabalho Resumo Notas Finais 261 263 267 269 273 279 280 Parte V Estudo de Caso .................................................................281 Capítulo 17 Desenvolvendo Aplicações Orientadas a Serviços — Um Estudo de Caso......................... 283 A Perspectiva da Indústria Distribuição de Mensagens na OTA Objetivos da OTA Planos e Especificações da OTA Membros da Aliança Estudo de Caso Desafios Estratégias de Implementação da Solução Serviço de Reservas de Viagem Fluxo de Trabalho ou Definição do Processo Considerações da Plataforma de Solução Resumo Notas Finais 285 285 286 286 287 288 289 290 291 294 296 298 299 SUMÁRIO Capítulo 18 xv Disponibilizando SOA Usando o Pacote NetBeans SOA: Estudo de Caso — Solução .......................... 301 Estratégia de Implementação — Visão Geral 1HW%HDQV,'( Invocando o NetBeans Explorando o IDE O Básico de Projeto Criação de Projetos Resumo Notas Finais 302 304 304 305 306 319 319 Referências .................................................................................... 321 Referências da Web AJAX BPEL CICS Padrão de Projeto ESB Importância do ESB GDS Hibernate Implementação do SOA com o Java EE 5 IMS IMS TM Melhores práticas do J2EE Padrões J2EE J2EE versus .NET Produtividade do desenvolvedor Java EE 5 Solicitação da especificação Java jRuby OTA Mudança de paradigma Mudança de paradigma na TI Benchmark de performance Portlet Ruby Sabre, GDS SOA SOA geral SOAP 321 321 321 322 322 322 322 322 322 323 323 323 323 323 323 323 324 325 325 325 325 325 325 325 325 325 326 326 xvi SUMÁRIO Padrões SOA Tango Web Services WSDL WSDL e UDDI XML Yahoo! Livros Padrões de Projeto ESB J2EE Java Java, XML MDA NetBeans SOA Arquitetura do software Web Services XML 326 326 326 326 327 327 327 327 327 327 327 327 328 328 328 328 328 328 328 Índice ............................................................................................. 329 Prefácio Robert Brewin Recentemente, analistas experientes, tais como Anne Thomas Manes, têm dito que o SOA está morto e falhou em cumprir as vantagens prometidas. Têm havido pontos de vista opostos para isto. O blogueiro da ZDNet Joe McKendrick organizou uma discussão sobre “Como evitar a desilusão SOA”, onde os participantes concluíram que qualquer desilusão percebida originou-se da falta de planejamento e medida por parte do ambiente corporativo, e não de uma falha do SOA. Na verdade, as corporações que trabalhavam com as práticas e as metodologias do SOA permanecem irredutíveis sobre a abordagem e reconhecem que o SOA continua a manter a promessa como um modelo para a integração e como uma ajuda para reduzir taticamente os custos em tempos difíceis. A promessa do SOA é oferecer uma abordagem arquitetural para suportar a proliferação e a adoção de serviços reutilizáveis. É uma abordagem que as empresas devem adotar para simplificar seus processos de desenvolvimento e melhorar a qualidade e manutenção de seu código. Na Sun, desenvolvemos a plataforma Java Enterprise Edition (Java EE) como um padrão da indústria e ela forma a base ideal sobre a qual os desenvolvedores podem implementar o SOA no nível corporativo e as aplicações web da próxima geração. Estou satisfeito por ver este livro de Kumar, Narayan e Ng, que adota uma abordagem prática para implementar SOA com Java EE. O foco está nas técnicas de implementação reais, alavancando o servidor de aplicações GlassFish e o IDE NetBeans. Falando sobre essa abordagem, os autores desmistificaram o SOA em relação a uma confusão de padrões de web services e mostraram como os leitores podem implementá-lo rápido e facilmente em sua empresa. Além de explicar os conceitos do SOA e os conceitos do Java EE, os autores mergulham fundo na implementação SOA com Java EE e mostram como os serviços podem ser enviados dentro das diferentes camadas de uma arquitetura corporativa. xvii xviii PREFÁCIO Arquitetos, desenvolvedores, gerentes e outros profissionais de TI, educadores e alunos aproveitarão os diferentes aspectos deste livro, desde os conceitos até a arquitetura, implementação, configuração e otimização. Acredito que você achará este livro vantajoso e instrutivo. 5REHUW%UHZLQ Diretor de Tecnologia, Software. Sun Microsystems Raj Bala Agora mais do que nunca, conceitos como disponibilidade, investimento, escalabidade, expansão, extensão e segurança, permeiam toda discussão sobre a arquitetura da tecnologia. Como empresas que ficaram mais conscientes do máximo valor sustentável resultante dos investimentos da tecnologia, a fraternidade da arquitetura sempre gritou alto o quanto os fundamentos importam. A integridade arquitetural é medida por todas as suas “particularidades” que mencionei em minha primeira frase e é encorajador ver como as respostas têm existido e, de fato, estão ficando melhores. A arquitetura orientada a serviços (SOA), como uma correção fundamental para os futuros problemas, evoluiu para fronteiras mais novas e mais avançadas. Dominando tecnologias eficientes, tais como o Java EE, o SOA está ficando mais atraente e convincente do que nunca. Na Cognizant, estamos desenvolvendo e enviando soluções corporativas usando o SOA. E sinto-me privilegiado em escrever um Prefácio para um livro de um dos nossos – Kumar é coautor com Prakash e Tony. O livro desvenda com cuidado o vasto tópico da arquitetura orientada a serviços através de uma abordagem definitiva e ilustrativa. Ele segmenta os web services nos web services da Primeira Geração para a composição dos serviços, web services da Segunda Geração para ligar esses serviços no processo/fluxo de trabalho da corporação e WS-* para endereçar as necessidades não funcionais da aplicação corporativa. Este livro também se desdobrará como um guia de implementação eficiente sobre os recursos avançados da nova plataforma Java, a Enterprise Edition, e indicará como as diferentes APIs, tais como JAX-WS e JAXB, da nova plataforma ajudam nos diferentes aspectos da orientação a serviços para a aplicação corporativa. Este livro deve ser muito importante para os vários envolvidos, inclusive arquitetos, desenvolvedores corporativos sêniores e integradores de aplicativos. Este livro também é um ótimo material de consulta para alunos da Ciência da Computação, Software e Arquitetura de Sistemas. PREFÁCIO xix De acadêmicos a arquitetos, profissionais a pessoas exigentes, alunos a especialistas, codificadores a Diretores de Experiência com clientes, este livro deve ser uma fonte vital de inspiração SOA – sobre como construir uma ótima arquitetura sem comprometer as “particularidades”. 5DM%DOD Vice-presidente e Diretor de Tecnologia Cognizant Technology Solutions Agradecimentos Gostaria de reconhecer e agradecer imensamente a Cognizant pelo encorajamento e suporte deste trabalho de colaboração, que foi iniciado há dois anos com Prakash e Tony. Um obrigado em especial vai para Frank (diretor executivo) e Chandra (presidente e diretor-geral) por seu encorajamento neste trabalho de colaboração. Obrigado a Raj Bala (vice-presidente e diretor de tecnologia) e Dr. Appa Rao (vice-presidente, diretor de tecnologia) por seu encorajamento contínuo e apoio durante a escrita deste livro. Tenho um débito elevado com Viswakumar (vice-presidente, Projetos) por sua ajuda incessante e suporte deste trabalho de colaboração. O apoio de minha esposa Sujatha Kumar, minha filha Nayana Kumar e meu filho Govind Kashyap foi enorme durante a correção deste livro e reconheço, sinceramente, o apoio contínuo deles neste projeto nos últimos dois anos. Devemos o nosso sincero apreço a Ramesh Srinivasaraghavan e Arijit Chatterjee, da Adobe (Índia), pela ajuda oportuna ao dar forma ao site complementar a este livro. Também Sujit Reddy e Shyam Prasad da Adobe (Índia) por nos ajudarem no conteúdo e design do site. ²'U%9.XPDU xxi xxii AGRADECIMENTOS Gostaria de agradecer a Chris Atwood e Octavian Tanase, na Sun, seu apoio e encorajamento neste projeto. Um agradecimento especial e amor para minha família – Jayanthi, minha esposa, e Akshay, Madhuri e Roahn, meus filhos, por sempre estarem por perto e apoiarem meus esforços com vigor. Tive sorte por trabalhar com uma ótima equipe de coautores: B. V. Kumar e Tony Ng. Cada um trouxe suas habilidades especializadas para tornar isto uma experiência recompensadora. Obrigado a Gopalan Suresh Raj, Binod P. G., Keith Babo e Rick Palkovic por seu texto de base, Implementing Service-Oriented Architecture (SOA) with the Java EE 5 SDK (Implementando a Arquitetura Orientada a Serviços (SOA) com o Java EE 5 SDK), que me inspirou a explorar mais o tema e a ficar envolvido na escrita deste livro. Este livro é sobre implementação. A base para este livro é o IDE NetBeans. A equipe com a qual trabalhei – Todd Fast, Chris Webster, Girish Balachandran, Nam Nguyen, Rico Cruz, Jiri Lopsa, Ajit Bhate, PCM Reddy e Hong Lin (entre muitos outros) – contribuiu ao ajudar a tornar o produto NetBeans um grande sucesso. Na parte editorial e de produção, obrigado a Greg Doench, Michelle Housley, Anne Goebel e ao resto da equipe editorial na Pearson por sua orientação. ²3UDNDVK1DUD\DQ Gostaria de agradecer a Jeet Kayl e Tom Kincaid o encorajamento e apoio, Bill Shannon e Eduardo Pelegri-Llopart a orientação e à equipe inteira da GlassFish, que trabalhou na plataforma Java EE e SDK. ²7RQ\1J Sobre os Autores 'U%9.XPDU, atualmente diretor e arquiteto-chefe na Cognizant Technology, é pós-graduado na IIT Kanpur e doutor pela IIT Kharagpur. Possui mais de 19 anos de experiência no campo da tecnologia de informação em vários níveis e em organizações como ComputerVision Corporation (Cingapura), Parametric Technologies (Seul, Coreia do Sul) e Sun Microsystems (Índia). Antes de se juntar à Cognizant, Dr. Kumar era o principal pesquisador e técnico na Infosys Technologies e responsável pela pesquisa e desenvolvimento de atividades e novas iniciativas no SETLabs. Dr. Kumar vem trabalhando com tecnologias corporativas por mais de 7 anos, focando no J2EE e nas tecnologias de web services. Como arquiteto-chefe e diretor no Global Technology Office da Cognizant (Índia), Dr. Kumar está gerenciando o IP e a criação de recursos, divulgação da tecnologia, desenvolvimento da comunidade e suporte de projetos. Dr. Kumar registrou duas patentes no espaço IP e publicou muitos documentos tecnológicos em jornais internacionais e conferências. Ele é coautor de web services – An Introduction e J2EE Architecture. 3UDNDVK1DUD\DQ é diretor de tecnologia e cofundador da Micello, Inc. Micello é uma pioneira no Vale do Silício que foca no envio de dados com alto valor para usuários de ponta, fornecendo informações dentro de um mapa de localização interna. Antes de fundar a Micello, Prakash estava na Sun Microsystems, onde foi um dos fundadores do Zembly – uma rede social para os desenvolvedores construírem serviços, componentes e aplicativos sociais. Antes do Zembly, Prakash era responsável pelo Java EE e a ferramenta SOA no NetBeans. xxiii xxiv SOBRE OS AUTORES Prakash tem mestrado em Ciência da Computação no Indian Institute of Technology, Deli, e é bacharel em Engenharia Eletrônica no Birla Institute of Technology and Science, Pilani, Índia. 7RQ\ 1J é diretor sênior de engenharia no Yahoo!, onde é responsável pelas plataformas e tecnologias do desenvolvedor Yahoo!, inclusive a plataforma Yahoo! Application (UAP), Yahoo! Query Language (YQL) e Yahoo! Developer Network (YDN). Antes de se juntar ao Yahoo!, Tony era diretor de engenharia na Sun Microsystems, onde gerenciou o desenvolvimento da plataforma Java EE e do servidor de aplicativos GlassFish. Tony é coautor do J2EE Connector Architecture and Enterprise Application Integration. Ele tem mestrado em Ciência da Computação no Massachusetts Institute of Technology e MBA na Universidade da Califórnia, Berkeley. Parte I Visão Geral • Capítulo 1 Introdução • Capítulo 2 Evolução das Arquiteturas TI • Capítulo 3 Evolução da Arquitetura Orientada a Serviços 1 1 Introdução A s empresas estão em um estado de fluxo. Novas exigências de negócios são desafiadoras o bastante para conduzir as inovações nas tecnologias da informação. Tais avanços estão empurrando as empresas para desafios de negócios mais novos. Inovações importantes sempre impactam as exigências arquiteturais. Isto tem transformado as empresas, de um estado no qual não havia nenhum conceito de arquitetura em um estado no qual uma quantidade significativa de planejamento arquitetural é a etapa mais importante em uma solução corporativa. Embora a funcionalidade dos aplicativos corporativos tenha conduzido as exigências das empresas em uma época anterior, as partes não funcionais agora estão controlando as exigências da arquitetura corporativa. A natureza variada dos negócios corporativos tem tornado necessário que os negócios reorientem a arquitetura para permitir a automação. Isto é vantajoso para as empresas, seus parceiros e colaboradores a longo prazo. A Arquitetura Orientada a Serviços (em inglês, Service Oriented Architecture - SOA) é o último jargão arquitetural que toma de assalto as empresas. As exigências corporativas para as empresas estão mudando mais rapidamente do que nunca e estão trazendo vários desafios, que colocam uma enorme pressão nos envolvidos comercialmente para que eles empurrem os negócios, buscando soluções de longa duração. Embora não haja nenhuma arquitetura milagrosa (ou nova arquitetura) de solução corporativa implementar, SOA parece prometer uma solução duradoura e, talvez, até futurista para as empresas. Mas, é o SOA a tendência mais nova? Se virmos as tendências históricas na evolução arquitetural, podemos observar que as tentativas para a orientação a serviços na arquitetura existiam, mas nunca foram reconhecidas por essa terminologia. Nas seções seguintes, iremos explorar a evolução do termo SOA e explicar seu impacto nas corporações. 3 4 CAPÍTULO 1 INTRODUÇÃO Produtos e Serviços Inicialmente, as corporações dependiam de meios tradicionais de condução das transações de negócios, inclusive o marketing e a promoção de produtos e serviços. Embora os modos tradicionais de comercializar produtos e serviços fossem simples, as maneiras inovadoras e criativas buscadas por muitas corporações eram poderosas o bastante para sustentar o negócio em um ambiente competitivo. A vida útil de comercialização de um produto ou serviço envolvia estas etapas simples: • • • • • Criação de produtos ou serviços e formas de comercializar. Descoberta de produtos e serviços pelos clientes. Confluência e negociação entre revendedores e clientes. Venda de produtos e serviços. Manutenção de produtos e serviços até o término da vida útil. Serviços Guiados por Software Produtos e serviços eram referidos quanto à comercialização como o ponto de vista. Observe aqui que os produtos são tangíveis por natureza, ao passo que a natureza dos serviços é mais intangível. O treinamento técnico, manutenção e proteção, instalação de maquinário (ou hardware), envio de produtos ou pacotes etc. são alguns exemplos de “serviços”. Os serviços são apresentados e usados como parte do processo ou do fluxo de trabalho em quase todas as empresas. A exigência de serviços1 como parte do processo/fluxo de trabalho está ganhando mais importância. O crescimento das tecnologias de informação nas indústrias parece ter estimulado a exigência e o envio de serviços de uma maneira profunda. Serviços como um negócio estão se tornando uma proposição atraente para muitas corporações. O negócio de entrega de serviços tem diversas vantagens, inclusive o fato de que eles podem ser enviados ou usados direta ou indiretamente. Um serviço direto é tangível por natureza. Um serviço de entrega poderia ser considerado tangível, ao passo que um serviço de ações e títulos não pode ser considerado tangível. E mais, qualquer serviço pode ser simples ou complicado por natureza. Um serviço simples pode ser uma tarefa precisa com uma etapa, ao passo que um serviço complexo pode ser composto de vários serviços simples, que podem ser associados a implicações tangíveis e intangíveis. Um serviço de correio pode também usar um serviço de rastreio de entrega, no qual os serviços de software são usados para controlar a rota e outros detalhes do envio do pacote. A importância crescente da TI em geral e a demanda ascendente por serviços tangíveis e intangíveis aumentaram a demanda por negócios de serviços guiados por software. Esses serviços desempenharam um papel importante ao permitir o envio de serviços em várias corporações, que alavancaram ativamente seu negócio ao utilizá-los. Cadeias de SERVIÇOS GUIADOS POR SOFTWARE 5 fornecimento, varejistas, serviços bancários e financeiros, educação, fabricação, produtos farmacêuticos, assistência médica etc. são exemplos de algumas indústrias verticais que alavancaram continuamente os serviços base em software como parte de seu processo/fluxo de trabalho. Quando os serviços guiados por software são usados para entregar ou utilizar serviços, existem implicações adicionais, com base na natureza e no uso do software. Um serviço entregue usando um sistema mainframe pode ser isolado dentro do ambiente do sistema autônomo. Do mesmo modo, a entrega de serviços em um sistema cliente/ servidor pode ocorrer em qualquer lugar dentro da Local Area Network (LAN). Por outro lado, a entrega de um serviço de software na internet pode acontecer além da LAN ou em ambientes em redes maiores, tais como a Wide Area Network (WAN) ou a Metropolitan Area Network (MAN). Da mesma forma que o requisito de entrega de serviço guiado por software cresce, também aumenta a complexidade da entrega de serviços. É importante entender a natureza e o papel do “serviço” ou processo de serviço, o “cliente” ou aplicativo do cliente, e o cliente que usa o serviço. Um serviço guiado por software pode ser definido como um processo do servidor (um programa executado em um sistema) que atende a solicitação do cliente realizando uma tarefa especificada no sistema servidor. Os exemplos incluem um aplicativo que pode recuperar as informações mais atualizadas sobre uma determinada transação de ações ou um aplicativo que pode fornecer um relatório de tráfego em tempo real sobre qualquer rota que o usuário solicita. Entre outras coisas, o processo do servidor envolve o sistema operacional hospedeiro, servidor de arquivos e outros aplicativos afins. Observe que o processo do servidor geralmente estará sendo executado como um processo daemon* e sempre estará aguardando uma solicitação. O cliente pode ser um usuário ou um aplicativo do computador. Os aplicativos do cliente têm duas variedades. Um aplicativo exibe as consultas para o usuário humano e obtém as entradas em tempo real. Tais aplicativos do cliente geralmente são associados às Interfaces Gráficas do Usuário (em inglês, Graphic User Interface - GUI), que são projetadas para coletar as entradas do usuário. O outro aplicativo do cliente acessa e usa automaticamente os serviços sem nenhuma interação humana. São aplicativos completos e podem lidar com todas as possíveis situações. Tais clientes ajudam a automatizar o processo/fluxo de trabalho. Quando o processo do servidor recebe a solicitação de um aplicativo cliente, ele aceita e a analisa, gerando uma resposta adequada que é comunicada de volta para o cliente. A solicitação e a resposta entre o cliente e o servidor são síncronas e usam o mesmo protocolo para a comunicação. Isto é análogo a duas pessoas se comunicando usando um idioma em comum. * N.R.T.: Daemon é um processo executado em segundo plano. 6 CAPÍTULO 1 INTRODUÇÃO Antes do advento da internet e da World Wide Web, os sistemas e as arquiteturas de software eram projetados para oferecer serviços aos clientes na LAN/WAN da intranet da empresa. Os processos do servidor e os aplicativos do cliente eram desenvolvidos em sistemas operacionais idênticos (e ambientes de programação) e distribuídos em sistemas compatíveis. Porém, se tais serviços fossem desenvolvidos e distribuídos em um hardware e sistemas operacionais diferentes, eles não poderiam comunicar-se. Assegurar a compatibilidade entre tais sistemas heterogêneos, embora possível, tornou-se dependente do revendedor. O surgimento da World Wide Web e da internet e a popularidade do Protocolo de Transferência de Hipertexto (em inglês, Hypertext Traster Protocol - HTTP) como um protocolo de comunicação leve mudaram profundamente o cenário dos serviços guiados por software. Um navegador web padrão podia ser usado como um cliente eficiente na intranet e na internet. Inicialmente, a web e a internet eram usadas exclusivamente por universidades, academias de pesquisa e estabelecimentos de pesquisa militares. A proliferação da web e da internet na esfera corporativa e a aceitação da mesma como uma mídia comercial adequada por empresas forneceram um impulso tremendo para a internet, ao passo que a aceitação do HTTP2 como um protocolo de comunicação de negócio também ganhou força. O serviço enviado pelo processo do servidor para o aplicativo cliente (navegador) está em HTML. O conteúdo dos serviços pode ter uma das três formas: informações estáticas, informações geradas dinamicamente ou uma combinação de informações estáticas e geradas dinamicamente. Embora as informações estáticas possam ser adaptadas, o conteúdo gerado dinamicamente indica a disponibilidade de informações mais atualizadas. Homens de negócios e corporações, geralmente, requerem uma mistura adequada de ambos. Web Services Os web services estão disponíveis, na maioria dos computadores em todo o mundo, em Assistentes Digitais Pessoais (em inglês, Portable Digital Assistants - PDA) e telefones móveis. A maior vantagem que a web forneceu aos negócios foi a disponibilidade e a acessibilidade dos serviços guiados por software na internet. A escala e a distribuição de clientes também apresentam oportunidades únicas para os negócios expandirem, embora a escala e a distribuição também tragam muitos desafios para os negócios. Como as vantagens superam as desvantagens, os negócios e as indústrias estão dependendo cada vez mais da web e da internet para o crescimento. O crescimento e a proliferação de corporações Business-to-Consumer (B2C) podem ser vistos como um resultado imediato da revolução da internet. O advento na internet e na web não trouxe o mesmo tipo de crescimento para o Business-to-Business (B2B). Os problemas predominantes podem ser atribuídos WEB SERVICES 7 a alguns fatores, tais como: sistemas muito diferentes, aplicativos incompatíveis e um protocolo de comunicação proprietário. Na verdade, o meio de comunicação foi identificado como o obstáculo predominante na realização da automação corporativa. Quando duas ou mais organizações precisavam concordar sobre os procedimentos B2B, elas eram confrontadas com um cenário complicado e eram vencidas por problemas graves de integração e interoperabilidade. A interoperabilidade é a chave para a automação corporativa e promove-a de forma eficiente entre parceiros e colaboradores. Interoperabilidade é a capacidade de um aplicativo se comunicar com qualquer outro aplicativo, independentemente do hardware no qual é distribuído, do ambiente operacional no qual o aplicativo é executado ou da linguagem de programação usada para desenvolvê-lo. Em outras palavras, os aplicativos distribuídos em sistemas muito diferentes devem comunicar-se e trocar informações corporativas. A tecnologia web services promete a interoperabilidade entre vários aplicativos corporativos distribuídos em sistemas diferentes. Os web services também prometem alavancar totalmente a web e a internet para tornar a interoperabilidade possível além dos limites geográficos. A inauguração da Linguagem de Marcação Extensiva (em inglês, Extensible Markup Language - XML), em meados dos anos 1990, introduziu a possibilidade da interoperabilidade através do uso da linguagem de marcação baseada em texto. O XML pode ser usado para representar qualquer informação relacionada com negócios. Tem a capacidade de tornar a troca de informações independente da rede, do sistema operacional ou da plataforma de distribuição, assim permitindo a interoperabilidade das informações corporativas. O XML é a linguagem fundamental, suportando vários dialetos avançados (ou padrões), geralmente referidos como vocabulários. Há mais de 450 vocabulários, representando diferentes requisitos verticais da indústria. Os aplicativos web services podem ser usados para implementar serviços síncronos e assíncronos. Observe que os web services não se referem a uma única tecnologia, aplicativo ou especificação, mas a uma combinação de várias tecnologias e especificações baseadas em XML. Os três vocabulários considerados mais importantes em relação aos web services são Protocolo Simples de Acesso a Objetos (em inglês, Simple Object Access Protocol - SOAP), Linguagem de Descrição de web services (em inglês, web services Descripton Language - WSDL) e Descrição, Descoberta e Integração Universais (em inglês, Universal Description, Discovery and Integration - UDDI). Segundo o Gartner Group, um web service pode ser definido como: [...] os componentes de software que utilizam uma ou mais das seguintes tecnologias – SOAP, WSDL e UDDI – para realizar computação distribuída. O uso de qualquer uma das tecnologias básicas – SOAP, WSDL ou UDDI – constitui um web service. O uso de todas elas não é requerido [...]. 8 CAPÍTULO 1 INTRODUÇÃO Utilizar serviços através da rota dos web services basicamente envolve três categorias de participantes, como mostrado na Figura 1.1. São eles o provedor de serviço, o solicitador do serviço e o agente de serviço (em inglês, service provider, service requester and service broker). Um provedor seria uma indústria, negócio ou empresa, capaz de criar e fornecer serviços baseados em software. Do mesmo modo, um solicitante seria uma empresa ou um negócio que gostaria de usar o serviço. Por outro lado, o agente seria um lugar, entidade ou sistema, que ajuda o solicitante a descobrir o provedor: Agente Internet / www Provedor Solicitador Figura 1.1 Os web services da primeira geração As setas na Figura 1.1 indicam as interações entre os três participantes. As interações entre o provedor e o agente são basicamente a publicação dos serviços. A interação entre o solicitador e o agente é a tarefa de pesquisar os serviços e o provedor de serviços. Finalmente, a interação entre o provedor e o solicitante é chamada de vínculo (em inglês, bind). Embora o papel do provedor de serviços e do solicitante do serviço seja simples e direto, o papel do agente requer um esclarecimento adicional. O papel do agente é permitir que o provedor e o solicitante se reúnam para descobrirem e entenderem um ao outro, discutirem e negociarem. A exigência do agente e de seus serviços não pode mais ser requerida depois de provedor e solicitante concordarem com a transação entre eles. O provedor e/ou solicitador, geralmente, não precisam visitar o agente depois de concordarem entre si sobre os termos e as condições da transação dos serviços. Contudo, a necessidade dos serviços do agente pode surgir apenas quando há uma mudança nos serviços e informações relacionados aos mesmos. Esta situação é provável quando o provedor do serviço prefere notificar as alterações no registro. SOA SOA é um método de arquitetar o aplicativo corporativo como um conjunto de serviços de cooperação que todos os usuários empresariais desejam. O usuário corporativo pode ser um usuário humano ou uma aplicação cliente. Vamos consi- 9 SOA derar um aplicativo corporativo como uma loja de animais de estimação online. Uma loja online, por exemplo, pode oferecer vários itens que os clientes remotos podem comprar. Quando um botão Submit (Enviar) é pressionado para finalizar a compra, vários outros serviços entram em ação, como mostrado na Figura 1.2. Por exemplo, o serviço de inventário inicializou a verificação do status do inventário de todos os itens selecionados. O serviço de envio pode ser chamado para iniciar o envio de diferentes materiais. Um serviço de controle pode, então, ser chamado para gerar o número de controle para localizar o pedido enviado. O processo inteiro, desde o pedido inicial até o envio, pode ser gerenciado pelas interações entre os vários programas que cooperam. Figura 1.2 Os serviços e a interação entre os serviços formando o SOA SOA é perfeito para a elaboração de programas como conjuntos de serviços de cooperação que podem interagir entre si através da internet. O termo “serviço” refere-se essencialmente às operações envolvendo negócios. Um aplicativo coporativo projetado para usar o SOA é composto de vários serviços, apresentando, geralmente, baixo acoplamento por natureza, para que novos serviços possam ser adicionados ou os existentes possam ser modificados (ou até aposentados) rapidamente, com base na natureza dinâmica da situação dos negócios. As organizações que utilizam SOA podem ser mais competitivas e, portanto, têm mais probabilidade de sobreviverem e prosperarem no mundo corporativo empresarial. Resumindo, uma aplicação corporativa criada com o SOA seria um conjunto de componentes de serviço distribuídos em uma rede. Esses componentes de serviço comunicam-se, através de padrões de mensagem, com os usuários finais e intermediários, usando os padrões web services reconhecidos no ambiente da computação. Os provedores de serviço podem, algumas vezes, publicar informações relacionadas a serviços, conhecidas como exposição do serviço. 10 CAPÍTULO 1 INTRODUÇÃO E mais, o conceito de SOA não é inteiramente novo. Ele existia anonimamente até antes do advento das linguagens orientadas a objetos.3 Iremos explorar algumas abordagens iniciais para o SOA. Uma das primeiras tentativas de implementar a arquitetura orientada a serviços foi o Ambiente de Computação Distribuído (em inglês, Distributed Computing Environment - DCE), que precedeu a internet e a web. Com o DCE, você podia implementar serviços em diferentes locais (algumas vezes em diferentes cidades) e em diferentes tipos de sistemas e ambientes operacionais. Os aplicativos cliente podiam solicitar diferentes serviços de qualquer lugar na rede, sem levar em conta de onde o serviço era acessado. As abordagens posteriores no SOA incluíam o Modelo de Componente Distribuído (em inglês, Distributed Component Model - DCOM) da Microsoft. Uma abordagem multiplataforma chamada Arquitetura Comum para Agente de Requisição de Objetos (em inglês, Common Object Request Brokered Architecture - CORBA), do Grupo de Modelos de Objetos (em inglês, Object Modeling Group - OMG), incluída a abordagem IDL. A solicitação de serviços por um usuário ou aplicativo a partir de outro aplicativo ou serviço pode ser agenciada, permitindo que aplicativos em diferentes ambientes operacionais e usando bancos de dados diferentes se comuniquem com eficiência. Porém todas as três abordagens4 anteriores – DCE, DCOM e CORBA – não foram abençoadas com a internet e o HTTP. As duas abordagens de criação do SOA e utilização de web services para implementá-lo são a abordagem top-down e a abordagem de bottom-up. Na abordagem top-down você define o negócio geral em torno de seus processos, como eles fluem e como são separados como serviços. Na abordagem de bottom-up você pode iniciar com alguns serviços e depois integrá-los na aplicação que a corporação já está usando. Alguns arquitetos defendem um meio termo para que as pessoas de negócio e os engenheiros TI elaborem uma abordagem pragmática que se desenvolva gradualmente em uma representação real do mundo de negócios, desenvolvendo aplicativos em componentes usando os web services. Qualquer que seja a abordagem usada é importante saber quais são os principais padrões e quais produtos são necessários para a construção dos componentes de serviço que tornam a empresa realmente orientada a serviços, ágil e dinâmica. O HTTP desempenhou um papel importante na proliferação das transações B2C e desempenha um papel importante nas transações B2B. Outro padrão chamado Protocolo de Acesso a Objetos Simples (em inglês, Simple Object Access Protocol - SOAP) se adiciona ao HTTP, portando as informações na forma de uma mensagem que pode ser síncrona ou assíncrona por natureza. E mais, em um cenário corporativo, a existência de uma combinação de padrões de troca de mensagens síncronas e assíncronas é comum. Outro avançado vocabulário XML padrão da indústria chamado Linguagem de Descrição de web services (em inglês, web services Description Language – WSDL, pronunciado como “Wisdel”) permite descrever os serviços que uma corporação pode oferecer. Esses serviços podem ser listados em um diretório ou registro conhecido como UDDI, algo como fosse as “páginas amarelas” eletrônicas para os serviços gerais.
