Da Orientação para Objetos até o SOA chegando ao BPM

Transcrição

1 Da Orientação para Objetos até o SOA chegando ao BPM Glauco Reis (gsrt@terra.com.br) é Consultor em Java e metodologias OO, e especializado em plataforma IBM. Têm o título de SCJP 1.1 e 1.4, SCJWCD 1.4, e IBM CSE e IBM Websphere Application Server Certified. Escreve há mais de 8 anos sobre o tema Java e trabalha na área de informática há mais de 20 anos, participando também como palestrante COMDEX e FENASOFT. É especialista em WebServices e está envolvido com a tecnologia BPMS, como arquiteto principal na criação de uma solução BPMS nacional. A orientação para objetos existe há um longo tempo. Smaltalk já existia como linguagem operacional ao final da década de 60. Entretanto, mesmo após estes mais de 40 anos, continuamos tendo dificuldades na sua adoção. Os graus de complexidade ainda são altos, e há um grande GAP entre o resultado esperado pelo usuário e o processo de desenvolvimento em si. A industria vêm promovendo alternativas, que vão da componentização até métodos ágeis de desenvolvimento, na tentativa de suplantar as dificuldades. Algumas tiveram sucesso de alguma forma, outras são mero hype promovido pela indústria, e acabam desaparecendo no mercado. A nova sopa de letrinhas mais comentada no mercado é o SOA (Service Oriented Architecture). Ela se propõe a resolver a panacéia do desenvolvimento, e parece ser o foco os CIOs no momento. Vamos falar um pouco sobre a tecnologia, mas iniciando desde os primórdios da OO até os dias atuais. Existem duas constantes presentes na lista de preocupações de qualquer metodologia, linguagem ou técnica de programação que já existiu, e provavelmente nas que irão aparecer nos próximos anos. As funções (rotinas, métodos, procedimentos ou funções) e os dados (atributos, campos, colunas). Ao longo do tempo, duas grandes disciplinas apareceram para resolver os problemas de desenvolvimento : a programação estruturada e a engenharia da informação. O foco central de atuação de cada uma delas eram respectivamente as funções e os dados. Na programação estruturada a idéia é a divisão do sistema em problemas cada vez menores, até que chegamos a uma descrição tão simples que o problema pode ser resolvido facilmente através de uma rotina. Um módulo é separado em submódulos, que por sua vez é separado em unidades funcionais e outras subdivisões menores ainda, até que chegamos à uma rotina (procedure, função, método ou qualquer outro nome que deseje atribuir). É atribuído a Dijkstra esta idéia de divisão e conquista, mas parece que o conceito é ainda mais antigo, já que Sun Tsu, em a arte da guerra, já propunha que a melhor forma de destruir um exercito inimigo era forçar a divisão em grupos menores, desviando sua atenção, e derrotar estes grupos menores, um a um. Esta idéia é utilizada até hoje, mas dois fatores pesam contra esta abordagem: em primeiro lugar, as rotinas são muito voláteis, e em segundo é impossível dissociar dados de funções. A primeira afirmação significa dizer que dentro de um sistema qualquer, porcentualmente as rotinas alteram-se com uma frequência muito maior do que os dados. Pare para pensar nos sistemas que você já desenvolveu até hoje. Provavelmente muitas alterações ocorreram na forma como os dados eram manipulados (funções) e poucas alterações nos dados em si, como mudança de tipo e reajuste do número de colunas. Fixar o foco da metodologia em um elemento volátil é mais ou menos como construir um prédio sobre areia movediça. A segunda abordagem, surgida mais ou menos nos anos 80, foi a engenharia da informação. O foco do estudo foram os dados, e técnicas para estruturar e dividir como a informação seria armazenada. Neste caso, Ganne e Yourdon deram grande foco à informação, e como armazená-la de forma eficiente. Novamente, lidar com dados sem se preocupar com a manipulação deles também é utopia. No meio do

