Serviços em SOA
Quando falamos de SOA é inevitável falar de Serviços. Eles são a base de SOA, na indústria de software existe grande confusão e discórdia sobre esse assunto. Neste post vou falar qual é a minha perspectiva sobre o assunto, vou comentar o que eu considero um serviço e o que eu não considero um serviço.
Também vou falar sobre os tipos de serviços e como podemos implementar cada um deles, neste ponto existe bastante confusão e o pior existe uma forte junção disto ferramental e soluções prioritárias, comentarei isso mais para frente.
O Que é um Serviço?
Tentando Desenvolver um Serviço?
Separando Infra do Negócio
Ainda pensando que vamos implementar os serviços em java, como poderíamos fazer essa separação. A resposta é simples, interfaces. Você deve usar interfaces em Java como contratos, que por sinal podem ser usadas em Webservices. Mas o mais importante e o que eu nunca vi ninguém no mercado fazer: Design de jars.
Você tem que modelar os módulos da sua aplicação em componentes, separando os módulos por responsabilidades o apache maven 2 ajuda muito nisso, mas tudo pode ser feito com diagramas da UML o problema é que ninguém faz esse tipo de design, logo as coisas começam a ficar acopladas, misturadas, bagunçadas e ai serviços acabam por se misturar por código de arquitetura e infra e ai a bagunça está feita.
Onde Ficam os Serviços?
Essa é uma questão hilariante, muitos gerentes falam de SOA hoje em dia, porem poucos falam a onde os serviços vão ficar, acho que o pessoal pensa que os serviços vão ficar no limbo e que essa questão não importa tanto, a questão aqui é simples.
Serviços não ficam no limbo, eles vão estar dentro de uma aplicação, dentro de um container JEE, dentro de um contexto do Spring publicado em uma aplicação JSE, etc. Isso é importante por que você tem que saber que serviços tem, tem que se preocupar com transação e principalmente com segurança.
Essa questão é deixada de lado por que existem muitos arquitetos que ao falar de SOA vem WS na cabeça deles como única forma de implementação e ai eles pensam a eu todo tudo no UDDI e deu já eras isso. Esse é um erro comum e que vai dar dor de cabeça quando se percebe-se que nem tudo pode ser feito com Webservices por que não compensa ou por que não se paga o custo ou por que o sistema é muito velho e não tem esse recurso.
E a Transação...
Sou obrigado a falar de transação com Serviços, vamos por partes transação local no mesmo sistema pode ser utilizada sem problemas por que a principio não será um gargalo mas como disse antes depende muito do sistema.
Agora o problema é que ainda vejo arquitetos falando de transação distribuída com SOA e isso é um grande problema. O Comite de duas fases é um inimigo da performance, sistemas distribuídos tem problemas para escalar com transações distribuídas e tem mais nem sempre você pode ter isso por que nem todos os recursos são transacionados, o pessoal esquece disso :)
Transação distribuída em ambientes heterogêneos envolvendo várias linguagens e plataformas, hahahahahaha que piada. :)
Em SOA a abordagem padrão para isso é a Compensação eu já utilizei essa abordagem com BPEL sem problemas, então basicamente pode se fazer dois tipos de compensação.
No primeiro tipo o sistema chamador tem que dar um jeito de corrigir os dados inconsistentes no outro sistema, isso pode ser feito pela invocação de rotinas, componentes genéricos que apagam dados no sistema com inconsistências.
No segundo tipo o usuário corrige essas inconsistências, teve um sistema que fiz onde de uma lado existia um sistema Java com Spring e Hibernante que falava através de uma fila JMS e do outro lado um sistema clipper que falava através de arquivos texto, com BPEL foi gerado uma Human Task para apresentar os problemas ao usuário para ele corrigir.
Por default não sou contra a transação distribuída, mas o cenário para sua utilização tem que ser olhado com muita cautela. Os serviços podem utilizar transação local como falei antes, pode ser usando até um TransactionManager do Spring.
Abraços e até a próxima.
Também vou falar sobre os tipos de serviços e como podemos implementar cada um deles, neste ponto existe bastante confusão e o pior existe uma forte junção disto ferramental e soluções prioritárias, comentarei isso mais para frente.
O Que é um Serviço?
Tentando Desenvolver um Serviço?Essa é um pergunta simples mas nem sempre você vai ouvir uma resposta simples. Existe muita discórdia sobre o que é ou o que não é um Serviço. Para mim um serviço é:
Outra questão relativa a serviços é a quando ao acesso, no meu ponto de vista o serviço tem que ser acessível por outro sistema, não interessa se isso será feito por um webservice, EJB, RMI, Sockets, HTTP ou até mesmo por um arquivo texto. Por que a partir do que o serviço expõe vamos ter um contrato, esse contrato pode ser estabelecido até por um método Java, o importante é que isso possa ser acessível por outros sistemas, se você não consegue reutilizar o que escreveu, não tem serviços.
Novamente quero deixar bem claro o fato de que isso vai de situação a situação, em SOA você terá sistemas comuns que podem não ter serviço e isso não é necessariamente errado, você tem que lidar com componentes e rotinas de nível mais baixo, um serviço é um abstração de alto nível e nem sempre é um para um.
Serviços um para um ?
Imagine que você vai desenvolver os serviços de um sistema em Java, não pense que necessariamente uma classe java vai ser um serviço. Em alguns casos isso pode ser verdade na maioria não será, por que em SOA é quase impossível lidarmos com a homogeneidade, os sistemas são heterogêneos, por que envolvem diversas linguagens, fornecedores, plataformas, sos, etc.
Esse assunto acaba levando a outro assunto que é os tipos de serviços, existem alguns tipos de serviços, nesse ponto vou falar da relação disso com BPEL. Podemos classificar os serviços de acordo com a sua empresa e os seus sistemas, mas falando de um modo geral podemos falar de 3 tipos de serviços são eles:
Serviços compostos usam outros serviços para atender/conseguir fazer o seu propósito, é comum ter um mix destes dois tipos de serviços.
Serviços de Processos aqui o bicho pega. Na verdade serviços de processos podem ser implementados em Java ou em qualquer linguagem de programação. Mas existe uma vertente em SOA que insiste que isso deve ser feito com BPEL, você pode fazer isso, des de que saiba o custo e o que vai acontecer se você utilizar BPEL, quando você para pode ter gastado muito esforço e recursos em BPEL para um ganho muito pequeno e pior ainda pode ter sérios problemas de performance.
Serviços de processos podem usar serviços básicos e serviços compostos, normalmente o serviços de processo estão em nível mais alto do que os outros dois tipos e bem como disse podem ou não ser implementados com BPEL.
E os Componentes?
Existe outra vertente forte que é a favor do SCA e outros são contra, alguns confundem JBI com SCA mas uma coisa não tem nada a ver com a outra. SCA é um modelo de componentes que serve para definir a relação de serviços e componentes e para muitos isso feri a definição de SOA.
Você pode usar SCA, mas a portabilidade também não é garantida, na prática tudo o que você faria com SCA pode fazer com Spring, muito mais fácil e simples. Mas você tem que ter componentes e ter rotinas reaproveitáveis os famosos úteis. Os serviços podem utilizar esses componentes mas cuidado para não chamar isso de serviço.
Lembrando que o serviço tem que ser visível ao negócio, você tem que tomar cuidado para não confundir um componente com um serviço. De um modo geral pense em negócio quando falamos de serviços e pense em infra e arquitetura quando falamos de componentes.
Chamar componentes de infra de serviços pode gerar muita confusão com o pessoal do negócio e complicar a sua adoção de SOA, então procure diferenciar o que é infra-estrutura do que é negócio.
- Alguma funcionalidade de negócio que foi implementada e pode ser acessada por vários sistemas.
Outra questão relativa a serviços é a quando ao acesso, no meu ponto de vista o serviço tem que ser acessível por outro sistema, não interessa se isso será feito por um webservice, EJB, RMI, Sockets, HTTP ou até mesmo por um arquivo texto. Por que a partir do que o serviço expõe vamos ter um contrato, esse contrato pode ser estabelecido até por um método Java, o importante é que isso possa ser acessível por outros sistemas, se você não consegue reutilizar o que escreveu, não tem serviços.
Novamente quero deixar bem claro o fato de que isso vai de situação a situação, em SOA você terá sistemas comuns que podem não ter serviço e isso não é necessariamente errado, você tem que lidar com componentes e rotinas de nível mais baixo, um serviço é um abstração de alto nível e nem sempre é um para um.
Serviços um para um ?
Imagine que você vai desenvolver os serviços de um sistema em Java, não pense que necessariamente uma classe java vai ser um serviço. Em alguns casos isso pode ser verdade na maioria não será, por que em SOA é quase impossível lidarmos com a homogeneidade, os sistemas são heterogêneos, por que envolvem diversas linguagens, fornecedores, plataformas, sos, etc.
Esse assunto acaba levando a outro assunto que é os tipos de serviços, existem alguns tipos de serviços, nesse ponto vou falar da relação disso com BPEL. Podemos classificar os serviços de acordo com a sua empresa e os seus sistemas, mas falando de um modo geral podemos falar de 3 tipos de serviços são eles:
- Serviços Básicos
- Serviços Compostos
- Serviços de Processos
Serviços compostos usam outros serviços para atender/conseguir fazer o seu propósito, é comum ter um mix destes dois tipos de serviços.
Serviços de Processos aqui o bicho pega. Na verdade serviços de processos podem ser implementados em Java ou em qualquer linguagem de programação. Mas existe uma vertente em SOA que insiste que isso deve ser feito com BPEL, você pode fazer isso, des de que saiba o custo e o que vai acontecer se você utilizar BPEL, quando você para pode ter gastado muito esforço e recursos em BPEL para um ganho muito pequeno e pior ainda pode ter sérios problemas de performance.
Serviços de processos podem usar serviços básicos e serviços compostos, normalmente o serviços de processo estão em nível mais alto do que os outros dois tipos e bem como disse podem ou não ser implementados com BPEL.
E os Componentes?
Existe outra vertente forte que é a favor do SCA e outros são contra, alguns confundem JBI com SCA mas uma coisa não tem nada a ver com a outra. SCA é um modelo de componentes que serve para definir a relação de serviços e componentes e para muitos isso feri a definição de SOA.
Você pode usar SCA, mas a portabilidade também não é garantida, na prática tudo o que você faria com SCA pode fazer com Spring, muito mais fácil e simples. Mas você tem que ter componentes e ter rotinas reaproveitáveis os famosos úteis. Os serviços podem utilizar esses componentes mas cuidado para não chamar isso de serviço.
Lembrando que o serviço tem que ser visível ao negócio, você tem que tomar cuidado para não confundir um componente com um serviço. De um modo geral pense em negócio quando falamos de serviços e pense em infra e arquitetura quando falamos de componentes.
Chamar componentes de infra de serviços pode gerar muita confusão com o pessoal do negócio e complicar a sua adoção de SOA, então procure diferenciar o que é infra-estrutura do que é negócio.
Separando Infra do Negócio
Ainda pensando que vamos implementar os serviços em java, como poderíamos fazer essa separação. A resposta é simples, interfaces. Você deve usar interfaces em Java como contratos, que por sinal podem ser usadas em Webservices. Mas o mais importante e o que eu nunca vi ninguém no mercado fazer: Design de jars.
Você tem que modelar os módulos da sua aplicação em componentes, separando os módulos por responsabilidades o apache maven 2 ajuda muito nisso, mas tudo pode ser feito com diagramas da UML o problema é que ninguém faz esse tipo de design, logo as coisas começam a ficar acopladas, misturadas, bagunçadas e ai serviços acabam por se misturar por código de arquitetura e infra e ai a bagunça está feita.
Onde Ficam os Serviços?
Essa é uma questão hilariante, muitos gerentes falam de SOA hoje em dia, porem poucos falam a onde os serviços vão ficar, acho que o pessoal pensa que os serviços vão ficar no limbo e que essa questão não importa tanto, a questão aqui é simples.
Serviços não ficam no limbo, eles vão estar dentro de uma aplicação, dentro de um container JEE, dentro de um contexto do Spring publicado em uma aplicação JSE, etc. Isso é importante por que você tem que saber que serviços tem, tem que se preocupar com transação e principalmente com segurança.
Essa questão é deixada de lado por que existem muitos arquitetos que ao falar de SOA vem WS na cabeça deles como única forma de implementação e ai eles pensam a eu todo tudo no UDDI e deu já eras isso. Esse é um erro comum e que vai dar dor de cabeça quando se percebe-se que nem tudo pode ser feito com Webservices por que não compensa ou por que não se paga o custo ou por que o sistema é muito velho e não tem esse recurso.
E a Transação...
Sou obrigado a falar de transação com Serviços, vamos por partes transação local no mesmo sistema pode ser utilizada sem problemas por que a principio não será um gargalo mas como disse antes depende muito do sistema.
Agora o problema é que ainda vejo arquitetos falando de transação distribuída com SOA e isso é um grande problema. O Comite de duas fases é um inimigo da performance, sistemas distribuídos tem problemas para escalar com transações distribuídas e tem mais nem sempre você pode ter isso por que nem todos os recursos são transacionados, o pessoal esquece disso :)
Transação distribuída em ambientes heterogêneos envolvendo várias linguagens e plataformas, hahahahahaha que piada. :)
Em SOA a abordagem padrão para isso é a Compensação eu já utilizei essa abordagem com BPEL sem problemas, então basicamente pode se fazer dois tipos de compensação.
No primeiro tipo o sistema chamador tem que dar um jeito de corrigir os dados inconsistentes no outro sistema, isso pode ser feito pela invocação de rotinas, componentes genéricos que apagam dados no sistema com inconsistências.
No segundo tipo o usuário corrige essas inconsistências, teve um sistema que fiz onde de uma lado existia um sistema Java com Spring e Hibernante que falava através de uma fila JMS e do outro lado um sistema clipper que falava através de arquivos texto, com BPEL foi gerado uma Human Task para apresentar os problemas ao usuário para ele corrigir.
Por default não sou contra a transação distribuída, mas o cenário para sua utilização tem que ser olhado com muita cautela. Os serviços podem utilizar transação local como falei antes, pode ser usando até um TransactionManager do Spring.
Abraços e até a próxima.
