Oracle WebLogic Server: um Sólido Alicerce para a Arquitetura Orientada a Serviços. White paper Oracle Atualizado em Junho de 2008

Transcrição

1 Oracle WebLogic Server: um Sólido Alicerce para a Arquitetura Orientada a Serviços White paper Oracle Atualizado em Junho de 2008

2 Oracle WebLogic Server: um Sólido Alicerce para a Arquitetura Orientada a Serviços Introdução... 3 Oracle e o Java Platform, Enterprise Edition Melhor Lógica de Negócios para o SOA... 5 O EJB 3.0 Elimina Tarefas... 6 Anotações Fazem todo o Trabalho... 6 Descritores de Implantação Ficaram Simplificados... 7 O Oracle WebLogic Server Implementa o EJB 3.0 com Pitchfork... 7 Persistência agilizada para o SOA... 8 Suporte para JPA e JDO... 9 Implementação com Alta Performance... 9 Oracle TopLink Melhor Processamento de Web Services Interfaces da Web Melhoradas Implantação e Gerenciamento de SOA em Nível Corporativo Conclusão página 2

3 Oracle WebLogic Server: um Sólido Alicerce para a Arquitetura Orientada a Serviços INTRODUÇÃO A arquitetura orientada a serviços (SOA) iniciou uma revolução na tecnologia da informação. A implantação de pacotes coerentes de funcionalidade de software como serviços agrupados com baixo acoplamento proporciona uma melhora radical na flexibilidade dos aplicativos, permitindo que as empresas adaptem constelações de serviços continuamente, mantendo o alinhamento entre os recursos de TI e os objetivos de negócios. A Oracle é a líder quando se trata de ajudar as empresas a aproveitar os benefícios do SOA com Java. Com o Oracle WebLogic Server, a Oracle fornece um sólido alicerce para o SOA, baseado no Java Platform, Enterprise Edition 5 (Java EE 5). O Oracle WebLogic Server é extremamente fácil de usar desde o início e oferece confiabilidade, disponibilidade, escalabilidade e desempenho de nível corporativo. Os clientes podem fazer o upgrade dos serviços existentes rapidamente e gerenciá-los com poderosas ferramentas de configuração, implantação e gerenciamento. Eles também podem aproveitar a integração a outros produtos Oracle Fusion Middleware, bem como a experiência de seus desenvolvedores com tecnologias de código aberto, como o Spring Framework. Este documento discute como o Java EE 5 acelera drasticamente o desenvolvimento dos aplicativos SOA e como os desenvolvedores empresariais podem aproveitar seu poder usando o Oracle WebLogic Server. página 3

4 ORACLE E O JAVA PLATFORM, ENTERPRISE EDITION 5 A Oracle é a líder quando se trata de ajudar as empresas a aproveitar os benefícios do SOA com Java. A empresa detém a maior participação no mercado mundial de servidores de aplicação Java, de acordo com as empresas de pesquisa Gartner e IDC. É líder também em satisfação do desenvolvedor, de acordo com uma pesquisa recente da Evans Data Corporation, e em desempenho no benchmark SPECjAppServer2004. A Oracle é a líder quando se trata de ajudar as empresas a aproveitar os benefícios do SOA com Java. A empresa detém a maior participação no mercado mundial de servidores de aplicação Java, de acordo com as empresas de pesquisa Gartner e IDC.2 É líder também em satisfação do desenvolvedor, de acordo com uma pesquisa recente da Evans Data Corporation3, e em desempenho no benchmark SPECjAppServer2004. A Oracle construiu essa liderança com anos de incansável inovação em SOA. Uma de suas inovações mais recentes é o Java Platform, Enterprise Edition 5 (Java EE 5). Esse padrão apresenta melhorias radicais tanto na lógica de negócios quanto na persistência dos objetos. O Enterprise JavaBeans (EJB) 3.0 simplifica a programação de lógica de negócios rica, enquanto a Java Persistence API (JPA) torna mais fácil conectar essa lógica aos dados de registro correspondentes. O aprimoramento nos conjuntos de aplicativos da Web e Web Services torna a composição de aplicativos úteis a partir dos serviços mais fácil do que nunca. Como um todo, o Java EE 5 simplifica o desenvolvimento de SOA sem sacrificar o poder. Como mostra a Figura 1, a Oracle desempenhou um papel crucial no fornecimento das melhorias ao Java EE 5, avaliando os requisitos dos clientes e identificando a necessidade de simplificação. Então, fez contribuições importantes durante o desenvolvimento da especificação do EJB 3.0 e contribuiu para melhorias no processamento dos Web Services por meio de mecanismos como o Streaming API para XML. O mais importante é que a Oracle foi o primeiro fabricante comercial a apresentar uma implementação do Java EE 5 pronta para produção: o Oracle WebLogic Server. Figura 1: novas ferramentas de produtividade para desenvolvedores no Java EE 5 1 Market Share: AIM and Portal Software, Worldwide 2005, pesquisa da Gartner (junho de 2006). 2 Worldwide Application Server Software Forecast and 2005 Vendor Shares, IDC (dezembro de 2006). 3 Developers Choice Application Servers 2006 User Rankings, Evans Data Corporation (outubro de 2006). página 4

