MODELING SYSTEMS ARCHITECTURE USING ARCHITECTURE DESCRIPTION LANGUAGE IN SOA CONTEXT

5 th International Conference on Information Systems and Technology Management 5º Congresso Internacional de Gestão da Tecnologia e Sistema de Informação De 04 a 06 de Junho de 2008 - São Paulo - Brasil PS-1092 MODELING SYSTEMS ARCHITECTURE USING ARCHITECTURE DESCRIPTION LANGUAGE IN SOA CONTEXT Luiz Paulo Rocha Yanai (Universidade de São Paulo, São Paulo, Brasil) luiz.yanai@poli.usp.br Selma Shin Shimizu Melnikoff (Universidade de São Paulo, São Paulo, Brasil) selma.melnikoff@poli.usp.br Jorge Luis Risco Becerra (Universidade de São Paulo, São Paulo, Brasil) jorge.becerra@poli.usp.br The Software Architecture (SA) is an important research field that has been evolving a lot in past decades due to the possibility of ensuring the non-functional requirements by defining the SA in the system development process. SA is tightly related with project organization, reusability, quality attributes and development patterns. A good architecture can leverage the system development and result in software compliant with stakeholder requirements. Service Oriented Architecture (SOA) is a new architectural style that came to solve a lot of problems with distributed architectures, dynamic systems and other issues found in today industry. In this paper, an approach for describing a Service Oriented Architecture is proposed by comparing with several other initiatives. Through a research about SOA concepts and using Medvidovic s classification framework, the basis for a SOA Architecture Description Language is presented. Keywords: Software Engineering, Software Architecture, Architecture Description Language, Service Oriented Architecture. MODELAGEM DE ARQUITETURA DE SISTEMAS USANDO ADLS NO CONTEXTO DE SOA A Arquitetura de Software é um campo de pesquisa que vem evoluindo muito nas últimas décadas devido à possibilidade de se garantir os requisitos não-funcionais de um sistema através da definição da Arquitetura de Software no processo de desenvolvimento dos sistemas. A Arquitetura de Software está intimamente ligada com reusabilidade, atributos de qualidade e padrões de desenvolvimento. Uma boa Arquitetura pode alavancar o desenvolvimento de software e resultar em software que satisfaça os requisitos das partes interessadas. A Arquitetura Orientada a Serviços (SOA Service Oriented Architecture) é um novo estilo arquitetural que surgiu para resolver os problemas existentes em sistemas distribuídos, sistemas dinâmicos e sistemas em geral. Neste artigo, levantam-se os aspectos importantes para a descrição de SOA através da comparação com outras iniciativas de definição de Linguagens de Descrição de Arquitetura e utilizando o arcabouço de classificação de Medvidovic e Taylor. Palavras-Chave: Engenharia de Software, Arquitetura de Software, Linguagem de Descrição de Arquitetura, Arquitetura Orientada a Serviços. 1355

1. Introdução Atualmente, o desenvolvimento de software baseado em Arquitetura tem sido utilizado em diversos projetos, a fim de assegurar qualidade, ter controle e rastreabilidade sobre os requisitos funcionais e não-funcionais e também sobre as expectativas das partes interessadas. Como importante passo no processo de desenvolvimento, uma Linguagem de Descrição de Arquitetura (Architecture Description Language - ADL) tem o papel de oferecer suporte ao armazenamento das decisões arquiteturais, estilos e requisitos do sistema em uma Arquitetura. Na figura 1, é apresentado o modelo de picos gêmeos de Ward e Mellor (1991) que mostra o desenvolvimento progressivo e concorrente dos requisitos e das especificações arquiteturais resultando nos produtos caso de uso e descrição da Arquitetura utilizando uma ADL. Figura 1 - Modelo de picos gêmeos adaptado de Ward e Mellor (1991). Nos últimos anos, muitas ADLs, ferramentas e métodos de suporte foram propostos por pesquisadores da área de desenvolvimento de Arquitetura de Software. Algumas iniciativas usam a Unified Modeling Language (UML) para descrever graficamente a Arquitetura, embora haja problemas de inconsistências, informalidade e modelos incompletos inerentes à estrutura da linguagem como discutido por Lange, Chaudron e Muskens (2006). Outras iniciativas usam ADLs existentes aplicadas a domínios de aplicação específicos (Medvidovic e Taylor, 2000; Vestal, 1993). Entretanto, em todos os casos existe um grande desafio em se identificar o que uma ADL deve representar e também como aplicar estas ADLs comercialmente no processo de desenvolvimento de Arquitetura para software (Open Group, 1999). O objetivo deste trabalho é levantar os pontos importantes e requisitos necessários para definir uma linguagem de descrição de Arquitetura Orientada a Serviços (Service Oriented Architecture - SOA) tomando como base a pesquisa atual referente a linguagens de descrição de Arquitetura existentes e fazendo uma comparação com as ADLs já propostas para o contexto de SOA. Uma preocupação deste estudo é desenvolver uma ADL mais voltada para a utilização nas empresas como auxílio à representação da Arquitetura, suporte a análise de completude, consistência, ambigüidade e desempenho, e geração automática de código. 1356

