Software AG Products in Action!

I've found this link that enabled a serie of demonstrations of webMethods products in action. Since we're not able to download the software to test it (god, that's why I like open source) it's a good start to see the features of the products. If you need to download the software to do a proof of concept, it's necessary to make a contact with Software AG local office and request a trial copy of the software. It sucks but, at least they're very compreensive.

Software AG has one of the most complete, mature and robust software for SOA, BPM and Governance of services. Even being a reference for Natural and Adabas technologies, they've a vast portfolio of middleware software. Application Modernization is one of the topics that they're the best. webMethods ApplinX, is one example of good software of their portfolio.

See U ;-)

Process Governance (CDL) usando Overloard

Neste post, irei comentar um pouco sobre um dos projetos mais badalados da comunidade JBoss dos últimos tempos: O projeto JBoss Overloard!

Trata-se de um projeto que visa criar uma infra-estrutura para governança de processos e serviços de negócio usando como tecnologia de referência a especificação de WS-CDL. A idéia é você poder criar um arcabouço conceitual para seus processos e serviços onde cada interação entre eles é rastreada a partir de uma interação de negócios, onde então questões como papéis, responsabilidades, políticas e mapeamento do negócio podem ser, pragmaticamente definidos.

O projeto já têm sua versão 1.0 disponível para download, além de um designer de CDL bastante interessante que roda no Eclipse. Este designer foi resultado de uma doação do conhecido Thomas Erl numa tentativa de tornar a prática de governança de processos mais acessível e solidificado na comunidade de profissionais que usam arquiteturas centradas em serviços. A parte interessante é porque ele escolheu a Red Hat como a empresa que irá cuidar da sua criação original:

"There is a real need to have some support for the specialized service-oriented analysis service modeling process that is required in a typical SOA delivery lifecycle to precede the physical design and development process that comes thereafter. This is a tool that is specifically designed to accommodate service modeling."

Você pode ler mais sobre o assunto em: http://news.softpedia.com/news/Red-Hat-Gets-SOA-Modeler-Tool-60957.shtml

Generating EDI Documents on JBoss ESB

We all know that the XML is the better format to interchange data between applications. It's text based, it's structured and most of the development platforms have support for it. We should consider it as the main (and perhaps) the unique form of data integration.

But when we speak about integration, we've to consider platforms that must not support XML documents, or even that they support, the application could not be changed for some reason. I've worked in a project that must integrate platforms using EDI documents. I've used JBoss ESB as the software for the EAI broker. The JBoss ESB should receive a EDI document, transform this EDI document in XML to be sended for a Web Service endpoint. That part was very easy todo since JBoss ESB has a native smooks support for EDI reading (See the "transform_EDI2XML_Groovy_XSLT" demo for more details).

Have the document processed asynchronously by a legacy platform (the platform that received the SOAP request made by the ESB), this legacy platform notifies the ESB that the request is done sending a JMS message for the Broker. The ESB JMS gateway just deliveries the message for a internal service that makes a series of transformation on the message to prepare it for FTP delivering. Using the current resources of JBoss ESB this was not a hard task to accomplish. But the problem cames when the target endpoint (the application that was waiting for the response) asked me to send a EDI document back to it.

I'd all the data in XML format, and using JBoss ESB transformation features, I could transform this document to anything that I could imagine (CSV, Java, other XML using XSLT). But the customer requirement was delivery a message response using the EDI format, and for my surprise (and bad luck), JBoss ESB does not have support for EDI generation. And because this scenario, this post has been written. I've created a generic action that creates a EDI document from a Java regular object. To solve my problems, I'd transformed the XML response to Java (using Smooks) and from that point, I've used my custom action to generate the EDI document. I'm going to share with you this implementation, since could help you at scenarios like mine. Here we go ...

Imagine for instance, that you've the following XML document at your ESB pipeline:

Using the JBoss ESB current transformation features, we could easily transform this document to a Java instance based on the following group of classes:

At this point, we could generate our EDI document using the following ESB action declaration:

And the result of this transformation would be:

Cool isn't? with this little configuration we can generate a complex EDI document to be sent for every channel that JBoss ESB supports as outbound since it's text based. That's the code I created to support this configuration:

In the implementation above, there are a Java interface mentioned. It's used to define custom behaviors for field processing in that cases when logic are related to a specific field. For instance, suppose that you want to guarantee that a specific field must have 40 characters of length even when the value only have 20. You could write a custom handler for that field and put this logic of characters. Here's the interface code:

Hope that help anybody like me that not every time can determine the format of messages that must be delivered by the ESB. We see around ;-)