Web Services como Tecnologia de Suporte a Processos de Negócio - PDF
Download "Web Services como Tecnologia de Suporte a Processos de Negócio"
Gustavo Azambuja Palmeira
1 Web Services como Tecnologia de Suporte a Processos de Negócio Rodrigo C. Macedo, Vasco Mesquita, Artur Caetano, André Vasconcelos, José Tribolet Centro de Engenharia Organizacional, INESC INOV e Departamento de Engenharia Informática, Instituto Superior Técnico, Universidade Técnica de Lisboa. Resumo Actualmente, uma vasta maioria das organizações existentes a nível mundial, estruturam a sua actividade com base no conceito de processo de negócio. Visto que os sistemas de informação apresentam uma importância indiscutível como suporte aos processos da organização, há que recorrer a sistemas cada vez mais flexíveis e de fácil integração. É neste contexto que surgem os Web Services como tecnologia de suporte aos processos de negócio, cujas características preenchem cada vez mais os requisitos referidos. No entanto, a representação dos processos deve ser feita de forma independente da tecnologia que os implementa, factor que presentemente nem sempre é satisfeito. É desta forma que este artigo propõe um modelo com vista à representação de processos de negócio cujo suporte a nível tecnológico é dado pelos Web Services. Este modelo é composto por três camadas distintas camada de Processos de Negócio, camada de Web Services Genérica e camada Tecnológica tendo como objectivo a abstracção de detalhes tecnológicos irrelevantes a nível de negócio. A proposta é apresentada como uma framework orientada a objectos na linguagem UML (Unified Modeling Language). Palavras-chave: Web Service, Processo de Negócio, Modelação INTRODUÇÃO A Internet surge actualmente como uma plataforma essencial de integração de sistemas e aplicações, visto que consiste num conjunto de standards aceites universalmente, o que permite a comunicação entre duas máquinas de uma forma simples e automatizada. No entanto, a Internet por si só não fornece todos os mecanismos necessários para que esta integração seja possível, apenas fornece todo um conjunto de protocolos necessários à comunicação. É neste contexto que surgem os Web Services, como tecnologia que permite a interoperabilidade universal utilizando os standards referidos e consequentemente a integração de diversas aplicações nos domínios do B2C (Business to Consumer), B2B (Business to Business) e outros. Inicialmente, os Web Services começaram por se basear num conjunto reduzido de especificações, entre as quais, o SOAP (Simple Object Access Protocol) que especifica o formato de mensagens, o HTTP (HyperText Transfer Protocol) como protocolo de transporte de dados e o UDDI (Universal Description, Discovery, and Integration) como um mecanismo de publicação e pesquisa de serviços. Os Web Services são actualmente uma tecnologia que suporta tecnologicamente inúmeros processos de negócio, quer estes representem interacções intra-empresariais como interacções inter-empresariais, pelo que a sua importância tem crescido de uma forma exponencial nos últimos anos.
2 Desta forma, têm surgido várias propostas no que se refere à modelação de processos de negócio utilizando Web Services tais como o BPEL4WS (Business Process Execution Language for Web Wervices), BPML (Business Prcocess Modeling Language) e DAML (DARPA Agent Markup Language). No entanto, estas especificações geralmente confundem conceitos relacionados com os processos de negócio, com detalhes e/ou conceitos relacionados com a tecnologia que os implementa. É neste contexto que se propõe no presente artigo, uma framework (apresentada na linguagem UML) de modelação de processos de negócio cujo suporte tecnológico seja realizado em Web Services. A framework consiste em três camadas distintas Camada de Processos de Negócio, Camada de Web Services Genérica e Camada Tecnológica cujo objectivo é separar claramente os conceitos associados a cada uma destas componentes. 2 PROBLEMA A importância da modelação de processos de negócio e sua respectiva representação de um determinado contexto organizacional, tem sido cada vez mais reconhecida como forma de controlar e optimizar o workflow/dataflow de uma determinada organização. Sem considerar o respectivo suporte tecnológico inerente a estes processos de negócio, não representaria tanta vantagem recorrer à sua representação e optimização, visto serem os sistemas de informação que os implementam que permitem a automatização dos mesmos. Os Web Services surgem no panorama actual como uma das tecnologias de maior relevância e mais inovadoras, que permitem integrar diversas aplicações e que permitem às organizações disponibilizar um leque variado de serviços a entidades externas. É como resultado desta crescente importância que surgiram as linguagens de modelação de processos de negócio tendo como suporte tecnológico os Web Services. No entanto, não é vantajoso nem correcto do ponto de vista do modelo de negócio, existirem detalhes ou conceitos tecnológicos na definição de um processo de negócio utilizando uma destas linguagens, tal como acontece actualmente. É tendo este factor em conta, que se propõe um modelo de representação de processos de negócio cuja base tecnológica resida em Web Services e que permite abstrair detalhes técnicos aquando da representação de um determinado processo. Tendo como objectivo o desenvolvimento de um modelo de representação comum a todos os Web Services, ou seja, que permita representar um processo de negócio independentemente da tecnologia específica de Web Services que os implemente, surge a dificuldade de determinar quais os conceitos comuns a um Web Service genérico. No desenvolvimento de um modelo com estas características há ainda que ter em conta quais são os conceitos necessários e respectivas relações entre estes, para representar diferentes tipos de processos de negócio e ainda as características tecnológicas mais relevantes no âmbito dos Web Services que os implementam. Por outro lado, há que analisar se as linguagens de modelação mais comuns e aquelas em que o modelo proposto se baseia, possuem poder de modelação de processos semelhantes ou se existem limitações que influenciem o desenho.
3 3 PROPOSTA Nesta secção é então apresentado o modelo proposto que pretende ser uma forma de representação de um processo de negócio cujo suporte a nível tecnológico seja feito recorrendo aos Web Services. Este modelo é composto por três camadas distintas (ver Fig. 3.) onde em cada camada são abstraídos os detalhes representados nas outras duas. As três camadas são: Camada de Processos de Negócio: Camada que se preocupa apenas em identificar os vários intervenientes do processo de negócio (PN) e respectivas trocas de informação entre eles (dataflow/workflow); Camada de Web Services Genérica: Camada com o objectivo de representar os serviços disponibilizados por cada interveniente do PN descrito na camada anterior, sem olhar a detalhes técnicos ou implementações específicas; Camada Tecnológica: Camada responsável por descrever os detalhes técnicos relevantes para a descrição, pesquisa e execução de um determinado serviço; Figura 3. Representação das três camadas em que consiste o modelo proposto Entre cada duas camadas adjacentes existe alguma relação de conceitos, ou seja, conceitos existentes numa determinada camada, são directa ou indirectamente mapeados na camada(s) adjacente(s), o que permite obter a rastreabilidade desejada num modelo desta natureza (em que exista sub-divisão em camadas). 3. Camada de Processos de Negócio Esta primeira camada é constituída por três estereótipos cujas relações entre si permitem definir o workflow/dataflow associado a um determinado processo de negócio (ver Fig. 3.2). Esta camada foi desenvolvida com base na framework CEO [9], no entanto não pretende ser uma extensão ou especificação desta, embora possa existir a partilha de alguns conceitos ao nível da definição de determinados elementos (particularmente Activity e Resource). Os elementos definidos no contexto deste artigo e envolvidos nesta camada são: «Actor»: Elemento que suporta a execução de uma actividade de um Processo de Negócio, pode ser um conjunto de elementos humanos e/ou tecnológicos. Neste caso, os actores limitam-se aos SI que são importantes no âmbito dos Web Services devido à existência das noções de requester e provider de um serviço;
4 «Activity»: Elemento que representa uma actividade de um processo de negócio. Entenda-se como actividade um conjunto de acções/operações que consomem/produzem um ou mais recursos; «Resource»: Elemento que representa um recurso que é consumido ou produzido por uma actividade, através de uma relação de CRUD (Create, Read, Update e Delete). Two different actors shows the data /work flow between two activities executed by these actors. «Actor» «Actor»..* Executes «Activity»..* Executes «Activity» Produces Is Consumed Produces 0..* «Resource» 0..* 0..* «Resource» Figura 3.2 Meta-modelo referente à camada de Processos de Negócio representando o fluxo de informação entre actividades executadas por diferentes actores 3.2 Camada de Web Services Genérica Esta camada (Fig. 3.3) representa as entidades que disponibilizam um ou mais serviços, bem como a descrição dos mesmos de uma forma genérica, a informação trocada e as operações executadas. A visão estática pretende ser uma representação da entidade que fornece um ou mais serviços. A utilidade desta visão justifica-se com o facto de existirem situações em que não é relevante representar quem invoca o serviço, mas apenas que o disponibiliza. A visão dinâmica, tal como o nome indica, permite representar a invocação de um determinado serviço. Nesta visão são representadas ambas as entidades que participam nesta interacção (quem invoca e quem disponibiliza determinado serviço). Os elementos definidos para esta camada são os seguintes: «ServiceBlock»: Representa uma infra-estrutura aplicacional que disponibiliza um conjunto de serviços ou que invoca uma operação no contexto de um serviço fornecido por outro ServiceBlock (esta distinção é feita recorrendo à classe ServiceRole). «ServiceRole»: Representa uma classe que tem por objectivo especificar o papel desempenhado por um ServiceBlock. Esta classe é tipificada como Requester ou Provider caso o ServiceBlock disponibilize serviços ou invoque uma operação, respectivamente. «Service»: Representa um serviço que é disponibilizado por um determinado ServiceBlock. É também a entidade que agrega operações de alguma forma relacionadas.
5 «Operation»: Representa a operação que é invocada por um Service Requester. Tem uma determinada funcionalidade associada e consome e/ou produz determinada informação representada pelo elemento Document. «Document»: Representa a informação trocada resultante da invocação de uma operação no contexto de um serviço. «ServiceBlock» «ServiceBlock» «Service Role» Type: Requester «Service Role» Type: Provider Provides «Service» Invokes Provides «Operation» «Document» Figura 3.3 Meta-modelo referente à camada de Web Services Genérica (visão dinâmica) 3.3 Camada Tecnológica Esta camada foi desenvolvida com o objectivo de representar os detalhes técnicos associados à execução de um determinado serviço (ver Fig. 3.4), detalhes esses que as camadas superiores pretendem abstrair, visto não serem relevantes para a representação de um serviço genérico nem tão pouco de um processo de negócio mesmo que suportado tecnologicamente por Web Services. Consiste em diversos elementos que, entre outras características, permitem representar: o endereço físico onde se executa o serviço, a operação executada, as mensagens trocadas, o protocolo de transporte a ser utilizado, etc. Os elementos definidos para esta camada são os seguintes: «Operation»: Representa a operação que é executada por um service provider e invocada por um service requester. «PortType»: Representa a interface abstracta de um serviço e define um conjunto de operações com características comuns. Deste ponto de vista, diz-se que um PortType é a classe agregadora de operações. «Binding»: Descreve como a interface abstracta do serviço («PortType») é mapeada em protocolos específicos de formato e transmissão de dados. «Port»: Indica a localização específica de um serviço, associando um «Binding» a um endereço de rede (URI).
6 «Message»: Representa a informação trocada entre as duas entidades intervenientes na execução de um Web Service. Pode ser tipificada em mensagem de Input, Output ou Fault (esta permite indicar uma falha na execução de uma determinada operação). «Parameter»: Representa um parâmetro pertencente a uma mensagem. Cada mensagem pode ter um ou mais parâmetros cujo tipo poderá ser visto como um tipo primitivo (string, int, etc) ou uma estrutura de dados definida(o) em XML. «Operation» «Port» A port defines an individual endpoint by specifying a single address for a binding Addresses 0..3 «Message» Type: {Input, Output, Fault} «Binding» A binding describes how the abstract interface (PortType) maps to specific transport and message format protocols Describes..* «Parameter» «PortType» Figura 3.4 Meta-modelo referente à camada Tecnológica 3.4 Mapeamento entre camadas do meta-modelo Tendo por base as secções anteriores obtém-se então o meta-modelo final com o respectivo mapeamento de camadas que é apresentado na Fig Note-se que não se pretende que haja uma relação directa entre as camadas mas sim um conceito de rastreabilidade a manter na transição entre as mesmas. Do mapeamento da camada de Processos de Negócio para a camada de Web Services Genérica destaca-se o facto de um ServiceBlock constituir um elemento dedicado à disponibilização de um serviço (e execução de respectivas operações do mesmo) numa visão microscópica de um actor (Actor) e, tendo em conta os conceitos de recurso (Resource) e documento (Document) - ambos representam, embora de um diferente ponto de vista, a informação trocada entre duas entidades - pode ser ainda realçada a relação entre estes mesmos, ainda que pertençam a camadas distintas. Relativamente ao mapeamento da camada Genérica de Web Service para a camada Tecnológica surge então rastreabilidade entre o conceito de documento (Document), que representa a informação trocada aquando da invocação do serviço e o conceito de mensagem (Input Message e Output Message), com o mesmo objectivo de representação mas "transportado" para a camada Tecnológica. Do facto de a um serviço (Service) estar associado um Port (ou Endpoint) surge nova rastreabilidade entre estes dois conceitos pertencentes às camadas distintas (Tecnológica e Genérica).
7 Business Process Layer «Actor»..* Executes «Activity» Produces «Actor»..* Executes «Activity» Is Consumed Produces 0..* «Resource» 0..* 0..* «Resource» «ServiceBlock» «ServiceBlock» Generic Web Services Layer «Service Role» Type: Requester Invokes «Service» Provides «Service Role» Type: Provider Provides «Document» «Operation» «Port» «Message» Type: Input Technological Layer Addresses «Binding» Describes «Message» Type: Output «Message» Type: Fault 0.. «PortType»..*..*..* «Parameter» Figura 3.5 Mapeamento entre camadas
8 4 RESULTADOS Para resolver os problemas inerentes ao desenvolvimento do modelo proposto, foi realizado um estudo que permitiu compreender em detalhe o modo de funcionamento dos Web Services. Para tal foram estudados aspectos como a sua definição, invocação e descrição de um serviço. O passo seguinte consistiu numa fase de análise do estado da arte actual no domínio dos Web Services. Desta forma, foi realizada uma investigação sobre as mais relevantes especificações/linguagens associadas a este domínio, tais como BPEL4WS, BPML, DAML, etc. Visto que o modelo apresentado pretendia ser uma representação comum aos Web Services, foram identificadas as linguagens/especificações mais relevantes neste âmbito e procedeu-se à recolha de características comuns a todas elas. Após recolhidas e captadas essas mesmas características deu-se início ao processo de desenvolvimento do meta-modelo. O modelo proposto pretende evitar que sejam confundidos conceitos relacionados com processos de negócio e conceitos relacionados com a tecnologia que é utilizada para os implementar. Com um esboço do modelo efectuado, foi modelado um exemplo de um processo de negócio baseado em Web Services. Esta modelação permitiu efectuar refinamentos no modelo que foram tidos como muito importantes até à obtenção do meta-modelo final, visto que possibilitou eliminar incorrecções nos protótipos anteriores e adicionar características que reforçaram o poder de modelação deste. O modelo foi desenhado seguindo uma abordagem top-down, começando por desenvolver a camada de processos de negócio tomando como base a framework de representação de processos de negócio do CEO, embora esta camada não pretenda ser uma extensão desta framework. Relativamente à camada de Web Services genérica, esta foi desenvolvida através dos conceitos que se revelaram fundamentais para descrever um determinado serviço e com o objectivo de criar rastreabilidade entre os conceitos desta camada e da camada de processos de negócio. Quanto à camada tecnológica, esta procura representar aspectos técnicos relacionados com a descrição e invocação dos serviços utilizados pelo processo de negócio. Para isso foi considerada como base de descrição de qualquer Web Service, a linguagem WSDL que actualmente é usada na grande maioria dos Web Services existentes. 5 CONCLUSÃO A necessidade de existir um modelo que permitisse a representação de um processo de negócio cujo suporte tecnológico fosse realizado recorrendo aos Web Services surge na sequência de estudos anteriores, que demonstram que as linguagens de modelação de processos de negócio utilizando esta tecnologia confundem conceitos relacionados com o processo de negócio com conceitos relacionados com a tecnologia que os implementa. Após realizado o estudo de diversas linguagens/especificações existentes nesta área, foi feito um levantamento das características comuns a todas elas, que posteriormente seriam tidas em conta para a realização do modelo. Do estudo exaustivo realizado, conclui-se também que actualmente a base do suporte tecnológico da Web Services faz sempre uso de especificações tais como WSDL para descrever
9 a interface dos serviços, SOAP para descrever o formato das mensagens trocadas e HTTP como protocolo de transporte utilizado. A realização de protótipos de aplicação do modelo foi também de extrema importância no desenvolvimento deste, visto que permitiu identificar diversas lacunas e incorrecções nas versões anteriores à apresentada. Devido à sua simplicidade de implementação, descrição, execução e integração com outras aplicações, os Web Services são actualmente a mais popular implementação de uma arquitectura SOA (Service Oriented Arquitecture), embora existam outras que fornecem benefícios semelhantes. Há ainda que referir que na sua origem, as arquitecturas baseadas em Web Services continham algumas lacunas que dificultavam a sua integração em alguns casos, tal como a necessidade em garantir a confidencialidade das mensagens trocadas através de mecanismos de cifra ou controlar a execução de um Web Service composto por diversos intervenientes recorrendo a mecanismos transaccionais. Por forma a resolver estes e outros problemas existentes inicialmente, têm vindo a ser desenvolvidas diversas especificações que permitem atenuar ou mesmo resolver estes problemas. Tendo em conta que a tecnologia dos Web Services é relativamente recente e ainda está em crescimento, é evidente que o modelo apresentado não abrange todos os aspectos relacionados com esta tecnologia. Nomeadamente, não permite representar directamente aspectos relacionados com a segurança da invocação de um determinado serviço, modelação de processos recorrendo a Web Services com conteúdo semântico (apesar desta ser uma extensão ainda muito pouco desenvolvida e quase não utilizada) ou características relacionadas com invocação composta de vários serviços, recorrendo a mecanismos transaccionais. Sendo assim, estas são algumas das particularidades no âmbito dos Web Services que podem ser tidas em conta para uma ampliação do poder de modelação do modelo proposto. 6 REFERENCIAS BPEL4WS, Business Process Execution Language for Web Services Version., Maio WSGlossary, Web Services Glossary W3C Working Draft, Agosto MicrosoftWS, Web Services Specifications. Microsoft MSDN, Salz, Rich - XML.COM: Examining WSDL, Maio Selim A., M. Pallavi, K. Srinivasa, Business Process Modeling: The Next Big Step, Communications of the IEEE, Maio WSDL, Web Services Description Language (WSDL)., Março
10 J. Tribolet, A. Vasconcelos, M. Mira da Silva, A. Fernandes, An Information System Architectural Framework for Enterprise Application Integration, C. Adam, Why Web Services?, Fevereiro J. Tribolet, A. Vasconcelos, M. Mira da Silva, A. Fernandes, An Information System Architectural Framework for Enterprise Application Integration, XML.COM: What is Service-Oriented Architecture?, Setembro