Java Management Extensions (JMX) é uma tecnologia Java que permite monitorar e gerenciar aplicações Java. É muito comum utilizar este recurso em soluções corporativas escritas em Java. Neste post vou mostrar como expor um bean do Spring como um MBean do JMX.

Vamos criar um job no Quartz que de tempos em tempos chama um bean do Spring, com os recursos de JMX do Spring vamos parar este serviço no Quartz de fora da aplicação. Esta aplicação vai estar rodando no ORACLE Weblogic 10.3 e o deploy sera realizado através do maven 2.



Um pouco mais sobre JMX

JMX é baseado em uma arquitetura de 3 camadas. As camadas são as seguintes:

• Probe Level:Nesta camada ficam os famosos MBean. Esta camada também é conhecida como camada de instrumentalização. Mais a frente vamos ver como fazer isto com Spring!
  
• Agent Level:Nesta camada reside o MBeanServer, que fica entre os MBeans e o nível de gerenciamento. O Spring também facilidades para o MBeanServer.
• Remote Management Level: Por fim o nível de gerenciamento, este nível permite que aplicações acessem o servidor de MBeans através de conectores e adaptadores. Os conectores permitem acesso via RMI, WS e JMS em quanto os adaptadores permitem acesso HTTP e SNMP por exemplo.

JMX é suportado por todos os principais container do mercado. Existe um console genérico chamado de JConsole que vem na pasta bin do JDK do java, mais adiante neste post vou mostrar como utilizar o JConsole com o Weblogic 10.3.

Quartz Framework

É uma solução open source de agendamento e execução de tarefas. Estas tarefas são chamadas de jobs no Quartz. A solução prove a possibilidade de realizar agendamentos complexos usando expressões chamadas de Cron Expressions que são semelhantes as expressões do sistema operacional Linux.

O Quartz pode ser usando em cluster e em transações usando distribuídas com JTA. A lista completa das funcionalidades você pode conferir aqui. O Spring também prove facilidades na utilização do Quartz.

Agora vamos ao projeto que criei para mostrar como podemos expor os serviços de uma aplicação com o Spring estes serviços vão ser consumidos pelo Quartz em um job via JConsole vamos poder parar e iniciar esta aplicação. Vamos lá então.

DateService

<br />package com.blogspot.diegopacheco.springjmx.service;<br /><br />/**<br /> * Interface de contrato que prove as funções do serviço de datas.<br /> *<br /> * @author Diego Pacheco<br /> * @since 13/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public interface DateService {<br /> public String getDate();<br />}<br />

Bom essa é a interface do serviço. Eu sempre uso esse serviço pela simplicidade e facilidade para o entendimento da solução. Na prática poderia ser qualquer contrato de serviço :).

DateServiceImpl

<br />package com.blogspot.diegopacheco.springjmx.service;<br /><br />import java.util.Date;<br /><br />/**<br /> * Interface de contrato que prove as funções do serviço de datas.<br /> *<br /> * @author Diego Pacheco<br /> * @since 13/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public class DateServiceImpl implements DateService {<br /><br /> @Override<br /> public String getDate() {<br /> return new Date().toString();<br /> }<br /> <br />}<br /><br />


A implementação do serviço é simples, só retorna um data. Agora vamos ver mais algumas coisas da aplicação como esta outra interface que segue a baixo.

ControlBean

<br />package com.blogspot.diegopacheco.springjmx.service;<br /><br />/**<br /> * Interface de controle que sera exposta via JMX, seu proposito eh parar algum serviço<br /> * e bem como iniciar o serviço que foi parado.<br /> *<br /> * @author Diego Pacheco<br /> * @since 13/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public interface ControlBean {<br /> public void stop();<br /> public void start();<br />}<br />

Esta interface defini os métodos para que um serviço exposto via JMX possa ser parado e iniciado novamente. Vamos ver como seria esta implementação.

ControledBridgeDateService

<br />package com.blogspot.diegopacheco.springjmx.service;<br /><br />/**<br /> * Pattern Bridge que utiliza o service de DateService com suporte a ControlBean<br /> * Sendo capaz de não acessar o service caso a aplicacao esteja parada.<br /> *<br /> * @author Diego Pacheco<br /> * @since 18/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public class ControledBridgeDateService implements DateService, ControlBean{<br /> <br /> private boolean doit = true;<br /> private DateService ds;<br /> <br /> @Override<br /> public void start() {<br /> doit = true;<br /> }<br /><br /> @Override<br /> public void stop() {<br /> doit = false; <br /> }<br /><br /> @Override<br /> public String getDate() {<br /> if (doit)<br /> return ds.getDate();<br /> throw new ApplicationStopedException("Aplicação foi parada. Este método não pode ser executado neste momento");<br /> }<br /><br /> public void setDs(DateService ds) {<br /> this.ds = ds;<br /> } <br />}<br /><br />

O Serviço a cima implementa o pattern Bridge do GOF para a interface DateService. Este serviço também implementa ControlBean, logo ele pode ser parado. Este controle é feito por uma variável booleana que se chama 'doit' que por padrão é true.

Quando alguem invocar o método stop esta variável fica como o valor false e ao invocarem o método start esta variável volta ao valor true. A variável 'doit' é levada em considerações no método getDate() que delega para o método getDate da implementação de DateService caso contrário é levantada uma exception indicando que a aplicação foi parada e não poder ser executada.

Vamos a configuração do Spring, vamos expor estes serviços como MBeans do JMX, confira o xml a baixo:

<br /><?xml version="1.0" encoding="UTF-8"?><br /><beans xmlns="http://www.springframework.org/schema/beans" aop="http://www.springframework.org/schema/aop" tx="http://www.springframework.org/schema/tx" p="http://www.springframework.org/schema/p" xsi="http://www.w3.org/2001/XMLSchema-instance" util="http://www.springframework.org/schema/util" schemalocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd "><br /><br /> <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" init="false"><br /> <property name="beans"><br /> <map><br /> <entry key="bean:name=DateService" ref="dateService"><br /> <entry key="bean:name=ControledBridgeDateService" ref="controledBridgeDateService"><br /> </map><br /> </property><br /> </bean><br /><br /> <bean id="dateService" class="com.blogspot.diegopacheco.springjmx.service.DateServiceImpl"><br /> <br /> <bean id="controledBridgeDateService" class="com.blogspot.diegopacheco.springjmx.service.ControledBridgeDateService"><br /> <property name="ds" ref="dateService"><br /> </bean> <br /><br /></beans><br /><br />

A exposição é realizada pelo MBeanExporter do Spring.A estratégia que estou usando vai expor todos os métodos públicos dos beans que forem informados ao MBeanExporter. Existem outras estratégias e outras formas de expor seus serviços como MBeans para isto confira na documentação oficial do spring.

Agora vamos a parte do Quartz, aqui existe uma pegadinha. Por que o Spring instância os jobs do quartz de forma diferente que ele instância seus beans. Logo a injeção de dependências não vai funcionar para resolver este problema criei uma classe utilitária que se chama ApplicationContextHolder.

<br />package com.blogspot.diegopacheco.springquartz.job;<br /><br />import org.springframework.beans.BeansException;<br />import org.springframework.context.ApplicationContext;<br />import org.springframework.context.ApplicationContextAware;<br /><br />/**<br /> * Bean que eh resposavel por segurar a instancia de ApplicationContext do Spring.<br /> *<br /> * @author Diego Pacheco<br /> * @since 18/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public class ApplicationContextHolder implements ApplicationContextAware{<br /> <br /> private ApplicationContext ac;<br /> <br /> @Override<br /> public void setApplicationContext(ApplicationContext ac) throws BeansException {<br /> this.ac = ac;<br /> }<br /> <br /> public ApplicationContext getApplicationContext(){<br /> return ac;<br /> }<br /> <br />}<br /><br />

Esta classe helper nada mais faz do que implementar ApplicationContextAware e expor o ApplicationContext do Spring através de um método getter.

Esta classe é passado ao Quartz via um Map e você pode recupera-la de dentro do seu Job é isto que vou mostrar agora na classe a baixo.

DateJob

<br />package com.blogspot.diegopacheco.springquartz.job;<br /><br />import org.quartz.JobExecutionContext;<br />import org.quartz.JobExecutionException;<br />import org.quartz.SchedulerException;<br />import org.springframework.scheduling.quartz.QuartzJobBean;<br /><br />import com.blogspot.diegopacheco.springjmx.service.ApplicationStopedException;<br />import com.blogspot.diegopacheco.springjmx.service.DateService;<br /><br />/**<br /> * Job do Quartz que chama o serviço de datas. Esta classe usa apenas a interface do service. Como instancia<br /> * eh injetado o ControledBridgeDateService que eh uma bridge para implemantacao e pode ser pausado via JMX.<br /> *<br /> * @author Diego Pacheco<br /> * @since 18/07/2009<br /> * @version 1.0<br /> *<br /> */<br />public class DateJob extends QuartzJobBean {<br /><br /> private DateService getDateService(JobExecutionContext jec) {<br /> try {<br /> <br /> ApplicationContextHolder ach = (ApplicationContextHolder) jec.getScheduler().getContext().get("applicationContextHolder");<br /> return (DateService) ach.getApplicationContext().getBean("controledBridgeDateService");<br /> <br /> } catch (SchedulerException e) {<br /> throw new RuntimeException("Erro ao objeto o parametro 'applicationContextHolder' do contexto do scheduler do quartz. ");<br /> }<br /> }<br /><br /> @Override<br /> protected void executeInternal(JobExecutionContext jec) throws JobExecutionException {<br /> try{<br /> <br /> System.out.println("DataService: " + getDateService(jec).getDate() );<br /> <br /> }catch(ApplicationStopedException ase){<br /> System.out.println(ase.getMessage());<br /> }<br /> <br /> }<br /><br />}<br /><br />

Este job do quartz usa o serviço de datas através da interface DateService. Ele obtém este bean com o bean utilitário que falei acima no método getDateService(). No final das contas o service que esta sendo utilziado por este job não é o DateServiceImpl que foca apenas na implementação do contrato e na lógica de negócio. O bean utilizado aqui é o ControledBridgeDateService que além de chamar o serviço de datas real implementa o contrato para parar e iniciar este serviço.

Sempre é uma boa prática de design seprar este tipo de código do código de negócio eu fiz isto usando a classe ControledBridgeDateService através do pattern bridge do GOF.

Agora vamos ver a configuração do Spring, confira o XML a baixo:

<br /><?xml version="1.0" encoding="UTF-8"?><br /><beans xmlns="http://www.springframework.org/schema/beans" xsi="http://www.w3.org/2001/XMLSchema-instance" p="http://www.springframework.org/schema/p" aop="http://www.springframework.org/schema/aop" context="http://www.springframework.org/schema/context" jee="http://www.springframework.org/schema/jee" tx="http://www.springframework.org/schema/tx" schemalocation=" http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"><br /> <aop:aspectj-autoproxy><br /><br /> <bean id="simpleJoDetail" class="org.springframework.scheduling.quartz.JobDetailBean" init="false"><br /> <property name="jobClass" value="com.blogspot.diegopacheco.springquartz.job.DateJob"><br /> </bean><br /><br /> <bean id="simpleCronTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean"><br /> <property name="jobDetail" ref="simpleJoDetail"><br /> <property name="cronExpression" value="0/2 * * * * ?"><br /> </bean><br /><br /> <bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"><br /> <property name="triggers"><br /> <list><br /> <ref bean="simpleCronTrigger"><br /> </list><br /> </property><br /> <property name="schedulerContextAsMap"><br /> <map><br /> <entry key="applicationContextHolder" ref="applicationContextHolder"><br /> </map><br /> </property><br /> </bean><br /> <br /> <bean id="applicationContextHolder" class="com.blogspot.diegopacheco.springquartz.job.ApplicationContextHolder"><br /><br /></beans><br /><br />

JobDetailBean é uma classe utilitária do Spring para criarmos jobs do Quartz. Você indica o job a ser criado pela propriedade jobClass. Depois é configurado um CronTriggerBean que agenda a sexecução de um JobDetailBean com um cron expression. Por fim configuramos um SchedulerFactoryBean informado o CronTrigger configurado anteriormente e através do atributo schedulerContextAsMap passamos detalhes para o contexto do job do quartz, neste caso apénas é passado o applicationContextHolder que é a classe utiliária para obter o contexto do Spring de dentro de job do quartz.

OK. Agora é só fazer o deploy da aplicação no Weblogic. Para isso usei maven conforme a configuração do POM que segue a baixo.