2 caminho, surgiu uma técnica que propunha utilizar elementos da programação estruturada com elementos da engenharia da informação, que é a análise essencial. Figura 1. Algumas metodologias de desenvolvimento. O aprendizado adquirido durante os anos nos mostra que uma das idéias importantes que a Orientação a Objetos (OO) nos trouxe é a idéia de que dados não podem ser dissociados das rotinas que os manipulam, não importa a técnica que você utilize para desenvolver. Este conceito é tão importante que é um dos pilares da OO, chamado de encapsulamento. O encapsulamento faz com que os dados e as rotinas que os manipulam fiquem próximos, e isto facilita na criação e manutenção dos códigos. Este conceito também não está preso a nenhuma linguagem orientada para objetos. Com boas práticas de programação você pode restringir o acesso aos dados a partir de um conjunto de rotinas, em virtualmente qualquer linguagem de programação existente. A união de dados e rotinas em grupos de funcionalidade nos traz o conceito de classe. O que chamamos de Objeto é uma instância de uma classe. Um comparativo interessante é o seguinte: o molde que gera um boneco de gesso é uma classe, e cada boneco de gesso criado a partir do molde é um Objeto. Podemos modificar a cor do chapéu e da roupa, para um boneco criado (ou uma instância). Mas não podemos modificar a forma do objeto, pois isto está preso ao molde (classe).

3 Figura 2. Representação comum de Objeto (DONUT) Após esta breve introdução, chegamos ao objeto, que é consenso em todas as práticas de programação atualmente existentes. Ainda há divergências na forma como os objetos se relacionam. Imagine que tracemos uma linha horizontal, indo desde objetos sem relacionamento algum até objetos com relacionamento complexo. Se você tiver um fraco acoplamento entre os objetos, estará em um extremo próximo da linha de algo chamado componentização. Na componentização, a idéia é que poucos relacionamentos existam entre os objetos, facilitando a reutilização. No extremo oposto temos o framework, onde há um agrupamento de objetos relacionados, normalmente com forte acoplamento entre eles. Veja por exemplo o Struts ou Hibernate, que são exemplos de framework. Você não consegue utilizar a classe Action ou ActionForm fora do struts, pois há interdependência entre o que você cria e o próprio framework. Também não dá para utilizar o Struts sem utilizar um servidor de aplicações, que é outro exemplo de framework. Já veja o caso de um componente JavaBean, por exemplo. Você pode utilizar um componente JavaBean em qualquer ferramenta de desenvolvimento. Pode ser o NetBeans, VisualAge ou qualquer outra ferramenta visual. Pode-se igualmente utilizar um JavaBean em um projeto J2EE ou desktop. Uma das razões é que há fraca dependência entre o código criado e outras tecnologias. Infelizmente não há um marco divisor entre os componentes e os frameworks. Você vai gradualmente migrando das particularidades de um até chegar ao outro. É como ir da cor branca para a preta. Existem infinitos tons de cinza entre as duas cores. Por exemplo, a tecnologia EJB é considerada um tipo de componentização, mas que executa sobre um framework. Normalmente um framework consegue gerar resultados satisfatórios somente quando o conhecemos na totalidade. A Componentização é mais fácil de ser utilizada, pois como os componentes são blocos isolados e com uma interface bem definida, é mais fácil criar códigos que interfaceiem com ele, sem conhecer o todo. Por outro lado, geramos resultados mais rápidos a partir do zero utilizando Componentes do que Frameworks. Quando criamos um Servlet ou um EJB, estamos à mercê das regras e APIs disponíveis no servidor de aplicações, para gerenciar o pedaço de código. Raramente em um framework temos a visão do todo, ficando restritos às partes. O ciclo de aprendizado na utilização de um framework é normalmente mais longo, se comparado ao componente. Mas, como disse anteriormente, a linha que delineia os dois é contínua, e frequentemente os frameworks começam a ser construídos a partir de componentes. Figura 3. Comparativo em relação ao acoplamento entre os objetos A OO tradicional fica em um meio termo entre a componentização e o framework, tentando definir relacionamentos que são importantes, nem ficando em um extremo de isolar cada peça, como a componentização, nem se especializando e criando corpo, como o framework. A especialização se faz em função do sistema que está sendo desenvolvido. Esta tarefa de criar apenas os relacionamentos necessários, propostos pela OO, é uma atividade não trivial e demanda um conhecimento profundo sobre a tecnologia. Houve um aprendizado na criação e evolução da arquitetura J2EE, em relação aos frameworks tradicionais, pois apesar de vários componentes relacionados, de alguma forma ele foi componentizado, para facilitar a assimilação da tecnologia. As APIs de servlet, por exemplo, são totalmente independentes das APIs de EJB. Pode-se aprender a utilizar uma delas, e somente depois avançar o conhecimento para outra. Isto ajuda na adoção.