5 Clientes existentes do Oracle WebLogic Server já valorizam o compromisso da Oracle com o suporte a iniciativas de SOA de missão crítica. Entretanto, a versão mais recente do Oracle WebLogic Server oferece ainda mais com essa plataforma comprovada: os clientes podem criar serviços mais rapidamente, compô-los com maior facilidade e gerenciá-los com mais eficácia. Para as organizações que querem recursos de nível corporativo para seus desenvolvedores, esta solução é a escolha mais óbvia como a mais moderna, robusta e poderosa plataforma de SOA baseada em Java. Figura 2: Oracle WebLogic Server MELHOR LÓGICA DE NEGÓCIOS PARA SOA Em um ambiente SOA, diferentes serviços podem operar em níveis de abstração diferentes. Para as empresas, alguns dos serviços mais importantes, que geralmente correspondem a tarefas de âmbito comercial, podem incluir verificar pontuação de crédito no domínio de processamento de empréstimos, provisionar conta no domínio de telefonia celular e enviar fatura no domínio de contas a receber. Obviamente, a implementação de tais serviços requer algum tipo de modelo de software para o domínio correspondente. O EJB 3.0 isola totalmente os desenvolvedores do trabalho braçal. Em grande parte, os EJBs podem ser tratados como objetos Java comuns, simplificando drasticamente o desenvolvimento. Com essa abordagem agilizada, os desenvolvedores podem finalmente usar o EJB para implementar uma grande variedade de modelos de domínio que suportam os serviços empresariais mais importantes. O objetivo original do EJB era fornecer a infraestrutura para criar ricos modelos de domínio que pudessem suportar processos de negócios sofisticados. Beans de entidade manipulavam dados e implementavam o comportamento das entidades de domínio, como proposta de empréstimo, cliente e pedido de compra. Um portfólio de beans de sessão coordenava as interações das entidades para executar os processos de cada domínio por exemplo, avaliar empréstimo, inscrever cliente e pagar fornecedores. Em muitos casos, versões anteriores do EJB se mostravam complexas demais para suportar essa abordagem. A API expunha muitos dos mecanismos necessários para assegurar a execução robusta de processos de domínio. Para criar modelos de domínio eficazes, geralmente são necessárias muitas idas e vindas em um ciclo que inclui protótipo, testes e refinamento. Ao forçar os desenvolvedores a se preocuparem com o trabalho subjacente durante esse ciclo, os EJBs se tornavam muito complicados de usar em muitos projetos. página 5

