Posts

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...