Na Seção 2, são apresentadas as ADLs mais importantes encontradas na literatura de Arquitetura de Software, que servem como base para o levantamento das características para descrição de uma Arquitetura. A Seção 3 discute a definição de SOA a fim de reunir a informação necessária para descrever tal estilo arquitetural. Já a Seção 4 analisa as tentativas de descrição de SOA, confrontando com as características das ADL existentes e usando o arcabouço de classificação proposto por Medvidovic (Medvidovic e Taylor, 2000). Finalmente, os resultados da análise são apresentados na Seção 5. 2. Linguagens de Descrição de Arquitetura Notações formais de modelagem e ferramentas de desenvolvimento para especificação arquitetural são essenciais para o suporte ao desenvolvimento baseado em Arquitetura (Medvidovic e Taylor, 2000). Muitas ADLs foram propostas para apoiar esta necessidade. Nesta seção, serão analisadas as principais ADLs criadas, de forma a aprofundar o conhecimento neste conceito. Mas para iniciar a análise das ADLs existentes, deve-se primeiro definir o conceito sobre a Arquitetura de Software que é o objeto da representação. Segundo Shaw e Garlan (1996), A Arquitetura de software é um nível de projeto que envolve a descrição de elementos, através dos quais os sistemas são construídos, interações entre estes elementos, padrões que guiam sua composição e restrições sobre estes padrões. Bass (1998) define Arquitetura de Software de um programa ou sistema computacional como a estrutura ou estruturas do sistema que compreende componentes de software, as propriedades externamente visíveis destes componentes e os relacionamentos entre eles. Além dos conceitos de componentes, interface e relacionamentos que estão presentes nas duas definições apresentadas anteriormente, existe a preocupação de se representar na Arquitetura de Software os requisitos não-funcionais dos sistemas e atributos de qualidade. O desenvolvimento de ADLs deve se voltar principalmente para a representação destes conceitos básicos listados para qualquer Arquitetura. De acordo com Vestal (1993), Uma ADL para aplicações de software foca na estrutura de alto nível de uma aplicação em geral, ao invés de focar nos detalhes de implementação de qualquer módulo específico. Aprofundando um pouco esta definição, ADL pode ser definida como uma linguagem usada para descrever software em alto nível de abstração utilizando componentes, interfaces e relacionamentos que pode ser decomposto em diversos pontos de vistas atendendo a diferentes preocupações e requisitos. E, segundo o consórcio Open Group (2008), existem quatro pontos de vistas de Arquitetura comumente aceitos como pertencentes a uma Arquitetura corporativa: Arquitetura de Negócios ou Processos: define a estratégia de negócios, governança, organização e processos de negócios chave. Arquitetura de Dados: descreve a estrutura de dados física e lógica de uma organização e os recursos de gerenciamento de dados. Arquitetura de Aplicações: Fornece um blueprint para as aplicações serem implantadas, suas interações e seu relacionamento com os principais processos de negócio da organização. 1357

