quinta-feira, 19 de março de 2009

Implementando conversor de moeda com JSF

Algumas pessoas já devem ter passado pelo problema de criar um conversor de moedas em JSF que funcione bem para diferentes países. Segue abaixo uma sugestão de como implementar um conversor legal.

O primeiro passo é implementar a classe de conversor. Segue abaixo a classe:

public class MoedaConverter implements Converter {

@Override
public Object getAsObject(FacesContext facesContext,
UIComponent uiComponent, String value) {

FacesContext fc = FacesContext.getCurrentInstance();
Locale l = fc.getViewRoot().getLocale();

if (value != null) {
value = value.trim();
if (value.length() > 0) {
try {
return new BigDecimal(NumberFormat.
getNumberInstance(l).parse(
value).doubleValue());
} catch (ParseException e) {
e.printStackTrace();
}
}
}
return null;
}

@Override
public String getAsString(FacesContext facesContext,
UIComponent uiComponent, Object value) {

if (value == null) {
return "";
}
if (value instanceof String) {
return (String) value;
}
try {
FacesContext fc = FacesContext.getCurrentInstance();
Locale l = fc.getViewRoot().getLocale();
NumberFormat formatador = NumberFormat.getNumberInstance(l);
formatador.setGroupingUsed(true);
return formatador.format(value);

} catch (Exception e) {
throw new ConverterException("Formato não é número.");
}
}
}

Depois deve-se adicionar o seguinte trecho no arquivo faces-config.xml:

<converter>
<converter-id>MoedaConverter</converter-id>
<converter-class>
com.converter.DoubleConverter
</converter-class>
</converter>


Para utilizá-lo agora basta utilizar da seguinte maneira:
   <h:inputText id="moeda"
label="#{msgs.campo_geral_volume_compra}"
value="#{enderecoBean.valor}">
<f:converter converterId="MoedaConverter" />
</h:inputText>
Não se esqueça que este conversor não é também máscara de javascript. Então é importante criar a máscara e adicionar no componente para facilitar a vida do usuário.

É isto aí pessoal. Qualquer problema avisem.

[]s,

quarta-feira, 11 de março de 2009

Artigos sobre gerênciamento de Processos de Negócio

Dois artigos que são bem interessantes sobre processos de negócio são “As empresas são grandes coleções de processos”  que se encontra disponível em http://www.fgvsp.br/rae/artigos/006-019.pdf e outro é “Processo, que processo?” que se encontra disponível em http://www.fgvsp.br/rae/artigos/008-019.pdf. Ambos os artigos são escritos pelo Professor do Departamento de Administração Geral e Recursos Humanos da EAESP/FGV, José Ernesto Lima Gonçalves.

O primeiro artigo (“As empresas são grandes coleções de processos”) é um texto que mostra como a idéia de processos está enraizada nas empresas e organizações atuais. O artigo tem como objetivo facilitar a compreensão do assunto e aplicações para o conceito de processos empresariais.

O artigo se mostra bem útil, pois representa uma introdução bem prática sobre alguns dos principais processos nas empresas, além de ressaltar a importância de se organizar também os processos não fabris nas empresas e descreve além disto as características dos processos empresariais e também mostra a importância dos processos na organização e como a tecnologia se liga a eles de forma a facilitar seu mapeamento e gerenciamento.

Em sua conclusão o autor cita que as empresas tem sido cada vez mais centradas em processos, apesar de várias das empresas brasileiras ainda não conhecerem e nem mapearem seus processos.

O texto é muito bem ilustrado com quadros que mostram exemplos de processos, classificações, processos característicos e categorias. O artigo é bem abrangente nos conceitos de processos, mas peca um pouco em não enfatizar nenhum dos pontos de maneira mais profunda.

O segundo artigo (“Processo, que processo?”) é uma continuação do artigo citado anteriormente e resume as diferenças entre as organizações tradicionais e as empresas estruturadas por processos.

O artigo começa enfatizando o fato das empresas em geral não saberem como se organizarem por processos e identifica algumas empresas que já possuem esforços nesta direção como a IBM, HP, entre outras e então fala sobre como a empresa pode verificar e desenhar seus processos e como em alguns casos isto pode ser bem difícil em áreas não fabris da empresa, além de mostrar que para que a empresa se organize em processos o foco da empresa deixa de ser a estrutura da empresa e passa a ser o cliente.