<br /><project xmlns="http://maven.apache.org/POM/4.0.0" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"><br /> <modelversion>4.0.0</modelversion><br /> <groupid>com.blogspot.diegopacheco.sandbox.java</groupid><br /> <artifactid>spring-jmx-weblogic-ear</artifactid><br /> <name>spring-jmx-weblogic-ear</name><br /> <version>1.0-SNAPSHOT</version><br /> <packaging>ear</packaging><br /> <description>spring-jmx-weblogic-ear</description><br /><br /> <build><br /> <plugins><br /> <plugin><br /> <groupid>org.apache.maven.plugins</groupid><br /> <artifactid>maven-compiler-plugin</artifactid><br /> <configuration><br /> <source>1.6</source><br /> <target>1.6</target><br /> <encoding>UTF-8</encoding><br /> </configuration><br /> </plugin><br /> <plugin><br /> <inherited>true</inherited><br /> <groupid>org.apache.maven.plugins</groupid><br /> <artifactid>maven-source-plugin</artifactid><br /> <executions><br /> <execution><br /> <id>attach-sources</id><br /> <goals><br /> <goal>jar</goal><br /> </goals><br /> </execution><br /> </executions><br /> </plugin><br /><br /> <plugin><br /> <groupid>org.apache.maven.plugins</groupid><br /> <artifactid>maven-ear-plugin</artifactid><br /> <version>2.3.2</version><br /> <configuration><br /> <displayname>spring-jmx-weblogic-ear</displayname><br /> <description>spring-jmx-weblogic-ear</description><br /> <version>1.4</version><br /> <modules><br /> <webmodule><br /> <groupid>com.blogspot.diegopacheco.sandbox.java</groupid><br /> <artifactid>spring-jmx-weblogic</artifactid><br /> <contextroot>spring-jmx-weblogic</contextroot><br /> </webmodule><br /> </modules><br /> </configuration><br /> </plugin><br /> <plugin><br /> <groupid>org.codehaus.cargo</groupid><br /> <artifactid>cargo-maven2-plugin</artifactid><br /> <configuration><br /> <container><br /> <containerid>weblogic103x</containerid><br /> <home>D:\\Diego\\Java\\bin\\ORACLE\\bea\\wlserver_10.3</home><br /> <log>${project.build.directory}/cargo.log</log><br /> <output>${project.build.directory}/output.log</output><br /> </container><br /> <configuration><br /> <type>existing</type><br /> <home>D:\\Diego\\Java\\bin\\ORACLE\\bea\\wlserver_10.3\\samples\\domains\\wl_server</home><br /> <properties><br /> <cargo.weblogic.domain>wl_server</cargo.weblogic.domain><br /> <cargo.weblogic.server>wl_server</cargo.weblogic.server><br /> <cargo.weblogic.administrator.user>weblogic</cargo.weblogic.administrator.user><br /> <cargo.weblogic.administrator.password>weblogic</cargo.weblogic.administrator.password><br /> <cargo.servlet.port>80</cargo.servlet.port><br /> <cargo.logging>high</cargo.logging><br /> </properties><br /> </configuration><br /> </configuration><br /> <executions><br /> <execution><br /> <id>start-container</id><br /> <phase>pre-integration-test</phase><br /> <goals><br /> <goal>deploy</goal><br /> </goals><br /> </execution><br /> </executions><br /> </plugin><br /> </plugins><br /> </build><br /><br /> <dependencies><br /> <dependency><br /> <groupid>com.blogspot.diegopacheco.sandbox.java</groupid><br /> <artifactid>spring-jmx-weblogic</artifactid><br /> <version>1.0-SNAPSHOT</version><br /> <type>war</type><br /> </dependency><br /> </dependencies><br /><br /></project><br /><br />

Eu criei dois projeto do maven são eles:

• spring-jmx-weblogic: Que é uma aplicação Web, os fontes que mostrei neste post estão neste projeto.
• spring-jmx-weblogic-ear: É outro projeto que contem o empacotamento e o deploy do EAR no Weblogic, o pom que você viu acima fica aqui.

Agora basta rodar: mvn clean install nestes dois projetos e pronto. Apénas coisa para que o Weblogic ja esteja no ar quando você rodar o clean install do projeto spring-jmx-weblogic-ear.

Agora abra o JConsole. Você faza isso executando o jconsole.exe que fica na pasta bin da instalação do seu JDK. Conecte no processo local chamado de weblogic.Server. Va na sessão dos MBeans e procure por bean, lá você vai ver os beans expotos pelo Spring.

Você pode testar indo em ControledBridgeDateService e operations, que na prática são os métodos que foram expostos via Spring. Primeiro clique em stop e verifique se a aplicação mudou a mensagem no log do Weblogic e depois clique em start a mensagem deve mudar de novo.




Spring sempre prove facilidades para integração do seu modelo de desenvolvimento de serviços com as tecnologias java como JMX e soluções abertas como o Quartz, você pode usar essa solução para diversos aspectos de sua aplicação em termos de monitoramento e gerenciamento.

Se você quiser pode obter os fontes completos da aplicação no meu repositório do Subversion nos seguintes endereços:

• http://diegopacheco.svn.beanstalkapp.com/sandbox/trunk/spring-jmx-weblogic
• http://diegopacheco.svn.beanstalkapp.com/sandbox/trunk/spring-jmx-weblogic-ear

Até a próxima, abraços.

Leia Mais…

Quando estamos falando de mudanças em um projeto de desenvolvimento de software existe uma grande necessidade de saber no que essa mudança irá impactar. Esse impacto pode ser encarados de várias formas.

Você precisa saber o impacto da mudança em termos de requisitos, design e até código. É importante ter esse conhecimento para poder dimensionar a mudança e ver a forma certa de lidar com a mesma. Todas essas questões tem impacto direto na gestão do projeto, por que dependendo da mudança vai demandar mais recursos, tempo e complexidade.

Uma ferramenta de requisitos deve tratar com essas questões. Muitas ferramentas analisam o impacto somente a nível de requisitos, de facto isso não é o suficiente por que na pratica vai demandar toda uma analise manual de um projetista ou analista.

Neste post vou mostrar como podemos fazer analise de impacto em dois níveis com a ferramenta Enterprise Architect ou famoso EA. No primeiro nível vou mostrar o impacto entre Requisitos funcionais e casos de uso e em segundo nível mostrarei o impacto dos casos de uso para o código fonte.



Análise de Impacto sempre tem um custo

Esta é uma verdade universal. Você sempre terá um custo com a analise de impacto, ou seja, ela nunca vem de graça. Para poder consultar a ferramenta(EA) e saber o impacto você tem que manter o diagrama de impacto atualizado, isso tem um custo e é mais uma coisa a se preocupar.

Se você não realizar essa tarefa não hora da mudança terá o custo de atualizar a ferramenta, isso pode ser tão custoso que não se pague fazer essa tarefa e você pode acabar tendo que fazer a analise na mão.

Não fazer analise de impacto é um risco, você pode se surpreender com a mudança. Em projetos pequenos não é necessário o uso desta prática, mas em projeto de médio e grande porte onde a complexidade começa a aumentar essa prática mostra ter muito valor.

Exemplo prático no EA

Irei mostrar isso de forma muito simples. Não liguem para a veracidade dos dados. O objetivo aqui é mostrar na prática como usar este recurso, então vamos a estrutura do projeto. No projeto de exemplo EA-Matriz-Impacto, existem as seguintes visões top level:

• Requisitos
• Código
  
• Matriz Impacto

Requisitos é aonde estão os requisitos funcionais e bem com os casos de uso, lembrando que casos de uso são requisitos, mais conhecidos como requisitos do usuário.

Código é aonde estão os fontes de aplicação, não tive o trabalho de definir métodos e atributos nas classes, você podem perceber que eu coloquei em uma estrutura que é padrão do maven 2. Isso foi de propósito.

Neste exemplo apesar da estrutura do maven, poderia ser construído com qualquer linguagem como por exemplo PHP, .NET, Python essas são linguagens que assim como Java o EA faz engenharia reversa e pode sincronizar os fontes com os seus diagramas.

Matriz Impacto é aonde está a matriz que liga os requisitos aos fontes. Como esse é um exemplo usei um único diagrama para isto. Somente em projetos pequenos isso é viável. Em projetos maiores você terá que ter diversos diagramas para mapear a realização dos seus requisitos para o código.

Os Requisitos

Leia Mais…

Os requisitos não vieram de hoje, a sua necessidade já foi confirmada a muito tempo, mas ainda é comum ver empresas que falam aos 4 ventos que trabalham com requisitos e na verdade não sabem diferenciar um requisito de uma Constraint.

Neste post vou falar mais de requisitos, dizendo o que são e o que não são requisitos, bem como qual a relação deles com as Constraints, pretendo falar um pouco mais dos tipos de requisitos e quanto tempo devemos gastar com requisitos.

O Que é um Requisito?

Um requisito tem que atender a duas premissas básicas, se você não atender a essas duas premissas, logo você não tem um requisito. Vamos então:

• Condição ou capacidade necessitada pelo usuário para realizar algum objetivo ou resolver algum problema. E o mais importante Desejado.
  
• O usuário tem que poder perceber, ou seja, Observado Externamente.

Se não satisfaz esses itens acima, não é um requisito, infelizmente muitos analistas nem sabem o que é isso. Muitos viram do velho modelo em que o analista de Sistemas era o "cara" e hoje em dia não é mais, alguns consideram que ele perdeu seu papel.



Os Requisitos não estão na sua cara...

Levantar requisitos não significa ouvir o usuário, não é simples assim. Na verdade você tem que descobrir o que o usuário deseja de verdade e isso não é fácil. Existem algumas técnicas para você fazer isso, pretendo fazer isso em outros posts.

Muitas vezes o cliente não tem tempo para fornecer as informações necessárias ao analista de Requisitos, isso acontece mais ainda quando a sua empresa é de TI e o seu cliente não é de TI, em empresas onde existe um equipe de TI interna é mais fácil obter informações dos usuário.

Não é fácil levantar requisitos e um requisito mal levantando gera muita dor de cabeça e custos adicionais no futuro, neste caso se você trabalha em um equipe de TI interna isso gera mais stress, agora se você esta em um empresa TI e o seu cliente não é de TI e você está em escopo fechado em termos de custo não é um problema para sua empresa, mas para o cliente sim, isso ocorrendo com muita freqüência pode levar ao fracasso do projeto.

E não adianta ficar só reclamando do cliente, ele pode não colaborar 100% e ajudar na elicitação, logo seus requisitos seriam bem vagos, mas seu software tera que ser especifico e detalhado, logo é bom gastar o tempo suficiente nesta tarefa mesmo que isso signifique educar o cliente.

O Analista não tem que ser Técnico...

O Caramba!!! É comum ver por ai o pensamento de que só quem é desenvolvedor tem que ser técnico, como se o o gerente e analistas não precisam ser técnicos. O Gerente tem que ser técnico em gestão e bem como o analista de Requisitos tem que ser técnico em Requisitos.

Ser técnico nestes dois casos significa conhecer práticas, técnicas, métodos, padrões, etc... Isso tudo não vem só com a prática, você precisa de estudo, só estudando que você obtém essas coisas, mas só com a prática que você aprende a usar da forma correta.

Requisitos não são a Solução

Você não usa requisitos para definir a solução, ou seja, vai ser em Java, vou usar MVC básico e tudo vai rodar no JBoss 5. Se existem essas questões que falei agora elas são tratadas como restrições e não requisitos, logo elas devem ser mapeadas como Constraints. Para poder lidar bem com essas questões junto com os requisitos, falando de gestão de requisitos é necessário uma boa ferramenta de requisitos.

Requisitos como Centro de Tudo

Métodos de desenvolvimento de software como RUP e OpenUP são focados em requisitos através de Casos de uso. Utilizam casos de uso por que casos de uso são bons para representar a perspectiva do usuário e favorecem um contexto muito bom. O TOGAF que é um método de Arquitetura Corporativa também é focado em requisitos, tanto para o TOGAF como para o RUP/OpenUP a Arquitetura é construída a partir do Requisitos.

Arquitetura de Software que é construída sem requisitos não é arquitetura, em projetos pequenos essa abordagem errante pode funcionar em alguns casos, mas em outros casos de projetos mais complexos pode gerar o muitos problemas e até mesmo o fracasso do projeto.

Telas são importantes, bem como boas amigas aliada as técnicas de prototipação para ajudar a validar e considerar informações com o usuário, mas telas e botões são solução e não são requisitos.

