Service-Oriented Architecture, integrando processos executados em primeiro e segundo planos

Service-Oriented Architecture, integrando processos executados em

primeiro e segundo planos

Tadeu Cruz (SAGE-COPPE-UFRJ) tadeucrz@trcr.com.br

Resumo: Todos os dias novas Tecnologias da Informação surgem prometendo o que outras

não conseguiram realizar. Emquanto isto, as organizações continuam a comprar e a tentar usar TI sem resolverem problemas fundamentais, como os causados pela ausência da análise e modelagem de processos de negócio. Este artigo introduz uma nova tecnologia, chamada SOA, e suas ligações com o gerenciamento de processos de negócio.

Palavras-chave: Processos de Negócio, Tecnologias da Informação, SOA.

1. Introdução

A criação de processos que serão executados em segundo plano (background

processes) é uma tarefa quase totalmente desconhecida da maioria dos analistas de processos.

Especialmente a criação dos processos primários, de natureza industrial de manufatura contínua ou de transformação, CRUZ (2006). Mesmo processos secundários, administrativos ou de suporte, que deverão ser executados em segundo plano, mas que sejam essencialmente ligados à camada de infra-estrutura tecnologica, requerem determinado tipo de lógica que não é dominada pela maioria dos profissionais da área de processos. Processos que serão executados em segundo plano devem ser construídos de forma a integrar hardware e software a processos em primeiro plano, o que torna a tarefa dos analistas de processos ainda mais crítica. Esta realidade é o que faz com que uma nova Tecnologia da Informação,

Service-Oriented Architecture (SOA), ganhe, a cada dia, mais e mais espaço nos projetos de

integração hardware, software, processos e negócios nas organizações.

2. Topografia dos processos de negócio

Com o advento de novas tecnologias da informação e de novas metodologias para análise e modelagem de processos de negócio, dois termos em Inglês têm sido freqüentemente usados em conversas entre especialistas, em cursos, palestras e seminários: foreground &

background processes, respectivamente processos em primeiro e segundo planos. Precisamos

entender corretamente o significado destes termos e as implicações advindas das suas existências nas organizações para podermos entender a tecnologia SOA.

2.1 Foreground processes

Em Português, processos (executados) em primeiro plano. O termo foreground

processes refere-se a processos que são executados na camada externa do ambiente

operacional ao qual estão ligados, ou seja, são processos executados na parte mais visível das estruturas que dão forma às organizações. Embora não sejam exclusivamente processos que interajam com pessoas, eles são, na maioria das vezes, processos com intensiva interação homem-máquina, o que requer dos analistas de processos cuidados especiais quanto ao que chamamos de ergonomia, a fim de que as pessoas se sintam confortáveis ao trabalharem e não

venham a sofrer doenças, genericamente, chamadas “do trabalho”; como a síndrome LER (Lesão por Esforço Repetitivo). Além deste cuidado, este tipo de processo requer uma análise e modelagem cuidadosa, pois por meio dela serão atribuídas responsabilidades que exigirão das pessoas envolvidas total comprometimento com o dia-a-dia das operações da organização.

Por exemplo, processos que requiram que o ser humano abra formulários eletrônicos, se relacione com outras pessoas, com tecnologias da informação, com máquinas, com equipamentos, com dispositivos e instrumentos de forma direta são processos executados em primeiro plano ou que, quando prontos, serão executados em primeiro plano. São tecnologias nesta categoria programas de computador, softwares diversos, microcomputadores, máquinas industriais, etc. Para processos cuja operacionalidade está diretamente ligada à ação do ser humano existem dois tipos de tecnologias:

• Tecnologias da Informação. São sistemas especialistas ou de propósito geral que operacionalizam o dia-a-dia das organizações. Por exemplos, os sistemas de gerenciamento de recursos empresariais (Enterprise Resource Planning), uma parte dos sistemas de gerenciamento do relacionamento com clientes (Customer

Relationship Management), Workflow, KM (Gerenciamento do Conhecimento)

entre outros. Todos estes sistemas têm direto e intensivo uso dos seres humanos, mas é bom ressaltar que os mesmos sistemas podem ter módulos com funcionalidades que não são acessadas pelas pessoas e, desta forma, partes deles rodariam em segundo plano.

• Tecnologias de Processos. São, também tecnologias da informação, pois máquinas, equipamentos, dispositivos e instrumentos que processam e transformam entradas em saídas nos processos industriais de manufatura (discreta e contínua), e até mesmo em alguns processos de serviços, contêem processadores embutidos. É com este tipo de tecnologia de processo que as pessoas também interagem, de forma direta ou indireta, ao representarem papéis funcionais, principalmnte nos processos primários (aqueles ligados à fabricação do produto). Algumas destas tecnologias podem ter camadas que rodam em primeiro plano e outras que rodam em segundo plano.