6 Em contrapartida, o EJB 3.0 isola totalmente os desenvolvedores do trabalho braçal. Em grande parte, os EJBs podem ser tratados como objetos Java comuns, simplificando drasticamente o desenvolvimento. Com essa abordagem agilizada, os desenvolvedores podem finalmente usar o EJB para implementar uma grande variedade de modelos de domínio que suportam os serviços empresariais mais importantes. O EJB 3.0 Elimina Tarefas As mudanças no EJB 3.0 afetam principalmente como os desenvolvedores interagem com as facilidades do container. Com exceção da persistência, essas mudanças não afetam significativamente as facilidades em si. Em versões anteriores do EJB, os desenvolvedores tinham de realizar tarefas pesadas para interagir com o container. A primeira grande tarefa era implementar todas as interfaces necessárias, que exigia a criação de interfaces iniciais, locais e remotas, bem como a implementação da interface correspondente ao tipo do EJB. Para as interfaces inicial e remota, o desenvolvedor precisava lidar com todas as exceções necessárias. Os Beans de Entidade também exigiam métodos localizadores. A etapa final era implementar todos os métodos do ciclo de vida para a interface EJB aplicável. A segunda grande tarefa era escrever consultas em JNDI (Java Naming and Directory Interface) para adquirir referências de recursos. Modelos de domínio ricos naturalmente têm muitos relacionamentos entre seus elementos. Cada relacionamento, assim como qualquer referência a recursos de infraestrutura, exigia código de consulta. O EJB 3.0 elimina ambas as tarefas. Os desenvolvedores escrevem EJBs como POJOs (plain old Java objects ou objetos Java antigos e simples). Eles interagem com as facilidades do container adicionando anotações simples e declarativas ao código do POJO. O container se encarrega das tarefas necessárias, permitindo que os desenvolvedores se concentrem em criar modelos de domínio. Anotações Fazem todo o Trabalho O Java EE 5 inclui anotações correspondentes para outros tipos de EJBs. Além disso, em vez de implementar métodos do ciclo de vida, os desenvolvedores podem criar novas instâncias, como com qualquer outro POJO. Para os beans de entidade, há até mesmo anotações para o caso comum de especificar um identificador gerado automaticamente como chave principal e depois executar consultas usando essa chave. Além de controlar EJBs, o Java EE 5 também inclui várias anotações para simplificar o acesso à segurança, persistência e facilidades dos Web Services. Como mencionado, as anotações são a principal inovação que melhora a experiência do desenvolvedor com o EJB 3.0. A Oracle foi uma das pioneiras no uso de anotações e trabalhou para ampliar seu uso no Java EE. Se um desenvolvedor pode especificar de forma não ambígua o que é para ser feito, por que não simplesmente cuidar disso automaticamente? Por exemplo, suponha que um desenvolvedor que está trabalhando no domínio de processamento de empréstimos queira escrever um cliente para um bean de sessão sem estado que execute processamento de empréstimos. Em vez de toda a implementação da interface e do código de consulta JNDI necessários com as versões anteriores do EJB, o desenvolvedor simplesmente escreveria import public class LoanProcessorClient LoanProcessor } página 6

7 A substitui a definição manual da interface remota, enquanto a uma consulta JNDI manual. O Java EE 5 inclui anotações correspondentes para outros tipos de EJBs. Além disso, em vez de implementar métodos do ciclo de vida, os desenvolvedores podem criar novas instâncias, como com qualquer outro POJO. Para os beans de entidade, há até mesmo anotações para o caso comum de especificar um identificador gerado automaticamente como chave principal e depois executar consultas usando essa chave. Além de controlar EJBs, o Java EE 5 também inclui várias anotações para simplificar o acesso à segurança, persistência e facilidades dos Web Services. Descritores de Implantação Ficaram Simplificados Como se não bastassem as tarefas de programação associadas às versões anteriores do EJB, os desenvolvedores também tinham de enfrentar complicados descritores de implantação. Após realizar as tarefas e escrever a lógica de negócios em si, a implantação e execução de um EJB exigia que um descritor de implantação fosse escrito usando XML. Para os beans de sessão, o descritor continha em sua maioria informações redundantes como a classe, os nomes das interfaces associadas e o tipo do EJB. Então, havia diretivas para serviços de infraestrutura, como gerenciamento de transações e segurança. No caso de beans de entidade com persistência gerenciada pelo container, o descritor da implantação poderia conter dezenas de entradas especificando seu esquema abstrato de dados e várias consultas para esse esquema. A maioria das implementações de produção, como o Oracle WebLogic Server, incluiu ferramentas para gerar descritores de implantação e colocá-los no local correto. Mas esse se tornou outro item com o qual o desenvolvedor tinha de se preocupar, em vez de se concentrar no problema de negócios. No EJB 3.0, os descritores de implantação são opcionais. O desenvolvedor pode escrever e executar qualquer tipo de EJB sem um descritor, com as anotações e um conjunto de padrões fornecendo informações suficientes para executar o EJB. E o desenvolvedor que quiser realmente especificar um descritor precisa especificar apenas as entradas que se sobrepõem aos padrões. No EJB 3.0, a implementação de um serviço sofisticado que utiliza um grupo de EJBs em cooperação exige muito menos arquivos, cada um com muito menos entradas. O Oracle WebLogic Server Implementa o EJB 3.0 com Pitchfork Acrescentando o Pitchfork ao Oracle WebLogic Server, o container do EJB cria uma das melhores soluções da categoria: um container comprovado e de nível corporativo, e uma estrutura que aprimora a produtividade. Como foi observado anteriormente, o EJB 3.0 não muda significativamente as facilidades fornecidas pelos containers do EJB; em vez disso, facilita ainda mais seu uso. O Oracle WebLogic Server implementa o EJB 3.0 como extensão de seu container comprovado, que fornece a inteligência necessária para executar EJBs mais simplificados, convertendo anotações em instruções específicas e resolvendo dependências declarativamente especificadas. Para criar essa extensão, a Oracle trabalhou com os desenvolvedores do Spring Framework de código aberto para criar o Pitchfork, uma versão especial do Spring uma estrutura popular que ajudou a introduzir a simplificação do desenvolvimento de aplicativos Java através do uso de injeção de dependência. Acrescentando o Pitchfork ao Oracle WebLogic Server, o container do EJB cria uma das melhores soluções da categoria: um container comprovado e de nível corporativo, e uma estrutura que aprimora a produtividade. página 7

