soa e web services

Mais uma do Geek And Poke

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Gartner Enterprise Technologies Summit 2010

Houve casos de portais importantes ficarem inoperantes devido a um bug em um WS client ter enviado a um WS um XML de alguns gigabytes; o WS tentou carregar o XML todo na memória, que acabou estourando. Na sequência, cada máquina do cluster tentou fazer a mesma coisa e todas elas cairam.

Como prevenção, ou cria-se mecanismos para prevenir as diversas possibilidades, ou usa-se um appliance, hardware especial que funciona como filtro. Interessante.

Quem souber de casos interessantes sobre isso, e como foram resolvidos, deixe sua mensagem.

Abraço

Marcelo

Related posts:

1. SOA ajuda Cloud? Sim!

Nos meus últimos posts, discutimos sobre o Modelo de processamento SOAP e sobre a Anatomia do WSDL . Para quem não tem muita familiaridade com estes temas, recomendo fortemente a leitura destes dois posts antes de começar a ler esta série.

O primeiro padrão que falaremos é o WS-Addressing. Este padrão define construções em XML para dois tipos de informação: endpoint reference e message information. Estas informações são tipicamente de responsabilidade dos protocolos de transporte (ex: HTTP, SMTP). O padrão WS-Addressing normatiza estas informações dentro de um formato uniforme de modo que possa ser processado independentemente da camada de transporte. Mas afinal o que é um endpoint reference? Endpoint reference é uma entidade, recurso ou processador para onde as mensagens dos Web Services são encaminhadas, ou seja, um endpoint reference está para Web Services assim como URL e email estão para os protocolos HTTP e SMTP, respectivamente.

Um endpoint reference pode ser usado de duas maneiras: a primeira, para endereçar e referenciar o provedor do serviço e a segunda, para endereçar as mensagens transmitidas entre o consumidor e o provedor do Web Service (message information). Para isso, o padrão WS-Addressing define um bloco XML que deve estar contido dentro do header do envelope SOAP. O header geralmente contém informações auxiliares usadas para controlar segurança, transações e outros aspectos que não estão diretamente ligado a funcionalidade do Web Service.

A figura acima apresenta alguma das tags definidas pelo padrão WS-Addressing.
<MessageID> – Identificador da mensagem. Nenhuma mensagem de uma mesma aplicação pode ter o mesmo identificador. Se uma mensagem é retransmitida ela mantém o mesmo MessageID.
<ReplyTo> – Especifica o endpoint reference para onde deverá ser enviada a resposta para esta mensagem.
<To> – Especifica o endpoint reference destino desta mensagem.
<Action> – Identifica a semântica da mensagem. Em outras palavras, amarra a mensagem com o portType do WSDL identificando se a mensagem é um <input>, <output> ou <fault>.

Existem algumas API’s para Web Service que implementam este padrão (Apache CFX, JBOSS Native, Apache Axis 2 entre outros). Você deve está ser perguntando: por que eu preciso deste padrão? Simples, ele é base para outros padrões que veremos a seguir. Vou ficando por aqui, até a próxima pessoal.

Related posts:

1. Davi x Golias em SOA
2. Princípios Básicos de SOA – Serviços são Capazes de se Compor
3. Referências para SOA [1]

O WSDL descreve a interface do serviço de forma estruturada e padronizada usando XML. É importante entender que diferentemente das linguagens de definição de interfaces – IDL anteriores (Corba, COM), o WSDL envolve duas partes diferentes: abstrata e concreta. A parte abstrata descreve a interface do serviço propriamente dita, ou seja, descreve como o serviço pode ser invocado por seus clientes. A interface de um serviço pode ser descrita através das operações e dos parâmetros de ida e volta. Muito similar ao um método de classe Java, por exemplo: int registrarPedidoCompra(Pedido pPedido). Inclusive existem anotações no Java e .Net que permitem fazer um mapeamento automático para elementos do WSDL. Já a parte concreta define o protocolo e o endereço onde o serviço estará disponibilizado. Observe que esta separação é proposital, pois um mesmo serviço pode ser disponibilizado através de endereços e protocolos diferentes.