Arquitetura Tecnológica: descreve as funcionalidades de software e hardware necessárias para fornecer suporte à implantação de negócios, dados e serviços de aplicação. Ela inclui infra-estrutura de TI, middleware, redes, comunicações, processamento, padrões, etc. Considerando esta conceituação de Arquitetura de Software e ADL, sugere-se um estudo mais aprofundado das ADLs existentes que foram criadas para diferentes propósitos e domínios de aplicação de forma a reunir os componentes comuns em todas as descrições e formar uma base para o desenvolvimento de uma nova ADL para SOA. As ADLs mais comumente encontradas na literatura são (Cook, 1999; Vestal, 1993): Aesop É um ADL de propósito geral que tem ênfase em estilos arquiteturais. Foi desenvolvida por David Garlan na Carnegie Mellon University. Ela tem ênfase em estilos que utilizam funcionalidades hierárquicas sofisticadas centradas em subtipos e herança. É muito similar as ADLs ACME e Wright. C2 É um estilo baseado em componente e mensagens projetado para fornecer suporte a necessidades particulares de aplicações que tem interface gráfica. Tem potencial para ser utilizado com outros estilos, principalmente em sistemas distribuídos e em ambientes heterogêneos. O estilo C2 pode ser resumido informalmente como uma rede de componentes concorrentes unidos por conectores. A figura 2 mostra um exemplo de Arquitetura no estilo C2.. Figura 2: Uma Arquitetura exemplo de C2. [Medvidovic,1996] MetaH É uma ADL voltada para os requisitos de sistemas de controle de vôos e aviação, incluindo segurança, tempo real, tolerância a falhas e multiprocessamento. Ela contém elementos de linguagem para suporte a componentes de software e hardware. Cada componente tem uma lista de atributos, uma interface e zero ou mais implementações. Por fim, as conexões ligam os componentes para formar uma Arquitetura. Existem ferramentas para compilar as especificações do MetaH para código fonte, diretivas de compilação e ligação, e também ferramentas para compilar o código para o sistema de hardware de destino (McDuffie, 2001). 1358

Rapide é uma ADL orientada a objeto de propósito geral projetada com ênfase em simulação. Ela descreve e simula o comportamento de arquiteturas de sistemas de objetos distribuídos. Nela são definidos componentes que executam independentemente e que observam e geram eventos. Modela comportamentos semelhantes à máquina de estados. Os principais elementos arquiteturais do Rapide são os componentes, as conexões, as interfaces e as restrições. Ela possui um extenso ferramental que inclui ferramentas de análise para confrontar simulações com padrões de comportamentos não permitidos, análise temporal e causalidade e ferramentas para geração de executáveis a partir das especificações. A figura 3 mostra um exemplo simples de uma especificação em Rapide. Figura 3: Um exemplo simples de especificação utilizando a ADL Rapide. (Cook, 1999) SADL refinamento formal de Arquitetura através de níveis de detalhamento. UniCon é uma ADL de propósito geral projetada com ênfase em geração de conectores. Ela foi desenvolvida por Mary Shaw da Carnegie Mellon University com foco em conectores como objetos de primeira classe. Como linguagem, ela foca no paradigma componente/conector/sistema, mas tem ênfase em estilos arquiteturais. Assim como Rapide e MetaH, existe a possibilidade de geração de código a partir da especificação. Weaves arquiteturas de fluxo de dados, caracterizadas por alto volume de dados e requisitos de tempo real no seu processamento. Wright é uma ADL de propósito geral projetada por David Garlan da Carnegie Mellon University, com ênfase em análise de protocolos de comunicação. Como linguagem, ela se baseia no paradigma componente/conector/sistema e tem sintática similar as ADLs Aesop e ACME. Para especificar o comportamento de componentes, conectores e sistemas, Wright usa uma variação da linguagem de descrição de padrões de interação em sistemas concorrentes chamado CSP Communicating Sequential Processes. Um exemplo simples de especificação Wright é mostrado na figura 4. 1359

Figura 4: Exemplo simplificado de uma especificação utilizando a ADL Wright. [Cook, 1999] ACME A ACME pode ser vista como um bom ponto de partida para o estudo das ADLs e para o desenvolvimento de novas já que ela foi desenvolvida como uma linguagem de intercâmbio entre ADLs. Contudo, ela não fornece adequadamente a resposta ao problema da definição de uma ADL genérica. A ACME representa apenas o denominador comum das ADLs existentes. Ela é baseada na premissa de que existe suficiente semelhança nos requisitos e capacidades das ADLs de forma a se poder compartilhar informações independente de ADL. A ACME endereça o problema de representação de Arquitetura utilizando o conceito de templates. Templates definem estruturas semânticas que podem ser expandidas para produzir novas declarações. Os templates são agrupados em estilos arquiteturais. ACME fornece uma base extremamente simples para a representação de Arquitetura. As características chave do ACME são [Garlan, Monroe, Wile, 1997]: 1) uma ontologia arquitetural com sete elementos de projeto: a) Componentes b) Conectores c) Sistemas d) Portas e) Responsabilidades f) Representações g) Mapas de representação 2) um mecanismo de anotação flexível - com o mecanismo de anotação é possível acomodar uma grande variedade de informação de tipagem (tipo de dados comunicados entre componentes, protocolos de interação) 3) um mecanismo de template para abstrair estilos e idiomas comuns 4) um arcabouço semântico aberto para descrições de Arquitetura Em geral, todas as ADLs tem seus pontos fortes e fracos dependendo do domínio onde elas são aplicadas. Não há um consenso na comunidade de pesquisa sobre quais aspectos e níveis de detalhes deveriam fazer parte de uma ADL (Medvidovic e Taylor, 2000). Algumas ADLs oferecem apenas uma forma de entendimento e comunicação sobre o 1360

