quarta-feira, 13 de abril de 2011

CRIANDO E PUBLICANDO UM SERVIÇO – ORACLE SERVICE BUS

Considerações.
Um projeto básico pode ser criado utilizando apenas os seguintes recursos.
1 – Adapter
 Nesta pasta, ficam os arquivos (mais relevantes):
Arquivo.jca : referente as configurações dos adapters (criados pelo JDEV).
Arquivo.jpr: referente a composite (design dos adapters – melhor visualizado no JDEV)
Arquivo.wsdl: Como todos adapters são web services, este é o referente ao adapter criado.
XSD/arquivo.xsd – Arquivo xsd referente ao web service criado.
2 - Business service
Esta pasta é referente aos serviços de negócios do projeto OSB. O serviço deve (poderá) ser apontado a um serviço: WebService, mensagem, serviço XML ou serviço soap.
É neste serviço que são definidos as configurações de políticas, configurações de transport (se serão jca (acesso a um banco de dados), wsdl (acesso a um WebService) ) é neste momento que o protocolo de transporte de dados é definido.
3 -  Proxy service
O proxy service sera nossa porta de entrada ao barramento (service publicado).
Aqui definimos o fluxo de mensagens ou seja, qual caminho a mensagem deverá percorrer para que a requisição seja aceita.
O Proxy deve ser apontado há um tipo de serviço (web service, soap, mensagem XML ou serviço SOAP).
Um tipo de transporte deverá ser definido (HTTP, JCA, JMS, etc).
As configurações de segurança podem ser definidas( nenhuma, usuário/senha ou token).
4 – WSDL
Nesta pasta ficarão alojados os WebService e seus respectivos XSD.
É possível alterar configurações dos WebService (criar operações, elementos, etc).
Estrutura de Pastas:

É possível criar o projeto de duas formas:
1-      Utilizando o JDEV/Eclipse (Plugin Oepe), weblogic console.
2-      Utilizando Oracle Service Bus e weblogic console. (pouco produtivo)

Criando à partir do Item 1.
Primeiro vamos criar uma nova aplicação no JDEV.

Note que o Diretório está selecionado, este mesmo será usado posteriormente.

No próximo passo, selecione composite template: Empty Composite. Clique em Finish.
A seguinte estrutura será montada:

O próximo passo será criar acesso a base de dados através do Database Adapter. Como já mencionado anteriormente, todo adapter criado é automaticamente “transformado” em um WebService.
Na paleta de componentes clique sobre Database Adapter e arraste até External references.


Clique em Next.

Note que o service name está selecionado, o wsdl utilizará este nome (PessoaService.wsdl)



Casa ainda não tenha uma conexão criada, estou exibindo uma forma de criar.
Note: O JNDI-NAME, será usado no weblogic console, o mesmo nome utilizado aqui será o Nome da nossa conexão lá.
Clique em next.

Neste passo, vamos selecionar o tipo de operação que iremos fazer. No nosso caso vamos utilizar apenas no Select.
Clique em next.



Agora vamos importar a tabela utilizada em nossa POC (prova de conceito).
Note: Selecione o schema que sua tabela foi criada e clique no botão Query. Não é necessário alterar o filtro da consulta (%).
Após selecionada, clique e Ok e Next.

Como estamos utilizando apenas uma tabela, no próximo passo é só clicar em NEXT.
Note: Caso tenha a necessidade criar relacionamentos, basta selecionar mais de uma tabela no passo anterior,  e clicar em Create neste passo, uma tela para configurar os relacionamentos será exibida.

Neste passo, serão exibidos os campos das tabelas que foram selecionadas No nosso caso, vamos deixar todos selecionados.
Clicar em Next.


Neste passo será configurada a consulta que será realizada no BD. Vamos criar uma consulta com um filtro, onde o usuário deverá informar a pessoa que será pesquisada, pelo ID.
Após configurar a consulta, clicar em Next.


As próximas configurações não serão utilizadas em nossa POC, então é NEXT, NEXT e FINISH (rs).
O adapter foi criado e configurado. Conforme mencionado anteriormente, todo adapter “vira” um WebService, e na imagem a seguir estou demonstrando.

Salve o projeto.
Como neste passo estamos utilizando o JDeveloper, eclipse, weblogic console, vamos agora para o Eclipse e criar o nosso projeto OSB.
Note: um detalhe importante neste passo, é não esquecer de apontar o workspace para o mesmo local onde o projeto do JDEV foi criado.


Definir o nome do projeto OSB e uma OSB Configuration (caso ainda não exista).


Como apontamos o workspace no eclipse para o mesmo local onde foi criado o projeto no JDEV, os arquivos gerados no JDEV serão exibidos no eclipse.