Requisitos nunca são perfeitos e não existe um tempo certo pre determinado para ser gasto com isso, se você trabalha de forma iterativa incremental essa questão não é um problema, agora em um projeto de escopo fechado com tempo e recursos fechados isso pode ser um problema.

Tipos de Requisitos

Existem os dois tipos clássicos de requisitos que são os Funcionais e os Não-Funcionais. Os Requisitos funcionais são específicos dos produto, ou seja, se referem a o que o sistema deve fazer em termos de funcionalidades para o negocio do seu cliente. Já os requisitos não Funcionais são as qualidades que o seu produto deve ter, ou seja, quanto tempo é aceitável para dar retorno ao usuário em uma consulta, qual a disponibilidade mínima do sistema, entre outras questões.

Outro tipo de requisito é o Requisito candidato, este tipo pode ser utilizado no processo de elicitação de requisitos, você pode tratar primeiramente todos os seus requisitos como candidatos e tempos da validação e aceite do cliente ele vira um requisito de facto.

Requisitos de Usabilidade, quase ninguém usa ou sabe o que são. Assim como a preocupação com usabilidade é quase nula nos sistemas que existem por ai. Existem vários outros tipos, inclusive existem diversos padrões de requisitos como por exemplo: Estrutura de Dados, Aprovação, Avaliabilidade, Relatórios, etc... Se você quiser saber mais sobre esses padrões, pode conferir este livro: Software Requirement Patterns.

Fechando...

Analise, Desenvolvimento e Gestão de Requisitos é uma necessidade nas empresas que querem ter sucesso, isso é valido independente da tecnologia e metodologia de sua empresa. Requisitos não significam burocracia ou página de MS Word sem valor, mas sim o que o sistema deve fazer e o que o cliente precisa.

Para isso é necessário analistas de requisitos com capacitação para o mesmo, essa capacitação não vem só com a prática, logo precisamos aliar os estudos a prática. Levantar requisitos não é fácil e não se aprende a fazer isso apénas ouvindo o usuário, tem que se perguntar os porques das coisas.

Abraços e até a próxima.

Leia Mais…

Como Arquiteto de Software não posso deixar de olhar para as outras solução que estão fora do mundo Java. Desenvolver um sistema em Java pode trazer diversas vantagens mas também pode trazer complexidade e custo desnecessário.

Aplicações para empresas de pequenas e médio tamanho consideram o uso de PHP com solução para seus sistemas web, dependendo das características e dos requisitos do sistema eu considero o PHP como uma ótima solução. A evolução dos frameworks MVC em PHP foi muito boa nestes últimos anos.

O que é MVC mesmo?

É um padrão de arquitetura de software largamente utilizado em soluções para Web. Sua principal vantagem é a separação das telas(view) da camada de negócio(model). Você pode usar MVC em um sistema desktop, dependendo do sistema será uma boa escolha.

Neste post vou mostrar como pode ser fácil e rápido construir uma solução usando MVC com PHP, neste caso vou usar o framework CodeIgniter.

Por que não Java?

Por que dependendo do sistema seria só adicionar mais complexidade e custo, desenvolver um sistema em Java é mais caro, isso não significa que devemos fazer todos os sistemas em PHP, mas sempre temos que balancear e a escolha da tecnologia tem que sempre que levar a complexidade do sistema em conta.

Code Igniter...

Com esse framework em PHP você verá como que é fácil e simples de desenvolver um sistema MVC de qualidade com pouca configuração. Vou mostrar um exemplo simples, mas será o suficiente para que o leitor veja as facilidades e a qualidade da solução.



Requisitos

• PHP 5.2
• Apache 2.2
• Mysql 5
• Code Igniter 1.7.1

Não entrarei nos detalhes de como instalar e configurar o PHP no Apache com suporte a Mysql. Para instalar o Code Igniter basta extrair o framework dentro da sua pasta onde você esta listando as paginas no Apache.

Vamos mexer na pasta application que fica no caminho CodeIgniter_1.7.1\system\application. Primeiro criarei o Controller. Para criar um model basta ir na pasta models e criar uma página PHP. Confira o código a baixo:

test_model.php

<br /><?php <br /> <br />class Test_model extends Model { <br /> <br /> var $id = ''; <br /> var $nome = ''; <br /> var $endereco = ''; <br /> <br /> function Test_model(){ <br /> parent::Model(); <br /> } <br /> <br /> function get_last_ten() <br /> { <br /> $query = $this->db->get('pessoa', 10); <br /> return $query->result(); <br /> } <br /> <br />} <br /> <br />?> <br />

Existem algumas formas de nomear uma classe model, a classe model é responsável pela regras de negócio e acesso ao banco de dados. Repare que o nome da classe é igual o nome do arquivo(test_model.php) só que com a primeira letra em maiúscula.

Os atributos com "var $" são referentes aos atributos que existem no banco de dados, neste exemplo existe o método get_last_ten que retorna os últimos registros da tabela pessoa do banco de dados.

Criei um banco de dados no mysql com 1 tabelinha. Segue o script do banco:

<br />-- phpMyAdmin SQL Dump<br />-- version 3.2.0<br />-- http://www.phpmyadmin.net<br />--<br />-- Host: localhost<br />-- Generation Time: Jul 04, 2009 at 07:54 PM<br />-- Server version: 5.0.67<br />-- PHP Version: 5.2.10<br /><br />SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";<br /><br />--<br />-- Database: `test`<br />--<br /><br />-- --------------------------------------------------------<br /><br />--<br />-- Table structure for table `pessoa`<br />--<br /><br />CREATE TABLE IF NOT EXISTS `pessoa` (<br /> `id` int(11) NOT NULL auto_increment,<br /> `nome` varchar(30) NOT NULL,<br /> `endereco` varchar(150) NOT NULL,<br /> PRIMARY KEY (`id`)<br />) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;<br /><br />--<br />-- Dumping data for table `pessoa`<br />--<br /><br />INSERT INTO `pessoa` (`id`, `nome`, `endereco`) VALUES<br />(2, 'Diego', 'GTI Centro'),<br />(3, 'Bruna', 'Centro Viamao');<br />

Agora que temos o model e o banco vamos ao Controller que controla tudo, para isso basta criar outra página PHP no diretório CodeIgniter_1.7.1\system\application na parte de controllers.
Confira o código do controller a baixo:

test.php

<br /><?php <br /> <br />class Test extends Controller { <br /> <br /> function Test() { <br /> parent::Controller(); <br /> } <br /> <br /> function index(){ <br /> <br /> $data = array( <br /> 'nomeApp' => 'CodeIgnitorAppTest', <br /> 'developer' => 'Diego Pacheco' <br /> ); <br /> <br /> $this->load->view('test',$data); <br /> } <br /> <br /> function listar(){ <br /> <br /> $data = array( <br /> 'nomeApp' => 'CodeIgnitorAppTest', <br /> 'developer' => 'Diego Pacheco' <br /> ); <br /> <br /> $this->load->model('Test_model','myModel'); <br /> $data['query'] = $this->myModel->get_last_ten(); <br /> $this->load->view('test', $data); <br /> } <br />} <br /> <br />?> <br />

Algumas explicações, o método index é executado por padrão, cada método desta classe poderá ser acessível quando você acessa pelo browser

http://localhost/CodeIgniter_1.7.1/index.php/nomeDoController/nomeDoMetodo/parametros

Logo digitando http://localhost/CodeIgniter_1.7.1/index.php/test você entra na aplicação acessando o método padrão chamado index. No método index estou criando uma variável chama de data que é um array e dentro desse array estou passando dois parâmetros. Também estou mandando carregar a view chamada de test.

Vamos ao código da View... Confira o código a baixo:

test.php

<br /><html><br /><head><br /><title>Primeira View com CodeIgniter</title><br /></head><br /><body><br /><br /><h1>View gerada pelo CodeIgniter!</h1><p><br /><br /><b><?=$nomeApp;?></b> Desenvolvida por: <b><?=$developer;?></b><br /><br /><br /><br /><br /><?php if(isset($query)) { ?><br /><br /><h3>Lista de Pessoas</h3> <br /><ul><br /><br /><?php foreach($query as $item):?><br /><li> <?php echo $item->id;?> | <?php echo $item->nome;?> </li><br /><?php endforeach; }else{ echo "<a href="'test/listar'">Listar Pessoas</a>"; } ?><br /><br /></ul><br /><br /><br /><br /><br />Página renderizada em {elapsed_time} segundos</p><br /><br /></body><br /></html><br />

A página deve estar dentro de CodeIgniter_1.7.1\system\application views. Como pode ver é uma página html com blocos de código PHP, e usuário clicar em listar o framework ira chamar o controller no método listar que ira chamar o model pegando os registros da tabela pessoa e voltando ao controler que repassa isso a view pela variável $query.

Para que toda essa aplicação funcione você deve configurar o acesso ao banco de dados e carregar as bibliotecas para isso entre na pasta config e edite o arquivo autoload.php e procure pela linha $autoload['libraries'] = array(); e substitua e mesma por: $autoload['libraries'] = array('database'); Assim estamos carregando o módulo de banco de dados.

Agora só falta configurar o acesso ao banco, abra o arquivo database.php também na pasta config, neste caso como é um exemplo estou com a instalação default sem senha do root, mas isso não é aconselhável para sua aplicação.

<br />$active_group = "default";<br />$active_record = TRUE;<br /><br />$db['default']['hostname'] = "localhost";<br />$db['default']['username'] = "root";<br />$db['default']['password'] = "";<br />$db['default']['database'] = "test";<br />$db['default']['dbdriver'] = "mysql";<br />$db['default']['dbprefix'] = "";<br />$db['default']['pconnect'] = TRUE;<br />$db['default']['db_debug'] = TRUE;<br />$db['default']['cache_on'] = FALSE;<br />$db['default']['cachedir'] = "";<br />$db['default']['char_set'] = "utf8";<br />$db['default']['dbcollat'] = "utf8_general_ci";<br />

E pronto agora temos uma mini aplicação MVC com o Code Igniter o bom é que isso pode ser feito em menos de 5 mim e com uma excelente qualidade; Estou desenvolvendo uma aplicação com esse framework e mais para frente mostro outras facilidades.

Abraços.

Leia Mais…

Quando falamos de SOA é inevitável falar de Serviços. Eles são a base de SOA, na indústria de software existe grande confusão e discórdia sobre esse assunto. Neste post vou falar qual é a minha perspectiva sobre o assunto, vou comentar o que eu considero um serviço e o que eu não considero um serviço.

Também vou falar sobre os tipos de serviços e como podemos implementar cada um deles, neste ponto existe bastante confusão e o pior existe uma forte junção disto ferramental e soluções prioritárias, comentarei isso mais para frente.



O Que é um Serviço?

Separando Infra do Negócio

Ainda pensando que vamos implementar os serviços em java, como poderíamos fazer essa separação. A resposta é simples, interfaces. Você deve usar interfaces em Java como contratos, que por sinal podem ser usadas em Webservices. Mas o mais importante e o que eu nunca vi ninguém no mercado fazer: Design de jars.

Você tem que modelar os módulos da sua aplicação em componentes, separando os módulos por responsabilidades o apache maven 2 ajuda muito nisso, mas tudo pode ser feito com diagramas da UML o problema é que ninguém faz esse tipo de design, logo as coisas começam a ficar acopladas, misturadas, bagunçadas e ai serviços acabam por se misturar por código de arquitetura e infra e ai a bagunça está feita.

Onde Ficam os Serviços?

Essa é uma questão hilariante, muitos gerentes falam de SOA hoje em dia, porem poucos falam a onde os serviços vão ficar, acho que o pessoal pensa que os serviços vão ficar no limbo e que essa questão não importa tanto, a questão aqui é simples.

Serviços não ficam no limbo, eles vão estar dentro de uma aplicação, dentro de um container JEE, dentro de um contexto do Spring publicado em uma aplicação JSE, etc. Isso é importante por que você tem que saber que serviços tem, tem que se preocupar com transação e principalmente com segurança.

Essa questão é deixada de lado por que existem muitos arquitetos que ao falar de SOA vem WS na cabeça deles como única forma de implementação e ai eles pensam a eu todo tudo no UDDI e deu já eras isso. Esse é um erro comum e que vai dar dor de cabeça quando se percebe-se que nem tudo pode ser feito com Webservices por que não compensa ou por que não se paga o custo ou por que o sistema é muito velho e não tem esse recurso.

E a Transação...