sistema de software, enquanto outras oferecem uma sintaxe formal e ferramental de análise poderoso. Uma classificação das ADLs existentes é importante para unificar e verificar a abrangência dos conceitos encontrados nestas iniciativas. Logo, de forma a fazer a escolha da melhor ADL para solucionar um conjunto particular de problemas, (Medvidovic e Taylor, 2000) construiram um arcabouço de comparação e classificação de ADLs que é apresentado a seguir. 2.3 Definição de ADL usando o Arcabouço de Medvidovic A idéia do Arcabouço de Medvidovic é classificar e comparar diversas ADLs existentes ajudando a identificar as propriedades chave das ADLs. A comparação destaca áreas onde as ADLs existentes oferecem um bom suporte e outras em que são deficientes. As categorias identificadas (os blocos de construção de uma Arquitetura) no arcabouço são: a) Componentes unidades de computação ou armazenamento de dados Interface Tipos Semânticas Restrições Evolução Propriedades não-funcionais b) Conectores Interface Tipos Semânticas Restrições Evolução Propriedades não-funcionais c)configurações arquiteturais topologias, grafos conectados de componentes e conectores que descrevem uma Arquitetura. Habilidade de compreensão Habilidade de composição Rastreabilidade e refinamento Heterogeneidade Escalabilidade Evolução Dinamismo Restrições Propriedades não-funcionais Estas categorias servem como base para a definição de uma ADL e através delas pode ser feito um comparativo destas dimensões com uma determinada ADL de forma a analisar a abrangência e aplicação da ADL. Alguns conceitos encontrados nas linguagens apresentadas não aparecem nas categorias, mas podem ser representados de outras formas. Este arcabouço será utilizado para avaliar as iniciativas de criação de ADLs para o caso específico de Arquitetura Orientada a Serviço. Mas, primeiramente, é preciso definir a base conceitual da Arquitetura Orientada a Serviço de modo a oferecer uma melhor descrição da Arquitetura. 1361

3. Arquitetura Orientada a Serviços A Arquitetura Orientada a Serviços é um estilo arquitetônico que se preocupa com questões relacionadas à criação e uso de processos de negócios, encapsulados como serviços, através de um ciclo de vida, e também fornecendo a infra-estrutura de TI necessária para diferentes aplicações trocarem dados e participarem de processos de negócios em um ambiente distribuído e heterogêneo (Newcomer, Lomow, 2005). SOA representa um modelo em que as funcionalidades são divididas em unidades distintas (serviços) que podem estar distribuídas por toda uma rede. Estes mesmos serviços podem ser combinados e reutilizados de forma a prover necessidades de negócios das corporações (Erl, 2005). A comunicação entre os serviços é através da troca de mensagens de um serviço com outro, no esquema mostrado na figura 5. Este comportamento vem sendo considerado uma evolução da computação distribuída e da programação modular (Erl, 2005). Figura 5: Modelo geral contendo os componentes e papéis básicos de SOA Segundo Xiangyang apud (Dan et al, 2006), SOA foi projetada para criar um ambiente organizado dinamicamente composto de serviços distribuídos que podem ser compostos e interoperáveis. Estes serviços têm como características serem: autocontidos e modulares interoperáveis fracamente acoplados localização transparente módulos compostos. Para Jia et al. (2007), as principais diferenças apontadas entre os softwares tradicionais e aqueles construídos usando o SOA são: Componentes com grossa granularidade Fraco acoplamento Serviços autônomos Distribuídos Composição dinâmica 1362