8 Dois efeitos dessa abordagem são a compatibilidade retroativa e olho no futuro. Como o Pitchfork atua como mediador entre o código do EJB 3.0 e facilidades tradicionais do container, o Oracle WebLogic Server é totalmente compatível retroativamente com o EJB 2.1. Os EJBs simplesmente ignoram o Pitchfork e usam as facilidades do container diretamente. E os clientes podem executar o EJB 3.0 e o EJB 2.1 lado a lado. Além da compatibilidade retroativa, o Pitchfork facilita que se pense no futuro. Muitos desenvolvedores adotaram abordagens de programação avançada como programação orientada a aspecto usando o Spring. O Pitchfork permite essas mesmas abordagens com o EJB 3.0. PERSISTÊNCIA AGILIZADA PARA SOA Ao isolar os desenvolvedores da complexidade, o EJB 3.0 permite que se concentrem em criar modelos de domínio representativos. A persistência é o próximo desafio. A execução de processos de negócios requer manipulação dos dados de registro. As entidades proposta de empréstimo, cliente e pedido de compra mencionadas anteriormente como exemplos têm representações Java que são executadas no container EJB. Entretanto, para executar um trabalho de verdade é necessário carregar e salvar as representações correspondentes armazenadas em bancos de dados de back-end, que asseguram que haja apenas uma cópia verdadeira de cada unidade de alta granularidade dos dados e que serviços diferentes manipulando as mesmas unidades de dados não interfiram um no outro. Em teoria, uma abordagem multinível como SOA torna a camada de aplicativos independente da camada de dados. Na prática, uma grande parte do código da camada de aplicativos se dedica a tarefas de gerenciamento de dados. O problema fundamental está em como a camada de aplicativos agrega valor. A maioria dos serviços fornece um valor razoavelmente único dentro de um determinado domínio eles executam um conjunto atribuído de tarefas dentro de processos mais amplos. Essa especificidade requer que eles manipulem dados sobre a entidade de negócios de maneira particular. Não é de se surpreender que queiram organizar os dados necessários da maneira mais conveniente. Com base em uma grande experiência de campo da Oracle, o Oracle WebLogic Server incorpora o Oracle Kodo, que integra perfeitamente tanto o JPA quanto JDO (Java Data Objects). Com o Oracle WebLogic Server, os desenvolvedores podem escolher o mecanismo ideal para modelos de domínio específicos. Portanto, cada serviço deve mapear unidades de alta granularidade dos dados de back-end a seus modelos de entidade de menor granularidade. A escrita e depuração manuais do código de mapeamento é extremamente demorada e suscetível a erros. Abordagens de mapeamento automatizado não são uma panacéia porque equilibram flexibilidade e complexidade. Se não houver flexibilidade suficiente, os desenvolvedores precisarão escrever manualmente um monte de código para atender aos requisitos. Devido à complexidade excessiva, os desenvolvedores têm a impressão de que o uso da ferramenta automatizada equivale a escrever um monte de código. Com base em uma grande experiência de campo da Oracle, o Oracle WebLogic Server incorpora o Oracle Kodo, que integra perfeitamente tanto o JPA quanto JDO (Java Data Objects). Com o Oracle WebLogic Server, os desenvolvedores podem escolher o mecanismo ideal para modelos de domínio específicos. página 8

