MonthFebruary 2013

Changing Default HSQLDB to Use Database in Jboss 4.2.3 for JMS

As we know jboss uses HSQLDB for the jms persistence to modify this to persist the JMS messages to user Database like mysql, oracle, etc. Following changes as to be made in jboss 4.2.3. We assume the Postgres Database for this purpose.

1. Delete the hsqldb-ds.xml from JBOSS_HOME/server/[instance]/deploy folder.

2. Copy the respective database related ds file from JBOSS_HOME/docs/examples/jca/*-ds.xml file to deploy folder of your [instance].

3. Change the jndi-name in *-ds.xml file to “DefaultDS“.

4. Delete hsqldb-jdbc2-service.xml file from JBOSS_HOME/server/[instance]/jms folder.

5. Copy the respective database persitence manager service xml file *-jdbc2-service.xml from JBOSS_HOME/docs/examples/jms to JBOSS_HOME/server/[instance]/deploy/jms folder.

6. Change the jndi name in the *-jdbc2-service.xml to “DefaultDS“, jboss.jca:service=DataSourceBinding,name=DefaultDS

7. Rename the hsqldb-jdbc-state-service.xml to respective database name *-jdbc-state-service.xml, its optional you can keep the file as it is.

8. Copy the respective database connector jar file to /JBOSS_HOME/server/[instance]/lib folder.

Now the configuration is modified for the jms persistence to user database and data will persist to jms_message table only when the huge number of jms are generated and its a temporary storage once the jms message is consumed it will deleted automatically from the jms_message table.

Afinal, o que é o Modelo Canônico?

Antes de mais nada, Modelo Canônico é uma questão de semântica. Em se falando de SOA, o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões. Na realidade, a solução SOA precisa incluir um amplo interesse do conjunto de design, refletindo informação das melhores práticas de arquitetura a fim de escalonar o suporte totalmente, consistente e acesso reutilizável da informação.

Mas antes de falar sobre canônico, vamos voltar em um tópico mais “básico” que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um “simples” refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados, vai ser um “Deus nos acuda”. Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio.

Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.

Então, respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.

Uma terminologia consistente é um bom ponto de partida na concepção de serviços mas isso por si mesmo não é suficiente. Você deve também ter um entendimento claro da forma como a informação do negócio é estruturada. Os parâmetros de entrada e saída, isto é as mensagens, são geralmente muito mais complexas do que dos únicos tipos de dados. Eles representam as definições complexas das entidades e os relacionamentos entre eles. O tempo de desenvolvimento e qualidade dos projetos SOA podem ser muito melhorados se arquitetos SOA alcançam o modelo canônico no designing dos formatos de dados expostos e modelos de serviços. O alinhamento resultante do processo, serviço/mensagem e modelos de dados aceleram o design, alcançam orientação normativa para a modelagem de dados e evita transformações desnecessárias.

Modelagem sempre é um assunto indigesto, pesado. Digo isso porque leva um tempo para ser digerido, assimilado, e isso só é alcançado através de exercícios, ou seja, só se aprende fazer fazendo! Mas existem algumas ‘dicas’ que podem ajudar a encurtar este caminho.

A parte mais dificil e complexa na modelagem do Modelo Canônico é a ‘normalização semântica’, então vamos deixa-la para o próximo post, começando pela parte técnica:

  • Como estamos falando em SOA e a maioria das implementações utiliza SOAP, a implementação do Modelo Canônico é em XML Schema;

  • Deve ser definida um padrão de nomenclatura. Normalmente é utilizado como em java, UpperCamelCase para os tipos (complexType) e lowerCamelCase para campos (element);

  • Como as entidades do Modelo Canônico são reutilizadas por várias operações, não é possível definir a obrigatoriedade dos campos (elementos). Por este motivo todos os campos devem ser opcionais utilizando o atributo minOccurs="0"e não devem possuir nenhum tipo de restrição, como limite de tamanho;

  • Utilize element para representar os campos, não attributes;

  • Não utilize referência cíclica, mais conhecida como relacionamento bi-direcional. Por exemplo: se a entidade Cliente possui um relacionamento com a entidade ContaCorrente não deve ser criado um relacionamento da entidadeContaCorrente para Cliente. Isso pode gerar problemas de performance e incompatibilidade em alguns clients / ferramentas;

Depois da parte técnica, existem alguns tópicos relacionados a modelagem:

  • Evite criar relacionamentos entre entidades muito independentes. Este tipo de composição pode ser feito na interface do serviço;

  • Eventualmente uma associação é identificada, porém não é necessário que tais informações sejam estruturadas. Neste caso a desnormalização pode ser usada. Por exemplo: a entidade Endereço possui todos os campos do entedereço estruturados, porém para a entidade Nota Fiscal esta normalização não é necessária, podendo ser um único campo texto;

  • Em alguns casos similares ao exemplo acima o tipo de informação de uma determinada entidade muda de acordo com o contexto. Por exemplo para o contexto de faturamento o Cliente possui algumas informações e para o contexto de CRM possui outros. Neste caso a entidade Cliente pode ser ‘quebrada’ de acordo com o domínio;

Modelagem é um assunto complexo e subjetivo. E ainda existem outras considerações a respeito da modelagem de Modelo Canônico.

© 2017 Ziben IT Solutions

Theme by Anders NorénUp ↑