Deixando um pouco o bom e velho Java de lado...

Trabalhar com Java sempre foi empolgante para mim, e ainda é, contudo quem poderia imaginar que eu encontraria numa solução fundamentalmente baseada em MQ (o velho MQ Series) a solução de conectividade que eu iria melhor me identificar.

Nos meus últimos projetos venho trabalhando com uma solução que em geral é pouco conhecida, contudo acreditem, bastante presente no Brasil. O Websphere Message Broker, barramento de integração que funciona sobre a já conhecida, provada e bem estabelecida solução de mensageria originalmente chamada de MQ Series, é sem dúvida alguma uma das mais simples e robustas soluções de conectividade do mercado. E quem diria, de java tem muito pouca coisa. Talvez isso justifique porque consigo colocar para rodar o servidor do Broker (que funciona sobre uma instalação do MQ) para funcionar no meu Netbook de 1 giga de RAM =D .

Nos próximos posts eu gostaria de aproveitar para falar mais sobre esta solução e de suas capacidades únicas de transformação. Por hora é apenas isso, tirando a poeira do blog...

JSF logging no JBoss

Esta semana em um teste de carga de uma aplicacao JSF/JBoss Seam rodando no JBoss 4.3 EAP reparei um grande número de threads com estado "waiting to lock" na classe Logger e enfileiradas, em sua maioria no seguinte stack...

java.util.logging.Logger.findResourceBundle(Logger.java:1252)
java.util.logging.Logger.doLog(Logger.java:492)
java.util.logging.Logger.log(Logger.java:517)
com.sun.faces.util.Util.getFacesMapping(Util.java:628)
com.sun.faces.application.ViewHandlerImpl.getActionURL(ViewHandlerImpl.java:663)
org.jboss.seam.jsf.SeamViewHandler.getActionURL(SeamViewHandler.java:74)
com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:803)
org.ajax4jsf.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:92)
com.sun.faces.renderkit.html_basic.FormRenderer.getActionStr(FormRenderer.java:195)
com.sun.faces.renderkit.html_basic.FormRenderer.encodeBegin(FormRenderer.java:127)
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:813)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:196)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:619)

Bom sendo bastante objetivo, se observarem na implementacao JSF perceberão a existencia de diversas chamadas de Logger.log(...), o problema em si não é esse mas o fato que para cada chamada dessa temos um isDebugEnabled(...) associado (ou algo similar... não me recordo agora) e isDebugEnabled, no meu caso, sempre estava dando true. Embora meu root logger no jboss-log4j estivesse configurado para nível ERROR, eu não tinha um category específico para o JSF e aparentemente isso levava a DEBUG ser o nível default. Declarar um category no jboss-log4j para o JSF e Facelets é algo natural nas versões JBoss 4.2/4.3 EAP, ou seja, embora JSF utilize java.util.logging, o JBoss é capaz de interceptar os loggers on-the-fly e envia-los para o log4j do container, contudo minha percepcão é, na dúvida garanta que o nível de log do JSF e do Facelets estão corretamente configurados declarando-os no arquivo jboss-log4j.xml. Declara-los explicitamente como ERROR/WARN, no meu caso, resolveu meus problemas de lock no Logger.

Seguem os nomes dos loggers:

javax.enterprise.resource.webcontainer.jsf.managedbean
javax.enterprise.resource.webcontainer.jsf.renderkit
javax.enterprise.resource.webcontainer.jsf.taglib
javax.enterprise.resource.webcontainer.jsf.application
javax.enterprise.resource.webcontainer.jsf.context
javax.enterprise.resource.webcontainer.jsf.config
javax.enterprise.resource.webcontainer.jsf.lifecycle
javax.enterprise.resource.webcontainer.jsf.timing
facelets.compiler
facelets.factory
facelets.tag.component
facelets.viewhandler
facelets.tag.meta

Mais Informacões:

http://www.jboss.org/community/docs/DOC-10379

A velha questão... BPEL modelando processo?

A um pouco mais de um ano participei de um projeto onde foram experimentados 3 produtos de BPM/SOA onde lutávamos para atender os requisitos de nosso cliente, basicamente eram o Sun JCAPS, o projeto OpenESB da Sun acompanhado do BPEL Service Engine + NetBeans SOA Plugin e o desconhecido Savvion. O JCAPS, na época, no Enterprise Designer modelávamos processos utilizando BPEL 1.0 com uma notação visual própria, da ferramenta fundamentalmente nosso projeto sofria com o fato do cliente exigir que o processo, na sua notação visual, utilizasse a representação BPMN. O NetBeans por sua vez esbarrava no mesmo problema, modelava BPEL com uma notação visual bem distante do que o cliente desejava oferecer para seus analistas de negocio. E por fim o Savvion oferecia uma plataforma muito amigável ao analista de negocio, contudo bastante distante de um tradicional modelador BPEL.