9 Suporte para JPA e JDO Como foi discutido anteriormente, o EJB 3.0 usa anotações para reduzir a codificação das implementações de interface e entradas em descritores de implantação. A vantagem desta última é mais clara para beans de entidade com persistência gerenciada por container. A codificação abstrata mais descritores de implantação prolixos foram responsáveis pela complexidade do uso no EJB 2.1. Além disso, embora o EJB 2.1 fizesse algum esforço para tornar suas facilidades de persistência independentes da tecnologia de banco de dados, tendia a tornar o uso de bancos de dados relacionais muito mais complicado do que o necessário. A facilidade de uso e os aprimoramentos funcionais que vêm com o JPA dão aos desenvolvedores a capacidade de rapidamente implementar a persistência para os requisitos de acesso aos dados de SOA mais comuns. O JPA resolve todos esses pontos fracos. Os desenvolvedores simplesmente fornecem anotações de código instruindo o container a acessar os dados apropriados do banco de dados relacional. Uma antes de um conjunto de métodos acessadores define a chave principal. Há até anotações para especificar chaves compostas. Uma antes de uma definição de coleção define um relacionamento de um para muitos. No caso de relacionamentos de muitos para muitos, uma fornece o meio de configurar uma tabela de junção. Anotações mais sofisticadas incluem um grande conjunto de atributos para controlar de forma precisa interações especializadas com bancos de dados relacionais. O JPA faz mais do que apenas simplificar os recursos de persistência do EJB 2.1. Inclui também aprimoramentos necessários. O mais importante: os desenvolvedores não precisam mais especificar métodos do ciclo de vida para beans de entidade. O container automaticamente fornece um objeto EntityManager para controlar o ciclo de vida das instâncias. O JPA também permite que as classes Java especifiquem estratégias para lidar com a herança no mapeamento para o banco de dados. Em comparação com a linguagem de consulta do EJB da versão 2.1, a linguagem de consulta do JPA inclui diversos novos recursos, como operações em volume, junções externas e subconsultas. Juntos, a facilidade de uso e os aprimoramentos funcionais dão aos desenvolvedores a capacidade de rapidamente implementar a persistência para os requisitos de acesso aos dados de SOA mais comuns. Apesar dos aprimoramentos do JPA, muitos desenvolvedores ainda vão querer usar o JDO. Como o JPA concentra-se na persistência do banco de dados relacional, adota um estilo relacional. Quando se trabalha com modelos avançados orientados a objetos, a sintaxe mais orientada a objetos do JDO poderia ser atrativa. Em muitos casos, a escolha simplesmente será uma questão de gosto. Com o Oracle WebLogic Server, os desenvolvedores podem usar persistência gerenciada pelo container com o JPA ou persistência de gerenciamento de beans com o JDO. Embora JPA e JDO compartilhem muita funcionalidade subjacente, cada um tem recursos que faltam ao outro. O Oracle WebLogic Server fornece extensões a ambas as APIs, tornando-os funcionalmente equivalentes. Os desenvolvedores não precisam sacrificar recursos ao escolher um ou outro. página 9

10 Implementação com Alta Performance O compromisso da Oracle em criar serviços de alto valor com o Java EE 5 vai além de dar aos desenvolvedores uma opção de API de persistência. Inclui o fornecimento de alta performance, qualquer que seja a alternativa preferida pelo desenvolvedor. O compromisso da Oracle em criar serviços de alto valor com o Java EE 5 vai além de dar aos desenvolvedores uma opção de API de persistência. Inclui o fornecimento de alta performance, qualquer que seja a alternativa preferida pelo desenvolvedor. Como foi mencionado, o mesmo mecanismo de persistência executa funções tanto do JPA quanto do JDO. O Oracle Kodo inclui uma longa lista de recursos de nível corporativo. Talvez o maior desafio ao fornecer persistência para os serviços de negócios mais importantes seja o suporte a transações grandes e de longa duração. A conclusão de uma etapa significativa em um processo de negócios pode resultar em extensas atualizações em muitos dados diferentes. O Oracle Kodo suporta transações de tamanho ilimitado. Para garantir a coordenação de processos de negócios complexos, podem ser necessárias transações que permaneçam em andamento por vários minutos, horas ou até dias. O Oracle Kodo gerencia com eficiência conexões a fontes de dados durante essas transações de longa duração. ORACLE TOPLINK Oracle TopLink é uma tecnologia alternativa de persistência de alta performance que vem inclusa com o Oracle WebLogic Server. Essa solução é uma versão de nível comercial e é um superconjunto do TopLink Essentials. A Oracle, como líder na co-especificação do novo EJB 3.0/JPA, ajudou a projetar e fornecer orientação arquitetônica para a nova especificação JPA. Além disso, contribuiu com o código do TopLink Essentials para a implementação de referência do JPA. O TopLink Essentials agora tem o código-fonte aberto. Oracle TopLink é uma tecnologia alternativa de persistência de alta performance que vem inclusa com o Oracle WebLogic Server. Essa solução é uma versão de nível comercial e é um superconjunto do TopLink Essentials. Quando incluso com o Oracle WebLogic Server, o Oracle TopLink vem com recursos avançados de mapeamento objeto-relacional (ORM) além dos presentes no TopLink Essentials. Eles incluem armazenamento em cache coordenado para suporte a implantações de aplicativos em cluster e políticas de bloqueio otimistas e não invasivas. O Oracle TopLink fornece suporte para funções e procedimentos armazenados independente de plataforma; possibilita mapeamento histórico e consultas de um momento específico. Os beans gerenciados (MBeans) do Java Management Extensions (JMX) permitem gerenciamento e monitoração de sessões do Oracle TopLink e seus caches. Ao operar em um ambiente com Banco de Dados Oracle, o Oracle TopLink fornece os seguintes recursos: Um banco de dados privado virtual Mapeamento tipo XML e geração de consultas SQLX Dicas Consultas hierárquicas ORMs, matrizes, estruturas, referências de objetos e tabelas aninhadas Linha de negócios personalizada, registro de hora e tipos de dados de byte duplo Por fim, o Oracle TopLink suporta mapeamento para sistemas de informações executivos usando adaptadores de recursos do Java Connector Architecture. Oferece mapeamento objeto-xml baseado em Arquitetura Java para XML Binding (JAXB) 1.0 e forneces suporte antecipado para a funcionalidade do JAXB 2.0. Como a Oracle está comprometida com uma arquitetura hot-pluggable, os desenvolvedores podem optar por usar a tecnologia de persistência adequada ao seu projeto. página 10