Errata: A pasta do adapter era para ser criada anteriormente e o projeto criado dentro do JDEV ser apontado para esta, como pulei essa etapa, crie uma Folder (pasta) no eclipse e Mova todo o conteúdo para dentro desta:


Pronto, agora estamos indo pelo  caminho correto.
Crie mais 3 pastas no projeto: WSDL, PROXY-SERVICE e BUSINESS-SERVICE



Como dito anteriormente, precisamos de um serviço de Proxy, então vamos criar à partir PessoaService_db.jca.
Clique com o botão direito sobre este arquivo -> Oracle service Bus -> generate service.
Altere o nome como demostrado na figura abaixo.
A pasta de destino deverá ser a business-service.


O próximo passo é importar o WSDL para a pasta WSDL.
Vamos até o diretório onde o projeto foi criado e vamos copiar o PessoaService.wsdl e a pasta XSD para  c:\ws
Logo após a copia, vamos importar o arquivo e diretório.

Agora vamos criar um serviço de Proxy.



 Agora temos um Proxy service criado, no entanto precisamos de configurá-lo.
Dê um duplo clique sobre o Pessoaservice.proxy, as informações serão exibidas.
Na aba General, selecione o Service Type WSDL Web Service e clique em Browser. Navegue até a pasta WSDL, expanda o Pessoaservice.wsdl e selecione a opção PessoaService_pptSOAP11Binding.


Navegue até a aba Message Flow. Note que só tem o nó PessoaService.
Vamos criar um fluxo para mensagens com caminhos roteados.
1-      Add um route
2-      Add um rouding
3-      Clicar sobre o Routing, e configurar o service.
4-      Clicar em browser->selecionar business-service->selecionar o PessoaService.biz
No final, o fluxo deverá ficar conforme a imagem demonstrada.

Pronto, nosso projeto está configurado e pronto para ser Exportado para OSB.
Mas antes precisamos de configurar a conexão com o BD no Console do WebLogic. Estes passos não serei tão detalhista.
Logue no console do weblogic com o usuário administrador.
Primeiro temos que criar a Origem de Dados.
Clique em Novo-> Origem de dados genérica.


Preencha as informações:
Nome: pessoaservice
Nome da JNDI: jdbc/pessoaservice
Clique em próximo. Os próximos valores você já configurou no JDEV, são referentes a conexão com BD.

Nos detalhes da conexão criada, informe na aba ALVOS que é para publicar no SOA_SERVER.
Na estrutura de domínio (lado esquerdo da tela), clique e implantações.
Uma listagem de implantações será exibida. Navegue nesta listagem até encontrar o DBAdapter.
Clique sobre o Dbadapter-> Selecione a aba Configuração -> selecione a aba Pools de conexão de saída-> Clique em Novo
Note que já tenho alguns criados.

Selecione o grupo e conexão de saída (javax.resource.cci.ConnectionFactory).
Informe o nome da jndi, observe que este nome foi usado no JDEV.

Clique e salvar.
A listagem será exibida novamente, selecione o que foi criado.
Edite o valor da propriedade do data source name para: jdbc/pessoaservice

Bom a configuração está criada, agora temos que salvar e pedir para Atualizar o DBAdapter, pois o plano de implantação precisa de ser atualizado.
Obs.: não esqueça de Ativar as alterações.
Agora vamos gerar o Projeto OSB do Eclipse e publicarmos no OSB.

Salve o Jar em um local de sua preferência.


Clique em Finish.
Vamos até a interface do OSB para publicarmos o projeto.
Clique e Confguração de segurança ->importar recursos-> selecionar o jar criado.

No próximo passo, os arquivos serão exibidos, verifique se todos estão selecionados e clique em Importar.


Pronto o projeto foi instalado, agora podemos testar se está funcionando.
Ainda na interface da OSB, vamos testar nossos serviços.
Clique em Project Explorer -> Expanda o projeto Projeto_Final_OSB -> Clique em Proxy-service
Em ações clique Acionar Console de teste.

O console  abrirá.
Edite a seguinte linha:  De string Para:  1
Clique e Executar.


O resultado deverá ser parecido com este.


Pronto, serviço funcionado!

quarta-feira, 6 de abril de 2011

Estudo realizado sobre OSB - Oracle Service Bus

Estudo OSB
·         A oracle possui uma suite de produtos que pode ser compartilhada via OSB.
1)      Oracle User Interaction
2)      Oracle BPM
3)      Oracle Data Service Integrator