Estrutura do WSDL

Vamos agora destrinchar cada parte do WSDL. Para exemplificar vamos pensar num serviço de registro de pedido de compra que recebe com parâmetro uma entidade “Pedido” e retorna um “id” (inteiro) do pedido registrado:

Types: permite especificar os tipos que serão trocados nas mensagens de ida e volta do serviço. Permite usar XML Schema para definir as estruturas de dados. No nosso exemplo, a entidade “Pedido” e o tipo inteiro seriam definidos aqui.

Message: permite descrever as mensagens que são trocadas entre o serviço e o consumidor do serviço. Uma mensagem pode possuir várias partes, sendo que cada parte possui um nome e um tipo de dados. No nosso exemplo, são definidas duas mensagens, a primeira, é usada para fazer a requisição do serviço e possui uma parte apenas (nome: pPedido, tipo: Pedido). A segunda, define a resposta do serviço e também possui somente uma parte que define do tipo de retorno (nome: qualquer um, tipo: int).

PortType: define um conjunto de operações suportadas pelo serviço e que possuem uma relação entre si. Baseado nesta definição você deve está imaginando qual é a estrutura que agrupa as operações no mundo orientado a objeto? A resposta é Classe! É ela mesmo. Assim como classe possui operações, portType também possui. Cada operação dentro do portType possui elementos do tipo Message. No nosso exemplo, o portType poderia ter um nome sugestivo como “PedidoPortType” e dentro dele a operação “registrarPedidoCompra”.

Uma coisa que eu sempre me perguntei, por que os caras que especificaram o WSDL deram este nome. Não teria um nomezinho melhor pra dar não? O nome “Classe” também acho que não seria adequado, pois o WSDL tem propósitos de absorver linguagens que não são orientadas a objetos. Enfim, a conclusão que tirei é que eles mandaram mal e resolveram corrigir este erro na versão 2.0 do WSDL. A propósito, a versão 2.0 do WSDL ainda não pegou, por isso não estou falando dela neste blog. Mas para matar a curiosidade o termo PorType foi alterado para Interface.

Binding: provê detalhes de como as mensagens serão transmitidas. Por exemplo, o protocolo que irá carregar a mensagem do serviço até seu consumidor e vice e versa. Apesar de parecer intuitivo usar SOAP, o WSDL não fixa o uso deste protocolo. Inclusive podem ser usados outros protocolos como o HTTP e o SMTP puros. Pra falar a verdade, nunca utilizei um serviço que não fosse com SOAP. Inclusive, se alguém tiver tido esta experiência e quiser compartilhar com a gente agradeço.

Service e ports: por fim, os últimos elementos especificam a localização (endereço URL ou email) onde o serviço está disponível e o encoding utilizado, respectivamente. Encoding é um tema que merece um artigo só pra ele. Mas podemos resumir que o encoding define como que uma estrutura de dados é representada em XML, ou seja, dado um objeto na memória (ex: Pedido) como que ele é mapeado para XML e dado um XML como que ele é mapeado para um objeto na memória.

Bom pessoal, por enquanto é só. “Me lembrei daqueles desenhos antigos do pernalonga que falava por enquanto é só pessoal”. Nas próximas publicações vou detalhar cada parte apresentada aqui. Por favor, deixe seu comentário, sugestões, opiniões e críticas.

Related posts:

1. Boas Festas
2. Princípios Básicos de SOA – Serviços são Capazes de se Compor

Como eu já tive esta mesma necessidade em outros projetos não tive dúvida e abri a caixa de ferramentas para pegar o soapUI.

O soapUI é uma ferramenta desktop mantida pela eviware e específica para teste em Web Services.

As características interessantes do soapUI são:

• Open source. Também há uma versão Pro comercial com features adicionais, mas até hoje a versão open source me atendeu perfeitamente.
• Inspeção
• Invocação
• Simulação e Mocking
• Testes de carga, funcionais e de conformidade com alguns padrões.
• Independente de plataforma
• Fácil de usar e boa documentação