A diferença fundamental entre os dois tipos de tecnologias e suas homônimas existentes nos processos executados em segundo plano (background processes) é o grau de interação delas com os seres humanos, pois, via de regra, enquanto nos processos executados em primeiro plano tanto as tecnologias da informação quanto as de processos são diretamente usadas pelas pessoas, as tecnologias dos processos executados em segundo plano o são indiretamente, através de tecnologias ligadas a processos executados em primeiro plano e na maioria das vezes estas tecnologias. Algumas tecnologias que suportam processos executados em primeiro plano sequer são visíveis a quem as usa.

2.2 Background processes

Em Português, processos (executados) em segundo plano. O termo background

processes refere-se aos processos que são executados na camada interna do ambiente

organizacional ou, mais precisamente, na camada cujo contato com o ser humano é indireto ou inexistente. Nesta camada, também conhecida como a camada de infra-estrutura, as tecnologias podem desde suportar superficialmente os processo até, no extremo oposto, automatizá-los completamente. Toda e qualquer infra-estrutura tecnológica necessita ter processos organizados, que as façam existir dentro de padrões, muitas vezes, extremamente rígidos. Para automatizá-los e mantê-los operacionais existem dois tipos de tecnologias:

• Tecnologias da Informação. São sistemas especialistas ou de propósito geral que realizam operações de base nas organizações. Exemplos: os sistemas de gerenciamento de recursos empresariais (Enterprise Resource Planning), uma parte dos sistemas de gerenciamento do relacionamento com clientes (Customer

Relationship Management), assim como os sistemas de gerenciamento da cadeia

de suprimentos (Supply Chain Management), de resposta eficiente ao consumo (Efficient Consumer Response) e de Data Wharehouse (DW).

• Tecnologias de Processos. São máquinas, equipamentos, dispositivos e instrumentos que processam e transformam entradas em saídas nos processos industriais de manufatura discreta e contínua, e de serviços. Por exemplo, nas fábricas de papel, a máquina que transforma pasta em papel chama-se máquina de papel. Na saída dela existe um sensor longitudinal que varre permanentemente o resultado do processo de transformação, medindo a gramatura, a densidade e a umidade do papel que acabou de ser fabricado. Este sensor é a tecnologia de um processo executado em segundo plano (background process) e os sinais que ele coleta e envia a um computador de controle permitem que outras tecnologias da informação acionem controladores lógicos programáveis, que regulam a passagem de mais ou menos pasta para manter a gramatura, a densidade e a umidade constantes. Além disto, os dados coletados pelo sensor são enviados a computadores de controle de processos que são supervisionados por operadores que podem atuar para controlar a qualidade do produto, sempre que for necessária tala intervenção.

A Figura 1 mostra as camadas dentro da organização onde são executados processos em primeiro e em segundo planos suportados por tecnologias da informação. Entre a camada que tem interação direta com os funcionários (primeiro plano) e a camada que corre sem contato com os funcionários (segundo plano) existe uma nova classe de tecnologia chamada EAI (Enterprise Application Integration), que é um conjunto de ferramentas que possibilita à organização integrar as aplicações, softwares, módulos e ferramentas das duas dimensões (foreground & background) num único ambiente e este com o negócio da organização. Esta integração, das aplicações da organização, pode ser feita por meio de softwares chamados de

Enterprise Application Integration Suíte, vendidos por dezenas de fabricantes de softwares ou

desenvolvidos in house. Entretanto, o mais importante não é decidir de qual fabricante comprar este ou aquele EAI, mas como os processos em foreground e background serão mapeados, organizados, integrados e operacionalizados.

3. A camada integradora de aplicações

A industria de Tecnologias da Informação constantemente procura desenvolver produtos que integrem eficientemente sistemas de informações, e estes aos negócios da organização. Esta busca por intergração entre as duas camadas da topologia dos processos descrita anteriormente (foreground and background processes) remonta aos anos 60, início da computação comercial, época da introdução dos computadores nas organizações.

As primeiras tentativas se deram por meio de dispositivos de armazenamento de dados, chamados de discos rígidos, cujo papel de repositórios, por estocarem eletrônicamente dados que foram e/ou seriam tratados pelos sistemas da informações, mudava a forma como as organizações manipulavam testes dados. Antes dos discos rígidos os dados eram introduzidos nos sistemas por meio de cartões perfurados, que também eram usados como suporte para a saída dos dados, após o processamento. Entretanto, os discos rígidos eram propiciavam um tipo de integração que apenas unia as pontas (saídas e entrada) dos sistemas