Sou obrigado a falar de transação com Serviços, vamos por partes transação local no mesmo sistema pode ser utilizada sem problemas por que a principio não será um gargalo mas como disse antes depende muito do sistema.

Agora o problema é que ainda vejo arquitetos falando de transação distribuída com SOA e isso é um grande problema. O Comite de duas fases é um inimigo da performance, sistemas distribuídos tem problemas para escalar com transações distribuídas e tem mais nem sempre você pode ter isso por que nem todos os recursos são transacionados, o pessoal esquece disso :)

Transação distribuída em ambientes heterogêneos envolvendo várias linguagens e plataformas, hahahahahaha que piada. :)

Em SOA a abordagem padrão para isso é a Compensação eu já utilizei essa abordagem com BPEL sem problemas, então basicamente pode se fazer dois tipos de compensação.

No primeiro tipo o sistema chamador tem que dar um jeito de corrigir os dados inconsistentes no outro sistema, isso pode ser feito pela invocação de rotinas, componentes genéricos que apagam dados no sistema com inconsistências.

No segundo tipo o usuário corrige essas inconsistências, teve um sistema que fiz onde de uma lado existia um sistema Java com Spring e Hibernante que falava através de uma fila JMS e do outro lado um sistema clipper que falava através de arquivos texto, com BPEL foi gerado uma Human Task para apresentar os problemas ao usuário para ele corrigir.

Por default não sou contra a transação distribuída, mas o cenário para sua utilização tem que ser olhado com muita cautela. Os serviços podem utilizar transação local como falei antes, pode ser usando até um TransactionManager do Spring.

Abraços e até a próxima.

Leia Mais…

No post anterior mostrei como criar um Webservice wsdl de forma fácil usando Spring Framework, Apache CXF, Anotações e tudo isso rodando no servidor da ORACLE o Weblogic. Nesse post vou mostrar como é simples de consumir o mesmo Webservice do exemplo anterior usando Groovy.

Para isso vamos precisar do module do Groovy chamado de GroovyWS, você precisa baixar a solução aqui. Vou usar o mesmo Webservice construído no post anterior que esta aqui: http://localhost:7001/spring-cxf-pojo/DateService?wsdl eu instalei direto no diretório $GROOVY_HOME/lib e colei o jar groovyws-standalone-0.5.0.jar.

Agora basta executar o seguinte código, eu fiz isso pelo groovyConsole mesmo, tente você também:
<br />/**<br /> * Script Groovy que faz o consumo de um Webservice WSDL com groovy usando o module de GroovyWS.<br /> * <br /> * @autor Diego Pacheco<br /> * @since 15/06/2009<br /> * @version 1.o<br /> * <br /> */<br />import groovyx.net.ws.WSClient<br /><br />proxy = new WSClient("http://localhost:7001/spring-cxf-pojo/DateService?wsdl", this.class.classLoader)<br />proxy.initialize()<br /><br />result = proxy.getDate()<br />print "O Resultado do WS eh: ${result}"<br />

Por isso que adoro Groovy é simples, muito produtivo, adoro Groovy. Bom nesse código eu instancio a classe WSClient passando a localização do WSDL do Webservice que quero consumir e o classloader. Depois mando inicializar o proxy, por fim executo o método que eu quero do Webservice, no caso o método tem que existir no Webservice, usei único método que é o getDate(). Ainda mostrei o resultado no console.

Em outro post eu mostro como construir Webservices com Groovy, até a próxima.
Abraços.

Leia Mais…

WebServices é um padrão aberto que é muito utilizado, porem fazer um WebService escrevendo a WSDL pode ser uma tarefa pesada, usar ferramentas pode ser uma boa, mas isso pode gerar uma dependência com seu fornecedor de ferramentas. Vou mostrar como pode ser fácil e simples criar um Webservice com WSDL, sem você ter que criar uma linha de WSDL, como?

Usando duas excelentes soluções de mercado, Apache CXF veio do bom e velho XFire,Tempos passado eu fiz um poste sobre Spring e XFire, para dar mais facilidade, produtividade, simplicidade e outros tantos recursos vamos usar isso tudo em conjunto com o Spring Framework. Vamos fazer tudo isso usando anotações, no final você vai ver que com 6 arquivos, vamos fazer uma solução muito simples.

Não se preocupe para cada Webservice você não precisara criar 6 arquivos, por que 2 desses arquivos são o pom.xml do maven de dois projetos e um arquivo é o web.xml. Outro arquivo é um xml de beans do spring que pode ser reutilizado na criação de outros serviços des de que você vá adicionado mais definições dele.

Nesse exemplo além de usar Spring 2.5, Apache CXF 2.2 vou usar Maven 2 com o plugin do Cargo para fazer o deploy no ORACLE Weblogic 10.3, o servidor foi escolhido por que é muito robusto é fácil de fazer o deploy com maven.

Por fim vamos testar o Webservice de duas formas, a primeira dela escrevendo um client em Java usando o Apache CXF, Spring e Maven. Na segunda forma vou usar a ferramenta SoapUI que é excelente ferramenta para testes com WebServices.



Vamos ao código então, primeiro vamos a interface java que será exposta como Webservice, o legal do apache CXF é que ele vai gerar quase todo o mapeamento para o WSDL de forma automática, você ainda pode parametrizar informações via anotações se preferir ou tiver essa necessidade, no meu exemplo vou fazer o uso mais simples dessa solução.

DateService.java
<br />package com.blogspot.diegopacheco.spring.cxf.service;<br /><br />import javax.jws.WebService;<br /><br />/**<br /> * Interface do Serviço de datas.<br /> *<br /> * @author Diego Pacheco<br /> * @version 1.0<br /> * @since 13/06/2009<br /> *<br /> */<br />@WebService<br />public interface DateService {<br /> String getDate();<br />}<br />

Aqui é uma interface java normal com uma anotação do JAX-WS que indica o uso de Webservices, vamos a implementação do serviço e do Webservice por conseqüência. Como o leitor pode perceber eu adoro criar serviços de datas, não são serviços propriamente ditos se estivermos falando de SOA por exemplo, nos meus exemplos faço isso para simplificar as coisas só por isso :)

DateServiceImpl.java
<br />package com.blogspot.diegopacheco.spring.cxf.service;<br /><br />import java.util.Date;<br /><br />import javax.jws.WebService;<br /><br />/**<br /> * Implementação do Serviço de datas.<br /> *<br /> * @author Diego Pacheco<br /> * @version 1.0<br /> * @since 13/06/2009<br /> *<br /> */<br />@WebService(endpointInterface = "com.blogspot.diegopacheco.spring.cxf.service.DateService")<br />public class DateServiceImpl implements DateService {<br /><br /> public String getDate() {<br /> return new Date().toString();<br /> }<br />}<br />

Essa é a implementação do serviço de datas, como você pode reparar ele retorna a data/hora corrente do servidor aonde o Webservice esta publicado, isso será interessante para os testes, por que sempre tem que vir um valor diferente a cada chamada.

Nesta classe foi utilizada novamente um anotação padrão do JAX-WS para indicar qual a interface que esse serviço está implementado. Agora vamos a configuração do Spring juntamente com a configuração do Apache CXF.

spring-cxf-beans.xml
<br /><?xml version="1.0" encoding="UTF-8"?><br /><beans xmlns="http://www.springframework.org/schema/beans" context="http://www.springframework.org/schema/context" xsi="http://www.w3.org/2001/XMLSchema-instance" jaxws="http://cxf.apache.org/jaxws" schemalocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"><br /><br /> <!-- Faz um scan nos services anotados --><br /> <context:component-scan package="com.blogspot.diegopacheco.spring.cxf.service"><br /> <context:include-filter type="annotation" expression="javax.jws.WebService"><br /> </context:component-scan><br /><br /> <!-- Load CXF modules from cxf.jar --><br /> <import resource="classpath:META-INF/cxf/cxf.xml"><br /> <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"><br /> <import resource="classpath:META-INF/cxf/cxf-servlet.xml"><br /><br /> <!-- Configurações JAX-WS do WS --><br /> <jaxws:endpoint id="dateService" implementor="#dateServiceImpl" address="/DateService"><br /></beans><br />

Preciso explicar apenas 3 coisas nesse XML. A primeira é 'context:component-scan', com isso o spring registra os beans automaticamente des de que eles estejam devidamente anotados com as anotações do Spring Framework, ainda estou adicionado um filtro para ele pegar os beans com anotações do JAX-WS também. Se eu tivesse outros beans ou esses mesmos que fiz com anotações @Service ou @Component o spring ira registra-los também.

Esse é um recurso muito bom do Spring Framework que aumenta consideravelmente a produtividade, em contra partida perdemos um pouco a extensibilidade, pois para modificar os beans vamos ter que mexer no código :(

O Segundo ponto que vou explicar são os 3 imports de recursos que estão no jar do apache CXF, são necessários para o funcionamento da solução, antes esse tipo de configuração era feito na mão criando esses 3 arquivos com as configurações, com a evolução das coisas chegamos a essa solução que é prática e fácil.

Por fim o terceiro ponto que devo explicações a vocês é o 'jaxws' aonde são passadas algumas configurações para o Webservice como a implementação e o mais importante o atributo 'address' que sera utilizado no endpoint do WS para ser acessado pelos clientes.

Para expor esse Webservice no ORACLE Weblogic vamos ter que empacotar esses fontes em um war, no final do post eu dou o link para o meu repositório do Subversion onde vocês podem pegar os fontes completos com os códigos do maven para empacotamento do WAR e deploy do EAR no ORACLE Weblogic.

Vamos ver como fica o Web.xml desse projeto war aonde estão os serviços que serão expostos como Webservice, confira o arquivo a baixo:

web.xml
<br /><?xml version="1.0" encoding="UTF-8"?><br /><br /><web-app id="WebApp_springcxf" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"><br /><br /> <context-param><br /> <param-name>contextConfigLocation</param-name><br /> <param-value>WEB-INF/spring-cxf-beans.xml</param-value><br /> </context-param><br /><br /> <listener><br /> <listener-class><br /> org.springframework.web.context.ContextLoaderListener<br /> </listener-class><br /> </listener><br /><br /> <servlet><br /> <servlet-name>CXFServlet</servlet-name><br /> <servlet-class>org.apache.cxf.transport.servlet.CXFServlet<br /> </servlet-class><br /> <load-on-startup>1</load-on-startup><br /> </servlet><br /><br /> <servlet-mapping><br /> <servlet-name>CXFServlet</servlet-name><br /> <url-pattern>/*</url-pattern><br /> </servlet-mapping><br /></web-app><br />

Nesse arquivo foi configurado o Listener do Spring que carrega o contexto do Spring quando a aplicação é iniciada no container da ORACLE Weblogic, também é configurado o servlet do Apache CXF. Essa configuração é padrão não se preocupe muito com isso.

Uma vez que você faça o deploy do EAR com o maven no Weblogic agora basta consumir o seu Webservice, vou mostrar isso de duas formas a primeira com a ferramenta de testes para Webservices chamada SoapUI.

Abra a ferramenta SoapUI e crie um projeto novo com qualquer nome e informa a localização do WSDL, você pode pegar o WSDL nesse endereço: http://localhost:7001/spring-cxf-pojo/DateService?wsdl certifique-se de que o servidor esta no ar.

Vá no método getDate() e execute o request, se der tudo certo vocÊ receberá um retorno semelhante a esse da figura a baixo:

Leia Mais…

O Firefox continua a inovar com plugins. Recentemente eles lançaram as coleções, que são conjuntos de add-ons(plugins), já existem alguns prontos e você pode verificar isso no site oficial aqui.

Além disso agora você pode criar a sua coleção, para isso você tem que criar uma conta de usuário, isso é bom por que além de você não perder mais seus plugins pode deixar eles abertos para que as outras pessoas vejam a sua lista.

Eu criei a minha coleção de plugin já :) Vocês podem acessar a minha coleção neste link. Você pode saber mais sobre o assunto no blog da mozilla. Para criar a sua coleção você precisa do plugin gerenciador de coleções que pode ser instalado no firefox por aqui.

Aproveito para indicar 3 plugins para vocês, foram os 3 últimos que eu instalei :) São eles:

• WiseStamp - Email signature
• FoxTab
• Power Twitter

O WiseStamp gerencia as assinaturas de e-mail, e com ele você pode inserir a sua assinatura em qualquer página, muito útil para quem participa de muitos fóruns e discussões on-line. Já o FoxTab prove recursos em terceira dimensão para troca de abas no Firefox você faz isso apertando CTRL + ALT + TAB. Existem 5 tipos de visualização de abas no Foxtab. Por fim o Power Twitter é um prato cheio para quem usa o twitter pelo site, por que ele adiciona recursos de web 2.0 deixando o twitter mais ágil e colaborativo.

