Recentemente estive em um projeto e tive que desenvolver uma solu\u00e7\u00e3o bem bacana com integra\u00e7\u00e3o entre Oracle Webcenter e Siebel. O Siebel trabalha com tokens de seguran\u00e7a nas chamadas de servi\u00e7os, o problema \u00e9 que n\u00e3o h\u00e1 implementa\u00e7\u00e3o de WS-Security que fa\u00e7a a autentica\u00e7\u00e3o e tokens de seguran\u00e7a de forma satisfat\u00f3ria e sem problemas. Al\u00e9m disso h\u00e1 outros detalhes de desempenho que a equipe da Siebel disse que \u00e9 fundamental.<\/p>\n
A equipe Siebel queria que fosse associada a sess\u00e3o Web do usu\u00e1rio com a sess\u00e3o de conex\u00e3o com o Siebel para as chamadas de servi\u00e7os. O problema dessa solu\u00e7\u00e3o \u00e9 justamente fazer essa associa\u00e7\u00e3o de maneira correta (uma n\u00e3o tem nada a ver com a outra) e tratar solicita\u00e7\u00f5es paralelas. Isso \u00e9 fundamental em ambientes Web. Outro problema \u00e9 que haveriam muitas sess\u00f5es Siebel ociosas, pois ap\u00f3s o usu\u00e1rio realizar a requisi\u00e7\u00e3o, ele fica analisando os dados e navegando na p\u00e1gina, antes de realizar novas requisi\u00e7\u00f5es. A solu\u00e7\u00e3o que eu sugeri foi a implementa\u00e7\u00e3o de um pool de conex\u00f5es\u00a0 compartilhadas com o Siebel, da mesma maneira que utilizamos para Banco de Dados. Para atender o requisito solicitado pela equipe Siebel, definimos o n\u00famero de conex\u00f5es m\u00ednimas igual a 1 e o m\u00e1ximo igual ao n\u00famero de usu\u00e1rios conectados.<\/p>\n
Antes de entender o funcionamento do pool Siebel, vamos entender o funcionamento dos tokens no Siebel.<\/p>\n
Essa foi nossa primeira abordagem antes de criar o pool de conex\u00f5es. No header da requisi\u00e7\u00e3o SOAP n\u00e3o enviamos nenhuma informa\u00e7\u00e3o de usu\u00e1rio, apenas definimos o SessionType como None. Para cada requisi\u00e7\u00e3o ele abre uma sess\u00e3o e fecha ao enviar a resposta. O problema dessa implementa\u00e7\u00e3o \u00e9 que embora seja simples, o tempo de cria\u00e7\u00e3o de sess\u00e3o sem o uso do token \u00e9 bem elevado.<\/p>\n
\n<soap:Envelope xmlns:soap="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/">\n<soap:Header>\n <SessionType xmlns="http:\/\/siebel.com\/webservices">None<\/SessionType>\n<\/soap:Header>\n<soap:Body>\n <!-- ... -->\n<\/soap:Body>\n<\/soap:Envelope>\n<\/pre>\nAutoriza\u00e7\u00e3o Siebel, sem sess\u00e3o<\/h2>\n
Semelhante \u00e0 anterior, inclusive com os mesmo problemas, mas passando o usu\u00e1rio e senha para autoriza\u00e7\u00e3o.<\/p>\n
\n<soap:Envelope xmlns:soap="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/">\n<soap:Header>\n <UsernameToken xmlns="http:\/\/siebel.com\/webservices">usuario<\/UsernameToken>\n <PasswordText xmlns="http:\/\/siebel.com\/webservices">senha<\/PasswordText>\n <SessionType xmlns="http:\/\/siebel.com\/webservices">None<\/SessionType>\n<\/soap:Header>\n<soap:Body>\n <!-- ... -->\n<\/soap:Body>\n<\/soap:Envelope>\n<\/pre>\nAutoriza\u00e7\u00e3o Siebel com sess\u00e3o stateless<\/h2>\n
Essa foi a solu\u00e7\u00e3o adotada para o pool de conex\u00f5es com o Siebel que explicarei mais adiante. O funcionamento \u00e9 simples de entender, mas um pouco trabalhoso de se implementar j\u00e1 que \u00e9 sempre necess\u00e1rio guardar o \u00faltimo token de cada conex\u00e3o. A primeira requisi\u00e7\u00e3o deve realizar a autoriza\u00e7\u00e3o passando o usu\u00e1rio, senha e o tipo de sess\u00e3o Stateless, com isso uma sess\u00e3o \u00e9 aberta para esse usu\u00e1rio. Ao obter uma resposta da requisi\u00e7\u00e3o, o Siebel retornar\u00e1 o token de seguran\u00e7a que dever\u00e1 ser utilizado na pr\u00f3xima requisi\u00e7\u00e3o, que retornar\u00e1 outro token de seguran\u00e7a que dever\u00e1 ser utilizado na pr\u00f3xima requisi\u00e7\u00e3o e assim por diante. Para finalizar a sess\u00e3o Siebel \u00e9 s\u00f3 passar o usu\u00e1rio e senha com o tipo de sess\u00e3o None.<\/p>\n
Requisi\u00e7\u00e3o inicial<\/h3>\n
Para efetuar o log in e criar a sess\u00e3o \u00e9 necess\u00e1rio passar o seguinte header:<\/p>\n
\n<soap:Envelope xmlns:soap="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/">\n<soap:Header>\n <UsernameToken xmlns="http:\/\/siebel.com\/webservices">usuario<\/UsernameToken>\n <PasswordText xmlns="http:\/\/siebel.com\/webservices">senha<\/PasswordText>\n <SessionType xmlns="http:\/\/siebel.com\/webservices">Stateless<\/SessionType>\n<\/soap:Header>\n<soap:Body>\n <!-- ... -->\n<\/soap:Body>\n<\/soap:Envelope>\n<\/pre>\nDessa forma ele dever\u00e1 retornar uma resposta parecida com essa:<\/p>\n
\n<soap:Envelope xmlns:soap="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/">\n<soap:Header>\n <siebel-header:SessionToken xmlns:siebel-header="http:\/\/siebel.com\/webservices">TokenCriptografadoComValorEstranhoDoResponse\n<\/siebel-header:SessionToken>\n<\/soap:Header>\n<soap:Body>\n <!-- ... -->\n<\/soap:Body>\n<\/soap:Envelope>\n<\/pre>\nPr\u00f3ximas Requisi\u00e7\u00f5es<\/h3>\n
Para as pr\u00f3ximas requisi\u00e7\u00f5es e necess\u00e1rio recuperar o token da resposta e colocar no header da requisi\u00e7\u00e3o da seguinte forma:<\/p>\n
\n<soap:Envelope xmlns:soap="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/">\n<soap:Header>\n<SessionType xmlns="http:\/\/siebel.com\/webservices">Stateless<\/SessionType>\n<SessionToken xmlns="http:\/\/siebel.com\/webservices">TokenCriptografadoComValorEstranhoDoResponse<\/SessionToken>\n<\/soap:Header>\n<soap:Body>\n<!-- ... -->\n<\/soap:Body>\n<\/soap:Envelope>\n<\/pre>\nE assim por diante. Existe a op\u00e7\u00e3o do tipo de sess\u00e3o ser Statefull tamb\u00e9m para manter o estado da sess\u00e3o. O funcionamento \u00e9 o mesmo, s\u00f3 muda o SessionType para Statefull.<\/p>\n
Pool de conex\u00f5es<\/h2>\n
Como assinei contrato de confidencialidade n\u00e3o poderei disponibilizar o c\u00f3digo fonte utilizado no projeto, mas explicarei os caminhos necess\u00e1rios para tudo funcionar adequadamente.<\/p>\n
Para a inclus\u00e3o do header nas requisi\u00e7\u00f5es do Siebel, utilizei um SOAPHandler. O SOAPHandler funciona como uma esp\u00e9cie de \"filtro\" para todas as requisi\u00e7\u00f5es que utilize ele. Dessa forma eu posso modificar o header, alterar a requisi\u00e7\u00e3o e obter ou mesmo alterar os dados da resposta. Para realizar isso, \u00e9 s\u00f3 criar uma classe que implemente a interface SOAPHandler como no exemplo e associar com os clientes de cada servi\u00e7o (JAX-WS 2.0).<\/p>\n
\npublic class SiebelHandler implements SOAPHandler<SOAPMessageContext> {\n \/\/...\n}\n<\/pre>\nDos m\u00e9todos que a interface nos obriga a implementar utilizaremos dois: handleMessage <\/em>e handleFault<\/em>. Que \u00e9 onde iremos modificar os headers e obter os tokens.<\/p>\n
\n public boolean handleMessage(SOAPMessageContext smc) {\n Boolean outboundProperty =\n (Boolean)smc.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);\n\n if (outboundProperty.booleanValue()) {\n\n SiebelTokenHelper tokenHelper =\n SiebelSimpleTokenManager.getInstance().getNextToken();\n tokenUsed(tokenHelper);\n\n SOAPMessage message = smc.getMessage();\n\n try {\n SOAPEnvelope envelope =\n smc.getMessage().getSOAPPart().getEnvelope();\n\n SOAPHeader header = envelope.getHeader();\n if (header == null) {\n header = envelope.addHeader();\n }\n \/\/ Token\n if (tokenHelper.getTokenValue() == null) {\n SOAPElement userNameToken =\n header.addChildElement("UsernameToken", "",\n "http:\/\/siebel.com\/webservices");\n userNameToken.addTextNode(tokenHelper.getUser());\n\n SOAPElement password =\n header.addChildElement("PasswordText", "",\n "http:\/\/siebel.com\/webservices");\n password.addTextNode(tokenHelper.getPassword());\n\n } else {\n\n SOAPElement sessionToken =\n header.addChildElement("SessionToken", "",\n "http:\/\/siebel.com\/webservices");\n sessionToken.addTextNode(tokenHelper.getTokenValue());\n }\n\n SOAPElement sessionType =\n header.addChildElement("SessionType", "",\n "http:\/\/siebel.com\/webservices");\n\n if (isLogout(envelope)) {\n sessionType.addTextNode("None");\n SiebelSimpleTokenManager.getInstance().removeFromPool(tokenHelper);\n tokenHelper = null;\n } else {\n sessionType.addTextNode("Stateless");\n }\n\n } catch (Exception e) {\n logger.log(Level.SEVERE, "Erro ao invocar servico", e);\n }\n\n } else {\n SiebelTokenHelper tokenHelper = getUsedToken();\n try {\n\n SOAPMessage message = smc.getMessage();\n if (tokenHelper != null) {\n Node tokenCHild = message.getSOAPHeader().getFirstChild();\n if (tokenCHild != null) {\n tokenHelper.setTokenValue(tokenCHild.getTextContent());\n }\n }\n\n } catch (Exception ex) {\n ex.printStackTrace();\n tokenHelper.setTokenValue(null);\n } finally {\n if (tokenHelper != null) {\n SiebelSimpleTokenManager.getInstance().pushElemIntoPool(tokenHelper);\n }\n }\n }\n\n return outboundProperty;\n\n }\n\n<\/pre>\nA primeira condi\u00e7\u00e3o na linha 05 verifica se \u00e9 requisi\u00e7\u00e3o ou reposta. Se for requisi\u00e7\u00e3o o valor ser\u00e1 verdadeiro. Na linha 07 e 08 utilizo uma implementa\u00e7\u00e3o de fila (utilizando LinkedList) para recuperar o elemento mais antigo (menos recente usado), removo ele da fila para que outras conex\u00f5es Siebel possam ser utilizadas, ele ser\u00e1 novamente inserido no final da fila (linha 74), ap\u00f3s ter o valor do token atualizado (linha 65) na resposta (linha 57). Na linha 22 verifico se existe token anterior ou se \u00e9 uma conex\u00e3o nova. Se for uma conex\u00e3o nova, atribuo o valor do usu\u00e1rio (linha 26), da senha (linha 31). Caso contr\u00e1rio, utilizo o token (linha 38) atributo anteriomente na resposta (linha 65). Se for uma requisi\u00e7\u00e3o de logout (linha 45), atribuo o SessionType como None, caso contr\u00e1rio Stateless.<\/p>\n
O cora\u00e7\u00e3o da implementa\u00e7\u00e3o \u00e9 esse m\u00e9todo, mas ainda n\u00e3o estamos tratando exce\u00e7\u00e3o e reestabelecendo a conex\u00e3o caso a sess\u00e3o expire. Para reestabelecer a conex\u00e3o, basta colocar no catch do cliente uma nova tentativa se o erro tiver o c\u00f3digo 10944642. No nosso handleFault<\/em> basta remover da fila para n\u00e3o ser mais utilizado, caso contr\u00e1rio, se for outro tipo de erro, o token \u00e9 retornado no fault e devemos atribuir para ser utilizado na pr\u00f3xima requisi\u00e7\u00e3o. Quando a sess\u00e3o expira o Siebel retorna a seguinte mensagem:<\/p>\n
\n<SOAP-ENV:Envelope xmlns:SOAP-ENV="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/" xmlns:xsi="http:\/\/www.w3.org\/2001\/XMLSchema-instance" xmlns:xsd="http:\/\/www.w3.org\/2001\/XMLSchema">\n <SOAP-ENV:Body>\n <SOAP-ENV:Fault>\n <faultcode>SOAP-ENV:Client<\/faultcode>\n <faultstring>Error Code: 10944642 Error Message: Error: Inbound SOAP Message - Session Token is missing or invalid or has expired<\/faultstring>\n <detail>\n <siebelf:errorstack xmlns:siebelf="http:\/\/www.siebel.com\/ws\/fault">\n <siebelf:error>\n <siebelf:errorsymbol\/>\n <siebelf:errormsg>Error: Inbound SOAP Message - Session Token is missing or invalid or has expired<\/siebelf:errormsg>\n <\/siebelf:error>\n <\/siebelf:errorstack>\n <\/detail>\n <\/SOAP-ENV:Fault>\n <\/SOAP-ENV:Body>\n<\/SOAP-ENV:Envelope>\n<\/pre>\nPor isso devemos tratar quando obtermos o c\u00f3digo: 10944642, pois n\u00e3o \u00e9 um erro de servi\u00e7o, \u00e9 somente sess\u00e3o expirada. O controle de cria\u00e7\u00e3o de novas conex\u00f5es foi feito em uma classe que possui a fila de conex\u00f5es e tokens e o controle do n\u00famero m\u00e1ximo foi feito utilizando um Managed Bean para contabiliza\u00e7\u00e3o de login e logout e um Session Listener, para caso o usu\u00e1rio esque\u00e7a de clicar no bot\u00e3o Sair.<\/p>\n
Para testar a Oracle disponibiliza um VM do Siebel no e-delivery<\/a>. Com essa implementa\u00e7\u00e3o, tivemos um ganho de performance absurdo, paralelizamos as requisi\u00e7\u00f5es e otimizamos o uso de sess\u00f5es e compartilhamento de tokens no Siebel.<\/p>\n