11 MELHOR PROCESSAMENTO DE WEB SERVICES O uso de objetos Java comuns pelo EJB 3.0 torna rápido e fácil para os desenvolvedores criar modelos de domínio ricos e conectá-los a bancos de dados de back-end. É claro que esses modelos devem então ser disponibilizados como serviços dentro dos processos de negócios maiores suportados pelo SOA empresarial. A cooperação perfeita entre todos os serviços exige um alicerce sólido para processamento do protocolo de Web Services. O Oracle WebLogic Server inclui suporte para os mais recentes protocolos de Web Services voltados à segurança e à performance. Existem dois principais problemas no processamento do protocolo. Primeiro, a interoperabilidade requer implementação de todo um conjunto de protocolo e compatibilidade confirmada com conjuntos de diferentes fornecedores. O Oracle WebLogic Server inclui suporte para os mais recentes protocolos de Web Services (WS) voltados à segurança e à performance. Na área de segurança, as atualizações suportam WS- Security 1.1 e WS-SecurityPolicy 1.1 e 1.2. Há novo suporte para WS-Trust e WS- SecureConversation, que possibilitam aos serviços estabelecer um contexto de segurança compartilhada e manter relacionamentos confiáveis e duradouros. Na área de performance, há novo suporte para as especificações XML-binary Optimized Packaging (XOP) e Message Transmission Optimization Mechanism (MTOM). O XOP permite que os serviços transmitam dados binários como estão, sem codificação base64, e coloquem-nos no mesmo pacote MIME que o resto do documento XML. Essa abordagem reduz a largura de banda necessária e o trabalho de codificação. O MTOM descreve como usar o XOP para otimizar a transmissão de mensagens SOAP (Simple Object Access Protocol). A Oracle participou de diversos eventos de interoperabilidade para garantir que suas implementações desses protocolos, assim como outros do conjunto do Oracle WebLogic Server, funcionem bem como os de outros fabricantes. O segundo problema no processamento do protocolo é mais sutil. A API de processamento JAX-RPC (Java API for XML-Based Remote Procedure Call) de versões anteriores do Java EE suporta somente o estilo RPC, que infelizmente é o menos flexível de todos os estilos de interação dos Web Services. O Java EE 5 introduz uma nova API de processamento JAX-WS (Java API for XML Web Services), que suporta o estilo voltado aos documentos, que é mais flexível. O Oracle WebLogic Server também fornece suporte básico para um terceiro estilo Transferência de Estado Representacional que pode simplificar certas interações. A infraestrutura de processamento para vários estilos de Web Services permite aos desenvolvedores adequar as interações dentro de um SOA para atender a diferentes requisitos empresariais. Embora não seja estritamente um problema no processamento do protocolo, conjuntos de Web Services somente para clientes são um problema de ordem prática para os clientes que querem criar aplicativos leves que atuem apenas como consumidores de serviços, sem o fardo da funcionalidade voltada ao servidor. O Oracle WebLogic Server fornece uma biblioteca Java especial que implementa somente as porções cliente dos protocolos definidos no Perfil Básico da Organização de Interoperabilidade de Web Services. página 11