4 A idéia de componentes se popularizou muito alguns anos atrás, com o advento das ferramentas RAD (Rapid Application Development). Este tipo de ferramental gerava (e ainda gera) códigos de forma muito rápida e não exige conhecimento profundo da tecnologia, pois os componentes são normalmente conectados de forma visual. Uma enxurrada de tecnologias surgiram com base neste paradigma, como VBX, ActiveX, OCX, JavaBean, VCL e mais um monte de outras. Perceba que a receptividade de uma tecnologia componentizada é mais fácil por parte do desenvolvedor, pois ele pode tratar o componente como uma caixa preta, ligando-o de forma visual, sem se preocupar como foi criado, ou como o relacionamento está acontecendo. Para você, que entende de orientação para objetos, significa esquecer os tipos de relacionamentos (agregação, composição e associação), direcionalidade e algumas outras preocupações normais. O sucesso do VB e Delphi, por exemplo, são advindos desta abordagem. O problema é que a conexão visual dos componentes deixa a critério do fabricante da ferramenta a forma como eles são conectados. Como o desenvolvedor não se preocupa em como o código final, pois o processo é visual e rápido, o resultado tende a ser de pior qualidade do que se adotarmos uma abordagem de desenvolvimento tradicional. Se você tiver a curiosidade de gerar um diagrama de classes para um projeto criado visualmente a partir de uma ferramenta RAD, verá que o diagrama de classes se aproxima de algo como na figura 4. Figura 4. Código componentizado, criado visualmente a partir de uma ferramenta RAD Costumo dizer o seguinte : se algum dia você ouvir frases do tipo você chegará rápido ao mercado, com qualidade, desconfie. Rapidez e qualidade são palavras que não combinam em informática, ao menos no estágio atual. Por outro lado, a idéia de componentização existe muito viva até hoje, e ainda recebeu um novo escopo. Um conceito muito difundido como qualidade dos servidores web é que se pode dividir o processamento entre várias máquinas (WLM WorkLoad Management). Criar componentes distribuídos foi o caminho natural para a arquitetura J2EE, o que foi feito com os EJBS. Na verdade, a tecnologia CORBA surgiu bem antes dos servidores de aplicação explorarem a idéia de códigos distribuídos, mas foi com a adoção dos EJBs que a idéia se firmou. Com o surgimento dos EJBs a idéia de componentes distribuídos recebeu uma nova roupagem e algum estímulo do mercado. Algo semelhante foi sendo evoluído na plataforma Microsoft, com os componentes DCOM (Distributed Component Object Model). Embora os componentes sejam mais fáceis de utilizar (criar é outra estória),a arquitetura J2EE se popularizou, principalmente por causa da Web e aplicativos Web Based, onde cada um dos grandes fabricantes criou sua implementação de J2EE, como WebLogic (BEA), Websphere (IBM),JBoss (JBoss Inc),e outros. É inegável o sucesso. Aplicativos baseados em Web são dominantes hoje no mercado, e não há nenhum cenário futuro que pretenda mudar isto nos próximos anos. Muito pelo contrário.