É mostrado então algumas comparações entre organogramas e processos, estrutura organizacional versus estrutura organizacional por processos e estruturação por processos e também uma maneira de realizar a classificação de empresas com relação à organização por processos.

Uma parte mais prática do artigo se refere a como materializar os princípios de organização por processos que passa uma visão ampla, mas bem simplista dos passos a serem seguidos para que uma empresa mude sua estrutura para se aproximar de uma organização por processos.

Numa parte final o texto mostra em um quadro muito bem feito o quanto é recomendado para a empresa se orientar a processos de acordo com alguns fatores definidos pelo autor, tais como necessidade de flexibilidade e agilidade.

O autor então conclui que o futuro vai pertencer às empresas que consigam explorar seus processos tanto fabris quanto não fabris e que consigam centrar seus esforços em seus clientes, o que para mim faz muito sentido. O texto é muito bem escrito e possui exemplos claros e quadros e ilustrações que facilitam a leitura.

Ambos os textos cumprem muito bem os objetivos propostos e passam uma visão bem abrangente dos processos atuais nas empresas e de como orientar as empresas a processos.

É isto aí pessoal. Espero que ajude e que incentive vocês a ler os artigos que são bem interessantes. Qualquer problema me avisem…

image

domingo, 8 de março de 2009

Papel do ESB dentro de uma arqutetura SOA

SOA é uma arquitetura onde é possível criar, padronizar, documentar funções genéricas únicas, utilizadas por diferentes aplicações em componentes reutilizáveis e com total interoperabilidade, de modo que possam ser compartilhados e acessados por diferentes dispositivos sob a forma de serviço, sem precisarem ser reescritos.

O papel do ESB dentro de uma arquitetura SOA é atuar como infra-estrutura para suportar os princípios de projeto SOA, virtualizando os serviços providos e tornando toda TI transparente para o negócio. Numa arquitetura SOA, o ESB fundamentalmente atua no papel de prover independência de linguagem, transparência de protocolo e localização, independência de formato de dados, independência de plataforma e um modelo de comunicação transparente para que seja possível atingir um baixo acoplamento entre os serviços componentes da arquitetura.

Segue abaixo um exemplo de um ESB:

image

O ESB também tem o papel de prover infra-estrutura para gerenciamento adequado da arquitetura em grande escala. Um ESB serve então como  infra-estrutura de uma arquitetura SOA, lidando com o roteamento, transformação e mediação entre produtores e fornecedores de serviços, sejam eles internos ou externos à organização.

É isto aí pessoal. Qualquer problema avisem.

image

terça-feira, 3 de março de 2009

Funcionalidades de um ESB

Um dos objetivos deste post é dar uma breve explicação sobre as principais funcionalidades de um ESB que são o roteamento a transformação e a mediação.

Os envolvidos numa comunicação através do ESB não precisam compartilhar o mesmo protocolo de comunicação ou formato de mensagem, pois fica a cargo do ESB realizar as transformações necessárias nas mensagens trocadas. Isto acontece através do serviço de transformação do ESB. Por exemplo, uma mensagem com 10 campos enviada através de SOAP pode ser recebida pela outra ponta como uma mensagem JMS com 4 campos removidos.

O serviço de mediação no ESB compreende todo o workflow de mensagens envolvido para realizar uma determinada "interação" entre os participantes. Os participantes não entram em contato um com o outro, e sim, toda comunicação é mediada pelo ESB. Mediações complexas podem também ser formada a partir do encadeamento de outras mediações. Por exemplo, qualquer mensagem enviada de um componente para outro requer a mediação do ESB.

O serviço de roteamento de um ESB oferece uma infra-estrutura de comunicação e localização comum que pode ser utilizada para conectar serviços sem que os desenvolvedores precisem realizar uma lógica de conectividade complexa. Por exemplo, uma requisição a um serviço é realizada ao ESB por um componente sem que este conheça a localização física do serviço desejado, nem mesmo por qual caminho a solicitação será trafegada até chegar ao seu destino.

Um produto de mercado ESB se chama Websphere Message Broker. Esta é uma solução IBM para implementar um EAI robusto baseado em mensagens e serve para conectividade entre aplicações, mediações entre fornecedores e clientes e criação de um barramento de serviços.