12 INTERFACES DA WEB MELHORADAS Quase todos os processos de negócios suportados por um SOA requerem alguma forma de interação com o usuário, e a maioria dos processos envolve muita interação. Os serviços de SOA mais importantes tendem a fornecer uma representação natural das tarefas de negócios. O aproveitamento dessa representação para fornecer interfaces de usuário mais sofisticadas é uma tremenda oportunidade. O Java EE 5 fornece um pacote integrado de melhorias para suas APIs de interface Web. Elas permitem interações mais sofisticadas com o usuário, facilitam a programação da interface e expandem a amplitude e profundidade da interação das pessoas com os serviços. O elemento central das APIs da interface Web do Java EE 5 é o JavaServer Faces (JSF). O objetivo principal do JSF é fazer o desenvolvimento de interfaces Web mais semelhante ao desenvolvimento de GUIs. O modelo subjacente à estrutura permite que os desenvolvedores conectem recursos da interface aos componentes da lógica, criando essencialmente widgets abstratos. Interações entre usuário e widgets usam um modelo orientado pelo evento. A etapa final do desenvolvimento é ligar o modelo de interação abstrato a uma tecnologia específica como a Web. Esse estilo de interação torna muito fácil lidar com o estado da interface dentro da estrutura. Um benefício imediato é que os desenvolvedores não precisam implementar muito código Java e EL (Expression Language) relacionado ao estado em seus JavaServer Pages (JSPs). O JSF também pode lidar tranquilamente com conversão e validação de valores. E como o JSF usa o mesmo modelo como GUI, funciona muito bem com ferramentas de desenvolvimento de interface. Como desenvolvedores de cliente/servidor tradicionais aprenderam muito tempo atrás, criar uma interface com uma boa ferramenta é muito mais produtivo do que codificá-la na unha. As interfaces de usuário são o segredo para utilizar o poder do SOA. Facilitando sua construção e criando oportunidades para rápido aprimoramento futuro, estabelece-se um trabalho de base para um retorno ainda melhor do investimento em SOA. Agora que o JSF faz parte do Java EE, ele funciona perfeitamente com o JSP. Eles compartilham um EL unificado, e o JSP é o mecanismo de apresentação padrão para o JSF. Mais importante é o fato de haver uma tremenda oportunidade de ampliar os recursos da interface de usuário da plataforma padrão. O JSF, combinado com as bibliotecas de tags do JSP, facilita a criação de componentes reutilizáveis da interface de usuário. Além disso, a maioria das funções da estrutura é plug and play. Os desenvolvedores podem substituí-los peça por peça por versões aprimoradas ou podem até trocar a estrutura inteira por uma alternativa como o Spring. As interfaces de usuário são o segredo para utilizar o poder de SOA. Facilitando sua construção e criando oportunidades para rápido aprimoramento futuro, estabelece-se um trabalho de base para um retorno ainda melhor do investimento em SOA. IMPLANTAÇÃO E GERENCIAMENTO DE SOA EM NÍVEL CORPORATIVO Ao facilitar a escrita de serviços de negócios e suas interfaces, o Java EE 5 promove uma ecologia de SOA muito mais rica. Na verdade, para se construir essa ecologia dentro das empresas, é necessário manter instâncias de serviços individuais e o ambiente de SOA mais amplo precisa ser saudável. Uma especificação de API sozinha não consegue atender a esse requisito. As empresas precisam de uma implementação de nível corporativo, com a implantação, gerenciamento e robustez exigidos de qualquer componente de TI de missão crítica. página 12