Outras definições que podem ser encontradas de SOA são a do consórcio Open Group que realizou um projeto específico para a definição de SOA, a do OASIS que criou um modelo de referência muito conhecido para a Arquitetura Orientada a Serviço e a do SEI (Software Engineering Institute) que é uma entidade importante na pesquisa na área de Arquitetura de software. 3.1 Open Group: Segundo o projeto de definição de SOA do Open Group (Open Group, 2007), Service- Oriented Architecture (SOA) é um estilo arquitetural que suporta orientação a serviço. Orientação a serviço é um jeito de pensar em termos de serviços e desenvolvimento baseado em serviços e os resultados dos serviços. Um serviço: É uma representação lógica de uma atividade repetitiva de negócio que tem um resultado específico (p.ex., crédito de cheques, fornecer dados de clima, etc.. ). É autocontido Pode ser composto de outros serviços É uma caixa preta para os clientes dos serviços As características distintas do estilo arquitetural do SOA são: É baseado na definição de serviços A representação de Serviços utiliza descrições de negócios e implementa serviços usando orquestração. Estipula requisitos únicos na infra-estrutura. Requer governança da representação do serviço e implementação Requer Litmus Test", para determinar um bom serviço. 3.2 OASIS: No modelo de referência do OASIS (2007), SOA é descrito como um paradigma de organização e utilização de funcionalidades distribuídas que podem estar sobre o controle de diferentes domínios. SOA fornece um meio uniforme de oferecer, descobrir, interagir e usar funcionalidade para produzir os efeitos desejados de forma consistente com as précondições e expectativas. Os conceitos principais apresentados no modelo de referência estão apresentados na figura 6. 1363

Figura 6 - Principais conceitos descritos no modelo de referência SOA 3.3 Software Engineering Institute O SEI apresentou em um trabalho de avaliação de arquiteturas orientadas a serviços a seguinte definição de SOA (Bianco, Kotermanski, Merson, 2007): Um estilo arquitetural onde sistemas são constituídos de usuários de serviços e fornecedores de serviços. Um estilo arquitetural define um vocabulário de componentes e tipos de conectores, e restrições sobre como eles podem ser combinados. Para SOA, os tipos de componentes básicos são o usuário de serviço e o fornecedor de serviço, tipos de componentes auxiliares como o enterprise service bus (ESB) e o diretório de serviços. Os tipos de conectores SOA incluem chamadas síncronas e assíncronas usando protocolo SOAP, http, e/ou infra-estrutura de mensageria. Muitas propriedades podem ser atribuídas para estes tipos de componentes e conectores, mas eles são específicos para cada tecnologia de implementação. 3.4 Revisão das definições de SOA Como foi levantado, existem diversos pontos de vista com relação ao que uma Arquitetura precisa ter para ser orientada a serviços. Em geral, as definições apresentadas focam nos seguintes itens que são essenciais num sistema orientado a serviço: a existência dos serviços, propriamente dito, que são módulos auto-contidos e independentes disponibilizados através de uma interface bem definida e que podem ser compostos com outros serviços. Fraco acoplamento entre os componentes do sistema Dinamicidade na composição de serviços e semântica associada. Com os conceitos de SOA mais bem estabelecidos, pode-se tratar da descrição da Arquitetura usando linguagens ADL. Foram encontradas duas iniciativas principais para descrever SOA: SOADL (Jia et al, 2007) e modelagem através de grafos transformacionais (Baresi et al, 2006). Também é discutida a linguagem de descrição SCDL (Service Component Decription Language) que faz parte da Arquitetura de Componentes de Serviço (Service Component Architecture - SCA) (IBM, 2007). 1364

4. Tentativas de Descrição de Arquitetura Orientada a Serviços Por ser um estilo emergente, a Arquitetura Orientada a Serviço ainda não possui muito desenvolvimento teórico e formal com relação à sua descrição e ao processo de modelagem de Arquitetura. Buscou-se nesta seção reunir as principais iniciativas oriundas do campo de pesquisa e a partir delas fazer um cruzamento com as características das ADLs discutidas na seção 2. 4.1 SOADL Service Oriented Architecture Description Language A linguagem SOADL foi proposta em 2006 (Dan et al, 2006) partindo dos conceitos de SOA estabelecidos pelo modelo de referência do OASIS e também a partir da experiência dos autores na área. Segundo esta primeira iniciativa, SOA poderia ser descrito em três partes: 1 Serviços agrupa os conceitos de funcionalidade, contrato e política, modelo de ação e processo, semântica e estrutura. 2 Conectores agrupa os conceitos de modelo de informação e comportamento, contexto de execução e estado compartilhado. 3 Configuração agrupa os conceitos de links e topologia. Uma ferramenta de modelagem visual de SOA também foi proposta associada a esta ADL. Em 2007, o mesmo grupo aperfeiçoou o estudo acerca desta linguagem estabelecendo nova classificação dos componentes da SOADL e aprofundando no detalhamento da linguagem (Jia et al, 2007). Os Componentes de serviço no SOADL passaram a ser classificados em três níveis: - serviços arquiteturais - serviços de negócios - serviços de aplicação Os Conectores representam bindings entre service ports. O tipo de representação é hierárquico e utiliza XML como meta-linguagem conforme apresentado no exemplo da figura 7. Existe certo relacionamento entre os componentes da linguagem de forma a possibilitar a geração de implementação Business Process Execution Language (BPEL) a partir do SOADL. Esta foi uma grande evolução em relação às outras formas de representação por permitir a modelagem de processos de negócio na Arquitetura. Neste aperfeiçoamento, houve um maior detalhamento na sintaxe e semântica da descrição da linguagem. Contudo, SOADL ainda não é um trabalho concluído e muita pesquisa está sendo feita no desenvolvimento da ferramenta gráfica SO-ADL VMT. 1365