de informações.

Muitos outros produtos apareceram desde então, mas devemos dar especial destaque a uma classe de ferramentas chamada middleware, KRAFZIG et al (2004). Por volta dos anos noventa produtos que prometiam integrar os sistemas de informações e estes aos negócios da organizaçào surgiram com o nome genérico de middleware. Entretanto, por diversas razões os produtos desta classe de ferramentas não realizaram suas promesas de intergação, mas deixaram raízes que possibilitaram a criação de duas outras classes de softwares: Enterprise

Application Interface (EAI) e, mais recentemente, Service-Oreinted Architecture (SOA).

ERP ERP EC R EC R SC M SC M DW DW CM CM COLD COLD

Workflow

Workflow

KM

KM

(Enterprise Application Integration)

Atividades A4 A4 P ro ces so s em Se g u n d o P la n o Processos em Primeiro Plano SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA SOA

FIGURA 1 – Topografia dos processos

Fonte: Cruz (2006).

3.1 Enterprise Application Integration

O EAI é, de certa forma, a evolução do conceito middleware e descendente das sub-rotinas existentes na fase áurea dos mainframes. Em resumo, antes do advento dos sistemas integrados, como o MRP, o MRPII e mais recentemente o ERP, os grandes sistemas de informações das organizações que possuíam mainframes eram criados de forma estanque proporcionando a geração de “silos” (embora àquela época o termo não existisse com esta conotação) que dificilmente se comunicavam entre si. Para fazê-los “conversarem entre si” os analistas de sistemas desenvolviam subrotinas que ficavam encarregadas de levar e trazer dados de um silo (arquivo) para outro e vice-versa.

Os softwares de EAI são conjuntos (suítes) de várias ferramentas que possibilitam a integração de sistemas e softwares por meio de uma estrutura tecnológica, lógica e cronológica. Analogamente, os softwares da classe Enterprise Application Integration

trouxeram para o ambiente dos processos executados em segundo plano a “inteligência” que antes estava restrita a produtos executados nos processos em primeiro plano. Outra função importante da Enterprise Application Integration é a de integrar os dois planos tecnológicos da organização, o primeiro e o segundo (foreground e background), permitindo que as aplicações destinadas a funcionários, clientes, fornecedores, parceiros, acionistas, governo, além de confiáveis, quanto à veracidade dos dados e informações disponibilizadas (on-line) por meio e através delas, sejam a exata representação da realidade (real-time) operacional e gerencial da organização.

Entretanto, as suites Enterprise Application Integration são soluções proprietárias, o que, ao usá-las, remete as organizações de volta aos problemas que possuiam na época dos mainframes: a dificuldade em atualizar todo o conjunto integrado por estes softwares; além de imporem um “casamento eterno” com o “fabricante” do produto EAI, o que dificulta atualizações de softwares e torna, praticamente, impossível substituir sistemas, mesmo que sejam de um mesmo fabricante.

Os softwares EAI, ganharam popularidade nos anos noventa por terem sido os primeiros produtos feitos para integrar os portais corporativos à sistemas e às suas bases de dados.

3.2 Service-Oriented Architecture

Com a advento dos sistemas Web, surgiram algumas imperiosas necessidades, com as quais as organizações devem lidar1. Entre estas, a de que a integração dos diversos sistemas Web deve permitir não somente o perfeito funcionamento do ambiente como um todo, mas, e primordialmente, deve garantir a rapidez com que tais sistemas, por serem Web, necessitam ser atualizados.

Posteriormente ao EAI, surge o conceito SOA (Service-Oriented Architecture), e, baseado nele, softwares que permitem resolver, em grande parte, os transtornos enfretandos pelas organizações quando da atualização dos sistemas Web. Entretanto, devemos ressaltar que os softwares SOA têm limitações, sendo algumas delas muito sérias, mas que serão discutidas mais adiante. Autores como KEEN et al (2004) definen SOA como “modelos de

estruturas para desenvolvimento de aplicações Web, particularmente voltadas ao e-business”, por permitirem sua utilização e re-utilização por todos que precisarem executar tais

estruturas, serviços Web programados, sem a necessidade de conhecerem como eles foram programados, em qual linguage, nem em que plataforma rodam. Baseados em KEEN et al (2004), listamos algumas abordagens que esta arquitetura propicia quando corretamente implementada.

• Identificação da interação entre usuários, negócios e dados.