5 Neste ponto da história empresas tinham componentes criados em CORBA, alguns em RMI, outros em DCOM, alguns sistemas utilizando diretamente TCP/IP, e outros ainda utilizando outros mecanismos de comunicação distribuídos, não orientados para objetos, como mecanismos de envio de mensagens (MQ e Sonic, entre outros), mecanismos transacionais (CICs, entre outros), e com poucas possibilidades de comunicação entre eles. E aliás, em qualquer empresa que tenha utilizado informática ao longo do tempo deve haver diversidade (a menos que tenha migrado para um ERP). É impossível que a cada revolução tecnológica todo o legado seja jogado fora, e o mais provável é que novos desenvolvimentos tenham sido criados utilizando novas tecnologias. É importante que todo este legado se integre, e ainda por cima execute em um ambiente Web Based, como proposto pelos servidores de aplicação. Algo ainda pior acontece nas empresas, pois os novos sistemas têm uma alta propensão a se integrar com o legado (sistemas não são ilhas). Na tentativa de resolver estes problemas, bem como outros de interoperabilidade, a Microsoft iniciou um movimento que culminou com a criação do SOAP 1.0. Isto mesmo, um dos primeiros players a baterem na idéia de SOAP foi a Microsoft. Inclusive, eu me recordo que a Sun se posicionou contrária à idéia durante um longo tempo, mas com a união da IBM com a Microsoft para evolução da tecnologia, a Sun teve que silenciosamente absorver a tecnologia. Figura 5. Linha cronológica de algumas tecnologias discutidas A idéia do SOAP parece bem interessante, quando olhada de um nível mais alto. Utiliza um protocolo HTTP, simples de ser utilizado, onde trafegam arquivos XML, facilmente criados a partir de qualquer que seja a tecnologia, e portanto favorecendo ambientes heterogêneos. Na prática se mostrou um protocolo frágil, no que se refere à segurança, e muito perdulário em termos de redundância no envio da informação, ou seja, lento e ineficiente. Eu me lembro que na Comdex e Fenasoft de 2003 todos os consultores estavam fazendo apresentações sobre as virtudes e como SOAP iria revolucionar o mundo da informática. A verdade é que, em dezembro de 2002 foi feita uma pesquisa com uma massa de desenvolvedores brasileiros, e se detectou que 21% estavam utilizando SOAP. A mesma pesquisa, com a mesma massa de usuários, feita em abril de 2003 mostrou que o número havia diminuído para 19%. É claro que o que os fabricantes estavam vendendo como um milagre na verdade se mostrou efetivo em um montante menor do que se previa ou se vendia. SOAP, que é o mecanismo de transmissão da informação, se uniu ao WSDL (Web Service Description Language) que descreve como o serviço deve operar e também ao UDDI (Universal Description and Discovery Interface) que permite listar um grupo de serviços, para criar o termo que conhecemos como Web Service (para evidenciar que é um serviço disponível na Web), e mais recentemente recebeu o nome SOA (Service Oriented Architecture) para indicar que o conceito de serviços foi agrupado para se tornar uma arquitetura para criação de programas, e não mais apenas serviços isolados que devem ser publicados em casos específicos. Uma das particularidades interessantes do SOAP, é que ele na verdade não é apropriado para comunicação entre objetos remotos (e veja que SOAP é a sigla para Simple Object Access Protocol). Ele é mais indicado para prover serviços, utilizando-se de passagem de parâmetros e recepção em um formato hierárquico (XML). Uma das razões para isto é que não houve uma grande preocupação em fazer com que o cliente tivesse a sensação de que o que ele estava acessando do seu lado fosse um objeto real. Isto até

6 que é fácil de entender, pois SOAP pode ser acessado inclusive por tecnologias não orientadas para Objeto. Por exemplo, uma tarefa trivial em orientação para objetos, que é acessar um objeto Cliente remoto, e navegar pelos Produtos que ele comprou em uma loja pode ser uma tarefa um tanto quanto complexa para SOAP. Já para CORBA, isto é natural, e como se você estivesse acessando o objeto normal (pois os objetos remotos são apresentados como proxies). Como SOAP permite comunicação entre mundos de Objetos e mundos de não objetos, se resolveu que seria interessante desvincular a idéia de Objeto da tecnologia SOAP. A informação continua sendo fornecida por Objetos, caso a linguagem seja OO, ou não, para abrir o leque de possibilidades, pois SOAP pode ser utilizado em linguagens não OO. Já o acesso se faz através de serviços. Aumentou-se o escopo e se aplicou algum marketing sobre a tecnologia, para tentar vender o mesmo conceito com outro nome, que foi denominado de Web Service e posteriormente SOA (Service Oriented Architecture). Este trabalho de marketing ao longo dos anos mudou o foco de comunicação entre objetos SOAP para disponibilização de serviços SOA. Hoje, se aceita que a idéia de Web Service é prover um serviço, como obter o valor de uma cotação, efetuar uma compra, entrar dados no sistema. Se o que se encontra na outra ponta é um objeto ou não, não é relevante. Francamente, este novo cenário de Web Services fica melhor a algo corporativo, do que o SOAP, que é o protocolo de mais baixo nível e específico para comunicação. Mas SOAP resolve apenas parte dos problemas, já que é o protocolo de comunicação que trafega na rede. Ainda temos dois outros protocolos que não são fundamentais, mas foram agregados como parte do processo de definição do SOA, que são o WSDL e UDDI. Figura 6. Tríade de tecnologias que compõe os Web Services A idéia do WSDL é fornecer um descritivo para o serviço, como endereço do servidor e porta de comunicação, parâmetros a serem passados e por aí vai. Algumas vezes encontramos a definição de WSDL como o currículo do serviço. A idéia seguiu os mesmos princípios do SOAP, com arquivos XML simples para representação da informação. Veja exemplo na listagem 1. Listagem 1: Exemplo de WSDL <?xml version="1.0" encoding="utf-8"?> <message name="somarequest"> parâmetros <part name="valor1" type="xsd:double"/> <part name="valor2" type="xsd:double"/> </message> <message name="somaresponse"> retorno <part name="result" type="xsd:double"/> </message> <porttype name="calculadora"> <operation name="soma" parameterorder="valor1 valor2">