O ciclo de vida do OSB pode ser visto como:
1)      Pesquisa por serviços, utilizando o console OSB
2)      Implementação do serviço proxy
3)      Implementação de orquestração de serviços utilizando os fluxos definidos nos serviços de proxy.
4)      Implementação de transformação para tornar a comunicação de provedor-consumidor menso dependente.
5)      Definições de roteamento de serviços
6)      Testes de serviços e orquestrações dentro do console do OSB



Principais características OSB.
1)      Integração de serviços
- endpoints, broker de mensagens e reuso de serviços
2)      Segurança de serviços
- autenticação, validação de usuário, etc
3)      Composição de serviços
- logica de roteamento de mensagem, transformação de mensagem
4)      Gestão de serviços
- Monitoramento e gestão das atividades

Arquitetura de Componentes OSB.

1)      Service management
- Gestão de mensagem que trafegam no barramento.
2)      Mediation
- descoberta de serviços UDDI, testes de orquestração, especificação de service callout(INVOCA DETERMINADO SERVIÇO DE ACORDO COM O CONTEUDO DA MENSAGEM)
3)      Adaptive Messaging
- HTTP/SOAP, EJB RMI no WEBSPHERE, Protocolos nativos da oracle (oracle data service integrator), WS-I, WS-SECURITY, WS-POLICY, WS-ADRESSING
4)      Security
- segurança no transporte de mensagem(SSL), segurança na mensagem(WS-POLICY), segurança no console(single-sign-on), políticas(WS-SECURITY)

MENSAGENS VIA SERVIÇO DE PROXY.
Uma mensagem é enviada de por cliente via HTTP, JMS, ARQUIVO OU FTP, essa mensagem chega até o OSB para o processamento, após o processamento o OSB invoca uma chamada ao serviço solicitado com o mesmo protocolo de recebimento da mensagem, o serviço recebe e processa a mensagem e retorna ao OSB (sempre utilizando o mesmo protocolo)  e este responde ao cliente que solicitou.
É importante ressaltar que o conceito de proxy é fundamental na arquitetura OSB. É uma interface que os consumidores uitilizam. São definições de web services que o OSB implementa localmente.
O contexto de um serviço de proxy é um conjunto de variáveis XML, essas variaveis podem conter informações sobre a Mensagem, segurança, cabeçalhos etc. Este contexto pode ser lido ou modificado por XQUERY.
As principais variaveis de contexto são: $header(soap), $body(soap) $attachments.
Um serviço de proxy pode ser configurado independente do serviço de negocio ao qual ele se comunica.



Existem alguns tipos de trocas de mensagens no OSB.
Sincrona: envia e espera uma resposta
1pra1 Assincrona: O serviço envia uma resposta para o cliente publicado
 1praN assincrona: resposta dos serviços em broadcast para os clientes publicados
 requisição/resposta assincrona:  OSB prove fila de mensagens JMS, cria duas, uma para request outra para response.
Broker de mensagens:
Permite roteamente de mensagens baseado em conteudo e transformação de dados.
- Xqueries e Callouts de mensagens.
Usada para chamar um serviço de destino. Suporta RPC e substituição de URL
- Tabela de roteamento fora do proxy (maior aproveitamente). Permite definir rotas sem ter que re-configurar o proxy.
- Roteamento baseado em identidade: criar clientes e grupos para aplicar politicas de roteamento.
DATA BASE LOOKUP.
O OSB possui esta funcionalidade para leitura a BD com serviços proxy
CONSOLE DE TESTE.
O OSB possui esta funcionalidade para testar partes específicas de um sistema isoladamente. Permite rastrear fluxos de mensagens.
Podem ser testados: Serviço de proxy, serviço de negócio,  Xquery, XSLT
Outros recursos do OSB:
- tratamento de erros (mensagens customizadas)
- versionamento (permite controlar versões dos serviços)
- monitoramento (media de tempo de um serviço,  volume processado, etc)
PASSOS PARA PUBLICAÇÃO DE UM SERVIÇO.
São basicamente duas etapas para publicação de um serviço no OSB.
1)      Realizar a publicação da aplicação no WLS
2)      Publicar as interfaces de serviços (WSDL) no OSB.
- esta etapa consiste em gerar um .jar para publicação
Para que o serviço fique realmente disponivel, será necessário criar um Business Services associado ao WSDL gerado. Este business service é a configuração no barramento de um serviço que irá ser executado está fora do barramento.
É no business service que ficam configurações como: transporte de mensagem, balaceamento de carga, etc.
Dentro mesmo do ESB é possível testar o WSDL.
ROTEAMENTO DE MENSAGENS.

No cenário apresentado acima, caso a taxa é inferior a 5% o proxy faz o roteamento da mensagem para o serviço correspondente.
Para adicionar rotas é necessário alterar o fluxo do serviço.