• Criação em camadas, possibilitando a integração de multiplos sistemas sempre que a solução não puder ser desenvolvida num único modelo.

• Composição de padrões que representam as combinações de multiplos sistemas diferentes.

1

Segundo GOLD-BERNSTIEN e SO (2006) “The emergence of the Internet and the associated rush to

e-business further punctuated the need for organizations—and, by association, IT—to become more responsive to market dynamics. But with different departments launching their own initiatives and often duplicating one another’s work, the result was reduced visibility and control, along with reduced economies of scale.”

• Modelagem, da solução, que proporciona o leiaute conceitual, descrevendo como os componentes de aplicações e dados interagem com os negócios da organização. Vem da flexibilidade e independência listadas acima o poder e, também, a fragilidade do “padrão” SOA, das quais falaremos adiante.

Um dos fatores que faz aumentar o prestigio das aplicações SOA está na raiz de um problema existente na utilização dos sistemas de informações pelas organizações: a imprescindível necessidade de constante atualizar dos mesmos. SOA permite que sistemas sejam atualizados sem que suas ligações com outros sistemas, bancos de dados, agentes, etc. obrigatoriamente o sejam. Em outras palavras, isto significa dizer que a vida util dos sistemas pode aumentar, dada a caracteristica de desenvolvimento em camadas das aplicações, separando dados, regras de negócio e o processamento destes. Desta forma, as organizações ganhariam agilidade e rapidez para fazer, nos seus sistemas, as modificações que o ambiente altamente dinâmico da Web exige.

3.3 Componentes SOA

Para entendermos os componentes principais existentes em um ambiente

Service-Oriented Architecture necessitamos falar de padrões.

O que são padrões?

São regras definidas e pactuadas entre as partes. Os padrões para construção e uso dos serviços SOA são estebalecidos por três organismos que congregam desenvolvedores de softwares, pesquisadores, especialistas e estudiosos: o World Web Consortium (W3C), o Web Services Interoperability (WS-I) e o Organization for the Advancement of Structural Information Standards (OASIS). Estes organismos trabalham para garantir a “abertura de padrão” dos serviços SOA, impedindo que alguém, pessoa física ou jurídica, dele se aposse e venha a “fechá-lo”, como aconteceu no passados com outros padrões.

A architectura SOA basea-se em um conjunto de instruções chamado XML. É esta linguagem que começa a implementar os conceitos de interoperabilidade há muito tempo perseguido por fornecedores e usuários de Tecnologias da Informação.

XML (eXtensible Markup Language) é um conjunto de instruções (linguagem) para a construção de documentos em formato texto, que serão usados, qualquer que seja o propósito, na comunicação entre dois sistemas (hardware e software). O W3C criou a XML com base na linguagem SGML, considerada a avó de todas as linguagens Web, que foi desenvolvida pela International Standartization Organization (ISO).

Os seguintes padrões XML são o que podemos chamar de fundamentos do SOA: • Simple Object Access Protocol (SOAP). Conjunto de instruções para construção

dos documentos texto (menssagens.).

• Universal Description Discovery and Integration (UDDI). Documento que descreve, com exatidão, o QUÊ um serviço Web faz e COMO ele deverá ser “chamado” (ativado) por um documento texto (mensagem.).

• Web Services Description Language (WSDL). Diretório de todos os serviços Web disponíveis para uso dentro de uma organização.

Com estes três componentes SOA realiza a promessa, muitas vezes feitas, e nunca realizada, de Integração-Independente entre sistemas; entendendo-se por sistemas o conjunto formado por hardware e software.

3.4 Funcionamento do SOA

O problema: um sistema (software) “rodando” num determinado computador (hardware) necessita se comunicar com outro sistema (software) que está “rodando” ou no mesmo ou em outro computador (hardware), mas este sistema “não sabe” a linguagem com que o outro foi escrito, nem os protocolos de comunicação e segurança exigidos para estabelecer a comunicação e conseqüente troca de dados e informações, resultando completo bloqueio entre os dois sistemas.

Se para ligar os dois sistemas tivessem sido desenvolvidos agentes ou serviços Web dentro do padrão SOA, este problema não aconteceria.

Resumidamente, SOA funciona assim: primeiro o programador de SOA consulta o diretorio de serviços SOA (WSDL) disponíveis no ambiente para o qual ele escreverá o agente ou programa. Com este conhecimento ele desenvolve o documento que executará o serviço Web de acordo com as especificações contidas no documento (UDDI) do serviço que ele quer ativar. A partir daí o serviço Web poderá ser executado.

