Estaria eu sendo injusto se falar que ela “jogou fora” a primeira parta da minha certificação de Arquiteto SOA da BEA. Estaria sendo injusto talvez pelo fato de que “fiquei sabendo” agora que eu tinha até o dia 01 de Dezembro para fazer a segunda parte da prova. Pois bem, não fiz.

Não fiz porque a primeira parte fui ter tempo para tirar no dia 4 de novembro (acho que a BEA nem deveria mais ofereçer essa certificação em novembro, já que ela iria se extinguir menos de um mês depois.

Bom, acontece o seguinte, a BEA tinha a certificação para Arquiteto SOA e resolveu fazê-la em duas partes:

• Parte 1 – SOA Foundations: Prova que exigia conhecimento do Modelo “Six Domains” da BEA, conceitos de governança, SOA, conhecimento sobre a aplicabilidade do modelo, ROI na visão do cliente, obstáculos e diferentes cenários passíveis de encontro em uma empresa que estivesse iniciando a adoção.
• Parte 2 – SOA Adoption and Implementation: Todo o restante que não está englobado acima, ou seja, a implementação mesmo, do modelos e exemplos.

Acontece que agora a Oracle, que comprou a BEA, não quis manter em duas provas, quis fazer uma prova apenas, que é chamada obviamente de: Oracle SOA Foundations, Adoption and Implementation (um nome hiper criativo, concordo ) e é claro que terei que tirar a certificação por completo novamente, uma pena.

Mas e se eu tentar entrar em contato, procurar alguma alternativa, o que será que eles dizem? Segue abaixo:

I have taken the Phase 1 SOA Architect exam. If I do not take the Phase 2 exam before December 1, when the exams are combined, do I have to take the full exam even though I’ve already tested on ½ of the material?

If you are pursuing the BEA Certified Architect: BEA SOA Enterprise Architecture credential, you should pass both exams before December 1, 2008. If you do not pass both exams before that date, you will need to take the full Oracle SOA Foundations, Adoption and Implementation exam in order to obtain the Oracle SOA Architect Certified Expert credential.

O jeito agora é focar em estudar o que faltava para a segunda parte, e tirar a certificação por completo!

Para quem tiver interesse, basta visitar esta página no site da Oracle.

Bom, como já disse, não gosto muito de chamar de “legadas” as aplicações que serão ativadas pelo BUS em um arquitetura SOA. A não ser é claro, que realmente façam jus a este nome. O que não gosto é de construir uma nova aplicação que conterá realmente a lógica de negócio do zero, e ainda chamá-la de legada, e olha que isso é mais comum do que pensamos.

Enfim, a nossa grande aplicação que será ativada pelo BUS via JMS, seguindo o desenho deste post se chamará “ReverseIt”, e conterá uma lógica nuclear de inverter a string que receberá como parâmetro. Não vou entrar em detalhes dos detalhes da criação do projeto na IDE, mas basicamente será um “Web Service Project” com o facet do XMLBeans Builder Library, para que ele converta nosso XSD em objetos java facilmente. A aplicação está rodando em um domínio Weblogic Server puro, em localhost:30000.

Vamos definir um schema XSD (dentro da pasta schemas) que contenha a operação de request e de response para a operação. Obviamente como temos um parâmetro string para entrada e outro para saída, ficaria algo bem trivial, basicamente o escrito abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
        targetNamespace="http://blog.lucastex.com/reverseit" 
        xmlns:revit="http://blog.lucastex.com/reverseit" 
        elementFormDefault="qualified">

    <element name="reverseItRequest" type="revit:ReverseItRequest"></element>
    <element name="reverseItResponse" type="revit:ReverseItResponse"></element>

    (...) definição e descrição dos tipos (...)

</schema>

Agora vamos:

• Criar um web service como de costume
• Configurar entrada do serviço para ReverseItRequest
• Configurar saída do serviço para ReverItResponse
• Escrever a lógica para inversão da palavra
   

public ReverseItResponseDocument reverseIt(ReverseItRequestDocument request) {
    
    (...) 1- Pegar input do request
    (...) 2- Inverter a string
    (...) 3- Retornar no response 

}

Legal, mas até aí temos o nosso Web Service tão padrão quanto todos que já fizemos, vamos agora para as anotações, que vão garantir que o serviço trabalhe de forma assíncrona. Bom, como ele funcionará via JMS, uma coisa que temos que fazer é criar uma fila JMS onde serão colocadas as mensagens que este serviço irá consumir, e também uma fila de resposta, para que ele coloque as mensagens de response. Não podemos esquecer também da ConnectionFactory o nosso serviço. Estes foram os nomes que eu dei:

• Fila de Request: reversit.jms.requestQueue
• Fila de Response: reverseit.jms.responseQueue
• ConnectionFactory: reversit.jms.connectionFactory

@WLJmsTransport(serviceUri="ReverseIt",
		portName="ReverseItPort",
		connectionFactory="reverseit.jms.connectionFactory", 
		queue="reverseit.jms.requestQueue", 
		contextPath = "ReverseIt")

 

Bom, um dos cenários que eu mais tenho visto ultimamente em alguns dos lugares onde tenho passado, é quando o cliente quer disponibilizar um serviço para algum terceiro, porém faz questão (e está certo), que a partir do ponto de entrada do terceiro para o barramento de serviços do cliente esta requisição seja processada de forma totalmente assíncrona. 

Com isso, o cliente (que está processando a requisição) ganha em poder de processamento, e o terceiro (que está gerando a requisição) não percebe o que se passa “under the hood” (eu realmente gosto desta expressão), sendo para ele indiferente o que acontece durante o processamento.

Basicamente, este contexto é uma implementação de um Web-Service que utiliza como meio de transporte uma Fila JMS, ao invés do protocolo HTTP que é usado de costume.

Então, vou colocar aqui um exemplo de como fazer isso usando o Aqualogic Service Bus da Oracle (já era um produto da BEA).

Serão 3 pequenas aplicações para isto.

 

• Aplicação Legacy (é um costume horrível chamar estas aplicações de “legadas” visto que em grande parte dos processos de implementação SOA nas empresas, elas são reconcebidas, ou sofrem pelo menos, muitas alterações): É a aplicação que efetivamente possui a lógica de negócio, receberá a requisição do cliente e devolverá a resposta já processada.

• Configuração do Service BUS: Trata-se da exposição do serviço criado na aplicação legada no service BUS, como uma operação.

• Aplicação Tester: É a aplicação que irá consumir o serviço da aplicação legada, através da operação e endpoint disponibilizado no Service BUS.

Um desenho bem feio, mas aproximado deste cenário poderia ser este abaixo (clique para ampliar)

 

 

Diagrama do exemplo (clique para ampliar)

 

Bom, como meu tempo aqui se resume a pequenos intervalos onde eu poderia escrever isto, vou separar em 3 partes, uma para cada aplicação, um post para cada. Assim que der eu já começo!

Valeu!