Além disso, permite execuções via linha de comando, desta forma por exemplo, testes funcionais ou de carga de Web Services podem ser incorporados em um processo de integração contínua (servidor de build) durante o desenvolvimentos dos seus serviços.

Também existem plug-ins para IDE’s como: Eclipse, IntelliJ IDEA, NetBeans.

Site oficial: www.soapui.org

- Fábio Rosato

Related posts:

1. Davi x Golias em SOA
2. Princípios Básicos de SOA – Serviços são Capazes de se Compor
3. Grandes Volumes de Dados sem um Banco Relacional

SOAP é o protocolo de troca de mensagens usado pelos Web Services. Ele define um modelo de processamento, onde existem sempre dois papeis: initial sender e ultimate receiver. O initial sender é responsável pela criação e envio da mensagem SOAP, já e o ultimate receiver é o destinatário final da mensagem, ou seja, o responsável por ler e processar o conteúdo da mensagem. Existe também um terceiro papel opcional chamado intermediary node que, como o nome já sugere, é um nó intermediário que recebe e reenvia a mensagem para o ultimate receiver ou para outro intermediary node. Geralmente, estes nós intermediários tem a função de acrescentar algum valor no caminho de processamento da mensagem. Pode ser usado, por exemplo, para logging, autenticação, autorização e outros.

Para que este modelo de processamento possa ser implementado. A especificação SOAP define um formato padrão para suas mensagens chamado de SOAP envelope. Os envelopes são definidos no formato XML e iniciam com a tag (env:Envelope). Cada envelope possui um cabeçalho e um corpo. Ambos podendo conter um conjunto de sub-elementos livres de padronização, isto é, blocos de elementos XML  baseado em seus próprios XML Schema. O SOAP header estabelece um espaço para adicionar metadados ao conteúdo da mensagem sem influenciar no seu processamento. O SOAP header pode ser processado e modificado por nós intermediários permitindo assim uma flexibilidade horizontal do protocolo. Aqui surgem algumas questões. Como saber quais elementos XML deverão ser lidos e processados por cada nó intermediário? Para isso, a especificação SOAP define o atributo role que deverá conter a identificação do nó intermediário responsável por processar o trecho. A figura abaixo mostra uma mensagem SOAP contendo header e body. O header contém três blocos. O primeiro bloco (p:oneBlock) deverá ser lido pelo nó intermediário que responda pela identificação http://example.com/Log, o segundo bloco (q:anotherBlock) será processado pelo próximo nó no caminho da mensagem, e o último bloco (r:aThirdBlock) será processado pelo ultimate receiver da mensagem.

O modelo de processamento SOAP define as ações que são tomadas quando um SOAP node recebe uma mensagem SOAP. A especificação SOAP 1.2 esclarece como este processamento deve ser realizado:

1. Determina os roles que o SOAP node desempenha verificando o atributo role de todos os blocos do header do envelope
2. Identifica os blocos assinalados como obrigatórios verificando se contém o atributo mustUnderstand=”1” e o atributo role igual a um dos roles identificados no passo anterior
3. Gera uma falha MustUnderstand se um ou mais blocos identificados no passo anterior não puder ser processado pelo SOAP node, ou seja, não for compreensível
4. Processa o header e se o nó é um ultimate receiver processa o body da mensagem também
5. Se o nó estiver atuando como intermediary node, então remove o bloco XML do header e passa a mensagem adiante

Observe que quando um intermediary node processa a mensagem ele retirar o bloco processado do header da mensagem e passa a mensagem adiante. Portanto, os intermediary nodes tem permissão para alterar o header da mensagem, embora não possam processar o body. Isso pode parecer estranho, mas este é um dos pontos que traz grande flexibilidade ao protocolo SOAP. Um intermediary node além de retirar o bloco processado pode adicionar outros blocos no header e de certa forma interferir no caminho da mensagem. Podemos concluir que o protocolo SOAP é bastante robusto e permite pontos de flexibilidade. Para maiores informações consulte a especificação SOAP 1.2 publicada no site do W3C. Deixe seu comentário e até a próxima pessoal.