O serviço Web se incumbirá de fazer a ligação, colocando os dois sistemas em conversação.

3.5 Vantagens e desvantagens do SOA

O ambiente SOA tras inúmeras e significativas vantagens para a interoperabilidade dos sistemas (hardware e software) em qualquer organização. Independentemente de aonde os sistemas (softwares) estejam sendo executados, que padrões proprietários usem, que hardwares os hospedem. Não há qualquer impecilho. Nada precisa ser levado em conta, na hora que dois sistemas precisam se comunicar para trocar dados e informações entre si quando usamos padrões SOA. Este, aliás, é o princípio que norteia a disponibilidade e a usabilidade da World Wide Web.

Entretanto, existem elementos extremamente sensíveis que devem ser considerados, cuidadosamente analisados e projetos para que um ambiente SOA possa ser utilizado Como por exemplo:

• Segurança. Sendo um ambiente “aberto” SOA necessita de investimentos significativos para prover e manter a segurança do ambiente. Em principio, sem a devida implementação dos mecanismo de segurança, qualquer um, incluindo aqui hackers e crakers, que venha a ter acesso ao WSDL, e consequentemente ao UDDI, pode executar um serviço Web com qualquer proposito (legal ou criminoso).

• Lentidão. Também por serem baseados em padrão aberto os serviços SOA tenderão a ser mais lentos que serviços proprietários. Esta pode ser uma situação particularmente arriscada para organizações que necessitam de rapidez nos serviços disponibilizados nos seus sites.

• Desorganização informacional. Esta se deve à proliferação de serviços Web criados numa organização. Com a adoção do padrão XML as organizações tenderão a desenvolver mais e mais serviços SOA e a experiência nos mostra que a perda de controle sobre o conteúdo das libraries existentes nas áreas de informática é algo que já acontece com datasets em bancos de dados, pedaços de códigos que deveriam ser re-utilizados, entre outros elementos de TI.

• Análise e modelagem de processos de negócio. Como integradora dos ambientes onde são executados processos em primeiro e segundo planos (foreground &

beckground processes) a Service-Oriented Architecture (SOA) obrigatoriamente

deve refletir os processos de negócio da organização. Devem ser aderentes ao negócio! Caso contrário, corre-se o risco de, no mínimo, continuarmos a termos sistemas não-aderentes à organização; como o são grande parte das aplicações hoje existentes.

4. Conclusões

Finalmente, podemos começar a contar com uma plataforma Service-Oriented

Architecture (SOA) como padrão de programação de mecanismos, serviços e funcionalidades,

que permitirão integrar efetivamente a topologia dos processos de negócio em qualquer organização. Dentro desta perspectiva, surgiram novos papéis funcionais que devem ser entendidos e corretamente desenvolvidos por organizações que queiram implantar SOA.

Comecemos por entender o ambiente aonde o projeto SOA deve ser desenvolvido. Ele chama-se Planejamento da Arquitetura Empresarial, Enterprise Architecture Planning (EAP), KRAFZIG et al (2004).

EAP é um conjunto de processos que tem por objetivo planejar e implementar Tecnologias da Informação na forma e com o conteúdo necessarios à atender à gerência da organização; ao mesmo tempo em que garantem a continuidade e a efetividade do ambiente de TI. Surge, então o papel do Arquiteto responsável pela arquitetura orientada à serviços, ASOA. Este profissional deve trabalhar em conjunto com analistas de processos de negócio para poder desenhar o ambiente e os serviços SOA de forma a fazê-los aderentes ao negócio da organização.

Por fim, sem análise e modelagem de processos de negócio não há como estruturar um ambiente SOA, pois teríamos no máximo uma colcha de retalhos que em nada seria diferentes das até hoje construidas com outros tipos de integradores de sistemas, como interfaces, agentes e sistemas EAI.

Tecnologia da Informação sem organização, acreditamos, será sempre um estorvo, por cumprir seu papel fundamental de apoiar as operações da organização com eficiência e eficácia.

5. Referências Bibliográficas

CRUZ, Tadeu. O teatro organizacioal – construindo e implantando processos de negócio. Rio de Janeiro: E-Papers, 2006.

GOLD-BERNSTEIN, Beth; SO, Gary. Integration and SOA – concepts, technologies and best practices. New Rochelle, EbQuiz Press, 2006.

KEEN, Martin et al. Patterns: Implementing an SOA Using an Enterprise Service Bus. New York: RedBooks, 2004.

KRAFZIG, Dirk et al. Enterprise SOA: Service-Oriented Architecture Best Practices. New York: Prentice Hall, 2004.