7 <input message="tns:somarequest" name="somarequest"/> <output message="tns:somaresponse" name="somaresponse"/> método sendo chamado </operation> </porttype> </definitions> A idéia do UDDI é prover uma lista de serviços disponíveis, como uma lista telefônica de WSDLs. Em conjunto a idéia é que a tríade de protocolos funcionem da seguinte forma : a) o cliente lista os serviços disponíveis a partir de um servidor (UDDI) b) Escolhido um serviço, pede-se uma descrição do serviço através de seu currículo (WSDL) c) A chamada ao serviço acontece, passando parâmetros e recebendo valores (SOAP) Mas o que é SOA, afinal? Há muita propaganda sobre o termo, mas basicamente a idéia é modularizar a empresa em termos de serviços que podem ser reaproveitados, e até mesmo publicados para outras empresas. As idéias principais do SOA são modularizar e disponibilizar. Da mesma forma que a componentização tornou mais fácil a adoção da OO, a SOA expandiu o conceito para que todos os serviços sejam modularizados ou componentizados. Como o mecanismo padrão de disponibilização é o SOAP, que pode ser implementado por virtualmente qualquer linguagem ou tecnologia, reduzimos as restrições sobre o que pode ser feito em termos de legado. Desta forma, criamos uma camada uniforme sobre as informações advindas de sistemas antigos, bem como dos novos sistemas criados a partir da orientação para objetos. Na figura 7, cada ON pode ser um serviço em CORBA, Cobol, Java,.NET ou qualquer outra tecnologia. Neste mundo de serviços, se uniformizou a forma como eles são disponibilizados. Figura 7. Objetos de negócios disponibilizados como Serviços Agora já temos os serviços do legado e novos serviços componentizados, mas qual será a próxima onda? Um conceito até antigo (aproximandamente 10 anos), mas que vêm ganhando força no mercado é a idéia de gerenciamento da empresa por processos.

8 Se a empresa consegue desenhar e definir os papéis e processos de forma bem definida, chegaremos ao momento em que o processo será gerenciado (o termo correto é orquestrado ) através de ferramentas que utilizam uma técnica chamada BPM (Business Process Modeling). A idéia do BPM é permitir que os processos da empresa sejam modelados por fluxo de informação, ao invés de modelados por sistema. Isto por sí só já é uma quebra de paradigma. Imagine o seguinte : em um desenvolvimento tradicional, são desenvolvidos ou implantados cada um dos módulos da empresa. Por exemplo, se cria o módulo de controle de estoque, financeiro, compras, recursos humanos, etc. E procura-se fazer com que os módulos integrem criando portas de comunicação entre eles. Estas portas de comunicação podem ir desde a troca de arquivos TXT até técnicas mais sofisticadas, como comunicação via TCP/IP ou CORBA. Ou seja, os sistemas são construídos por áreas de atuação. Na idéia da modelagem por processos, os sistemas são construídos ignorando-se a área onde o sistema será executado, mas levando-se em consideração cada fase de sua execução. Neste caso, pensamos no que acontece desde o início até o final da cadeia produtiva. Como exemplo, uma empresa pode solicitar ao fabricante o envio de um pedido. Este pedido, ao chegar na empresa entrará para o estoque, através da recepção de materiais. O número de ítens em estoque será ajustado e disponibilizado para o departamento de vendas. Será solicitado ao departamento financeiro que a fatura do cliente seja paga, e por aí vai. O conceito de sistema e módulo não desaparece, ao menos em um primeiro momento, pois no final cada pequena atividade (pagamento de fatura, por exemplo) será uma das funcionalidades do módulo. Mas pensamos no fluxo de comunicação da empresa como um todo, e não de forma isolada, o que é mais realista. Normalmente dentro de uma empresa um fluxo caminha entre departamentos, transferindo responsabilidades entre os participantes, ao invés de ficar preso a um sistema específico.