Por essas e outras que o Firefox continua sendo o melhor browser do mercado. Bom era isso pessoal até a próxima.

Leia Mais…

Faz alguns meses que um amigo(Cássio Dias) meu me indicou a solução de BPM do BizAgi, neste post vou falar um pouco mais dessa solução e da ferramenta free que eles possuem de modelagem de processos de negócio.

BizAgi tem uma solução de BPM, ou seja, um BPMS, essa solução completa é paga. O que é gratuito é a primeira parte do ciclo deles que é a modelagem, o BizAgi Process Modeler, que é 100% compatível com BPMN 1.1.

A Solução deles é completa, com simulação, BAM e tudo mais, nesse post não vou falar da solução completa de BPMS mas sim da ferramenta de Modelagem.



BizAgi Process Modeler

Com essa solução você pode fazer a identificação e design de processos que existem ou vão ser criados. O editor é muito parecido com o Office da Microsoft. Isso é bom por que aproveita o modelo mental dos usuário e faz com que o uso da ferramenta seja facilitado.


É muito fácil de desenhar um processo com essa solução, por que quando você clica em qualquer componente ele já dá as opções de continuação do fluxo no próprio componente deixando assim o desenho do fluxo muito fácil e muito ágil.

A Ferramenta conta diversas opções de exportação sendo elas: Imagem, Word, PDF, Visio e XPDL e melhor de tudo é portável, eu fiz o teste, funciona, o XPDL que ela gera é a última versão, no momento(09/06/2009) que é XPDL 2.1.

Ainda é possível validar se o seu fluxo está correto em termos de bpmn, ele mostra de maneira amigável onde estão os problemas fazendo assim como que os usuário especialistas de negócio consigam usar a solução de maneira fácil.

Já testei algumas solução de modelagem com BPMN sendo que eu acho a solução muito mais leve, fácil de usar, amigável e funcional do que as soluções de grandes players como IBM(Modeler), ORACLE(BPM Studio, Aris), Intalio(Studio). Outra noticia boa essa ferramenta está em português.

Neste post não estou avaliando a solução inteira de BPMS mas sim só a parte de modelagem e nesse ponto acredito que o editor da BizAgi é o melhor. Você pode fazer download do produto aqui.

Um Exemplo

Fiz um processo de exemplo fictício sem comprometimento com a realidade só para mostrar a solução. Veja o diagrama a baixo:

Processo de Exemplo

Esse é um processo simples, onde existe o cliente a empresa que aluga carros e o DETRAN que indica para a empresa que aluga carros se os locatários tem multas ou não. A ferramenta gerou esse XPDL que é portável, confira a baixo:

<br /><?xml version="1.0" encoding="utf-8"?><br /><package xmlns="http://www.wfmc.org/2008/XPDL2.1" xsi="http://www.w3.org/2001/XMLSchema-instance" xsd="http://www.w3.org/2001/XMLSchema" id="1c525c3b-4e00-44c5-bc47-240227981289" name="Alugar Carro" onlyoneprocess="false"><br /> <packageheader><br /> <xpdlversion>2.1</xpdlversion><br /> <vendor>BizAgi Process Modeler.</vendor><br /> <created>2009-06-09T22:42:03.0115306-03:00</created><br /> <description>Alugar Carro</description><br /> <documentation><br /> </packageheader><br /> <redefinableheader><br /> <author><br /> <version><br /> <countrykey>CO</countrykey><br /> </redefinableheader><br /> <externalpackages><br /> <participants><br /> <participant id="eabc718a-f017-457f-8526-f8d6690d6a1e" name="DETRAN"><br /> <participanttype type="ROLE"><br /> <description>São enviados os dados do cliente ao DETRAN e com esses dados ele verifics se existem multas ou não para esse cliente.</description><br /> </participant><br /> <participant id="98ab7f67-5032-4927-84c4-3ab7d50f9320" name="Cliente"><br /> <participanttype type="RESOURCE"><br /> <description>Cliente é quem deseja alugar um carro, para isso além do dinheiro ele deve apresentar seus dados.</description><br /> </participant><br /> </participants><br /> <pools><br /> <pool id="46f30f50-3cca-4cf1-9fcb-64adc9395ee3" process="9a46cbbd-3a96-4bf7-8760-52aa23cf270b" boundaryvisible="false"><br /> <lanes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="350" width="700" bordercolor="-16777216" fillcolor="-1"><br /> <coordinates xcoordinate="0" ycoordinate="0"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> </pool><br /> <pool id="17f67b85-0a96-4976-9289-f91a0c4eec26" name="Processo Alugar Carro" process="5e814461-5fcd-4682-8682-ef40e101be8e" boundaryvisible="true"><br /> <lanes><br /> <lane id="c3f86f06-0701-4566-8f93-1d82557e6ef3" name="Cliente" parentpool="17f67b85-0a96-4976-9289-f91a0c4eec26"><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="112" width="901" bordercolor="-11513776" fillcolor="-1315861"><br /> <coordinates xcoordinate="50" ycoordinate="0"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <documentation><br /> <extendedattributes><br /> </lane><br /> <lane id="fd8e5d5c-eb86-4ff8-84b7-5b4c776f8888" name="Empresa" parentpool="17f67b85-0a96-4976-9289-f91a0c4eec26"><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="137" width="901" bordercolor="-11513776" fillcolor="-1315861"><br /> <coordinates xcoordinate="50" ycoordinate="112"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <documentation><br /> <extendedattributes><br /> </lane><br /> <lane id="c21f0062-cdf5-4551-b337-36cfec76b53f" name="DETRAN" parentpool="17f67b85-0a96-4976-9289-f91a0c4eec26"><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="188" width="901" bordercolor="-11513776" fillcolor="-1315861"><br /> <coordinates xcoordinate="50" ycoordinate="249"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <documentation><br /> <extendedattributes><br /> </lane><br /> </lanes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="437" width="951" bordercolor="-16777216" fillcolor="-1"><br /> <coordinates xcoordinate="40" ycoordinate="34"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> </pool><br /> </pools><br /> <messageflows><br /> <associations><br /> <association id="bfc6fd80-8d88-43e1-a38d-c595c6dc756a" source="0b84e44b-13ef-414b-9b20-60558f2f7577" target="d1f19a69-9ca2-4ddc-bed7-8e627ebf06ab" name=""><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="275" ycoordinate="373"><br /> <coordinates xcoordinate="490" ycoordinate="373"><br /> <coordinates xcoordinate="490" ycoordinate="550"><br /> <coordinates xcoordinate="525" ycoordinate="550"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> <extendedattributes><br /> </association><br /> </associations><br /> <artifacts><br /> <artifact id="d1f19a69-9ca2-4ddc-bed7-8e627ebf06ab" artifacttype="Annotation" textannotation="A verficação de multas se da por um email ao DETRAN."><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="100" bordercolor="-2763307" fillcolor="-2763307"><br /> <coordinates xcoordinate="345" ycoordinate="400"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <documentation><br /> </artifact><br /> </artifacts><br /> <workflowprocesses><br /> <workflowprocess id="9a46cbbd-3a96-4bf7-8760-52aa23cf270b" name="Processo principal"><br /> <processheader><br /> <created>2009-06-09T22:42:03.0645306-03:00</created><br /> <description><br /> </processheader><br /> <redefinableheader><br /> <author>BizAgi Process Modeler.</author><br /> <version>1.0</version><br /> <countrykey>CO</countrykey><br /> </redefinableheader><br /> <activitysets><br /> <activities><br /> <transitions><br /> <extendedattributes><br /> </workflowprocess><br /> <workflowprocess id="5e814461-5fcd-4682-8682-ef40e101be8e" name="Processo Alugar Carro"><br /> <processheader><br /> <created>2009-06-09T22:42:03.0665306-03:00</created><br /> <description><br /> </processheader><br /> <redefinableheader><br /> <author>BizAgi Process Modeler.</author><br /> <version>1.0</version><br /> <countrykey>CO</countrykey><br /> </redefinableheader><br /> <activitysets><br /> <activityset id="0b84e44b-13ef-414b-9b20-60558f2f7577" name="Verifica multas" adhoc="true"><br /> <activities><br /> <transitions><br /> </activityset><br /> </activitysets><br /> <activities><br /> <activity id="68f09b69-dd94-4b24-89f5-e7115af0727b" name="Verifica os dados do cliente"><br /> <implementation><br /> <task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="253" ycoordinate="186"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="c49f25b6-cae6-4805-a5ad-93c50afdad1d" name="Nega locação"><br /> <implementation><br /> <task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="485" ycoordinate="58"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="bf987255-cec5-465e-8493-2ef8d70c3c15" name="Notifica o cliente por email"><br /> <implementation><br /> <task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="788" ycoordinate="55"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="1cf66f62-a7f4-4943-a643-175183210a73"><br /> <event><br /> <endevent result="Terminate"><br /> </event><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="30" width="30" bordercolor="-6750208" fillcolor="-1135958"><br /> <coordinates xcoordinate="678" ycoordinate="73"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="3bf962d4-dee5-447e-ae98-a5a9b9198f1a"><br /> <event><br /> <endevent result="Terminate"><br /> </event><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="30" width="30" bordercolor="-6750208" fillcolor="-1135958"><br /> <coordinates xcoordinate="928" ycoordinate="70"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="44077f3a-394e-4a4c-a05e-13d1e5892d07"><br /> <event><br /> <startevent trigger="Message"><br /> <triggerresultmessage><br /> </startevent><br /> </event><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="30" width="30" bordercolor="-10311914" fillcolor="-1638505"><br /> <coordinates xcoordinate="151" ycoordinate="75"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="c058750a-611f-40ee-9159-7cd8cd221513" name=""><br /> <route gatewaytype="AND"><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="40" width="40" bordercolor="-5855715" fillcolor="-52"><br /> <coordinates xcoordinate="491" ycoordinate="353"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="0c064927-1240-449d-9bf1-fb2adaeeef8b" name="Registro de negação por multas"><br /> <implementation><br /> <task><br /> <taskservice><br /> </task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="410" ycoordinate="190"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="2fc7d9a9-3958-442f-9958-df5da693a6d8" name="Registra Locação"><br /> <implementation><br /> <task><br /> <taskservice><br /> </task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="761" ycoordinate="200"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="b8b6b9d4-2d1a-410f-8320-346017bd95e4" name="Escolhe modelo e envia o pedido"><br /> <implementation><br /> <task><br /> <tasksend><br /> </task><br /> </implementation><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281"><br /> <coordinates xcoordinate="253" ycoordinate="60"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> <activity id="0b84e44b-13ef-414b-9b20-60558f2f7577" name="Verifica multas"><br /> <blockactivity activitysetid="0b84e44b-13ef-414b-9b20-60558f2f7577"><br /> <performers><br /> <documentation><br /> <extendedattributes><br /> <nodegraphicsinfos><br /> <nodegraphicsinfo toolid="BizAgi_Process_Modeler" height="60" width="90" bordercolor="-16553830" fillcolor="-1249281" expanded="false" expandedwidth="270" expandedheight="180"><br /> <coordinates xcoordinate="185" ycoordinate="343"><br /> </nodegraphicsinfo><br /> </nodegraphicsinfos><br /> <isforcompensationspecified>false</isforcompensationspecified><br /> </activity><br /> </activities><br /> <transitions><br /> <transition id="56f43044-1108-485a-86f4-e2588c8a8dc0" from="b8b6b9d4-2d1a-410f-8320-346017bd95e4" to="68f09b69-dd94-4b24-89f5-e7115af0727b" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="298" ycoordinate="120"><br /> <coordinates xcoordinate="298" ycoordinate="186"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="e72ae797-0a16-4b19-9e44-08929066a799" from="68f09b69-dd94-4b24-89f5-e7115af0727b" to="0b84e44b-13ef-414b-9b20-60558f2f7577" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="298" ycoordinate="246"><br /> <coordinates xcoordinate="298" ycoordinate="287"><br /> <coordinates xcoordinate="50" ycoordinate="287"><br /> <coordinates xcoordinate="50" ycoordinate="343"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="d426acc3-acfe-481c-aa4f-c7462e8a6bd3" from="0c064927-1240-449d-9bf1-fb2adaeeef8b" to="c49f25b6-cae6-4805-a5ad-93c50afdad1d" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="455" ycoordinate="190"><br /> <coordinates xcoordinate="455" ycoordinate="155.5"><br /> <coordinates xcoordinate="530" ycoordinate="155.5"><br /> <coordinates xcoordinate="530" ycoordinate="118"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="c09a9def-c930-420e-9e84-600d9f5abe05" from="2fc7d9a9-3958-442f-9958-df5da693a6d8" to="bf987255-cec5-465e-8493-2ef8d70c3c15" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="806" ycoordinate="200"><br /> <coordinates xcoordinate="806" ycoordinate="154.5"><br /> <coordinates xcoordinate="833" ycoordinate="154.5"><br /> <coordinates xcoordinate="833" ycoordinate="115"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="330ee202-e82f-4b7a-8975-26250a759734" from="c49f25b6-cae6-4805-a5ad-93c50afdad1d" to="1cf66f62-a7f4-4943-a643-175183210a73" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="575" ycoordinate="88"><br /> <coordinates xcoordinate="678" ycoordinate="88"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="71961851-7273-4bd5-a183-2d7661531267" from="bf987255-cec5-465e-8493-2ef8d70c3c15" to="3bf962d4-dee5-447e-ae98-a5a9b9198f1a" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="878" ycoordinate="85"><br /> <coordinates xcoordinate="928" ycoordinate="85"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="eb3416d9-90e0-4a20-ba73-13b44bdac965" from="44077f3a-394e-4a4c-a05e-13d1e5892d07" to="b8b6b9d4-2d1a-410f-8320-346017bd95e4" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="181" ycoordinate="90"><br /> <coordinates xcoordinate="433" ycoordinate="90"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="8db96536-f759-4154-bb49-5c88fd83b8e5" from="c058750a-611f-40ee-9159-7cd8cd221513" to="0c064927-1240-449d-9bf1-fb2adaeeef8b" name=">= 2 multas"><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="511" ycoordinate="353"><br /> <coordinates xcoordinate="511" ycoordinate="292.5"><br /> <coordinates xcoordinate="455" ycoordinate="292.5"><br /> <coordinates xcoordinate="455" ycoordinate="250"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="5e92992c-6ad2-4a60-8f3f-6b3194043c97" from="c058750a-611f-40ee-9159-7cd8cd221513" to="2fc7d9a9-3958-442f-9958-df5da693a6d8" name="<= 1 multa"><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="531" ycoordinate="373"><br /> <coordinates xcoordinate="646" ycoordinate="373"><br /> <coordinates xcoordinate="646" ycoordinate="230"><br /> <coordinates xcoordinate="761" ycoordinate="230"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> <transition id="5be22f41-785d-41dd-a697-15aa1c29cc0d" from="0b84e44b-13ef-414b-9b20-60558f2f7577" to="c058750a-611f-40ee-9159-7cd8cd221513" name=""><br /> <condition><br /> <extendedattributes><br /> <connectorgraphicsinfos><br /> <connectorgraphicsinfo toolid="BizAgi_Process_Modeler" bordercolor="0"><br /> <coordinates xcoordinate="275" ycoordinate="373"><br /> <coordinates xcoordinate="671" ycoordinate="373"><br /> </connectorgraphicsinfo><br /> </connectorgraphicsinfos><br /> </transition><br /> </transitions><br /> <extendedattributes><br /> </workflowprocess><br /> </workflowprocesses><br /> <extendedattributes><br /></package><br />

