Posts

Showing posts from May, 2009

Arquitetura Corporativa com o TOGAF

Image
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ê

A Diferença de EA e Arquitetura de Software

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. A Arquitetura de software é uma prática muito saudável, framework de desnevolvimento de software como o RUP e OpenUP são baseados na Arquitetura como suporte ao desenvolvimento. Mas existe um grande diferença da Arquitetura de Sistema e da Arquitetura corporativa. A Complexidade A Arquitetura de sistemas além de servir como suporte para o desenvolvimento, isso não significa fazer tudo para o desenvolvedor, mas significa pegar as maiores pedras, ou seja, as coisas mais complexas. Investir na arquitetura de um sistema é sempre um bom negócio, a arquitetura não será a solução para todos os problemas e nem será feita de uma solução única, soluções homogêneas são cada vez mais di

Como vamos de BPEL Parte 2 - ODE

Image
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. O rchestration D irector E ngine é 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 acessa

Como vamos de BPEL Parte 1

BPEL é uma padrão. Mais popularmente conhecida como uma "linguagem" de orquestração e interação com WebServices. A idéia não é especificar como se construir um WebService mais sim como orquestrar de certa forma o comportamento de WebServices em termos um fluxo de sistema. Quando utilizamos W eb S ervices - B usiness P rocess E xecution L anguage estamos falando de um padrão que começou como BPEL4WS e depois evolui e se tornou um padrão aberto mantido pela OASIS . Um Pouco de História Tudo começou com empresas privadas como a IBM, Microsoft, SAP e outras que em 2003 criaram o BPEL4WS 1.1. Hoje ainda temos players que implementam esse padrão a ORACLE por exemplo em sua solução de SOA o SOA Suite 10g ainda conta com BPEL4WS 1.1 e isso já está assim des de 2006 que foi a primeira vez que utilizei o produto da ORACLE. O problema do produtos deles é que ele tem adapters que fazem coisa que não é de responsabilidade de um BPEL fazer e sim de um ESB. A próxima versão do Suite d

Debug Remoto no Websphere 6.1/7.0

Image
Neste post vou mostrar como fazer o deploy remoto no Websphere 6.1/7.0 através do eclipse, para tal função vamos ter que modificar algumas configurações no WAS console. Você pode fazer isso com o Process Server da IBM conhecido como WPS. Nesse exemplo vou utilizar o Process Server 6.1 (IBM WPS 6.1). Esse recurso é bem útil para depurar código que está em produção ou em um máquina Servidor Linux rodando o WAS por exemplo. Para isso você precisa do eclipse com os fontes do projeto. Vamos as configurações do Websphere primeiro. Suba o Websphere e entre no console de administração, se você está com o servidor na sua máquina mesmo acesse o console com o endereço: http://localhost:9060/admin . Configurando o Debug no Servidor Após entrar no console de administração do Websphere vá em: Servidores -> Servidores de Aplicativos e clique em server1conforme a foto a baixo. Agora procure pela opção de Propriedades Adicionais que esta no menu da direita bem a baixo e clique em Serviço de Depura

SCA com Java Parte 2

