Este documento fornece uma introdução aos WebServices com JBossWS, abordando conceitos como SOA, WebServices, arquitetura do JBossWS, publicação e consumo de serviços EJB e POJO, utilização de handlers e segurança com JAAS e autenticação.

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