Maratona JBoss 2010 - JBossWS

  • 1,921 views
Uploaded on

Maratona JBoss 2010: …

Maratona JBoss 2010:
Apresentação do JBossWS e seus recursos, no desenvolvimento e integração de aplicações instaladas no JBoss Application Server utilizando a tecnologia Web Services

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,921
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. WebServices com JBossWS Alexandre A. L. Costa 24/09/2010 d Fábrica de Software Sistemas e aplicações sob medida para as necessidades do seu negócio.
  • 2. Agenda Contextualização: O modelo SOA WebServices JBossWS - Conceitos JBossWS - Arquitetura Utilizando JBossWS: Publicando WebServices Criando Clientes Utilizando Handlers Acrescentando Segurança
  • 3. O modelo SOA A SOA (Service Oriented Archtecture) é um modelo de arquitetura/design de aplicações. A SOA é voltada para as regras/processos de negócio. O design é definido de forma semântica/lógica Na SOA o sistema é dividido em processos/operações de objetivos bem definidos.
  • 4. O modelo SOA Como um modelo semântico, a SOA é independente de plataforma tecnológica. Os processos são criados com objetivos e contratos bem definidos. Não é importante como as operações serão executadas desde que atendam ao contrato definido. Devido aos contratos, os serviços podem ser implementados em diferentes plataformas tecnológicas sem prejuízo à semantica do sistema.
  • 5. O modelo SOA Devido ao seu foco semântico e independência de plataforma tecnológica a SOA é uma opção ideal para: Modelagem de sistemas orientados processo. Integração entre sistemas em diferentes plataformas. Projeto de sistemas heterogênios e de grande porte.
  • 6. WebServices SOA é um conceito, com várias implementações possíveis. A tecnologia WebServices tem características que a qualificam como uma possível implementação de SOA. Características da SOA nos WebServices: Contrato semântico bem definido, em linguagem neutra (através do WSDL) Parâmetros definidos em uma linguagem neutra e multi-plataforma (arquivos texto estruturados – XML) Localização de serviços independente de plataforma.
  • 7. WebServices Visão Conceitual Catálogo Busca Publica Serviço Serviço Invocação Serviço Cliente Provedor
  • 8. WebServices Visão Conceitual Comunicação Independente de Plataforma E P n r d o Port P Client x o Service Impl y i Impl n t Comunicação Nativa
  • 9. JBossWS O JBossWS é um framework para definição, publicação e consumo de WebServices Implementa os conceitos básicos e necessidades de middleware para WebServices Abstraí a implementação das camadas de infra-estrutura necessárias a troca de informação entre cliente e servidor. Segue a especificação Java EE 5 para WebServcies e já vem instalado no JBoss Application Server Vem sendo desenvolvido pelo JBoss Group nos últimos anos
  • 10. Conceitos – End Point x Serviço End Point: Representação (abstração) do serviço disponibilizado via WebService. Definido por interfaces (fachadas) de serviço, com anotações específicas do padrão JAX-WS Em tempo de deployment o JBossWS prove a implementação do End Point automaticamente. Serviço: Implementação da regra de negócio atendendo o contrato. É a materialização do End Point a quem o container irá delegar a execução após o tratamento da infra- estrutura.
  • 11. Conceitos - Invocações São as chamadas de um cliente a um método (serviço) do End Point. As invocações podem trafegar informações (parametros / resultados) de duas maneiras distintas. Document : Focada na estrutura do contrato (WSDL) RPC (Remote Procedure Call): Focada na semântica de serviço
  • 12. Conceitos - Invocações Características do Document Cada elemento na mensagem são definida por um tipo complexo no XML Schema (XSD) Document/Bare: Utiliza um único JavaBean (anotado com JAXB) para representar todo o payload da mensagem. Document/Wrapped: Utiliza payloads específicos para cada elemento mensagem.
  • 13. Conceitos - Invocações Características do RPC Cara serviço definido no WSDL representa uma operação Os parâmetros são definidos como partes da mensagem Deve ser utilizado no modelo Literal
  • 14. Conceitos - Handlers Filtros utilizados para manipular as mensagens antes que sejam enviadas ou recebidas pelos EndPoints. Funcionam, conceitualmente, de maneira similar aos filtros HTTP ou interceptadores EJB Sua principal função é o tratamento de middleware necessários aos WebServices. Também pode ser utilizados para agregar funcionalidade cross-cut aos WebServices sem alterar o serviço em si.
  • 15. Conceitos - WS-Extensions As WS-Extensions, são padrões (ou políticas) definidos para o tratamento infra-estrutura declarativa para WebServices. O padrão WebServices é declarativo e voltado para integração entre plataformas. As necessidades de middleware são definidas declarativamente para que cada plataforma proveja sua implementação. No JBossWS essas políticas são tratadas como parte da infra-estrutura do servidor de aplicação.
  • 16. Conceitos - WS-Extensions WS-Addressing: Padrão para utilização de serviços stateful WS-Eventing: Padrão para comportamento assíncrono nos serviços WS-Security: Descrição de segurança da lógica mensagem WS-Reliable Message: Definições para a garantia de entrega das mensagens. WS-Transaction: Descrição de serviços transacionais WS-Policy: Descrição de políticas (reaproveitáveis) para uso de serviços. Essas políticas podem definir um ou mais dos comportamento acima. XML Registry: Descrição de publicação do WebService através de UDDI
  • 17. Arquitetura
  • 18. Arquitetura - Stacks JbossWS-Native: Implementação do JbossWS da especificação JAX-WS Glassfish-Metro: Implementação de referência para WebServices na plataforma Java EE 5. Apache-CXF: Framework para o criação/publicação/consumo de WebServices. Muito maduro, vem sendo desenvolvido desde antes da especificação Java EE 5 para WebServices.
  • 19. Publicando Serviços EJB EJBs do tipo Stateless Session Bean podem ser publicados, também, como WebServices. O WebService publicado é uma interface de invocação adicional para o componente. Substitui a invocação RMI pela chamada WebService A interface EndPoint faz as vezes da interface remota A implementação do EndPoint provida pelo container faz as vezes do EJBObject.
  • 20. Publicando Serviços EJB Para transformar um EJB num WebService basta marcá-lo com annotations da API JAX-WS. A interface (EndPoint) e a implementação do EJB devem ser anotadas como @WebService O métodos que serão acessíveis através do WebService devem estar marcados com @WebMethod
  • 21. Publicando Serviços EJB Em tempo de deployment: O JBossWS identifica as anotações e gera o WSDL, os EndPoints e publica o WebService. O JBossWS utiliza um conjunto de valores padrão (conforme a API JAX-WS) para gerar o WSDL. Os valores, nomes e parâmetros do WSDL podem ser customizados através de parametrização das annotations como no exemplo:
  • 22. Publicando Serviços EJB Definição do EndPoint (Interface Remota) @Remote @WebService @SOAPBinding public interface AccountServiceEndpoint { ... @WebMethod @WebResult public MovimentBean[] findMoviments( @WebParam String accountNumber, @WebParam Date beginDate, @WebParam Date endDate) { ... } ... }
  • 23. Publicando Serviços EJB Implementação do EJB @Stateless @WebService(name = "ManterContas", serviceName = "ManterContas", portName = "ManterContasPort", targetNamespace = "tns:cursows") @SOAPBinding(style = Style.DOCUMENT, use = Use.LITERAL, parameterStyle = ParameterStyle.WRAPPED) public class AccountServiceBean implements AccountServiceEndpoint { @WebMethod(operationName="ListarMovimentos") @WebResult(name = "resultado") public MovimentBean[] findMoviments( @WebParam(name = "conta") String accountNumber, @WebParam(name = "dataInicial") Date beginDate, @WebParam(name = "dataFinal") Date endDate) { ... } ...
  • 24. Publicando Serviços POJO O JBossWS permite também publicação de WebServices POJO (não EJB). Para que uma classe POJO seja um WebService ela deve estar: Marcada com as mesmas annotations JAX-WS Configurada no arquivo web.xml como se fosse uma Servlet neste caso o EndPoint será implementado como uma Servlet
  • 25. Publicando Serviços POJO Configurando um serviço POJO <web-app> ... <servlet>       <servlet-name>ExampleWSPojo</servlet-name>       <servlet-class>dextra.curso.ExampleWSPojo</servlet-class>     </servlet>     <servlet-mapping>       <servlet-name>ExampleWSPojo</servlet-name>       <url-pattern>/*</url-pattern>     </servlet-mapping> ... </web-app>
  • 26. Consumindo WebServices O JbossWS disponibiliza um utilitário utilizado para consumir WebServices. O WSConsumer é utilizado para: A criação de consumidores (clientes) de WebServices publicados a partir de seu WSDL. Cria classes para abstração do serviço e comunicação Cria classes auxiliares para e representações dos objetos passados como parâmetro (já com mapeamento JAXB). Cria exceções e classes representando as exceções necessárias.
  • 27. Consumindo WebServices O JBossWS trás o WSConsumer em duas versões, uma para execução em “linha de comando” e outra como uma “task ant”. Ambas são encontradas em $JBOSS_HOME/client/jbossws- spi.jar O código gerado é relativamente “limpo” e pode ser utilizado diretamente, salvo por alguns casos.
  • 28. Consumindo WebServices EJBs também podem ser clientes (consumidores) de WebServices. Isso é feito através da anotação @WebServiceRef, que funciona de maneira similar a anotação @EJB Isso torna o container EJB responsável por prover (injetar) um proxy para o consumo de determinado WebService.
  • 29. Utilizando Handlers Handlers funcionam de maneira parecida aos filtros HTTP, são executados antes do WebService propriamente dito Podem atuar como observadores ou “agentes” no fluxo da invocação, alterando dados ou mesmo impedindo a conclusão da invocação Handlers podem ser configurados tanto no lado servidor como cliente.
  • 30. Serverside Handlers São executados antes que a requisição chegue efetivamente ao WebService São adicionados, pelo container, às invocações feitas ao WebService São definidos declarativamente em um arquivo XML Na classes de implementação do WebService o arquivo XML é associado através da annotation @HandlerChain
  • 31. Serverside Handlers <handler-chains xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee"> <handler-chain> <handler> <handler-name>DecompressHandler</handler-name> <handler-class> dextra.curso.ws.DecompressHandler </handler-class> </handler> <handler> <handler-name>AuditHandler</handler-name> <handler-class> dextra.curso.ws.AuditHandler </handler-class> </handler> ... </handler-chain> </handler-chains>
  • 32. Clientside Handlers São executados antes a mensagem SOAP seja enviada ao servidor. Também é possível adicionar um HandlerChain no lado cliente. Diferente dos handlers serverside, que são definidos via annotation, os handlers clientside são definidos de forma programática. Os handlers são adicionados diretamente ao WebServicePort do proxy.
  • 33. Clientside Handlers Configurando clientside Handlers @WebEndPoint(name = "ExampleWSPort") public ExampleWS getExampleWSPort() { ExampleWS port = Service.getPort( new QName("tns:curso", "ExampleWSPort"), ExampleWS.class); BindingProvider bindingProvider = (BindingProvider) port; List<Handler> handlerChain = new ArrayList<Handler>(); handlerChain.add(new ClientHandler()); handlerChain.add(new CompressHandler()); bindingProvider.getBinding().setHandlerChain(handlerChain); return port; }
  • 34. Acrescentando Segurança O JBossWS utiliza o padrão JAAS para prover o controle de acesso aos WebServices publicados. O JBossWS se integra ao JBoss utilizando os serviços de segurança providos pelo container. Podem ser utilizados quaisquer LoginModules (e seus contextos) configurados no servidor Para definir a que contexto de segurança estará associado associados os WebServices basta utilizar a anotação @org.jboss.ejb3.annotation.SecurityDomainSecurityDoma in
  • 35. Autorização com JAAS Após definir o contexto de segurança utilizado pelo WebService é possível determinar os perfis (roles) com acesso aos métodos Os serviços e/ou métodos podem ser marcados com annotations padrão do pacote javax.annotation.security da mesma maneira que um EJB @Stateless @WebService @SecurityDomain("curso-ws") public class ExampleWSBean implements ExampleWSEndpoint { @WebMethod @OneWay @RolesAllowed("admin") public void sayHello(@WebParam String name) { System.out.println(“Hello ” + name); } }
  • 36. Autenticação com JAAS A cada invocação a credencial do cliente é enviada ao servidor. A forma de autenticação a ser utilizada é definida na annotation org.jboss.wsf.spi.annotation.WebContext pelo atributo authMethod O JBossWS aceita dois tipos de credencias: BASIC: Autenticação via Username/Password (token) CLIENT-CERT: Autenticação via certificado digital O JBossWS se integra ao contexto de segurança não necessitando de outras no serverside.
  • 37. Autenticação BASIC (Clientside) Os atributos USERNAME e PASSWORD são passados diretamente ao proxy que representa o WebService (BindingProvider) . O token é acrescentado diretamente aos parâmetros da requisição HTTP e enviado na mensagem. @WebEndpoint(name = "ExampleWSPort") public ExampleWS getExampleWSPort() { ExampleWS port = super.getPort( new QName("tns:curso", "ExampleWSPort"), ExampleWS.class); BindingProvider bindingProvider = (BindingProvider) port; bindingProvider.getRequestContext().put( BindingProvider.USERNAME_PROPERTY, "user"); bindingProvider.getRequestContext().put( BindingProvider.PASSWORD_PROPERTY, "pswd"); return port; }
  • 38. Autenticação CLIENT-CERT Funciona de maneira similar à autenticação por token, entretanto ao invés de usuário e senha o cliente passa seu certificado digital. Deve estar configurado no ambiente de execução do cliente as seguintes variáveis: org.jboss.ws.wsse.keyStore org.jboss.ws.wsse.keyStorePassword org.jboss.ws.wsse.keyStoreType org.jboss.ws.wsse.trustStore org.jboss.ws.wsse.trustStorePassword org.jboss.ws.wsse.trustStoreType
  • 39. Acrescentando Segurança Autenticação CLIENT-CERT (Clientside) Funciona de maneira similar à autenticação por token, entretanto ao invés de usuário e senha o cliente passa seu certificado digital. Deve estar configurado no ambiente de execução do cliente as seguintes variáveis: org.jboss.ws.wsse.keyStore org.jboss.ws.wsse.keyStorePassword org.jboss.ws.wsse.keyStoreType org.jboss.ws.wsse.trustStore org.jboss.ws.wsse.trustStorePassword org.jboss.ws.wsse.trustStoreType
  • 40. Conclusão O JBossWS apresenta hoje as características de um framework maduro e estável: Compatibilidade com a arquitetura Java EE 5 Integração “nativa” à infraestrutura do servidor JBoss Simplicidade de desenvolvimento através de annotaitions Ferramentas de desenvolvimento, como o WSConsumer Versatilidade pela integração com outras stacks através de contrato único Segurança e estabilidade dos serviços Boa documentação
  • 41. Dúvidas ? www.dextra.com.br contato@dextra-sw.com (11) 2824-6722 (19) 3256-6722