XFire é uma API para WebServices, ou um “SOAP Framework”, que facilita a Abordagem de Desenvovimento Orientado a Serviços (fazendo, por exemplo, as tarefas chatas de empacotamento do SOAP, geração automática de código Java <-> WSDL <-> XML <-> SOAP …, monitoramento de pacotes, dentre outros…). Muitos arquitetos e desenvolvedores que conheço estão o utilizando em detrimento do Axis, sob argumentos de ser mais moderno e mais fácil de utilizar. Acho que vale uma conferida.

Em tempo, este cara não se chama mais XFire, e sim CFX ( veja site antigo e site novo), e está sob a tutela da Apache (também dona do Axis )

“CXF includes a broad feature set, but it is primarily focused on the following areas:

– Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.

– Frontends: CXF supports a variety of “frontend” programming models. CXF implements the JAX-WS APIs (version 2.0 will be TCK compliant). It also includes a “simple frontend” which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.

– Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.

– Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.”

Veja o site oficial: http://cxf.apache.org/

Abraços,
Marcilio

Related posts:

1. Como aumentar as chances de sucesso na Nuvem
2. Gartner Enterprise Technologies Summit 2010
3. Davi x Golias em SOA

(por Kleber Bacili)

O assunto SOA está de fato em voga. Muito popular também é a implementação desse conceito usando Web Services. Muitas empresas estão desenvolvendo serviços web principalmente para integrar aplicações, normalmente desenvolvidas em plataformas diferentes. Embora essa seja uma das principais características dos Web Services, as empresas precisam ter cuidado em alguns aspectos relacionados a essa estratégia: a) mundo de conexões ponto-a-ponto; b) problemas com interoperabilidade.

Sobre o item “a”, cabe um texto específico no futuro mas, de forma geral, com o desenvolvimento de Web Services integrando as aplicações, embora essa seja uma boa estratégia no início, corre-se o risco, no médio prazo, de ter um número alto de serviços conectando aplicações (ponto-a-ponto), gerando muita dificuldade para se entender, manter e evoluir. As empresas estão atacando esse problema com a utilização de um middleware de mensageria, tipicamente um ESB (Enterprise Service Bus).

Sobre o item “b”, que é o foco desse Tech in Depth, gostaria de atacar alguns aspectos importantes. É bastante comum vermos a questão da interoperabilidade, ou seja, escrever um serviço web usando, por exemplo, Java e um cliente desse serviço (como em VB.NET), como uma forma de se resolver os problemas de integração entre aplicações desenvolvidas em plataformas diferentes. Bom, a estratégia é boa, mas alguns pontos precisam ser observados. Existem diversos protocolos relacionados a Web Services que nem sempre são totalmente compatíveis. Isso certamente causa dificuldades para integração via Web Services e diversos problemas de interoperabilidade. Foi criado inclusive uma organização chamada WS-I (Web Services Interoperability) composta por cerca de 130 empresas com o objetivo de integrar esses protocolos e oferecer guias, boas práticas, exemplos e ferramentas para garantia de interoperabilidade no uso de Web Services.

Para exemplificar essa questão, podemos citar as estruturas ADO e DataSet da plataforma Microsoft. Embora sejam muito utilizadas, elas não devem estar presentes nas interfaces dos serviços web, pois a engine SOAP da Microsoft não consegue fazê-la seriada de uma forma padronizada que possa ser “compreendida” por um cliente do serviço escrito em plataforma JEE, por exemplo. Certamente um problema! Ainda existem diversos outros aspectos problemáticos da interoperabilidade, como controle de transações distribuídas, utilização de attachments nas mensagens, entre outros.

A recomendação é que sejam usados os recursos da WS-I para se tentar garantir a interoperabilidade dos Web Services. Alguns deliverables importantes da WS-I são o Basic Profile e o Security Basic Profile. Procure usar as construções de XML Schema mais básicas e a forma de comunicação Document/Literal (ao invés do RPC/encoded). Seguindo essas recomendações, certamente algumas dores de cabeça poderão ser evitadas. Até a próxima!

Related posts:

1. Referências para SOA [1]
2. Davi x Golias em SOA
3. Gartner Enterprise Technologies Summit 2010