9 Figura 8. Modelo de fluxograma de uma modelagem por processo No desenho da figura 8, podemos observar algumas coisas : Ele é muito parecido com um diagrama de atividades da UML, e inclusive pode ser desenhado através de uma ferramenta UML. Em modelagem de processos o nome do artefato é workflow. Cada etapa até a conclusão será desenhada. Cada quadrado da atividade pode e será expandida em diagramas mais detalhados, até que chegamos a um quadrado para cada interação com usuário ou função a ser executada. Mas o que a modelagem de processos têm a ver com o SOA? Os dois se integram de forma magnífica. Nos próximos anos é o que os grandes fornecedores de tecnologia venderão como a próxima onda. Se você quiser estar sintonizado com o futuro, procure entender técnicas de modelagem por processo. Se cada atividade do diagrama acima estiver no grau de detalhamento menor, ou seja, for um passo para a execução do problema, isto significa que cada desenho azul pode ser resolvido por um Web Service. Se você tiver uma ferramenta que permita atachar um Web service a cada desenho azul, na figura 8, estará orquestrando os Web Services da empresa a interagirem para a geração do resultado final, que é todo o processo desenhado. O fato é que existem programas que permitem que esta orquestração seja feita de forma visual, ou seja, o desenho é criado e colocado em execução em um engine Run time, e passa a funcionar imediatamente. Ou seja, sem desenvolvimento. Este tipo de ferramenta recebe o nome de BPMS (Business Process Modeling System). Se você quiser experimentar, veja em JBOSS group o jbpm, que é uma versão open source de um engine de orquestração. Praticamente todos os grandes players estão se mobilizando para ter ou adquirir empresas que atuam no segmento de BPM. Existem empresas que se especializaram neste segmento, fornecendo ferramentais muito avançados para este tipo de atividade.

10 O benefício desta abordagem é que, é mais fácil para a empresa realinhar as atividades no negócio. Se a ligação entre os Web Services é feita através de um desenho, mudanças no desenho permitem alterações nas regras do negócio. Ou seja, pode-se mudar a forma como a empresa opera apenas mudando a ordem em que os Web Services são chamados. Caso não seja necessário criar um novo Web-Service, mudanças acontecem muito rapidamente nos sistemas. Estas ferramentas permitem também a retirada de métricas para cada atividade de um processo. Porque meu processo não é eficiente? Em qual parte do processo posso efetuar melhorias? Estas são perguntas frequentemente feitas pela área gerencial e dificilmente respondidas em abordagens tradicionais, pois como o desenvolvimento foi divido em sistemas, fica difícil saber onde exatamente uma atividade demorou. Como entender todas estas mudanças de paradigma? Eu entendo as técnicas de BPM como um forma de levar a componentização até o nível do sistema, fazendo com que cada serviço vire o que chamávamos de componente, e a orquestração o que colocávamos no diagrama de sequências como a ordem de chamada dos componentes. A diferença é que os artefatos estão mais próximos do usuário final do que do desenvolvedor, tendo mais chances de sucesso. O desenho do processo tende a ser feito junto com o usuário final, diminuindo a distância entre o levantamento e o resultado apresentado. Na verdade, as técnicas de modelagem por processos foram criadas sem o objetivo de gerar código, mas com o propósito de fornecer entendimento sobre como a empresa opera. Hoje, a evolução da modelagem de processos e a criação dos BPMs corre em paralelo com o desenvolvimento orientado para objetos, com um pequeno contato na tecnologia SOA, mas o caminho que parece natural é o encontro entre as tecnologias de forma mais forte, em um futuro próximo. Links e livros