Figura 7: Exemplo de estrutura de documentos do modelo arquitetural do SOADL. (Jia et al, 2007) 4.2 Linguagem de Descrição de Componentes de Serviço - SCDL A Arquitetura de Componentes de Serviço ( SCA Service Component Architecture) define uma abordagem para criação de componentes e descrição de como estes componentes podem trabalhar juntos para desenvolver uma aplicação. Não é propriamente uma ADL, contudo é uma forma de representação que pode e vem sendo utilizada na descrição e composição de serviços dentro de uma Arquitetura Orientada a Serviços. Existem três componentes primários no SCA: componentes, composto e domínio. Os componentes podem ser combinados em compostos e agregados para formar um domínio. A figura 8 mostra um exemplo simples do modelo de Arquitetura SCA. Figura 8: Arquitetura de Componente de Serviço - SCA (IBM, 2007) Componentes são os átomos de criação de uma aplicação SCA. A implementação dos componentes pode ser em Java ou em BPEL ou em qualquer outra linguagem de programação. A configuração destes componentes é feita no formato XML em uma linguagem chamada Service Component Description Language (SCDL). A evolução desta linguagem está sendo conduzida pelo OASIS e a mesma já vem sendo utilizada em algumas ferramentas proprietárias para o desenvolvimento de aplicações no contexto de Arquitetura Orientada a Serviço. Um exemplo da linguagem de descrição SCDL pode ser visto na figura 9. 1366

Figura 9: Exemplo de código SCDL para descrição de um componente de Serviço na implementação IBM. É possível que alguma ADL seja proposta e utilize alguns recursos desta linguagem aproveitando-se da sua similaridade com os componentes de uma SOA: serviços (componentes), interface, fornecedores de serviços, conectores, etc. Levando em consideração as categorias levantadas no arcabouço de Medvidovic, o SCDL tem diversas características e recursos que são observadas em linguagens de descrição de Arquitetura sendo, portanto, mencionadas entre as iniciativas de linguagem de descrição de SOA. 4.3 Modelagem SOA usando Grafos Transformacionais Existe ainda uma terceira proposta de modelagem de SOA baseada em modelos conceituais envolvidos em estilos arquitetônicos, formalizados por sistemas de grafos transformacionais. Esta abordagem tem enfoque na habilidade de reconfiguração dinâmica (alocação para um novo serviço em tempo de execução) típica de SOA (Baresi et al, 2006). A utilização de grafos transformacionais permite uma definição formal de SOA como estilo arquitetural. A figura 10 mostra um grafo de instância para um sistema automotivo apresentado em (Baresi et al, 2006). A técnica utilizada foi de refinamento da Arquitetura orientada a negócios, que é independente de aspectos de tecnologia, em Arquitetura Orientada a Serviços. Para a modelagem foi utilizada uma combinação de representação baseada em grafos com UML. Uma extensão à meta-modelo UML foi introduzida para fazer o mapeamento entre o perfil UML para SOA e os elementos do estilo arquitetônico. É uma abordagem diferente de descrição de Arquitetura mais voltada para a transformação de sistemas orientados a negócios para SOA que para a descrição dos itens pertencentes a uma Arquitetura SOA. 1367

