Olá pessoal, tudo certo?
Ao longo dessas semanas, tenho falado sobre orientação a serviços e alguns desafios reais que ocorrem nesse tipo de desenvolvimento e arquitetura. Quando pensamos em questões como autenticação, autorização, instrumentação, suporte a transação, tratamento de exceção, etc., vemos o quanto uma abordagem de serviços possui as mesmas necessidades de uma arquitetura de software baseada em componentes ou mesmo outros cenários de soluções. Ferramentas como a Enterprise Library 4.1 são tão importantes para SOA quanto para aplicações Web em ASP.NET tradicional, por exemplo.
Semana passada, aproveitei um post para citar algumas recomendações sobre o “chão-de-fábrica”. Hoje, gostaria de chamar a atenção para o mapa de produtos da plataforma Microsoft.
Pensando numa arquitetura de referência de serviços e algumas capacidades principais, temos o seguinte desenho:
Vemos acima os grupos de capacidades de Consumo de serviços, Composição e Interação, Composição e Transação e Exposição de Funcionalidades, onde destacamos as principais capacidades:
Veja ainda uma série de capacidades de administração (ao lado), como gerenciamento, segurança, governança, BI, análises de negócio, etc. A partir do modelo acima, podemos posicionar nossos componentes de serviços de acordo com as necessidades de nosso negócio. Existem ainda outras questões associadas, como granularidade de serviços, análise de domínios envolvidos, templates para cada tipo de implementação, etc.
Usando esse mesmo mapa de serviços, gostaria de propor um mapa de produtos atuais da plataforma Microsoft, para atender cada camada acima:
Assim, teríamos (a grosso modo):
Ao mesmo tempo, pacotes como System Center, MOF, Active Directory, ESB Guidance e soluções de terceiros oferecem recursos e ferramentas para as atividades de administração do ambiente.
Vemos que cada produto MS pode atender mais de uma camada ou conjunto de capacidades presentes numa visão de serviços. Ao mesmo tempo, quando pensamos em frameworks como WCF e WF, a implementação é por nossa conta, isto é, construímos os componentes de serviços (WCF) e workflow (WF) a partir de templates disponíveis no Visual Studio, conforme nossa necessidade de customização e desenvolvimento.
Usando pacotes completos como BizTalk Server e SharePoint Server, aproveitamos os recursos integrados oferecidos pelo ambiente, o que economiza dezenas de horas de desenvolvimento. Por exemplo, podemos implementar cenários de serviços customizados com WCF, que disponibilizam informações de notícias para uma certa empresa. Porém, se nossa solução exige a exportação dessas mensagens para uma série de ambientes diferentes, exigindo transformações de mensagens diversas, um motor baseado em BizTalk com seus recursos de mapeamento e transformação passa a ser interessante.
Em resumo, é importante conhecer as capacidades de cada produto, tecnologias e frameworks disponíveis no momento de decisão de cada camada de uma arquitetura de serviços. Podemos dizer que não existe um único produto ou tecnologia que atenda todos os cenários possíveis, de BPM a workflows, de serviços a web services. Cada cenário apresenta necessidades específicas que precisam ser identificadas e corretamente atendidas.
Por último, vale notar que o desenho acima é baseado apenas nas principais capacidades de cada produto. Existem cenários que podem aproveitar os produtos de diversas maneiras, compondo seus recursos e funcionalidades conforme a realidade de cada empresa.
Por enquanto é só! Até o próximo post :)
Waldemir.
PingBack from http://microsoft-sharepoint.simplynetdev.com/capacidades-de-servicos-e-produtos-da-plataforma-microsoft/
Excelente posição, o desenho esclareu muito as duvidas de minha equipe, acho que ira ajudar muitas pessoas. São n alternativas no mercado e isso mostra um mundo um pouco menos confuso.
Olá Claudio, tudo certo?
Obrigado pelo comentário no post !:)
Sem dúvida, esse tem sido um assunto recorrente em diversas empresas. Muitas vezes, a empresa já possui uma infra-estrutura rica, com produtos e tecnologia atuais, mas sem aproveitar o melhor de seus recursos e capacidades.
Independente da visão para serviços, é importante fazer um levantamento sobre os principais recursos de cada produto e plataforma de aplicação, para se obter o melhor ROI possível.
Um abraço!
Olá Waldemir! Excelente post! Acompanho sempre seu blog.
Vejo muito se falar sobre arquitetura de referência, mas gostaria de fazer uma pergunta trivial:
Qual a importância de possuir uma arquitetura de referencia que guie o desenvolvimento dos serviços?
Abraço!
Suzanny
Olá Suzanny, tudo bem?
Obrigado pelos comentários no blog.
Sem dúvida, existem vários desafios presentes num projeto de SOA.
A arquitetura de referência, seja para uma abordagem de serviços ou para qualquer outro modelo (como web, mobile, RIA, etc), apenas orienta a posição das várias camadas, enquanto oferece uma direção para a equipe de desenvolvimento no relacionamento entre essas camadas.
De fato, existem vários desafios na construção de uma arquitetura de serviços. Veja alguns:
1. Um cenário de serviços envolve uma reorganização da infra-estrutura, que precisa estar preparada para suportar capacidades de serviços diversos, como provisionamento, containers de serviços, administração, operação, etc. Uma arquitetura de referência pode ajudar apontando quais camadas são responsáveis pelos aspectos de infra-estrutura da arquitetura;
2. Um cenário de serviços envolve também uma metodologia e disciplinas que ajudem no reconhecimento dos domínios de negócio e funcionalidades que serão publicadas como serviços. Uma arquitetura de referência pode ajudar no plano de projeto, apontando quais serviços serão prioritários e suas relações com outras camadas (processos, workflows, serviços compostos, etc);
3. Uma arquitetura de serviços envolve conhecer os vários cenários de serviços disponíveis na empresa, assim como os principais SLA’s esperados. Questões como latência, integração de transações, recuperação, sincronização, etc. têm colaborado para surpresas desagradáveis em diversos projetos de SOA. Empresas que não fazem esse mapeamento prévio, correm sérios riscos. Podemos usar uma arquitetura de referência para lembrar quais são os pontos de risco, destacando os patterns em 3 grupos possíveis: consumo de serviços, implementação de serviços, administração de serviços.
Como eu disse, ajuda!! mas é só uma parte do processo! :)
Fique a vontade para novas questões.
Olá pessoal, tudo certo? Aqui no blog tenho aproveitado para falar bastante sobre os vários cenários