Muitas pessoas acreditavam que os elementos da semântica BPEL poderiam representados visualmente pelos elementos BPMN e assim atenderiam aos requisitos exigidos pelo cliente, a experiência deste projeto levou-me a perceber que isso é um grande equivoco e o contato na época com o Savvion confirmou minhas expectativas. O Savvion trabalhava com uma notação visual BPMN, uma modelagem simples, extremamente focada na necessidade de um analista de negocio, e com código sendo gerado em XPDL. Eu sei que é difícil levar alguém, principalmente uma pessoa altamente focada em tecnologia a compreender que so porque BPEL modela blocos lógicos de orquestração de serviços este é ou não melhor para modelagem de negócio, contudo o que venho a perceber que BPEL é ótimo para desenvolvimento de serviços compostos, ou seja, orquestração de serviços para a composição de serviços de alto nível, modelados e construídos com enfoque SOA e não enfoque de processo (processo de negocio), claro que tais serviços tem como rastreabilidade em requisitos de um processo desenhado por um analista de negocio, mas estes em si não são modelados em função do negócio mas como um bloco lógico de alto nível para atender a diversos processos de negocio, ou seja, um fragmento de código reutilizável.

Então depois de muito quebrar a cabeça com o que o cliente desejava e o que poderíamos oferecer diante dos produtos que tínhamos disponíveis chegamos a conclusão que para modelagem de processo de negócio utilizaríamos uma ferramenta que seria capaz de modelar processos focados no negocio numa semântica dominada pelo profissional desta área (o analista de negocio) e por seguinte, este processo seria cliente de uma camada de serviços onde fundamentalmente os serviços seriam definidos em serviços atômicos, unidades mínimas de serviços e serviços compostos, composição de serviços orquestrados por uma linguagem para este fim, que neste caso seria BPEL. Ou seja os dois mundos existiam, o modelo BPEL era focado exclusivamente na modelagem da colaboração de serviços atômicos e compostos enquanto que o XPDL era utilizado na modelagem da colaboração dos passos identificados no processo de negocio, que poderiam ou não estar sendo realizados por serviços compostos ou atômicos. De fato o XPDL aqui é apenas a linguagem computacional utilizada para execução do modelo BPMN elaborado na camada de negócio, portanto o que temos na modelagem de fato é um diagrama BPMN e uma relação de realização deste modelo no service layer e na forma serviços (sejam estes atômicos ou compostos). Certamente não sei dizer se esta é a melhor abordagem, contudo para meu cliente era bastante interessante, deixe eu tentar citar algumas vantagens de maneira bem objetiva:

- O processo de negocio desenhado pelo analista de negocio era executável não necessitando uma conversão intermediária entre um modelo BPMN e uma ferramenta de execução de processo baseada em BPEL.

- O processo de negocio poderia ser simulado e melhorado orientado a critérios de negocio, ou seja a modelagem da estrutura do processo não tinha nenhuma relação com a semântica de orquestração dos serviços de tecnologia, deste modo a competência do arquiteto de negocio não se misturava com a competência do arquiteto dos serviços.

- Objetivos de negocio eram realizados na modelagem do processo de negocio, objetivos não-funcionais de infraestrutura eram rastreados nos objetivos de negocio e realizados nos serviços atômicos ou serviços compostos (na forma de processos de tecnologia).

- Definição clara de o que é um processo de negocio e o que é um serviço composto reaproveitável corporativamente.

Bom, eu poderia ficar falando sobre este assunto por horas sem chegar a lugar algum pois, como eu disse, são questões ainda pouco resolvidas até mesmo no mercado, minha percepção e experiência levam-me a crer que a solução é contingencial e irá depender do que seu cliente quer. De maneira geral eu comecei a falar disso para introduzir um artigo bem interessante que li recentemente e intitulado Why BPEL is not the holy grail for BPM.

Em breve falaremos como a abordagem citada aqui pode ser implementada utilizando o JBPM, e dentro desta filosofia é interessante observar o conceito de PVM (process virtual machine) oferecida por esta API onde permitirá trabalharmos de maneira plugável com a linguagem de execução, permitindo assim os dois mundos, tanto ao orientado ao processo de negócio quanto o orientado ao processo de tecnologia (composite services) serem oferecidos por uma única suite simplificando bastante a arquitetura.

Para quem se interessar em quebrar a cabeça com as relações entre XPDL e BPEL segue o link para um paper publicado pela Universidade Karlsruhe na Alemanha, http://wi.wu-wien.ac.at/home/mendling/publications/TR-Caise06.pdf, boa sorte na leitura.