No post anterior eu falei um pouco sobre SCA e como esse padrão funciona. Agora vou mostrar um exemplo simples de como implementar um composite SCA feito em Java utilizando o Fabric3 .Neste exemplo você vai precisar de: JDK 6 Fabric3 Standalone Server Profile Web do Fabric3 Maven 2 Neste exemplo vou criar um serviço composto de utilidades que será composto pelo serviço de Data. O Serviço de data nada mais faz do que informar a data atual no servidor. Sem mais delongas vamos ao código dos serviços. Cada serviço tem a sua interface de negócio(contrato) e a sua implementação em Java. DateService.java package com.blogspot.diegopacheco.sca.services; /** * Interface do servico de datas * * @author Diego Pacheco * @version 1.0 * @since 17/05/2009 * */ public interface DateService { String getDate(); } Agora vamos a implementação Java. DateServiceImpl.java package com.blogspot.diegopacheco.sca.services; import java.util.Date; /** * Implementação do serv

SCA com Java Parte 1

Image
SCA é um padrão aberto para construção de serviços. Esse padrão é uma das possibilidades para a implementação de serviços compostos usando SOA, mas não é a única. A idéia não é nem um pouco nova, na verdade se você usa Spring Framework é bem provável que você já venha fazendo algo parecido. A grande diferença do SCA para o que você já faz é que como dito antes SCA é um padrão aberto que prove uma solução para amarração(wire) de serviços e composição de serviços de uma forma padronizada, consistente e independência de fornecedor. Além disso o SCA possibilita a tão sonhada interoperabilidade . A Interoperabilidade é algo fundamental quando falamos de SOA, mas isso pode ser conseguido de outras formas utilizando orquestração de serviços com BPEL e deixando o transporte para um ESB a vantagem de usar SCA sobre essa outra abordagem que descrevi é o fato de que você tem um módulo mais coeso com SCA. Conceitos Básicos de SCA Componente SCA A Figura a cima ilustra do que é composto um compone

Os Males da Gestão baseada em Project

É Comum ver gerentes de projetos tradicionais utilizarem a ferramenta MS Project ou genéricos, mas muitos usam independente da marca do produto PERT e GANT . Acredito que em certos cenários em que as coisas são muito previsíveis é possível usar esse tipo de ferramentas, mas em muitos cenários de desenvolvimento de software isso pode se transformar em um problema. Muitos profissionais consideram a gestão baseada em Project um erro, por que alguma vez na vida alguem acertou aquelas datas? Por que isso acontece? Será que a gestão baseada nesse ferramenta pode ser catastrófica? Neste poste vou tentar responder essas e outros perguntas com a minha experiência com essa e outras abordagens de gestão de projetos. O que é gestão de projetos? Para muitos a resposta dessa pergunta é controle. Mas isso é herdado de outras áreas onde a gestão de projetos existe, o problema é que o pessoal não se fraga que desenvolver software é diferente de: Construção de um Planta Produção de um filme Construção

Arquiteto Super Market

Image
Nos anos 90 existia um programa de televisão chamado de Supermarket . O programa é bem divertido, na verdade era um jogo, nele o objetivo era de colocar o máximo de produtos no carrinho e ganhava quem tivesse ficado com o carrinho mais caro. Então existiam 3 duplas que concorriam, eu me lembro que existia uns produtos maiores que valiam mais pontos. Existiam diversas estratégias dos concorrentes do jogo para ganhar, mas a mais comum que eu percebia era colocar tudo o que podia para dentro do carrinho de compras que nem louco. Para quem não se lembra... Supermercado do programa da época Bom quem quiser mais referências sobre o programa pode achar aqui . Na minha opinião algumas "crianças" daquela época olharam de mais esse programa e para piorar foram para a TI. Então nasce o Arquiteto Super Market. Nesse estereótipo de arquiteto acontece a mesma coisa a arquitetura é um tipo de jogo para ele e o negocio é sair colocando frameworks e tecnologias no seu curriculum ops quis dize

Passei a Bomba a Diante o Problema não é mais meu

Image
Quando eu era criança tinha uma brincadeira chamada de ovo podre. Hoje em dia essa brincadeira poderia se chamar de Ovo podre da TI. Além disso tinha outra brincadeira muito semelhante chamada de batata quente. O Objetivo da brincadeira era passar a batata quente a diante e depois de um tempo a batata ficava com alguém. Azar de quem estava com a batata, mas não sendo a "eu" não tinha problema. Esse é o pensamento que toda criança tinha na brincadeira, o problema é que isso existe na TI hoje em dia. Parece que muitos profissionais e se é que dá pra chamar assim só querem elevar o nível de TCR. A Explicação do que significa TCR você acha aqui . Passei a Bomba Bomba No post anterior eu estava falando de qual seria o foco dentro da TI, se seria de manter o TCR ou resolver os problemas, mas na verdade nem sempre é isso que acontece. Hoje em dia algumas pessoas tem o pensamento de que enviar um email é fazer com que eles sejam inimputáveis de qualquer crime e responsabilidade de re

A Carta Papal da TI e o Foco

Image
Existe um anti-pattern de comportamento nas empresa que trabalham com software de alguma maneira. De facto não é um problema só, são vários, este mal assola toda indústria de software, algumas empresas já estão livres desse mal e outras não, as vezes só algumas pessoas nas empresas tem esse tipo de comportamento em outras isso é como colocar veneno no ar condicionado. Acontece o Problema Os problemas estão na natureza de qualquer trabalho, não existe profissão em que os problemas não ocorram, mas a grande questão é como você lida com esses problemas. Existem várias formas de lidar com os problemas, algumas delas(mais comuns em alguns cenários) são: Fingir que o problema não existe Empurrar o problema com a barriga e achar que do nada tudo ira se resolver Não reportar o problema, não discutir o problema com a equipe Fingir que o problema não é tão critico Usar uma solução que não resolve o problema, mas não incomoda ninguém E assim por diante, em muitos casos para resolver um problema v

Scripts Groovy

Hoje vim compartilhar alguns scripts Groovy. Vou postar 3 scripts sendo que um é muito simples mas tem o seu valor e os outros dois tem mais utilidade prática, todos servem para que o leitor possa aprender mais sobre Groovy. Atualmente se tenho que fazer um script para fazer alguma coisa eu não penso duas vezes e uso Groovy, por que é simples, fácil e o código fica limpo e claro. Os scripts são esses: wcSvnCls.groovy pomDepReader.groovy toJSlash.groovy O primeiro script é de utilizada geral, o segundo script serve para quem mexe com o controle de versão Subversion e o terceiro para quem usa Maven 2. Esses scripts são válidos para windows ou Linux, não testei no Mac mas deve rolar também. O primeiro Script o toJSlash.groovy normaliza as barras, sabendo que as barras do windows são "\" e as do Java e Linux "/" então esse scriptzinho faz essa conversão: /** * Script Groovy que faz a conversao das barras do windows para as barras do java/linux * Ess

JBoss 5.0.1.GA, EJB3, Maven2 e Cargo Juntos e na Prática

Neste post vou mostrar como criar um projeto EJB 3 bem simples usando Maven 2. Vamos fazer o deploy no JBoss 5.o.1.GA através do plugin do maven do cargo. Além disso vamos criar um projeto cliente que acessa o EJB criado através de JNDI. Meu objetivo é mostrar de uma maneira simples e que funciona :) como usar maven 2 com projetos ejb3, de barbada vamos fazer o deploy no JBoss 5.0.1.GA, no fim do post você irá encontrar os códigos fontes e bem como as dependências(jars) da aplicação cliente. Criar uma aplicação Java com Maven é realmente muito fácil mais quando falamos de fazer um deploy no servidor com o cargo usando o plugin do maven as coisas não são tão simples, por que a documentação do Cargo não é 100% intuitiva e faltam exemplos práticos de como usar as configurações. Além disso o JBoss 5 ainda não está 100% com o maven 2, mais para frente do post vocês irão entender o por que disso. Cuidado com o JDK Recomendo que você use um JDK acima do JDKu10 , eu estou usando no mom

Engenharia Reversa com UML em cores

Image
Atualmente para um projeto que estou trabalhando, tive a necessidade básica de entender o que o código fazia :). Então simplesmente olhar código a código não achei uma boa idéia. Eu tinha que entender um framework SOA o qual estou ajudando a construir e um protótipo. Resolvi aplicar o método de UML em cores do Peter Coad . Peter foi um dos criadores da OOAD e um dos caras que mais falam de FDD . Bom neste post vou falar um pouco mais sobre UML em cores e bem como usei o método para ajudar no meu mini-projeto de Engenharia Reversa, então sem mais delongas vamos falar primeiro de UML e de OOAD. UML é um linguagem de modelagem mundialmente aceita no mercado de desenvolvimento de software, mas não se engane UML não é um método, essa é uma grande confusão que o pessoal faz com a Análise Estruturada Moderna . Na Análise Estruturada existia um método, coisa que a UML não propõe. Logo existiu e de facto ainda existe um gap para então saber como fazer as atividades de análise e design. O bject

Mais Poder ao Maven com Archiva

O Maven é uma excelente solução de gerência de configuração para Java, mas você não deve utiliza-lo sozinho, para tirar mais proveito do maven você irá precisar de uma solução de: hospedagem de dependências e proxy. Essa solução é o Archiva , neste post vou mostrar como instalar a solução e bem como a forma mais adequada de utiliza-lo. Em um post anterior eu já tinha mostrado como instalar o Archiva, juntamente com um servidor de Build Continuo e Maven 2. Então se você quiser ver como instalar o Archiva sugiro que de uma olhada neste post . Agora vamos ver a forma mais adequada de lidar com os repositórios e como que o Archiva e o Maven faz isso, vamos discutir a estrutura interna de repositórios do maven e bem como resolver pequenos problemas que você pode passar. Resolução de Dependências com Maven O maven resolve as dependências da seguinte forma. Primeiro ele procura no seu repositório local que fica no $USER_HOME/.m2 caso ele não ache a dependência ali ele iria para web