Impactos de SOA na Metodologia de Desenvolvimento de Software
Quando a gente pensa em SOA. Várias coisas mudam com relação a forma padrão de se desenvolver software.
Geralmente um sistema é desenvolvido a partir uma demanda de negócio e o cliente desse sistema tem na cabeça um série de telas que seguem a uma determinada sequencia de passos.
Baseado nessa sequência de telas o analista sistemas confecciona casos de uso( no caso de MDS baseada no RUP) ou use estories (no caso de MDS baseada em SCRUM) com o objetivo de traduzir essa visão do cliente.
A princípio essas telas manipulam as informações ali postadas e as grava num banco de dados.
Ainda nesse contexto um arquiteto de sistemas pensa na tecnologia que será adotada para se desenvolver o sistema e no padrão de desenvolvimento que os desenvolvedores deverão utilizar para a implementação deste sistema.
Bom, até aqui acredito que não existam novidades. Tudo o que foi feito baseou-se no processo de negócio apresentado pelo demandante do sistema e acontece em função do sistema que está sendo desenvolvido. Mais tradicional que isso, impossível!
Quando uma empresa adota o SOA deve-se pensar de uma forma mais corporativa, ou seja, os esforços de desenvolvimento não devem se limitar apenas ao sistema em questão, mas sim ao reuso desses esforços na construção de outros sistemas. Falei alguma novidade? Muitos dirão que não. Afinal de contas as aplicações de hoje são compostas por componentes.
Esses componentes estão muito voltadas para uma tecnologia específica. Como exemplo, podemos citar sistemas feito em java. Estes podem conversar perfeitamente com outras aplicações java. Entretanto criar uma interface capaz de fazer dois sistemas feitos utilizando linguagens de programação diferentes pode ser um grande desafio.
É possível? Obviamente sim. É a melhor forma? Dependo da situação pode ser, contudo existem formas mais inteligentes de se desenvolver esses sistemas e é aí que entra o SOA.
Isto posto, vamos imaginar o seguinte cenário: imagine se transformássemos os componentes que constituem um sistema em serviços multiplataforma reutilizáveis imaginando ainda que esses componentes venham compor vários sistemas. Essa não seria uma forma inteligente e mais barata de se desenvolver um sistema? A resposta é COM CERTEZA.
Entretanto é importante desenvolver esses serviços de forma inteligente com baixo acoplamento e alta coesão e para fazer isso o SOA utiliza-se de oito princípios que tentam responder alguns questionamentos:
• Como identificar os serviços a serem criados?
• Que características deve ter esse serviço?
• Qual tamanho deve ter o serviço em questão?
• Esse serviço deve atender ao processo como um todo ou deve atender a apenas uma atividade desse processo?
Falaremos agora sobre os princípios do SOA:
1. Toda interface de um serviço deve ter um contrato formalizado
2. Os serviços devem ter baixo acoplamento
3. Os serviços devem ser abstratos
4. Os serviços devem ser reutilizáveis
5. Os serviços devem ser autônomos
6. Os serviços não devem manter estado
7. Os serviços devem ter a capacidade de serem descobertos
8. Os serviços podem ser compostos
Muito bem, será que o foco deste texto é realmente externar os impactos que uma MDS tradicional. Na primeira parte falamos sobre as diferenças. Agora vamos tratar dos impactos. Basicamente falaremos sobre as etapas envolvidas no ciclo de vida do desenvolvimento de sistemas.
1. Etapa de planejamento (alto impacto)
2. Etapa de análise (médio impacto)
3. Etapa de design (Impacto alto)
4. Etapa de teste (baixo impacto)
É isso aí.
segunda-feira, 29 de agosto de 2011
terça-feira, 26 de abril de 2011
XSLT
XSL é o acrônimo de eXtensible Stylesheet Language, e é uma linguagem de folhas de estilo para documentos XML.
XSLT significa XSL Transformations. Aqui aprenderemos como usar o XSLT para transformar documentos XML em outros formatos, como XHTML.
XSL consiste de três partes:
• XSLT - uma linguagem para transformar documentos XML
• XPath - uma linguagem para navegar em documentos XML
• XSL-FO - uma linguagem para formatar documentos XML
XSLT é uma linguagem para transformar documentos XML em documentos XHTML ou para conveter esses documentos em outros documentos XML.
Como funciona?
No processo de transformação, XSLT usa XPath para definir partes do documento de origem que deve corresponder a um ou mais modelos predefinidos. Quando uma correspondência é encontrada, XSLT transformará a parte correspondente do documento de origem no documento de resultado.
Vamos a um exemplo:
Empire Burlesque
Bob Dylan
EUA
Columbia
10,90
1985
Vamos ao arquivo XSL
Neste exemplo estamos transformando o arquivo xml em outro arquivo xml, mas nada impede de você transformar o documento xml em um arquivo html por exemplo.
No próximo post falarei sobre o XPath.
Grande abraço!
XSLT significa XSL Transformations. Aqui aprenderemos como usar o XSLT para transformar documentos XML em outros formatos, como XHTML.
XSL consiste de três partes:
• XSLT - uma linguagem para transformar documentos XML
• XPath - uma linguagem para navegar em documentos XML
• XSL-FO - uma linguagem para formatar documentos XML
XSLT é uma linguagem para transformar documentos XML em documentos XHTML ou para conveter esses documentos em outros documentos XML.
Como funciona?
No processo de transformação, XSLT usa XPath para definir partes do documento de origem que deve corresponder a um ou mais modelos predefinidos. Quando uma correspondência é encontrada, XSLT transformará a parte correspondente do documento de origem no documento de resultado.
Vamos a um exemplo:
Vamos ao arquivo XSL
Neste exemplo estamos transformando o arquivo xml em outro arquivo xml, mas nada impede de você transformar o documento xml em um arquivo html por exemplo.
No próximo post falarei sobre o XPath.
Grande abraço!
segunda-feira, 25 de abril de 2011
Os padrões ligados ao XML
Entaum,
Assim que comecei a ter contato com SOA, encontrei um amigo de longa data ministrando uma palestra sobre o assunto. Dali fomos tomar um chopp e ele, como grande entusiasta de tecnologia, começou a explanar um caminho a seguir para se trabalhar com SOA.
A princípio, o que eu guardei da conversa dele foi que tudo utiliza XML. Sendo assim, ficou claro que quanto maior for o conhecimento de tecnologias correlatas ao XML, maior seria a facilidade de se trabalhar com SOA.
Isto posto comecei a estudar a sopa de letrinhas que me levaram a relembrar os velhos tempos de WEB, ou seja, conhecer HTML, CSS, JavaScript e alguma linguagem de script. Com o advento do .NET, foram grandes os esforços para ofuscar essas tecnologias que ainda existem e cujo conhecimento é de suma importância para o desenvolvedor WEB.
Com o XML não é diferente, existe uma série de padrões envolvidos no trabalho com o XML, cada qual com a sua função e utilidade.
Neste Post, farei um breve resumo sobre esses padrões que serão detalhados em outros posts. Vamos em frente
No post sobre XML verificamos que esta se trata de uma linguagem de marcação que foi criada para carregar e/ou transportar dados. Simples assim.
Mas digamos que você precise mostrar esses dados de maneira amigável. Como fazer isso? Você pode usar CSS, XSLT ou ainda XSL-FO para formatar esses dados e apresenta-los de forma elegante através de um navegador WEB.
Imagine agora a seguinte situação: você não quer mostrar todo o XML. Quer mostrar apenas uma parte das informações contidas neste. Como você faria isso? O padrão Xpath é a solução.
Xpath é utlizado dentro do XSLT para acessar os dados contidos em um arquivo XML. O Xpath possibilita atravessar um documento XML .
Para filtramos as informações contidas no XML é utilizado o XQuery. O XQuery foi projetado para qualquer efetuar consultas sobre um arquivo XML.
Agora vamos supor que você necessite criar links e âncoras num documento XML. Os padrões XLink e Xpoint foram respectivamente criados com esse propósito.
Como fazer com que um programador confeccione um arquivo xml que contenha as informações necessárias para você(tipos de dados, ordem dos elementos, etc)? O padrão XML Schema foi desenvolvido com essa finalidade.
Bom, este POST teve apenas o propósito de dar um gostinho dos padrões envolvidos no trabalho com XML. Obviamente, é importante detalhar esses padrões. Portanto, detalharei os padrões aqui mencionados em outros Posts.
Fico aqui.
Abs
Hugo
Assim que comecei a ter contato com SOA, encontrei um amigo de longa data ministrando uma palestra sobre o assunto. Dali fomos tomar um chopp e ele, como grande entusiasta de tecnologia, começou a explanar um caminho a seguir para se trabalhar com SOA.
A princípio, o que eu guardei da conversa dele foi que tudo utiliza XML. Sendo assim, ficou claro que quanto maior for o conhecimento de tecnologias correlatas ao XML, maior seria a facilidade de se trabalhar com SOA.
Isto posto comecei a estudar a sopa de letrinhas que me levaram a relembrar os velhos tempos de WEB, ou seja, conhecer HTML, CSS, JavaScript e alguma linguagem de script. Com o advento do .NET, foram grandes os esforços para ofuscar essas tecnologias que ainda existem e cujo conhecimento é de suma importância para o desenvolvedor WEB.
Com o XML não é diferente, existe uma série de padrões envolvidos no trabalho com o XML, cada qual com a sua função e utilidade.
Neste Post, farei um breve resumo sobre esses padrões que serão detalhados em outros posts. Vamos em frente
No post sobre XML verificamos que esta se trata de uma linguagem de marcação que foi criada para carregar e/ou transportar dados. Simples assim.
Mas digamos que você precise mostrar esses dados de maneira amigável. Como fazer isso? Você pode usar CSS, XSLT ou ainda XSL-FO para formatar esses dados e apresenta-los de forma elegante através de um navegador WEB.
Imagine agora a seguinte situação: você não quer mostrar todo o XML. Quer mostrar apenas uma parte das informações contidas neste. Como você faria isso? O padrão Xpath é a solução.
Xpath é utlizado dentro do XSLT para acessar os dados contidos em um arquivo XML. O Xpath possibilita atravessar um documento XML .
Para filtramos as informações contidas no XML é utilizado o XQuery. O XQuery foi projetado para qualquer efetuar consultas sobre um arquivo XML.
Agora vamos supor que você necessite criar links e âncoras num documento XML. Os padrões XLink e Xpoint foram respectivamente criados com esse propósito.
Como fazer com que um programador confeccione um arquivo xml que contenha as informações necessárias para você(tipos de dados, ordem dos elementos, etc)? O padrão XML Schema foi desenvolvido com essa finalidade.
Bom, este POST teve apenas o propósito de dar um gostinho dos padrões envolvidos no trabalho com XML. Obviamente, é importante detalhar esses padrões. Portanto, detalharei os padrões aqui mencionados em outros Posts.
Fico aqui.
Abs
Hugo
segunda-feira, 28 de março de 2011
Uma abordagem prática sobre SOA
Introdução
Poderíamos comparar a relação entre as áreas fins e a área de TI com uma batalha épica. De um lado, necessidades incompreendidas, especificações nebulosas, expectativas não-realistas, estimativas infundadas, quebras de comunicação, complexidades do domínio, conflitos de objetivos e mudanças à espreita,e acima de tudo isso necessidade de agilidade na entrega dos ativos desenvolvidos. Do outro, equipes de desenvolvimento resistem, apoiadas em ferramentas (mesmo que artesanais), metodologias (mesmo que burocráticas ou genéricas demais) e em habilidades (mesmo que individuais) de seus membros. E o resultado desse confronto, por enquanto, não é nada encorajador.
Analisando a arquitetura tradicional de sistemas da maioria das empresas, verifica-se um mundo de aplicações desenvolvidas em plataformas heterogêneas onde a integração dessas aplicações é feita através de troca de arquivos ,sendo as conexões realizadas ponto a ponto, com grande nível de replicação de informações.
Neste cenário há muita replicação de dados. Verifica-se que as equipes de desenvolvimento gastam boa parte de seu tempo em manutenção e pequenas evoluções dos sistemas legados e é óbvio que boa parte do Budget de TI é gasto nessas tarefas.
Isso exposto, poderíamos definir SOA como sendo mais uma tentativa de resolver os problemas aparentes entre áreas de negócio e a área de TI tendo como motivação para a sua adoção as questões de agilidade e produtividade.
A definição de SOA
Com o bombardeio de informações promovido pelas grandes empresas de TI, o conceito do que é SOA fica muito vago na cabeça das pessoas. Cabe primeiramente então definir o que não é SOA.
SOA não é uma tecnologia específica . Se analisarmos as empresas que adotaram SOA, poderemos verificar que diversas tecnologias estão envolvidas em suas atividades.
SOA não é WebService. Na realidade WebService é uma maneira de se implementar SOA, ou seja, é uma maneira de se desenvolver serviços que podem ser utilizados em diversas aplicações ou sistemas.
SOA não é um produto ou uma plataforma. Não se vende SOA. O que se negocia na realidade são soluções que adotam uma abordagem SOA. Geralmente as equipes de desenvolvimento utilizam uma plataforma de desenvolvimento (J2EE,.NET, DELPHI,etc.), mas nem sempre utilizam uma abordagem orientada a serviços.
Por fim SOA não é uma revolução e sim uma evolução. Como tudo que surgiu na área de desenvolvimento de sistemas, SOA é uma evolução. Com o surgimento da computação distribuída, foram lançadas várias soluções no sentido de promover a integração de sistemas (CORBA, EJB, DCOM). SOA é apenas mais uma opção.
SOA na realidade é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
Dimensões e disciplinas envolvidos em um projeto SOA (Metodologia/Processos/Governança)
Quando uma empresa resolve adotar SOA, surgem uma série de dúvidas relacionadas ao assunto. Como exemplo, podemos citar o caso de uma empresa que utiliza uma metodologia de desenvolvimento de software criada a partir de RUP, onde constam os papéis dos profissionais, seus departamentos e quais artefatos que serão confeccionados.
No caso de uma metodologia onde os analistas de negócio, após a especificação de requisitos, confeccionam casos de uso, como esses casos de uso vão se relacionar aos serviços?
Em que momento os serviços serão identificados,modelados, desenvolvidos ou reaproveitados?
Como esses serviços serão catalogados?
Como será distribuído o custo do desenvolvimento desses serviços (será o parceiro ou a Cassi que vai custear a implementação ou desenvolvimento de serviços)?
Quem ou qual área ficará responsável pela implementação e administração dos serviços? Devemos criar novos papeis e novos artefatos dentro da metodologia?
Há necessidade de treinamento para nivelar o conhecimento sobre o assunto?
No caso de desenvolvimento de serviços, há uma padrão de desenvolvimento, qual é? Quais boas práticas de modelagem utilizar(qual nível de granularidade dos serviços)?
Que plataforma de desenvolvimento será adotada? Que ferramentas serão utilizadas para apoiar as atividades envolvidas no processo?
Que abordagem utilizar no processo de adoção do SOA (top down, botton-up, meet-in the middle)?
Processo de desenvolvimento terá que passar por adaptações ou readequações?
Responder a essas e outras questões é um desafio, pois envolve organização e pessoas(papeis e responsabilidades),Tecnologia e ferramentas(arquitetura), processos e política.
Outro desafio constante e a expectativa dos usuários. Um problema recorrente é o imediatismo. As áreas fim querem ver o barramento funcionando, os serviços desenvolvidos. Segundo o Gatner, uma empresa que adota SOA só consegue ver o resultado do trabalho no prazo de 2 à 5 anos.
Respondidas essas perguntas e normatizados a forma de como vai se trabalhar, espera-se obter uma série de benefícios com SOA,São elas:
• Agilidade;
• Redução de custos;
• Facilidade de manutenção;
• Melhoria na qualidade;
• Otimização de processos;
• Transformação de negócios e oportunidades de receita.
Dinâmica de funcionamento
1. Uma aplicação requisita o consumo de um serviço ao barramento de serviços;
2. O barramento recebe a requisição, verifica o endereço físico do serviço e envia a requisição para o servidor onde o serviço está hospedado;
3. Esse servidor recebe a requisição e a passa para o serviço requisitado;
4. O serviço trata a requisição e fornece a resposta ao barramento de serviços;
5. O barramento de serviços encaminha a resposta ao consumidor do serviço.
Conforme podemos observar, o barramento funciona como uma espécie de mediador. É o barramento de serviços que se provê o monitoramento, a segurança, a orquestração ou a coreografia dos serviços, transformação destes, monitoramento e logging entre outras funcionalidades.
Fases de adoção
Toda empresa que resolve adotar SOA escolhe um estudo de caso para servir piloto para o projeto. Além disso, verifica-se a presença de 4 fases. São elas:
INICIAÇÃO
• Onde se dá o entendimento dos conceitos envolvidos;
• Onde se faz a análise de Gaps;
• Onde se faz a venda interna do Bussines Case;
PLANEJAMENTO E DESIGN
• Onde se estabelece os processos de governança;
• Onde se define a arquitetura tecnológica que será utilizada;
• Onde se estabelece os padrões a serem utilizados e se confecciona os guidelines dos processos envolvidos;
• Onde se define a infra estrutura que será envolvida;
• Onde se faz a seleção do projeto piloto;
IMPLEMENTACAO
• Onde se realiza a identificação dos serviços
• Onde se implementa a infra estrutura necessária
• Onde se realiza os serviços
MONITORAMENTO
• Onde se promove a coleta de indicadores;
• Onde se faz a análise crítica desses indicadores;
• Onde se realiza a propostas de melhoria dos processos;
Poderíamos comparar a relação entre as áreas fins e a área de TI com uma batalha épica. De um lado, necessidades incompreendidas, especificações nebulosas, expectativas não-realistas, estimativas infundadas, quebras de comunicação, complexidades do domínio, conflitos de objetivos e mudanças à espreita,e acima de tudo isso necessidade de agilidade na entrega dos ativos desenvolvidos. Do outro, equipes de desenvolvimento resistem, apoiadas em ferramentas (mesmo que artesanais), metodologias (mesmo que burocráticas ou genéricas demais) e em habilidades (mesmo que individuais) de seus membros. E o resultado desse confronto, por enquanto, não é nada encorajador.
Analisando a arquitetura tradicional de sistemas da maioria das empresas, verifica-se um mundo de aplicações desenvolvidas em plataformas heterogêneas onde a integração dessas aplicações é feita através de troca de arquivos ,sendo as conexões realizadas ponto a ponto, com grande nível de replicação de informações.
Neste cenário há muita replicação de dados. Verifica-se que as equipes de desenvolvimento gastam boa parte de seu tempo em manutenção e pequenas evoluções dos sistemas legados e é óbvio que boa parte do Budget de TI é gasto nessas tarefas.
Isso exposto, poderíamos definir SOA como sendo mais uma tentativa de resolver os problemas aparentes entre áreas de negócio e a área de TI tendo como motivação para a sua adoção as questões de agilidade e produtividade.
A definição de SOA
Com o bombardeio de informações promovido pelas grandes empresas de TI, o conceito do que é SOA fica muito vago na cabeça das pessoas. Cabe primeiramente então definir o que não é SOA.
SOA não é uma tecnologia específica . Se analisarmos as empresas que adotaram SOA, poderemos verificar que diversas tecnologias estão envolvidas em suas atividades.
SOA não é WebService. Na realidade WebService é uma maneira de se implementar SOA, ou seja, é uma maneira de se desenvolver serviços que podem ser utilizados em diversas aplicações ou sistemas.
SOA não é um produto ou uma plataforma. Não se vende SOA. O que se negocia na realidade são soluções que adotam uma abordagem SOA. Geralmente as equipes de desenvolvimento utilizam uma plataforma de desenvolvimento (J2EE,.NET, DELPHI,etc.), mas nem sempre utilizam uma abordagem orientada a serviços.
Por fim SOA não é uma revolução e sim uma evolução. Como tudo que surgiu na área de desenvolvimento de sistemas, SOA é uma evolução. Com o surgimento da computação distribuída, foram lançadas várias soluções no sentido de promover a integração de sistemas (CORBA, EJB, DCOM). SOA é apenas mais uma opção.
SOA na realidade é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
Dimensões e disciplinas envolvidos em um projeto SOA (Metodologia/Processos/Governança)
Quando uma empresa resolve adotar SOA, surgem uma série de dúvidas relacionadas ao assunto. Como exemplo, podemos citar o caso de uma empresa que utiliza uma metodologia de desenvolvimento de software criada a partir de RUP, onde constam os papéis dos profissionais, seus departamentos e quais artefatos que serão confeccionados.
No caso de uma metodologia onde os analistas de negócio, após a especificação de requisitos, confeccionam casos de uso, como esses casos de uso vão se relacionar aos serviços?
Em que momento os serviços serão identificados,modelados, desenvolvidos ou reaproveitados?
Como esses serviços serão catalogados?
Como será distribuído o custo do desenvolvimento desses serviços (será o parceiro ou a Cassi que vai custear a implementação ou desenvolvimento de serviços)?
Quem ou qual área ficará responsável pela implementação e administração dos serviços? Devemos criar novos papeis e novos artefatos dentro da metodologia?
Há necessidade de treinamento para nivelar o conhecimento sobre o assunto?
No caso de desenvolvimento de serviços, há uma padrão de desenvolvimento, qual é? Quais boas práticas de modelagem utilizar(qual nível de granularidade dos serviços)?
Que plataforma de desenvolvimento será adotada? Que ferramentas serão utilizadas para apoiar as atividades envolvidas no processo?
Que abordagem utilizar no processo de adoção do SOA (top down, botton-up, meet-in the middle)?
Processo de desenvolvimento terá que passar por adaptações ou readequações?
Responder a essas e outras questões é um desafio, pois envolve organização e pessoas(papeis e responsabilidades),Tecnologia e ferramentas(arquitetura), processos e política.
Outro desafio constante e a expectativa dos usuários. Um problema recorrente é o imediatismo. As áreas fim querem ver o barramento funcionando, os serviços desenvolvidos. Segundo o Gatner, uma empresa que adota SOA só consegue ver o resultado do trabalho no prazo de 2 à 5 anos.
Respondidas essas perguntas e normatizados a forma de como vai se trabalhar, espera-se obter uma série de benefícios com SOA,São elas:
• Agilidade;
• Redução de custos;
• Facilidade de manutenção;
• Melhoria na qualidade;
• Otimização de processos;
• Transformação de negócios e oportunidades de receita.
Dinâmica de funcionamento
1. Uma aplicação requisita o consumo de um serviço ao barramento de serviços;
2. O barramento recebe a requisição, verifica o endereço físico do serviço e envia a requisição para o servidor onde o serviço está hospedado;
3. Esse servidor recebe a requisição e a passa para o serviço requisitado;
4. O serviço trata a requisição e fornece a resposta ao barramento de serviços;
5. O barramento de serviços encaminha a resposta ao consumidor do serviço.
Conforme podemos observar, o barramento funciona como uma espécie de mediador. É o barramento de serviços que se provê o monitoramento, a segurança, a orquestração ou a coreografia dos serviços, transformação destes, monitoramento e logging entre outras funcionalidades.
Fases de adoção
Toda empresa que resolve adotar SOA escolhe um estudo de caso para servir piloto para o projeto. Além disso, verifica-se a presença de 4 fases. São elas:
INICIAÇÃO
• Onde se dá o entendimento dos conceitos envolvidos;
• Onde se faz a análise de Gaps;
• Onde se faz a venda interna do Bussines Case;
PLANEJAMENTO E DESIGN
• Onde se estabelece os processos de governança;
• Onde se define a arquitetura tecnológica que será utilizada;
• Onde se estabelece os padrões a serem utilizados e se confecciona os guidelines dos processos envolvidos;
• Onde se define a infra estrutura que será envolvida;
• Onde se faz a seleção do projeto piloto;
IMPLEMENTACAO
• Onde se realiza a identificação dos serviços
• Onde se implementa a infra estrutura necessária
• Onde se realiza os serviços
MONITORAMENTO
• Onde se promove a coleta de indicadores;
• Onde se faz a análise crítica desses indicadores;
• Onde se realiza a propostas de melhoria dos processos;
Assinar:
Postagens (Atom)