A TI nos dias de hoje passa cada vez mais por dificuldades. Dentre elas, posso citar a falta de alinhamento com o negócio como um dos maiores males. Com a globalização e a alta competitividade é cada vez mais importante se adaptar às mudanças e responder de forma
efetiva às necessidades do negócio. Esta resposta muitas vezes não é
rápida e muito menos fácil.
É muito comum vermos áreas de TI bagunçadas, com zero de
governança, com sistemas defasados, pessoas destreinadas, processos
pouco eficientes e, claro, muitos sistemas. Estes sistemas muitas vezes
têm sérios problemas de acoplamento e integração.
Mas por que SOA?
Porque com SOA você vai deixar o seu negócio mais ágil e fazer com que
as mudanças, quaisquer que sejam, aconteçam de
forma mais rápida e menos dolorida. Toda empresa consegue mudar, a
questão é o quanto isso é fácil e qual o custo envolvido. Poder realizar mudanças nos sistemas de sua empresa não é mais um
diferencial competitivo, mas conseguir efetuar isso com custo baixo e de
forma mais tranquila, evitando sustos e imprevistos, é sim algo que
precisamos atingir.
Uma vez que você decide adotar SOA para ajudar o seu negócio, você deve
bolar um plano estratégico visando o longo prazo, mais que dois anos, com certeza. As coisas devem ser feitas de forma
incremental, não tente atingir a perfeição de cara, isso só vai levar ao
fracasso.
Se você já tem um plano focando nas necessidades de
negócio e o que você sabe o que quer atingir visando um curto, médio e longo prazo,
você já deve ter alguns serviços funcionando e alguns consumidores para
este serviço.
Ok e como vai a sua governança? Bom, se você me disser que já tem um
plano de governança definido com certas decisões de design como
contratos, versionamento, metadados, escolhas de design e decisões
arquiteturais, eu diria “que bom”. Porque toda governança deve começar
com o design primeiro, depois disso você pode começar a pensar em
aspectos de runtime e na sua solução de repositório.
Por que eu preciso de uma solução de Repositório em SOA?
Você tem serviços diversos, e precisa saber onde eles estão, quais são as suas dependências, quais as versões que existem. Além disso, você precisa ser capaz de governar os serviços
colocando QoS, SLAs e policies em tempo de runtime. Existem diversas
soluções de governança SOA, mas todas elas sempre vão focar no aspecto de
runtime, logo você deve pensar em design primeiro e definir o seu
caminho, isso deve ser feito antes de você pensar em uma ferramenta.
Mule Galaxy
É uma solução open source da MuleSoft.
Este produto tem duas versões, uma paga e outro free. A versão
paga tem mais funcionalidades, mas você consegue viver bem com a versão free. O Galaxy lhe ajuda em diversos aspectos, como por exemplo:
- Gestão de Contratos
- Descoberta de Serviços
- Deploy estagiado
- Integração com Mule ESB, Apache CXF e Spring Framework
- Pesquisa, Tag, Monitoramento de ativos
O legal do Galaxy é que ele transforma os seus artefatos em ativos,
já existe uma série de ativos pré-cadastrados como por exemplo:
- Configuração do Spring (xml)
- Documento de Policies (CXF)
- Schemas de XML (XML, XSD)
- Arquivos Jar (jar)
- WebServices(WSDL)
E você ainda pode definir outros tipos de ativos, então você pode
definir os seus outros ativos, como por exemplo um pom.xml do maven ou um
arquivo de properties com configurações. Além disso, é possível
recuperar estes ativos através de uma API REST usando Atom pub api.
Com o Galaxy você pode recuperar estas informações e ativos usando o
Spring. Por exemplo, existe um ApplicationContext personalizado para o
Galaxy que você pode usar para buscar as configurações do Spring, claro
que você deve ter as classes no seu classpath.
Ainda é possível registrar os seus serviços/ativos durante o seu
processo de build, usando maven e uma solução de integração contínua,
como o Hudson. Em um próximo post vou mostrar como fazer esta tarefa de
forma detalhada e com um exemplo prático.
Caso você tenha interesse, eu tenho uma apresentação no meu slideshare
sobre o Governança SOA e Mule Galaxy.
Colocando a mão na massa
Agora, vamos criar um projeto no maven que consegue fazer deploy de ativos no Mule
Galaxy, usando o plugin de publicação do Galaxy para o Maven. Vamos criar
um bean no spring e um arquivo de configuração deste bean para o Spring
e também vamos registrar este bean como ativo no Galaxy, bem como um
WSDL de um webservice.
Instalando e Rodando o Mule Galaxy
Basta baixar o
war do Galaxy e colocá-lo no seu servidor de we. Eu vou utilizar no
Jetty, mas poderia ser outro. Você deve rodar a
solução com JDK 6 update 10 ou superior para não ter problemas com XML.
Estou usando a versão 1.5.3, porque a 2.0 ainda não é release e
está no M6. Você pode usar esta versão se quiser, ela tem algumas
funcionalidades novas, mas contém mais bugs.
Uma vez que você tenha baixado o mule e subido o seu servidor de
aplicação, você pode logar na solução, o usuário e senha padrão são admin
admin.
Vamos efetuar o deploy dos ativos usando maven, mas pelo console de
administração você pode fazer deploy de ativos, ou até mesmo evoluir as
versões dos ativos já existentes. Então vamos ao projeto do maven.
Estrutura do Projeto