Você pode ver esse XPDL em uma solução open source feita em Java, que é o together workflow editor. Ele importa todo o processo 100%, alguns elementos aparecem meio estranhos, por que o foco é XPDL e não BPMN, mas o fluxo de negócio esta lá certinho :).

Por que esses erros? Simples por que a ferramenta open source de XPDL é em cima de XPDL 1.0 e conforme dito antes o BizAgi gera o XPDL 2.1, isso também mostra que não existe uma boa compatibilidade para traz do XPDL, isso só comprova o post anterior no qual falei dos problemas de compatibilidade.

Outro detalhe que eu não falei, as soluções de modelagem de BPM não costumam ter bons facets nos projetos. Sim Facets, vou explicar o que é isso. Bom no eclipse que é um IDE de desenvolvimento Java os projetos tem factes, por exemplo existe um facets para EJB então posso escolher entre as versões 2.0, 2.1 e 3. A ferramentas de modelagem de BPM não tem essa opção logo é aquela versão de BPMN e de XPDL, infelizmente isso se o BizAgi também.

A Solução da ORACLE o BPM Studio só importa XPDL 1.0 ou 2.0, logo o do BizAgi não entra lá e nem do IBM Modeler, por sinal a IBM adora ficar com versões, alpha, beta, draft, etc... Mas o BPM Studio da ORACLE também não gera um XPDL 100% on rails, por que ele gera um XPDL2.0alpha. O mesmo que não importa no BizAgi.

Se vocês quiserem baixar os recursos deste post, diagrama bpmn, imagem e XPDL confiram nesse url. Em outros posts mais pra frente vou falar um pouco mais de BPM e outras formas de fazer mapeamento de negócio.

Para fechar com o BizAgi que como disse antes para mim é a melhor solução de modelagem, pensando só em modelagem, é uma abordagem válida para empresas que querem começar a mapear os seus processos para ajudar no desenvolvimento e para melhorar o funcionamento da empresa, para aplicação de uma solução de BPMS completa precisamos ter mais critérios, mas ai já é história para outro post.

Abraços e até a próxima.

Leia Mais…

No post anterior, escrevi um pouco sobre BPM e bem como andam os padrões que seguem esse modelo, neste post pretendo falar sobre a ligação de BPEL com BPM. Vou citar outras referencias que confiram a minha visão de que BPM e BPEL talvez não seja o casamento perfeito.

Quando falamos de BPMN, BPMS, simulação, estamos falando obrigatoriamente de BPM. Se falarmos de WS-BPEL, WebServices, WSDL podemos estar falando de SOA, mas nem sempre, usar WS-BPEL, WebServices, WSDL não significa ter SOA. Se você quiser saber mais sobre SOA pode ler esses posts:

• SOA: Cuidado com o Lock-In
• SOA sem BPMN e WebServices
• O papel do ESB em uma solução SOA
• SCA com Java Parte 1
• SCA com Java Parte 2
• A Diferença de EA e Arquitetura de Software

Para maior entendimento desse post, recomendo muito a leitura do post anterior e esses outros posts que fiz sobre BPEL:

• Como vamos de BPEL Parte 1
• Como vamos de BPEL Parte 2 - ODE
  

Nos posts anterior sobre BPEL falei dos pontos positivos e neste post vou mostrar os pontos negativos do uso de BPEL em conjunto com BPM. Não digo que é de todo o mal a abordagem mas o mercado já salienta diversos problemas os quais alguns vi na prática.

O Casamento de SOA com BPM

BPM é negócio, é o fluxo da sua empresa, é gestão de processos, SOA é arquitetura corporativa, ou pelo menos uma parte dela, focada em serviços, serviços estão relacionados a processos, então BPM e SOA são feitos um para o outro? Em alguns casos essa abordagem pode ser muito produtiva, implantar os dois do zero pode ser um grande risco. Por que SOA vai mexer muito com a TI e BPM vai mexer muito com o negócio.



Você pode realizar uma implantação parcial e primeiro colocar BPM e depois disso ir para SOA, para mim é o melhor cenário, não digo que seja impossível colocar os dois ao mesmo tempo mas aos meus olhos acredito que só aumenta a complexidade e os riscos de se ter sucesso e ROI em curto prazo.

Mas como juntar BPM e SOA?

Na verdade é simples, essa cola pode existir apénas em tempo de análise/design, tudo tem inicio do processo da empresa, do fluxo, desse fluxo se derivam, aplicações, serviços, sistemas legados, sistemas de terceiros, tarefas manuais do negócio, tarefas manuais da TI, etc...

Tudo isso pode ser controlado com uma boa ferramenta de metadados. Um exemplo é o ORACLE Design que não deixa de ser uma ferramenta de metadados para o banco ORACLE, você pode fazer esse sistema com meia dúzia de cadastros, ainda é possível usar algum sistema de gestão de assets.

Porem essa não é a única abordagem, existe outra vertente que é até defendida por grandes players como IBM e ORACLE a idéia de gerar o BPEL a partir de um diagrama de processo do BPM.

Esse casamento pode dar divorcio ou até mesmo...

MERDA!!!

Mas com o Problema dessa abordagem?

Se existisse só um problema eu não estava falando disso :). São vários os problemas, primeiro é que um processo BPM pode não ser 100% mapeavel do BPM para o BPEL. Se vocês tem suas dúvidas confiram esses outros posts/artigos:

• Why BPEL is not the holy grail for BPM
• Eu odeio BPEL
• BPMN-BPEL round-tripping
• BPEL não é BPM e Vice-Versa!
• BPEL: Who Needs It Anyway?
• WS-BPEL FAQ

No FAQ do WS-BPEL 2.0 item 4 vocês acharam isso:

4. What is the relationship between BPMN and WS-BPEL2.0?
1. There is no direct relationship between BPMN and WS-BPEL 2.0. WS-BPEL is a standard from OASIS and the BPMN specification is currently an OMG standard for visual representation of Business processes.

Em resumo, não existe relação direta de BPM e BPMN para BPEL são padrões diferentes de empresas diferentes com propósitos diferentes, ainda existe o grande problema de 'round-trip', ou seja, se eu gera o BPEL com BPMN se eu conseguir fazer posso não conseguir pegar as mudanças feitas no BPEL para o BPM de volta, que insiste nisso são os grandes players como disse antes ORACLE e IBM, por que?

Eles querem fazer o bom e velho lock-in e prender vocês ao ferramental deles, por sinal o IBM Modeler 6.0 nem implementar BPMN implementa, voltando a falar de BPEL, existem outros problemas sérios no uso de BPEL:

• Tudo é WebService, WDSL, XML, XPATH pra todo o lado
• Desenvolvimento pesado e complexo
• Problemas de performance e dimensionamento de máquinas
• Impossibilidade de forma portável de acessos mais leves

Vou explicar esse último item, como dito antes o BPEL tem problemas de performance por ser tudo WebServices, xml, etc... Uma solução seria acessar os serviços ou tasks através de uma mera classe java ou um EJB ou um bean do Spring, isso é possível na IBM por exemplo através do uso de SCA, mas isso é feito no BPEL através de extensões, logo perdemos a portabilidade e mais uma vez a IBM fez o lock in de novo e você está preso aos caras.

E o Pega Gerente?

Esse é o problema. Todo esse papo furado de gerar o BPEL pelo BPM é algo que os gerentes adoram, ou seja, uma solução mágica que com ferramentas vai eliminar, erros, descuidos, dar flexibilidade e até tirar o peso da responsabilidade das pessoas. É um mundo mágico que infelizmente não existe. Existe apoio dos gerentes por que as grandes empresas estão jogando nisso, mas o mercado não está comprando, a prova disso é esse gráfico:

Gráfico de tendências do site In Deed

Como vocês podem ver o uso de BPM vem crescendo muito e assim como de forma menor a demande de BPEL mas ainda é grande, agora quando olhamos as duas coisas associadas que seria a linha verde vemos que isso é muito pequeno. BPEL pode ser usado mas tem que existir um cenário que justifique muito isso e de preferência com uma boa solução como o Apache ODE e usando o SOA Tools do eclipse que são ferramentas open source para BPEL.

Alternativas ao WS-BPEL

Muitas vezes uma alternativa viável e simples é ao invés de fazer orquestração fazer roteamento de serviços, não resolve 100% dos casos, mas em alguns casos da no mesmo, isso pode ser feito com um bom ESB como o Apache Service Mix usando o Camel da Apache por exemplo.

Uma idéia que me agrada muito é, fazer orquestração de forma padronizada assim como no BPEL mas usando formas mais leves como interfaces java, ejbs, beans do Spring, apis REST, mas tudo isso de forma padronizada por alguma especificação. Mas nada indica que esse caminho ira surgir fora das extensões.

BPEL em DSL?

Essa seria uma coisa ótima, usar BPEL com schema XSD, xml e WSDL é algo muito ruim, muito pesado, que cria uma dependência muito forte com um ferramental se não é impossível faer algo que preste com o mínimo de produtividade.

Ouvi falar do SimPEL que seria um BPEL simplificado em forma de DSL, espero que isso vá para frente, confiram isso neste link: http://www.nabble.com/SimPEL-early-feedback-td19380187.html.

