Lendo vários papers pela net sobre SOA, servicos, eda, eai, bla, bla, fiquei com algumas pugas atrás da orelha.
Sei que integração de sistemas não é nada trivial e que decisões devem ser tomadas com cuidado, já que qualquer mudança será fatalmente muito mais dolorasa que refatorar um sistema qualquer.
Mas a impressão que tenho é que a maioria das abordagens, quando fala-se em SOA, vai contra todo esse “movimento” “anti waterfall”, contra o BDUF, etc …
Fala-se por exemplo na criação de um CDM (Canonical Data Model) para toda a organização. Vejo esse CDM mais ou menos como uma especie de modelo de domínio (tudo bem que são só estruturas de dados) mas, pelo menos o que tenho lido, não parece ser criado iterativamente e sim num grande BDUF.
Vocês utilizam esta abordagem de criar um modelo de dados comum para toda a organização?
E quando saimos do tradicional “SOAP/WSDL” e partimos para REST por exemplo? Isso ainda é válido?
Acho que minha maior preocupação é, as pessoas estão conseguindo implementar “Business Services” de forma iterativa ou estamos voltando para o waterfall? Se classes e métodos sofrem refatoração o tempo todo, seja por evolução ou alguma mudança no dominio, não seria um erro achar que é possível criar serviços e modelos de dados “a prova de mudança”? Ou to viajando e ninguém está tentando fazer isso?
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.
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.
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?
[quote=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?[/quote]
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?