Figura 10: Grafo de instância específico para SOA de um sistema (Baresi et al, 2006) 4.4 Análise das ADLs orientadas a serviço Em todas as linguagens apresentadas pode-se encontrar a preocupação em aplicar os conceitos dos sistemas orientados a serviços com a criação de elementos arquitetônicos específicos para representar serviço e conceitos relacionados. No entanto, existe uma maior semelhança entre as iniciativas da SOADL e SCDL por utilizarem o padrão XML como forma de representação e por descreverem os serviços ou componentes em estruturas separadas. A definição do serviço no SOADL é de mais alto nível com relação ao comportamento dos serviços e permite orquestração de serviços assim como para os grafos transformacionais. A SOADL abrange uma visão de maior granularidade com relação aos outros por possibilitar a classificação dos componentes em níveis. Existe a preocupação no SOADL com relação ao alinhamento do sistema com os processos de negócios através da divisão dos serviços no nível arquitetural, negócios e nível tecnológicos. Algo semelhante ocorre na terceira proposta que parte da modelagem de negócios para chegar à de serviços no seu processo de desenvolvimento de Arquitetura. A característica de reconfiguração dinâmica tem extenso suporte tanto em SOADL como em Grafos Transformacionais. No entanto, por ser baseada em uma extensão ao UML, a ADL de grafos transformacionais herda o problema de dispersão das definições da Arquitetura em diversos diagramas e também o problema da complexidade para ser utilizada em projetos comerciais. 1368

Outra questão importante é que para as três ADLs ainda não é intrínseca a preocupação relativa a segurança nas interações e nos componentes como encontrado na xadl (Ren, Taylor, 2005). O resumo dos resultados da análise dos recursos das três ADLs é apresentado na Tabela 1. Tabela 1 : Tabela de comparação dos modelos de ADLs para SOA apresentadas Conceitos SOA / ADLs SOADL SCDL Grafos Transformacionais Serviço possui elemento equivalente com 3 níveis de classificação: arquitetural, negócios e tecnológico conceito secundário ligado ao conceito de conector para definir pontos de interação Representado pelo componente de serviço Interface é uma entidade de primeira classe usualmente definida em wsdl Subtipo associado a componentes de serviços. Interface de Serviço suportado Descrição do Serviço especificação de serviço suporte limitado suportado Interação suportado suportado suportado Contrato e Política Está dentro do conceito de Serviço não possui não possui Reconfiguração dinâmica possui - possui Granularidade alta baixa média Suporte a processos de negócios possui Não possui possui Segurança não possui não possui não possui 5. Características básicas de uma ADL para SOA Levando em consideração a análise das tentativas de descrição de SOA e as características que definem uma ADL segundo o arcabouço de Medvidovic pode-se definir as características básicas e conceitos que uma Linguagem de Descrição de Arquitetura Orientada a Serviço deve abranger. A ADL que mais chega próximo dos requisitos de SOA para ser uma ADL completa possível e com maior perspectiva mercadológica é a SOADL. Ela apresenta classificação semelhante à apresentada pelo arcabouço dividindo a representação da Arquitetura em três principais elementos arquiteturais (Serviço, Conectores e Configuração), possui fácil representação utilizando o padrão XML de representação dos artefatos, foi desenvolvida sobre os conceitos básicos apontados pelo modelo de referência SOA do OASIS e apresenta classificação de serviços para fazer o alinhamento com os processos de negócios. Tomando estas características emprestadas do SOADL e juntando com o lado tecnológico do SCDL é possível estender a descrição da aplicação para artefatos executáveis a exemplo das ADLs UniCon, Rapide e MetaH. Podemos também incluir alguns conceitos relativos a estereótipos do Modelo de Grafos Transformacionais tais como Service Provider, Service Requester e Service Registry e as 1369

