Classificação de Serviços

Como falado nos dois últimos posts, Princípios de Design de Serviço e Granularidade de Serviços, foi mencionado que: O reúso é muito importante, mas não pode ser encarado como único direcionador na hora de levantar ou classificar um serviço. Já foi falado como a granularidade afeta a modelagem e o reúso, mas o que tudo isso tem a ver com a Classificação de Serviços?

Classificacao de Serviços

Este é o segundo post que suporta o tema Como o Reuso pode Atrapalhar uma iniciativa SOA!

(mais…)

Granularidade de Serviços

Como falado no último post, O reúso é muito importante, mas não pode ser encarado como único direcionador na hora de levantar ou classificar um serviço. Tá, mas o que isso tem a ver com Granularidade de Serviços?

granularidade

Senti a necessidade de escrever sobre Como o Reuso pode Atrapalhar uma iniciativa SOA! Estranho né? Mas foi algo que eu percebi que pode acontecer e precisava de uma certa atenção. Mas antes disso é importante explicar definir alguns conceitos, o primeiro deles é a Granularidade de Serviço.

(mais…)

Estratégia de Tratamento de Erros

Tratamento de erros é sempre um ponto negligenciado por muitos desenvolvedores. Quem nunca se deparou com um bloco catch vazio? Neste post vou iniciar uma abordagem deste assunto com ênfase na camada SOA.

Ilustração da implementação do Exception Shielding

Detalhes da exceção, em vermelho, sendo filtrados na implementação do serviço

(mais…)

Estudo de caso: Lições aprendidas de um grande projeto SOA

Recentemente participei desde o início de um grande projeto SOA, onde um dos maiores problemas foi uma corrida desenfreada contra o tempo. Acredito que a principal lição, e um tanto quanto obvia, foi: quanto mais rápido você tenta correr, mais se distancia do seu objetivo. Seguem os pontos positivos e pontos de melhoria do projeto como um todo:

Pontos positivos: No começo do projeto foram estabelecidas práticas de integração contínua. Isso economizou muito tempo.

Pontos de melhoria: Reuniões de kickoff, cerimônias como Daily Meeting, Sprint planning não podem ser ignoradas. Elas existem por um motivo, só as remova caso sua equipe tenha muita sinergia e maturidade (como equipe, maturidade individual não conta muito neste sentido).
Tenha apoio de um especialista no domínio (Project Champion, PO (Project Owner), analista de negócio, etc) caso não seja possível, aloque um membro da equipe no cliente e transforme-o no seu PO. Depois de algumas semanas imerso, ele conseguirá direcionar funcionalmente o restante da equipe, compensando em partes esta deficiência do projeto, conduzindo kickoffs de fases do projeto e sprint plannings.

(mais…)

Governança SOA na prática

Dando continuidade a nova série de posts sobre governança, vou aproveitar a palestra que ministrei no TDC 2013 SP e acabei não postando aqui. Apesar de ter sido uma apresentação hands-on fiz um vídeo demonstrando a criação de alguns assets em uma repositório.

O principal objetivo desta palestra foi demonstrar que é possível ter os benefícios de uma governança com pouco overhead, com auxílio de ferramentas especializadas, um pouco de processo e automatização.

(mais…)

Modelo Canônico: Vilão ou Mocinho?

Mais de dois anos após a publicação do meu primeiro post sobre o assunto ele continua atual, apesar de o foco agora estar mais voltado à API’s (o que não deixa de ser SOA, mas isso fica para outro post).

Pensando nisso montei uma palestra onde tentei mostrar a importância do Modelo Canônico e algumas práticas que facilitam a modelagem e evolução do modelo.

Esta palestra foi apresentada no TDC 2014 SP na trilha SOA e BPM, que ocorreu no dia 06/08/2014:

(mais…)

Modelo Canônico – Estudo de caso

Faz um ano que escrevi o ultimo post sobre este assunto, mas ainda existe muita confusão neste tema. Como os três primeiros a abordagem foi muito teórica, vou tentar dar um exemplo mais prático:

Considere que três sistemas legados possuem informações de cliente, o sistema de conta corrente possui informações básicas como código, cpf e nome, além das informações de movimentação da conta corrente; o sistema de crédito possui as informações básicas e o histórico de empréstimos do cliente; o sistema de cadastro de clientes, por sua vêz, possui as demais informações pessoais do cliente. Segue abaixo um diagrama com a representação do cliente nos três sistemas:

Modelo de dados dos sistemas legado

(mais…)