13 O Oracle WebLogic Server provou sua capacidade de operar em um ambiente empresarial. A versão mais recente amplia esse sucesso e abrange o Java EE 5, para que os clientes possam gerenciar todos os novos recursos do console conhecido, e facilitando ao máximo o upgrade dos serviços existentes. Para o upgrade, basta reimplantar um sistema existente na nova plataforma, sem necessidade de portar. O Oracle WebLogic Server provou sua capacidade de operar em um ambiente empresarial. A versão mais recente amplia esse sucesso e abrange o Java EE 5, para que os clientes possam gerenciar todos os novos recursos do console conhecido, e facilitando ao máximo o upgrade dos serviços existentes. As empresas também enfrentam o desafio de fazer o upgrade de clientes para novas versões de um serviço. Diversos recursos facilitam essa consequência natural de um SOA maduro. Várias versões dos mesmos serviços podem ser executadas no mesmo servidor ou cluster. Os administradores podem segmentar o acesso da população de clientes às versões por exemplo, disponibilizando versões mais novas somente aos clientes provenientes de segmentos da rede locais ou internos. Por fim, os administradores podem especificar declarativamente a política de migração dos clientes. O Oracle WebLogic Server resolve diversos outros problemas dos clientes. Para redes empresariais sem suporte para multicast, a versão mais recente oferece cluster com unicast. Ao operar um cluster, a migração dos serviços do Java Message Service e Java Transaction API de uma máquina para outra costumava exigir diversas etapas manuais. A versão mais recente conta com migração automática do serviço. Possibilita também a gravação e registro em script das operações do console. Conforme o Oracle WebLogic Server vai se tornando parte padrão da infraestrutura de TI, muitas empresas querem monitorá-lo como parte de seus consoles SNMP (Simple Network Management Protocol). A versão mais recente suporta SNMP 3, incluindo uma visão do SNMP do JMX Runtime MBeans. Além disso, o agente SNMP do servidor de administração agora fornece uma visão de todo o domínio do Oracle WebLogic Server. Essas melhorias demonstram o compromisso da Oracle em fazer do SOA um benefício para toda a organização de TI, não apenas para arquitetos e desenvolvedores. Figura 3: estrutura de diagnóstico do Oracle WebLogic Server página 13

14 CONCLUSÃO O Java EE 5 acelera drasticamente o desenvolvimento de aplicativos de SOA. O EJB 3.0 simplifica a lógica de negócios ao permitir que os desenvolvedores se concentrem mais no modelo de domínio e menos no trabalho do middleware. O JPA simplifica as tarefas de gerenciamento de persistência mais comuns associadas ao mapeamento dos objetos de domínio aos bancos de dados relacionais de back-end. As APIs de interface Web possibilitam uma interação mais rica e flexível do usuário com SOA, enquanto o JAX-WS permite uma cooperação mais rica e flexível entre os serviços de um SOA. O Oracle WebLogic Server é a plataforma Java EE de maior popularidade, produtividade e performance. Agora é uma das primeiras a disponibilizar aos desenvolvedores empresariais o poder de uma implementação do Java EE 5 pronta para produção. O Oracle WebLogic Server é uma das primeiras implementações do Java EE 5 prontas para produção. Ele não só cumpre o padrão, como também adota seu espírito, que é o da simplicidade sem sacrifício. Os desenvolvedores obtêm a vantagem de uma API simplificada sem abrir mão de nenhuma infraestrutura comprovada no alicerce do Oracle WebLogic Server. O Oracle TopLink também vem incluso, fornecendo uma instância de alta performance da implementação de referência da persistência do Java EE. Ajudar os clientes a operar melhor seus negócios é o objetivo primordial, e o Oracle WebLogic Server oferece recursos do Java EE 5 da maneira como são mais suportados. O Oracle WebLogic Server é a plataforma Java EE de maior popularidade, produtividade e performance. Agora é uma das primeiras a disponibilizar aos desenvolvedores empresariais o poder de uma implementação do Java EE 5 pronta para produção. Os clientes existentes podem tirar proveito imediato das APIs aprimoradas, enquanto os novos têm a confiança do alinhamento com um líder consagrado. página 14

15 Atualizado em junho de 2008 Oracle Corporation Filial Brasil Av. Alfredo Egídio de Souza Aranha, 100 5º andar Chácara Santo Antônio São Paulo SP Brasil Telefone para contato: Internet: Copyright 2008, Oracle e/ou afiliadas. Todos os direitos reservados. Este documento é fornecido com propósito meramente informativo, e as informações aqui contidas estão sujeitas a alterações sem prévio aviso. Este documento pode não estar isento de erros, nem está sujeito a nenhuma outra garantia ou condição, seja expressa oralmente ou implícita pela lei, incluindo garantias implícitas e condições de comercialização ou adequação a um propósito específico. A Oracle especificamente se isenta de qualquer responsabilidade com respeito a este documento. Nenhuma obrigação contratual é estabelecida direta ou indiretamente por este documento. Este documento não pode ser reproduzido ou transmitido de forma ou meio algum, seja mecânico ou eletrônico, para nenhuma finalidade, sem autorização prévia expressa por escrito. Oracle é uma marca registrada da Oracle Corporation e/ou de suas afiliadas. Outros nomes podem ser marcas comerciais de seus respectivos proprietários. 0408