O SimPEL é muito novo, é do final de 2008, não sei se evoluiu muito, apareceu na lista de discussão de desenvolvimento do Apache ODE e está em passos de bebe, mas achei muito interessante e gostaria muito de ver as coisas evoluindo para esse lado, o SimPEL é algo tipo isso:

<br />process HelloWorld {<br /> receive(myPl, helloOp) { |msgIn|<br /> msgOut = msgIn + \" World\";<br /> reply(msgOut);<br /> }<br /> }<br />

Como disse antes não sei se a iniciativa foi para frente, mas é algo muito legal. Mesmo com isso ainda não temos a tão sonhada cola do BPM com o BPEL e não vamos ter isso com ferramental nenhum, certas coisas ainda devem ser feitas da maneira antiga, com ferramentas sim, com pessoas e o bom e velho processo.

Abraços a até a próxima.

Leia Mais…

Com a crise econômica mundial, que tal reduzir 20% dos custos de sua empresa? Bom né? Pelo menos é isso que promete o Gartner se você usar BPM. Segundo ele seguirem a adoção de BPM podem ter esse lucro nos primeiros 12 meses, eu não duvido.

70% das empresas que usam BPM dizem que essa é a sua salvação, a idéia não é nova, com crise ou sem crise os preços tendem a ser ditados pelo mercado, então uma boa forma das empresas irem para frente é melhorar a qualidade dos seus processos internos e diminuir custos.

O que é Business Process Management?

Esse é um modelo gestão baseado em processos, a idéia é mapear e modelar os processos da empresa para ter um conhecimento maior de como as coisas funcionam e poder otimizar o processo. Tal tarefa de mapeamento pode ser feita com qualquer ferramenta estilo fluxograma.

Para mapear um processo não importa se a sua ferramenta é o MS Visio, IBM Modeler, BizAgi ou até mesmo o MS Excel. Quando falo em mapear não falo só no mapeamento, que é um tarefa de engenharia reversa, mas falo também de modelagem de processos, para a modelagem de um processo novo por exemplo.

Com o processo modelado e mapeado é possível aplicar SLA e através de simulações e até mesmo o uso empírico do processo ver pontos de melhoria e de simples descarte. Para simulações já vamos precisar de uma ferramenta mais própria para BPM como o Modeler ou o Intalio, o excel fica devendo :)

Infelizmente a simulação que é um recurso muito bom ainda é deixado como uma funcionalidade meio que de brinde sem muito foco ainda pelos grandes players, possível que depois da bpmn 2.0 isso mude, vou falar mais sobre bpmn neste post depois.



O Ciclo do BPM

Modelagem: Quando as coisas começam a se tornar tangíveis, nesse ponto você irá se preocupar com detalhes mais práticos dos que você viu na fase de design. Preocupações como o custo e materiais, pessoas, etc sempre aparecem aqui.

Execução: Aqui é aonde o trabalho acontece, seja ele feito por pessoas, por máquinas ou por sistemas, você pode aumentar cada vez mais seu nível de automatização, mas isso nunca será 100%, logo vai ter que existir interação com pessoas e tarefas manuais. Pode ser difícil de documentar como as coisas funcionam mas isso é mais uma questão de cultura e de hábitos do que de complexidade propriamente dita.

Monitoramento: Nessa fase você ira acompanhar os seus processos em execução, seja ela por meu de sistemas da TI ou por tarefas feitas na mão por pessoas, você deve ter estatísticas de performance do seu processo. Você pode usar ferramentas de BAM nesse ponto, a solução de BAM pode ajudar a detectar problemas para que você possa corrigir esses problemas ou melhorar a performance dos seus serviços.

Otimização: Depois de fazer o design, modelar, executar e monitorar, você tem a chance de aplicar otimizações nos processos de sua empresa. Nesse ponto que você pode remover gargalos e retirar passos e custos não necessários ao seu negócio.

Business Process Modeling Notation

É uma forma padronizada de fazer mapeamento de processo de negócio, a bpmn é uma notação visual, pelo menos até a versão 1.1. Na versão 2.0 vai existir um schema para validar a notação, isso será bom tanto em termos de ferramentas como em termos de padronização e portabilidade.

Hoje em dia a portabilidade de bpmn praticamente não existe, por que visualmente se existe um " + " em um gateway e uma ferramenta como o IBM Modeler 6.0 não tem esse sinal ela não é aderente a bpmn. Até a versão 1.1 teoricamente a portabilidade aconteceria com o XPDL, mas nem todas as ferramentas trabalham com o XPDL e mesmo que trabalhem existe sérios problemas de portabilidades como por exemplo do BPM Studio da ORACLE para o IBM Modeler e vice versa.

Padrões são bons, mas nesse ponto de bpmn 1.1 isso tudo serve apénas de convenção, na versão 2.0 do bpmn que é quando se pretende fazer a bpmn executável pode ser que as coisas mudem mas até que isso chegue não vai ser da noite para o dia. Nesse tempo você vai querer usar BPM, use a vontade com bpmn ou não, agora saiba que você estará preso a uma ferramenta, não caia na trova fiada da portabilidade.

XPDL ?

É um padrão de representação de fluxos baseado em XML, esse padrão é mantido pela Workflow Management Coalition (WfMC), já o bpmn é mantido pela OMG. O problema é que como dito antes poucas é que nem todas as soluções de BPMN seguem a última versão de XPDL que hoje(06/06/2009) esta na versão 2.1. Muitas ferramentas usam XPDL mas não existe portabilidade, você cria o processo com bpmn na ferramenta e não hora de importar em outra ferramenta ou não importa ou importa com erros.

BPMS

É um software para BPM, proprietário. O problema é que todas os processos de um BPMS devem ser executáveis e na verdade muita coisa não é executável, para muitos essa é outra tentativa sem sucesso de automatizar o que não deve ser automatizado e trocar pessoas por sistemas.

A Evolução dos padrões

Confira a evoluções desses padrões no diagrama de linha do tempo a baixo. Perceba a diferença de evolução do XPDL e do BPMN que mudou de dono no meio do caminho, perceba a velocidade de evolução dos padrões também.

Timeline de padrões

Como ainda estamos em 2009, não temos o XPDL 2.2 e o BPMN 2.0, eles ainda estão em discussão, você pode conferir boas dicas do que vai ter de novo no bpmn aqui. Porem existem algumas coisas ruins sobre o assunto como por exemplo a possível continuidade da baixa portabilidade, que só leva ao mais lock in nos grandes vendors como IBM e ORACLE.

Se você tem dúvidas quanto a portabilidade, leia esse trecho retirado do blog de um dos caras de BPM o Bruce Silver:

3. Model portability. Most people simply take it for granted that the first goal of any standard like BPMN is portability or interoperability between tools. You should be able to create a BPMN model in tool X and open it in tool Y. That takes more than a schema. It also requires the spec to enumerate the elements expected to be portable between tools, i.e. that all tools must support and understand. In an execution language like BPEL, this enumeration is the entire set. But for BPMN, currently used as a diagramming notation rather than a complete execution language, no tool with a runtime supports every last bit of it, and that probably won’t change with BPMN 2.0.

The team should have followed XPDL’s lead and defined multiple working sets – a hierarchy of portability levels – from a simple basic palette supported by essentially all tools, up to the full set, with portability conformance requirements spelled out for each level. I drafted language to that effect, but it didn’t get off the ground, either. Instead, the modeling conformance language is so vague as to be meaningless.

My interpretation of the reason is that team members were uncertain how much of the BPMN palette their own tools would support in their first “2.0-compliant” release. So don’t expect much portability when BPMN 2.0 tools first come out.

Bom acho que ele foi bem claro quanto a o que estou dizendo :)

Na versão 2.0 do BPMN que a idéia é ser executável, será nitidamente a saída do BPEL, que muitas vezes era utilizado como solução por limitações de distinção de informações de modelagem e informações de design da bpmn 1.0.

A Questão da simulação também pode vir a ficar melhor pela entrada dela na especificação de BPMN 2.0, mas isso tudo é para depois de 2010.

Fechando essa parte...

BPM é um modelo de gestão baseado em processos, não é tudo e não substitui a gestão tradicional, agrega novos conceitos, mas ainda precisamos do básico que existe em administração e gestão de projetos. BPM não é TI necessariamente é mais negócio que TI, pode ter e deve ter a ajuda da TI, mas é mais para área de negócios e a sua implantação é na empresa toda e não só no setor de TI.

No próximo post vou falar da relação de BPM com BPEL e se isso é possível ou não. Existe uma discussão muito grande sobre esse tema, no próximo post falarei das possíveis vantagens e desvantagens e bem como os mitos e patotas dessa questão.

Abraços e até a próxima.

Leia Mais…

Neste post vim falar um pouco mais de FDD, que além de ser um método ágil tem uma grande eficiência e aderência a requisitos. Vou dar uma visão geral de como o método funciona e como podemos mixar o método com outro método ágil chamado de Scrum.

Se você quiser saber mais sobre Scrum, pode ler outros posts que tenho sobre o assunto a baixo:

• Scrum
• O que faz a diferença usando XP, Rup, Scrum ?
• Scrum não substitui gerenciamento de projetos
• Estimando com Scrum
• Gerenciamento de Níveis com Scrum e RUP parte 1
  
• Gerenciamento de Níveis com Scrum e RUP parte 2
• O Melhor do Scrum

Voltando ao FDD, o método é iterativo incremental e funciona muito bem com iterações curtas de duas semanas, você pode usar um timebox maior, mas eu recomendo muito o uso desse timebox, para mim o foi o que melhor funcionou.

O FDD foi criado por Jeff De Lucca em 1997. FDD é um método que prega a visibilidade do estado projeto de forma consistente e honesta. Você consegue saber quantas funcionalidades já foram desenvolvidas e quantas faltam ser desenvolvidas por que tudo é orientado as funcionalidade.

O FDD ajuda muito a você organizar as suas entregas, o FDD funciona muito bem por que ajuda usando as boas práticas de gerência de configuração como plano de release, plano de deploy e outras práticas ágeis como build continuo e foco em testes.



Visão Geral

Visão Geral do FDD

O FDD tem duas fases basicamente a fase de Concepção e Planejamento e a fase de Construção, por ser simples e objetivo o FDD pode ser uma excelente solução para projetos de manutenção.

Na fase concepção acontece a triagem de requisitos, você ainda pode usar as técnicas tradicionais da Engenharia de Requisitos mas focando em funcionalidades, é perfeitamente viável essa abordagem. De inicio você tem que desenvolver um modelo abrangente isso é legal por que nesse ponto começar a se mixar o FDD com as práticas de OOAD e UML em Cores.

No modelo abrangente o foco está mais na forma do que no conteúdo, isso é bom por vários motivos, primeiro que é um incentivo para que você não faça um big design up to front e também não comece a querer fazer toda a arquitetura de uma vez só, esse é um bom ponto de interação do design com a arquitetura também.

Com isso você tem insumos para a geração da lista de features, que pode ser o seu backlog que você usa Scrum, logo você pode manter isso em uma boa planilha excel. Esse trabalho permite que você faça um planejamento por features que pode ocorrer em uma reunião de planejamento do Scrum, com as práticas do Scrum logo você consegue saber quantas funcionalidades por sprint você é capaz de desenvolver.

Na fase de construção existe um detalhamento por funcionalidade, nesse ponto que você vai especificar mais o que deve ser feito, acho plausível se você sentir necessidade, usar estórias do usuário do XP.

Neste ponto você constrói por funcionalidade, e o progresso é medido por funcionalidade, a cada funcionalidade feia se você quiser pode coloca-la em produção, eu recomendo, o Flckr por exemplo tem deploys em produção diariamente, deploy mais freqüentes são melhores para o negócio, quanto mais melhor.

Nota: Quando falo de deploy freqüente ou diário em produção, me refiro a quando isso é possível, não estou dizendo para você pular testes nem bypassar seu SQA. Mas se você puder fazer um deploy todo o dia melhor, isso será bom para todo mundo.

Medindo Progresso com o FDD

Essa medição se dá através de um cartão que representa a funcionalidade, você pode fazer isso com um post-it semelhante ao da figura a baixo, essa não é um funcionalidade pura e já fiz uma mix com o Scrum:

Tracking de Funcionalidades com o FDD

Na figura a cima existem as funcionalidades tradicionais do FDD, mas existe um mix que fiz com o Scrum também. Vamos por parte primeira ao FDD e as modificações que fiz. A cor amarela significa que a Feature está em andamento, em verde significa que já foi concluída e rosa significa que a funcionalidade está atrasada. Usei essas cores por que são as cores básicas dos post-its em se quiser você fazer tudo isso com post-its.

