SOA, EDA, EAI e afins

Eu vejo da seguinte maneira…

Com CDM ou não, esse modelo geral e único da empresa existe, pois esse é o negócio da empresa, o que muda é que ele geralmente está espalhado em várias aplicações, bancos de dados diferentes, com muita coisa duplicada, mas de um jeito ou de outro esse modelo existe.

E hoje uma preocupação maior com esse “modelo” está surgindo e com a idéia de “aproveitar” o que já está pronto, então essas siglas que vc citou vão crescendo mais e mais.

Mas com a grana que se gasta pra montar toda a “parafernalha” e se utilizar SOA, EAI, ESB, etc…etc…etc… Na IMHO eu faria um sistema direito, pensando mesmo nos módulos e subsistemas, com integrações descentes, sem essas “tralhas” no meio do software, mas admito que nunca consegui vender essa idéia para os superiores pq a propaganda de SOA é muuuuito forte.

Pq um ponto que vc citou tá certo, mudança nas regras vão ter, sendo o sistema baseado em “Business Services” ou em OO pura e simples, a diferença é como a equipe responde à essas mudanças.

[]´s

Olá Zinho, muito boa sua colocação gostei da pauta do assunto.

O modelo canônico realmente tem muito haver com o modelo de domínio e é a extração do negócio da companhia fisicalizado numa implementação intercambiável. As duas pontas precisam enxergar o mesmo modelo, para que a integração ocorra. Quando falamos em mudanças e refactoring, caímos em versionamento de serviços. Se você tem um modelo o cujo fora alterado, ele deixa de ser compatível, por tal motivo há introdução do conceito de Governança com repositórios, a fim não quebrar compatibilidade entre os serviços.

Os serviços podem e devem ser criados de forma iterativa mas para um maior sucesso do seu projeto, seria interessante ter ao menos um modelo de domínios que extraia a maior parte do seu negócio. Então não é um BDUF e sim apenas uma modelagem de domínio prévia , que irá perpetuar por toda sua gama de serviços.

Fazer esse design de forma iterativa implicará em muito tempo gasto em refactoring, talvez o custo disso não compense ao longo do projeto. Lembre-se, quando falamos em SOA, estamos supondo que haverá coordenação de serviços ( orquestração), com alguma plataforma como ESB (nível sistêmico) , ou BPM ( negócio) , linguagens de manipulação de XML, como Xquery e qualquer mudança no modelo implica rever todos os artefatos que foram produzidos e possuem referência.

Claro que você não vai conseguir numa primeira passagem abstrair todo o negócio da companhia para um modelo de domínio, essa é uma tarefa árdua. Entretanto, quanto melhor a qualidade do seu desenho, menor o impacto em refactorings e melhor para que se construa serviços em tempo de necessidade.

Quanto à diferença entre SOAP-WSDL e REST isso não se aplica, pois é somente a forma do empacotamento. O modelo canônico, ou seja o schema do seu negócio XSD, continua válido e você irá representar via XML da mesma maneira.

Valeu Kenobi, muito legal sua explicação.

O que sinto que acaba acontecendo é bem o que você citou, uma mudança qualquer no seu modelo canônico gera um grande trabalho para alterar XSDs, XQueries, XPaths, etc.

Um outro problema que vejo acontecer é que muitas vezes existem dados (geralmente no SGBD) nos sistemas legados que ninguém sabe para que servem. Com medo de faltar informação acabam poluindo o modelo canônico com tais dados e acabam perdendo uma grande chance de criar um modelo mais limpo e coerente.

Como você trata a questão de obrigatoriedade de informações?
Por exemplo. Você tem um Schema que representa um produto e dentro dele um elemento “descricao”. É obrigatório todo produto possuir uma descrição, porém nem sempre o serviço que irá receber um produto precisa desse elemento preenchido.
Você obriga (no XSD) o preenchimento desse elemento ou não (minoccurs = 0) e depois valida isso em uma Xquery por exemplo?

zinho:

Valeu Kenobi, muito legal sua explicação.

O que sinto que acaba acontecendo é bem o que você citou, uma mudança qualquer no seu modelo canônico gera um grande trabalho para alterar XSDs, XQueries, XPaths, etc.

Um outro problema que vejo acontecer é que muitas vezes existem dados (geralmente no SGBD) nos sistemas legados que ninguém sabe para que servem. Com medo de faltar informação acabam poluindo o modelo canônico com tais dados e acabam perdendo uma grande chance de criar um modelo mais limpo e coerente.

Como você trata a questão de obrigatoriedade de informações?
Por exemplo. Você tem um Schema que representa um produto e dentro dele um elemento “descricao”. É obrigatório todo produto possuir uma descrição, porém nem sempre o serviço que irá receber um produto precisa desse elemento preenchido.
Você obriga (no XSD) o preenchimento desse elemento ou não (minoccurs = 0) e depois valida isso em uma Xquery por exemplo?

Não obrigar o preenchimento - minoccurs = 0 , poderá quebrar serviços que necessitam dessa informação. Como o modelo é válido para diferentes serviços o mais prudente é carregar a informação e o serviço que não precisa daquela, irá descartar. O Overhead de tráfego é pequeno e evita dor de cabeça. Agora se você identificar que vários serviços necessitam somente de “parte” da informação, então está na hora de criar outro elemento, com referências a um mais completo, mas trazendo somente aqueles dados que serão necessários.

Bom dia, estava pesquisando sobre SOA, e acabei por encontrar este tópico, não sei o quanto o assunto do tópico é revelante a dúvida que tenho, mas minha dúvida é quanto a estas mensagens trocadas e conversão para modelos canônicos, estive olhando um site onde tem uma figura sobre a arquitetura de funcionamento do SOA, que está abaixo, o que eu não entendi e não consegui idealizar um caso real quando um consumidor 2 consome o serviço B, e o consumidor 3 consome o serviço C.

supondo que eu tenha um consumidor que tem a tabela de pessoa com a seguinte estrutura:

ID
NOME
SOBRENOME

e outro com a estrutura:

ID
NOMECOMPLETO

com estas estruturas acima, se eu precisar utilizar serviços de inclusão de pessoas um com os 3 parâmetros e outro com 2, supondo que o modelo canônico seja ID e NOMECOMPLETO, então o ESB converteria o nome e sobrenome para um campo só, de nomecompleto? é isto?

e quanto a conversão no Adaptador, por exemplo, para que ele serve?

Obrigado pela atenção!

dudu,

nao responder sua pergunta com precisão, mas talvez o link abaixo ajude vc

http://www.ricardogiaviti.com.br/2011/07/o-modelo-canonico-em-uma-abordagem-soa/