propriedades relativas à evolução e propriedades não-funcionais da Arquitetura mencionada no arcabouço de Medvidovic. Uma alteração importante na linguagem seria a adição de conceitos de segurança aos elementos e estilos arquiteturais como na ADL xadl. Todas estas características devidamente integradas permitem uma representação mais abrangente, compatível com a noção de ADL e de maior permeabilidade no meio corporativo. 6. Conclusão A linguagem de descrição de Arquitetura Orientada a Serviços SOADL apresenta uma forma simples e independente de tecnologia ao se modelar sistemas compostos por serviços. Existe a preocupação recorrente de alinhar os processos de negócios e os sistemas de TI. No entanto, não foram mencionadas considerações sobre segurança e semântica. A proposta que utiliza grafos transformacionais abrange grande parte dos conceitos de SOA levantados, no entanto, utiliza como representação uma extensão a UML que, talvez não satisfaça os requisitos de linguagem de representação de tal estilo arquitetônico. Os conceitos da nova ADL apresentada talvez forneça uma melhor forma de definição de Arquitetura levando em consideração a abrangência, nível de granularidade, objetividade e apelo comercial. Contudo, ela é apenas uma evolução na consolidação da modelagem de arquiteturas orientadas a serviços e precisa ser mais bem desenvolvida. É importante avaliar melhor os conceitos resultantes das definições de SOA de forma a criar uma linguagem de descrição da Arquitetura que expresse corretamente todas as características importantes para um sistema de software baseado no conceito de SOA. 7. Trabalhos Futuros Como trabalhos futuros, existe a criação de ferramental para desenvolvimento de modelos de sistemas orientados a serviços independentes de tecnologia a exemplo do SO-ADL VMT. Uma junção de idéias de SOA e MDA pode ser feito pensando na criação de ferramental para criação de uma estrutura geral dos componentes de um software a partir da descrição da Arquitetura. Uma avaliação levando em consideração a norma IEEE 1471 não foi possível neste artigo e será explorado em futuras pesquisas. Por fim, a utilização de indicadores chave de performance (KPI - Key Performance Indicators) como entrada para arquiteturas orientadas a serviços, ajudando a ter mecanismos mais precisos de controle para avaliação das arquiteturas. 1370

Referências Bibliográficas [Baresi et al, 2006] BARESI, L. et al. Style-based modeling and refinement of serviceoriented architectures. Software & System Modeling, 2006. [Bass et al, 1998] BASS, L.; et al. Software Architecture in Practise. Addison- Wesley Longman Publishing Co. Boston, 1998. [Bianco, Kotermanski, Merson, 2007] [Cook, 1999] [Dan et al, 2006] BIANCO, P.; KOTERMANSKI, R.; MERSON, P. et al. Evaluating a Service-Oriented Architecture. Software Engineering Institute. Technical Report, September 2007. COOK, Tw. Architecture Description Languages: An Overview. MCC, 1999. DAN et al. An Approach for describing SOA. Wuhan University IEEE Computer Society, 2006. [Erl, 2005] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0, 2005. [Garlan, Monroe, Wile, 1997] GARLAN, D.; MONROE, R.; WILE, D. Acme: An Architecture Description Interchange Language, 1997. [IBM, 2007] Service Component Architecture. IBM developerworks. http://www.ibm.com/developerworks/library/specification/ws-sca/. Acessado em 28 de Novembro de 2007. [Jia et al, 2007] [Lange, Chaudron, Muskens, 2006] [McDuffie,2001] [Medvidovic, Taylor, 2000] [Medvidovic,1996] JIA et al. A New Architecture Description Language for Service- Oriented Architecture. Wuhan University IEEE Computer Society, 2007. LANGE, C.; CHAUDRON,M.; MUSKENS,J. In pratice: UML Software Architecure and Design Description. IEEE Computer Society, 2006. McDUFFIE, J. H. Using the architecture description language MetaH for designing and prototyping an embedded spacecraft attitude control system, 2001. MEDVIDOVIC, N.; TAYLOR, R. Classification and Comparison Framework for Software Architecture Description Languages. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, v. 26, n. 1, p 70-93, jan. 2000. MEDVIDOVIC, N. et al. Using Object-Oriented Typing to Support Architectural Design in C2 Style. University of California, 1996. 1371

[Newcomer, Lomow, 2005] [OASIS, 2007] [Open Group, 2007] NEWCOMER, E; LOMOW, G. Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0, 2005. OASIS. SOA Reference Model TC. Disponível em http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-rm. Acessado em 28 de Novembro de 2007. The Open Group. SOA Oriented Architecture. Disponível em http://www.opengroup.org/projects/soa/. Acessado em 28 de Novembro de 2007. [Open Group, 2008] Open Group. The Open Group Architecture Framework 8.1.1. Disponível em http://www.opengroup.org/architecture/togaf8- doc/arch/toc.html. Acessado em 23 de Janeiro de 2008. [Ren, Taylor, 2005] [Shaw, Garlan, 1996] [Vestal, 1993] [Ward, Mellor, 1991] REN, J.; TAYLOR, R. A Secure Software Architecture Description Language. University of California, Irvine. ACM 2005. SHAW, M.; GARLAN, D. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, Apr. 1996. VESTAL, S. A Cursory Overview and Comparison of Four Architecture Description Languages. Technical report, Honeywell Technology Center, Feb. 1993. WARD, P. ; MELLOR, S. Structured Development for Real-Time Systems. Prentice Hall Professional Technical Reference, 1991. 1372