Outro mix válido é mixar o FDD com o Kanban, assim as atividades de planejamento, revisão, design, revisão, construção, revisão e deploy do FDD podem ser colocadas em um pipeline. Para facilitar a sua vida com post-it você pode deixar só para desenhar a barra de progresso ou então considere que a funcionalidade é o item do scrum e continuar quebrando a feature em tarefas, mas vá movendo o progresso só da feature e use o Tasks/W.I.P/Done do Scrum Tradicional.

Os números dos cartões de funcionalidades são o seguinte, vou explicar da esquerda para a direita de cima para baixo. O primeiro número é o identificador único da funcionalidade, esse pode ser o mesmo número que você tem no backlog do Scrum ou até mesmo o número de um ticket da sua ferramenta de tracking.

O número do meio é a pontuação do Scrum, onde está pontuado a complexidade de desenvolver essa funcionalidade. E o terceiro número bem a direita é a prioridade da feature que é dada pelo dono do produto. Você pode jogar o post-it fora para mudar a cor ou pode pintá-lo,outra abordagem para quem não usa um dashboard seria fazer isso em uma planilha excel, é uma boa mas eu prefiro as coisas feitas a mão por que elas favorecem a colaboração.

Quando atualizar o progresso?

Para mim o momento ideal é quando estamos fazendo as reuniões de pé. Todo o dia você pode atualizar o progresso de todas as funcionalidades em desenvolvimento no dashboard ou em sua planilha, assim todos vão saber do andamento das funcionalidades, esse mix com o Scrum é muito benéfico pois o scrum dá um framework geral e com o FDD colocamos algumas coisas especificas.

As Revisões

O FDD enfatiza a prática de revisão tanto de código como de projeto, isso é muito bom e contribui para a evolução da qualidade do produto. Aqui o FDD pode se juntar com diversas práticas da Garantia da Qualidade de Software.

O FDD é um método que prove muitas cosias legais em torno de funcionalidades, mas isso não elimina outras necessidades, em um projeto é muito saudável misturar FDD com outros métodos como Scrum, XP, RUP e OpenUP. Misturas com Kanban também são bem vindas e podem melhorar mais ainda a visibilidade e facilitar a visualização do status do projeto.

Se vocês quiserem mais informações sobre o FDD confiram neste site aqui, aqui e aqui.

Abraços e até a próxima.

Leia Mais…

Nos post anterior eu comecei a falar um pouco mais de arquitetura corporativa. Nesse post vou continuar no assunto, agora falando mais de TOGAF. TOGAF é um framework para a construção de uma arquitetura corporativa(EA) criado pelo The Open Group. Hoje(31/05/2009) ele esta na versão 9.

Os Tipos de Arquitetura

No TOGAF os tipos ou níveis de arquitetura são bem separados, o TOGAF aceita 4 tipos de arquitetura como subtipos de sua Arquitetura Corporativa, são os tipos:

• Arquitetura de Negócio
• Arquitetura de Dados ou de Informação
  
• Arquitetura de Sistemas
• Arquitetura de TI

A Arquitetura de Sistemas é a mais comum e é onde a maioria dos arquitetos trabalha, se já é difícil achar um arquiteto de Sistemas em Java com expertise e que saiba o que está fazendo, imagine achar um que domine os 4 subtipos de arquitetura do TOGAF.

TOGAF é ideal para construção de um Arquitetura Corporativa para sistemas de missão Critica, esses sistemas são fundamentais para o sucesso da organização. Mesmo que você não tenha muitos sistemas de missão critica, dependendo do cenário pode ser uma boa adotar o TOGAF.



O método ADM

O TOGAF tem no seu cerne o ADM, que é um método para criação da arquitetura de TI que consiga atender as necessidades do negócio. Para tal feito é perfeitamente possível usar outros padrões de mercado como a UML, BPM, SOA e todos esses bons anos de evolução da Engenharia de Software.

O método TOGAF se divide em duas partes, são elas:

• O método ADM para construção de um arquitetura de TI que atenda os requisitos e por conseqüência as necessidades do negócio.
• Arquitetura do TOGAF: Que é um conjunto de serviços e funções arquiteturais para construção de software, nesse ponto podemos utilizar SOA.

Requisitos: O centro de Tudo

No Framework do TOGAF os Requisitos estão no centro de tudo, as decisões são dirigidas pelos requisitos, veja isso pela figura a baixo:

Requisitos o Centro de Tudo !!!

Cada ciclo contem uma serie de coisas que devem ser feitas, mas todos as ações são tomadas em cima de requisitos, que são a base para um arquitetura Corporativa de sucesso. Como você pode ver na figura a cima existem 7 fases para atingir os objetivos do TOGAF.

As Fases

Vou comentar por cima como funciona cada fase e o que se deve fazer, se você quiser mais detalhes pode comprar o TOGAF aqui. Eu ainda não estou ganhando nada pela propaganda :(
Se você quiser uma referência razoável mas não tão completa pode acessar esse site que tem a versão 7 do TOGAF.

A: Initiation and Framework

O Objetivo dessa fase é especificar os requisitos de negócio, que se aplicam a evolução da arquitetura, leia-se, não são todos, digo isso por que se não alguém já pode pensar que o método é cascata e ele não é.

Esses requisitos servem para nortear a arquitetura com princípios, Metas de Negócio e Decisões Estratégicas da organização. Com isso será possível nesta mesma fase se produzir uma Visão Arquitetural.

Nesta fase serão identificados e documentados e pontuados(rank) os principais problemas que afetam o projeto. Além de identificar e documentar os objetivos de negócio. Aqui existe o mapeamento de papeis e sistemas e bem como suas funções e medidas que indiquem o que seria o certo e esperado para todas as entradas e saídas macro.

O que existe de muito válido nessa fase é a constante preocupação em saber se os problemas foram realmente entendidos e a arquitetura proposta não vai de encontro oposto aos objetivos do negócio.

No final dessa fase você terá a primeira versão da sua arquitetura de negócio.

B: Baseline Description

Aqui é feito a definição de alto nível dos sistemas. O grande objetivo dessa fase é descobrir ativos que posam ser reutilizados, nesse ponto é crucial que você armazene essas informações de forma concisa se possível em uma sistema de gestão de Assets.

Neste ponto é necessário levantar todos os pontos em que você não tem interoperabilidade, ou seja, problemas de comunicação e trocas de informações entre sistemas. Não é necessário que você refaça tudo do zero, se você tem uma material de valor e atualizado utilize o mesmo.

Essa sessão ira gerar mais um incremento na sua arquitetura de negócio, com isso você poderia ir para outra fase.

C: Target Architecture

O objetivo dessa fase é identificar a arquitetura que será base para o seu desenvolvimento e implementação de serviços e funções de negócio. Confira a figura a baixo:

Arquitetura Alvo

Essa fase tem 8 passos, que vão desde a representação da arquitetura segunda o óptica do TOGAF, Criar modelos de arquitetura, confirmar necessidades e requisitos de negócios, até ver problemas de análise como por exemplos serviços e funções que negócio que podem estar faltando.

Nessa fase que vai nascer a primeira versão da arquitetura técnica, então já vamos ter dois tipos de arquitetura documentadas a de negócio e a técnica. :)

D: Opportunities and Solutions

Um dos objetivos dessa fase é intenficiar pontos de mudanças, ou sejá que sistemas ou serviços que já existem será mudandos para aruitetura alvo. De novo nesta fase serão vistos as possíveis omições ou esquecimentos de análise de serviços e funções e bem como será maturado os requisitos técnicos sobre a perspectiva funcional.

Aqui deve ser utilizada a gestão de riscos e custo tradicional do Pmbok por exemplo, pois não podemos perder muito tempo na busca da arquitetura perfeita, então será prudente setar algun deadline de tempo ou dinheiro.

O trabalho realizado nesta fase vai gerar um lista de impacto no projeto.

E: Migration Planning

Aqui acontece algo muito importante que é a tarefa de priorização de projetos e necessidades. Nesse ponto é preparado um plano apartir de diversas discusões sobre:

• Dependências dos projetos e atividades
• Que componentes vão ter que ser desenvolvidos
• Temos recurso para esses desenvolvimentos?
• Sobre que padrões os componentes e serviços vão ser construidos
• Quando vão estar dispoíveis
• Qual o custo de reteinar os usuários?
• Qual o impacto cultural e se pode ser controlado?
• A Migração é viável?

Aqui os riscos serão trabalhados de novo e bem como a análise de impacto. Um roadmap de tudo sera produzido. O plano de migração é produzido no final da fase.

F: Implementation

Aqui o objetivo é levantar as recomendações para cada projeto de implementação. Aqui devem ser estipulados os contratos tanto em nível de sistema como de SLA para prover uma futura governança em cima disto tudo.

Nesse ponto eixste a junção da Arquitetura com o desenvolvimento, podemos aplicar essa junção com método de desenvolvimentos tradicionais como RUP, OpenUP, Scrum, XP, FDD e outros.

Essa fase é crucial, nela que surgem os primeiros imputs para a tão sonhada governança de TI.

G: Architecture Maintenance

Seu objetivo é estabelecer procedimentos e padrões de manutenção. Aqui será feito outra baseline em cima dos projetos que já estão rodando na arquitetura alvo. Aqui aplicaremos um monitoramento continuo no que deverá ser desenvolvido por conta de nudanças no negócio ou novas necessidades.

Aqui é atualizada a arquitetura técnica e é possível que se gera uma nova demanda de arquitetura corporativa nesse ponto o ciclo começa de novo e volta para a fase A.

Como você podem ver o TOGAF tem um método simples e consico para construção de uma arquitetura corporativa, na medida do possível fui faznedo os links com os métodos de desenvolvimento de software tradicionais aonde acredito que eles tenham junção com o TOGAF.

Abraços e até a próxima.

Leia Mais…

Neste posta venho falar de arquitetura, falando de software existem vários níveis de arquitetura, hoje venho escrever um pouco mais sobre isso. Vou ficar com dois níveis ou tipos de arquiteturas que são a Arquitetura de Sistema e a Arquitetura Corporativa. Ainda pretendo traçar uma pequena relação do tema como SOA.

Leia Mais…

No post anterior escrevi um pouco sobre BPEL. Neste post vou continuar no assunto mas falando de uma implementação de BPEL que é o ODE. O Apache ODE é uma implementação open source 100% aderente a WS-BPEL 2.0 e compatível com BPEL4WS 1.1.

Orchestration Director Engine é uma implementação muito leve de BPEL, não só pelo fato do ODE rodar em Apache Tomcat ou Jetty que são soluções leves para Java.

A solução de BPEL da Apache conta com uma brilhante solução de arquitetura chamada de JACOB. Essa solução compila o BPEL através de um recurso que pode ser executado em linha de comando para verificar a syntax e a validade do BPEL produzido, esse recurso se chama bpelc.

Desta forma a solução da Apache em tempo de runtime pode executar um processo totalmente em memória, que faz como que a performance seja muito boa, ou utilizar a persistência em banco de dados. Por default o ODE usa o banco de dados Derby mas você pode mudar essa configuração para utilizar outro banco.

Você pode acessar WebService REST com o ODE através de uma extensão, esse recurso é bom mas isso mata a portabilidade do BPEL. A Figura a baixo retirada do site da apache ilustra o desenho geral da boa arquitetura do ODE.

ODE é perfeito para ser embarcado com outras aplicações pois ele é muito leve e tem poucas dependências em termos de jars, outra forma de usar a solução é com a integração que ele possui para JBI, dessa forma você usa-lo como solução de orquestração no ESB da Apache o ServiceMix.

Você pode usar o ODE em outros servidor como o Weblogic, Websphere ou até mesmo o JBOSS com o mínimo de configurações. Se preferir pode distribuir o mesmo no Tomcat ou Jetty, isso vai depender da sua estratégia e preocupação com manutenção e gerência de configuração.

Em termos de desenvolvimento é interessante deixar o ODE no Jetty pois ai com o uso de Maven pode automatizar o processo de deploy e start/stop do servidor com o ODE.

Está nos planos do pessoal do ODE em realizar uma integração com SCA usando outro projeto da Apache o Tuscany.

No próximo post pretendo postar "códigos" de exemplo do uso de ODE e com uma aplicação cliente que inicia o processo do ODE e obtém o resultado do processo. Nesse exemplo vou usar o BPEL Designer do eclipse para fazer o BPEL.

Abraços e até a próxima.

Leia Mais…