Entre as principais funcionalidades temos o roteamento, transporte e mediação, suporte a pilha WebServices, integração com transportes do WebSphere MQ e repositório de mensagens persistentes.

Entre os mecanismos e protocolos suportados temos JCA, WebServices, Mensagens MQ, TCP/IP, Hats. Pode através de algum destes protocolos comunicar com Mainframe CICs entre outros.

O produto também permite virtualizar o acesso aos serviços e os disponibilizar de forma simples o acesso a aplicações heterogêneas. Suporta também como transporte http e SOAP, suporte a aplicações de tempo real, envio de mensagens, entre outros,

A arquitetura de referência se baseia em 4 elementos centrais:

· A modelagem e a simulação de novos processos de negócio. A ferramenta chave é o Websphere Businnes Modeler. Este produto permite que se modele o processo de negócio e utilize os serviços disponibilizados nas camadas inferiores.

· Desenvolvimento de novos serviços e processos – As ferramentas chave são o Rational RAD e o Websphere Integration Developer.

· A execução de processos - A ferramenta chave é o WPS (Process Server). O WPS requer um ESB para operar (WESB ou ESMB).

· A monitoração de processos com o WebSphere Business Monitor.

É isto aí pessoal. Espero que esta introdução sobre ESB ajude quem está começando.

image

domingo, 1 de março de 2009

Considerações do texto: The Web Services Debate e .Net vs. J2EE

A utilização de Web Services permite a comunicação e a interoperabilidade entre várias diferentes linguagens de programação. Sua utilização requer a cooperação entre as facções JEE e .NET. A tecnologia ainda não é madura o suficiente, mas basicamente é um servidor que escuta e responde SOAP, geralmente utilizando http. Na prática Web Services suporta WSDL para descrever suas interfaces, e podem também ser ouvidas em um registro UDDI.

A utilização de Web Services permite uma comunicação fácil entre várias plataformas de desenvolvimento, o que coloca fogo na discussão sobre qual plataforma de desenvolvimento é melhor. Particularmente nos artigos a comparação se concentra nas plataformas .NET e J2EE.

Uma vez que Web Services não é uma tecnologia que depende nem de J2EE e nem de .NET, é somente baseado em SOAP, XML e outros tecnologias independentes, a decisão de utilizar uma das duas tecnologias é somente uma questão de em que ambiente de desenvolvimento será realizado o deploy dos Web Services.

Segundo os defensores do J2EE a plataforma é mais madura, mais robusta, mais flexível e mais testada. Cerca de 55 a 70% dos deploys dos Web Services foram feitos utilizando a plataforma J2EE. Além disto, possui suporte de uma vasta quantidade de vendedores tais como SAP, IBM, BEA, Oracle, entre outros. Também segundo os defensores da tecnologia J2EE a plataforma é portável ou seja, possui a facilidade de ser escrita em algum lugar e poder rodar em qualquer lugar.

Segundo os defensores do .NET, esta plataforma é mais simples, mais barato para executar o deploy, mais barato de executar manutenção, possui melhor performance e custo de solução menor. Segundo também os defensores da tecnologia são necessárias menos linhas de código, o que aumenta a rapidez de desenvolvimento.

Web Services é realmente uma tecnologia que tende a ser muito importante para o desenvolvimento de aplicações no futuro e há espaço no mercado para o convívio tanto de aplicações J2EE quanto de aplicações .NET. Cabe a empresa a escolha da tecnologia que mais se aplica ao projeto a ser desenvolvido.

É isto aí pessoal. Qualquer problema me avisem.

image

Modelagem de processo de negócios com BizAgi

Olá pessoal,

Uma ferramenta que achei bem interessante para a modelagem de processo de negócios é a BizAgi Process Modeler. A ferramenta é bem simples de usar e possui bastante funcionalidades. Um exemplo de utilização se encontra em http://www.bizagi.com/eng/downloads/BPMNbyExample.pdf?token=1.4.1.0.

Para exemplificar a utilização da ferramenta resolvi modelar o processo de aprovação de posts do portal do arquiteto. Segue abaixo o modelo:

Com a ferramenta é possível modelar processos, subprocessos e é bem simples de se realizar a modelagem. Uma breve explicação sobre a ferramenta pode ser encontrado em http://www.baixaki.com.br/download/bizagi-process-modeler.htm.

É isto aí pessoal. Espero que ajude quem quer modelar os processos de negócio.