Este é um projeto padrão maven 2 no eclipse. Perceba que na pasta src/main/resources
contem os seguintes arquivos:
- 123.pom.properties
- metadata-spring-beans.xml
- UKBorderService.wsdl
Durante o deploy todos estes artefatos serão publicados no mule. Vamos ver as dependências e o script para deploy usando maven, então:
<plugin><br /> <groupId>org.mule.galaxy</groupId><br /> <artifactId>galaxy-maven-publish-plugin</artifactId><br /> <version>1.0</version><br /> <configuration><br /> <url>http://localhost:8070/galaxy/api/registry/Default%20Workspace</url><br /> <username>admin</username><br /> <password>admin</password><br /> <!-- Publish shared artifacts --><br /> <includes><br /> <include>src/main/resources/*.xsd</include><br /> <include>src/main/resources/*.wsdl</include><br /> <include>src/main/resources/*.xml</include><br /> <include>src/main/resources/*.properties</include> <br /> </includes><br /> </configuration><br /> <executions><br /> <execution><br /> <id>publish-artifacts</id><br /> <phase>package</phase><br /> <goals><br /> <goal>execute</goal><br /> </goals><br /> </execution><br /> </executions><br /> </plugin>
Como você pode ver, estou passando o url do galaxy com a API de atom e
usuário e senha, se você não quer deixar a senha fixa, é possível parametrizá-la usando o arquivo de settings.xml ou passar por parâmetros
na hora de executar o mojo.
Outra coisa importante aqui são os includes, com eles você especifica
quais artefatos devem ser publicados no Galaxy, estou configurado para
que o deploy aconteça automático para os artefatos:
- XSD
- WSDL
- XML
- Properties
Você pode criar seu formato personalizado, isso é muito
interessante. Na versão 1.5.3 do console você não pode fazer esta
tarefa, na versão 2.0-M6 é possível criar estes novos tipos pela
interface web.
Ainda é possível excluir artefatos, por que por padrão o galaxy vai
publicar todos os jars da sua aplicação seja os gerados pelo maven ou
das dependências. Então caso esse comportamento não seja interessante
para você, é necessário colocar uma exclusão.
Para rodar o script e publicar os seus ativos no Mule Galaxy basta rodar
no maven:
$ mvn install
Você pode verificar se a publicação ocorreu com sucesso no próprio
console do Galaxy.
Perceba que o Mule já informa para você quais os beans que estão no
arquivo de configurações do spring, além disso você pode adicionar
metadados ao ativo, estes metadados podem ser utilizados em futuras
pesquisas no Galaxy.
Carregando a Configuração de Beans do Spring
O Galaxy tem um plugin de integração com o Spring, agora vamos ver isso
em prática. Para mim esta é uma das melhores funcionalidades da solução.
Porque assim você pode externalizar totalmente a configuração do
spring e isso é bom por diversos motivos, mas o que é melhor é que você
pode definir um projeto com classes, interfaces e diversos padrões para
metadados e reutilzar estas funcionalidades em diversos projetos através
do mule galaxy.
Vamos ver um classe simples que criei, a idéia é que vou recuperar o
arquivo do spring com as definições dessa classe que estarão registras
no galaxy. Confira a classe abaixo:
package com.blogspot.diegopacheco.mule.galaxy.metadata;<br /><br />import java.util.Map;<br /><br />/**<br /> * POJO metadata for mule configuration loader.<br /> * @author Diego Pacheco<br /> * @version 1.0<br /> * @since 14/03/2010<br /> *<br /> */<br />public class MetadataInfo {<br /><br /> private String applicationID;<br /> private Map<String, Object> policies;<br /><br /> public MetadataInfo() {}<br /><br /> public String getApplicationID() {<br /> return applicationID;<br /> }<br /><br /> public void setApplicationID(String applicationID) {<br /> this.applicationID = applicationID;<br /> }<br /><br /> public Map<String, Object> getPolicies() {<br /> return policies;<br /> }<br /><br /> public void setPolicies(Map<String, Object> policies) {<br /> this.policies = policies;<br /> }<br /><br /> @Override<br /> public String toString() {<br /> return "ApplicationID: " + applicationID + ", Policies: " + policies;<br /> }<br /><br />}
Perceba que é uma classe java normal, sem nada de mais. Repare que o
Galaxy gerencia os arquivos de configuração do spring, então na prática é
apenas um arquivo xml; logo, você pode fazer o que quiser, mas, na hora
de rodar sua aplicação, se as injeções estiverem erradas ou você não
tiver todas as classes, vai ver um belo erro, então tenha certeza de que está
com todas as dependências setadas.
Vamos ver o arquivo de configuração do Spring que foi publicado no
Galaxy.
<?xml version="1.0" encoding="UTF-8"?><br /><beans xmlns="http://www.springframework.org/schema/beans"<br /> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br /> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"><br /><br /> <description>Spring Application Context</description><br /><br /> <bean id="RootMeta"<br /> class="com.blogspot.diegopacheco.mule.galaxy.metadata.MetadataInfo"><br /> <property name="applicationID" value="app01" /><br /> <property name="policies"><br /> <map><br /> <entry><br /> <key><value>pl01</value></key><br /> <value>teste</value><br /> </entry><br /> </map><br /> </property><br /> </bean><br /> <bean id="RootMeta2"<br /> class="com.blogspot.diegopacheco.mule.galaxy.metadata.MetadataInfo"><br /> <property name="applicationID" value="app02" /><br /> <property name="policies"><br /> <map><br /> <entry><br /> <key><value>pl02</value></key><br /> <value>teste2</value><br /> </entry><br /> </map><br /> </property><br /> </bean><br /></beans>
Agora podemos ver o código que carrega as informações do spring que estão
no Galaxy. Vamos usar o plugin do spring; para isso você precisa da
seguinte dependência do maven no seu pom.xml:
<dependency><br /> <groupId>org.mule.galaxy</groupId><br /> <artifactId>galaxy-integration-spring</artifactId><br /> <version>2.0-M6</version><br /> </dependency>Confira também o código que acessa os dados do spring, na classe abaixo:
package com.blogspot.diegopacheco.mule.galaxy.spring;<br /><br />import java.net.URL;<br /><br />import org.mule.galaxy.spring.GalaxyApplicationContext;<br />import org.springframework.context.ApplicationContext;<br /><br />import com.blogspot.diegopacheco.mule.galaxy.metadata.MetadataInfo;<br /><br />public class SpringRetriveMetadata {<br /> public static void main(String[] args) {<br /> try{<br /> String configURL = "http://admin:admin@localhost:8070/galaxy/api/registry?q=select artifact where spring.bean = 'RootMeta'";<br /> ApplicationContext ctx = new GalaxyApplicationContext(new URL(configURL));<br /><br /> MetadataInfo to = (MetadataInfo)ctx.getBean("RootMeta"); <br /> System.out.println("Sprint CXT: " + ctx);<br /> System.out.println("Bean: " + to);<br /><br /> }catch(Exception e){<br /> e.printStackTrace();<br /> }<br /> }<br />}
Perceba que estou usando a GalaxyApplicationContext, que é uma
implementação do Mule Galaxy da interface ApplicationContext, do Spring
Framework. Também estou informando onde está o galaxy através de uma URL;
e mais, estou fazendo um query no estilo SQL para pegar o bean do
spring que me interessa.
Se você quiser as fontes completas, pode baixar no meu repositório
do Subversion. Em uma próxima vez, vou mostrar como criar uma
policy personalizada e fazer o deploy desta policy no Mule Galaxy.
Abraços e até a próxima.







