Artigo_C&I_165

5
Art 58 Controle & Instrumentação Nº 165 | 2011 Rompendo os Limites dos Sistemas Tradicionais – Aplicação de SOA no Ambiente da Automação Carlos E. G. Paiola Engenheiro de Controle e Automação, M.Sc. Gerente Comercial - Aquarius Software Ricardo Caruso Vieira Engenheiro de Controle e Automação Gerente de Serviços Especiais - Aquarius Software Introdução As empresas sofrem constantes mudanças. Elas têm sido, cada vez mais, impelidas a reduzir seus custos para manutenção da competitividade e para melhor atender aos requisitos de mercado. Esta realidade cria, inevitavelmente, a necessidade de novas formas de gestão do empreendi- mento. Independente do segmento industrial, cada empresa possui necessidades bastante específicas para serem preen- chidas por seus sistemas e aplicativos. Se por um lado essa característica impede a adoção simples e imediata das no- vidades do setor de Tecnologia da Informação (TI), por ou- tro ainda existem tantos pontos em comum que, cedo ou tarde, de forma pura ou adaptada, muitas das ferramentas e práticas utilizadas por TI são inseridas no ambiente indus- trial dentro do escopo da Tecnologia da Automação (TA). Este artigo objetiva apresentar uma proposta relevante originada no universo de TI, o conceito de SOA (Service Oriented Architecture), e discutir alguns detalhes de sua adaptação para o ambiente de TA. Essa discussão inclui o detalhamento do conceito, a apresentação de alguns mé- todos de implementação e a descrição de um exemplo im- portante de aplicação que se beneficia do conceito SOA: Smart Grid para a área de gestão de energia. SOA – Arquitetura Orientada a Serviços Tradicionalmente, a arquitetura de software das em- presas é composta por um conjunto de aplicativos dedi- cados a funções bastante específicas, desde o chão de fá- brica até o ambiente corporativo. Todo o planejamento de desenvolvimento e manutenção tem como foco cada um desses aplicativos, de maneira individual, conduzindo a sis- temas caros e inflexíveis. Nomeamos esse tipo de estrutura de Arquitetura Centrada em Aplicações. Nesse ambiente, cada aplicativo é construído com uma função bastante par- ticular e com seu próprio conjunto de usuários, dados, ob- jetivos e interfaces exclusivas. Desta forma, o sistema geral resultante é formado por ilhas de automação [Ref. 9]. O conceito de SOA tem por premissa eliminar essas ilhas de automação e criar sistemas de software como um conjunto de serviços que possam interagir entre si, coorde- nados por regras de negócio. Cada serviço consome ou for- nece certa coleção de dados e consiste na implementação de uma determinada atividade, bem definida no contexto geral da empresa. As diferenças entre os dois modelos de arquitetura citados podem ser observadas na Tabela 1. Tabela 1 – Comparação entre as arquiteturas Centrada em Aplicações e Orientada a Serviços [Ref. 9]. Característica Arquitetura Centrada em Aplicações Arquitetura Orientada a Serviços Desenho e Implementação Orientada a funções Construída para durar Ciclos de desenvolvi- mento longos Orientada à coordenação Construída para mudar Construída e implementada incrementalmente Sistema Resultante Ilhas de aplicação Fortemente acoplados Interações orientadas a objeto Soluções globais Fracamente acoplados Interações orientadas a mensa- gens semânticas Essa proposta de arquitetura tem ainda por objetivo seguir um conjunto de boas práticas que permitam criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados. [Ref. 7 e 8]. A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das empresas, permitindo um melhor relacionamento entre as áreas que dão suporte tec- nológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implemen- tação de novos serviços e reutilização dos ativos existentes [Ref. 10]. Esta tecnologia permite verdadeiramente a inte- gração entre TA e TI. Alguns dos principais conceitos associados à estrutura do SOA são serviços, acoplamento flexível e interoperabi- lidade: Pode-se definir Serviço como um conjunto de funções ou abstrações de funcionalidades de um sistema, com uma interface bem definida. O Acoplamento Flexível é crucial para o funcionamento de um sistema distribuído. Esse conceito determina que diferentes partes e funcionalidades de um sistema sejam independentes umas das outras. Dessa maneira, alte- rações ou problemas em certas partes do sistema não trarão grandes consequências para o resto do sistema, trazendo grandes benefícios como escalabilidade, flexi- bilidade e tolerância a falhas. Uma das principais preocupações em um ambiente de computação distribuída, comum nas grandes soluções industriais, é a flexibilidade de comunicação entre dife- rentes sistemas, de modo que esses possam agir conjun- tamente sem que haja conflitos na troca de informações entre eles. Essa comunicação é chamada de interopera-

description

http://www.aquarius.com.br/Boletim/Artigo_C&I_165.pdf

Transcript of Artigo_C&I_165

Art

58

Pesquisa é muito

boa sim mesmo,

interessatne até

é demais, dados

relevantes

p r a a r a

caramba

Controle & InstrumentaçãoNº 165 | 2011

Rompendo os Limites dos Sistemas Tradicionais – Aplicação de SOA no Ambiente da Automação

Carlos E. G. PaiolaEngenheiro de Controle e Automação, M.Sc.

Gerente Comercial - Aquarius Software

Ricardo Caruso VieiraEngenheiro de Controle e Automação

Gerente de Serviços Especiais - Aquarius Software

IntroduçãoAs empresas sofrem constantes mudanças. Elas têm

sido, cada vez mais, impelidas a reduzir seus custos para manutenção da competitividade e para melhor atender aos requisitos de mercado. Esta realidade cria, inevitavelmente, a necessidade de novas formas de gestão do empreendi-mento.

Independente do segmento industrial, cada empresa possui necessidades bastante específicas para serem preen-chidas por seus sistemas e aplicativos. Se por um lado essa característica impede a adoção simples e imediata das no-vidades do setor de Tecnologia da Informação (TI), por ou-tro ainda existem tantos pontos em comum que, cedo ou tarde, de forma pura ou adaptada, muitas das ferramentas e práticas utilizadas por TI são inseridas no ambiente indus-trial dentro do escopo da Tecnologia da Automação (TA).

Este artigo objetiva apresentar uma proposta relevante originada no universo de TI, o conceito de SOA (Service Oriented Architecture), e discutir alguns detalhes de sua adaptação para o ambiente de TA. Essa discussão inclui o detalhamento do conceito, a apresentação de alguns mé-todos de implementação e a descrição de um exemplo im-portante de aplicação que se beneficia do conceito SOA: Smart Grid para a área de gestão de energia.

SOA – Arquitetura Orientada a ServiçosTradicionalmente, a arquitetura de software das em-

presas é composta por um conjunto de aplicativos dedi-cados a funções bastante específicas, desde o chão de fá-brica até o ambiente corporativo. Todo o planejamento de desenvolvimento e manutenção tem como foco cada um desses aplicativos, de maneira individual, conduzindo a sis-temas caros e inflexíveis. Nomeamos esse tipo de estrutura de Arquitetura Centrada em Aplicações. Nesse ambiente, cada aplicativo é construído com uma função bastante par-ticular e com seu próprio conjunto de usuários, dados, ob-jetivos e interfaces exclusivas. Desta forma, o sistema geral resultante é formado por ilhas de automação [Ref. 9].

O conceito de SOA tem por premissa eliminar essas ilhas de automação e criar sistemas de software como um conjunto de serviços que possam interagir entre si, coorde-nados por regras de negócio. Cada serviço consome ou for-nece certa coleção de dados e consiste na implementação de uma determinada atividade, bem definida no contexto geral da empresa. As diferenças entre os dois modelos de arquitetura citados podem ser observadas na Tabela 1.

Tabela 1 – Comparação entre as arquiteturas Centrada em Aplicações e Orientada a Serviços [Ref. 9].

CaracterísticaArquitetura Centrada em Aplicações

Arquitetura Orientada a Serviços

Desenho e Implementação

• Orientada a funções • Construída para durar • Ciclos de desenvolvi-

mento longos

• Orientada à coordenação • Construída para mudar • Construída e implementada

incrementalmente

Sistema Resultante

• Ilhas de aplicação • Fortemente acoplados • Interações orientadas

a objeto

• Soluções globais • Fracamente acoplados• Interações orientadas a mensa-

gens semânticas

Essa proposta de arquitetura tem ainda por objetivo seguir um conjunto de boas práticas que permitam criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados. [Ref. 7 e 8].

A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das empresas, permitindo um melhor relacionamento entre as áreas que dão suporte tec-nológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implemen-tação de novos serviços e reutilização dos ativos existentes [Ref. 10]. Esta tecnologia permite verdadeiramente a inte-gração entre TA e TI.

Alguns dos principais conceitos associados à estrutura do SOA são serviços, acoplamento flexível e interoperabi-lidade: • Pode-se definir Serviço como um conjunto de funções

ou abstrações de funcionalidades de um sistema, com uma interface bem definida.

• O Acoplamento Flexível é crucial para o funcionamento de um sistema distribuído. Esse conceito determina que diferentes partes e funcionalidades de um sistema sejam independentes umas das outras. Dessa maneira, alte-rações ou problemas em certas partes do sistema não trarão grandes consequências para o resto do sistema, trazendo grandes benefícios como escalabilidade, flexi-bilidade e tolerância a falhas.

• Uma das principais preocupações em um ambiente de computação distribuída, comum nas grandes soluções industriais, é a flexibilidade de comunicação entre dife-rentes sistemas, de modo que esses possam agir conjun-tamente sem que haja conflitos na troca de informações entre eles. Essa comunicação é chamada de interopera-

Art

59

Pesquisa é muito

boa sim mesmo,

interessatne até

é demais, dados

relevantes

p r a a r a

caramba

Controle & Instrumentação Nº 165 | 2011

bilidade. Qualquer implementação atual deve levar em conta esse conceito. Existem diversas tecnologias que visam prover interoperabilidade em um sistema distri-buído e que propõem um barramento que serve de in-terface entre os serviços e os consumidores de serviços, não existindo mais as comunicações ponto a ponto que diminuem a flexibilidade do sistema. Essas tecnologias disponibilizam recursos para localizar e coordenar ser-viços, bem como para mediar a comunicação entre os serviços e os consumidores.

Como foi dito, SOA resume um estilo de arquitetura de software onde as funcionalidades implementadas pelas apli-cações são disponibilizadas na forma de serviços e são fre-qüentemente conectados através de um barramento único que disponibiliza interfaces ou contratos, acessíveis através de Web Services ou outra forma de comunicação entre apli-cações. Dentro desta realidade de computação distribuída, faz-se uso do princípio de requisição/ resposta (request/ re-ply) para estabelecer a comunicação entre os sistemas clien-tes e os sistemas que implementam os serviços.

Figura 1 – Representação da Arquitetura Orientada a Serviços [Ref. 5].

A implementação via Web Services é considerada uma das principais maneiras de atender aos requisitos da arquite-tura orientada a serviços. É uma tecnologia recente no que diz respeito a padrões de desenvolvimento de softwares dis-tribuídos, fazendo com que aplicações consigam comparti-lhar facilmente informações heterogêneas.

Os Web Services são componentes de desenvolvimen-to de aplicativos baseados em códigos abertos, oferecendo sistemas e informações pela internet que rodam em qual-quer dispositivo, de desktops a celulares, de forma dinâ-mica. Web Services tem como sua principal característica a interoperabilidade, possuindo a capacidade de integrar aplicações e programas distintos, inclusive quando estes são criados utilizando linguagem ou plataformas diferentes.

A identificação dos Web Services geralmente é feita através de URLs (Uniform Resource Locator), normalmente como é feito numa página Web. O acesso é muito seme-lhante ao tradicional feito na Internet, diferenciando-se na

mensagem que é passada através do cliente e o retorno enviado pelo servidor.

As aplicações interagem entre si utilizando um proto-colo que define toda a estrutura desses serviços. Um pro-tocolo muito popular é o SOAP (Simple Object Access Pro-tocol) que, por meio de um arquivo WSDL (Web Service Definition Language), define uma maneira comum de con-versação entre as aplicações e os serviços. Esses serviços são gerenciados e conectados normalmente por um ESB (En-terprise Service Bus) que disponibiliza interfaces por meio de WebServices. Um exemplo de transação realizada nesta estrutura seria: o cliente faz uma chamada de requisição passando seus parâmetros necessários, e o servidor faz a execução da tarefa retornando um arquivo XML (Extensible Markup Language) resultante [Ref. 1].

Figura 2 – Representação do Barramento de Serviços [Ref. 2].

O ESB [Fig. 2] é um componente lógico de arquitetura que fornece uma infra-estrutura de integração consisten-te com os princípios da SOA, atendendo aos requisitos de operação em ambiente distribuído e heterogêneo [Ref. 2].

Esse barramento deve permitir a substituição de uma implementação de serviço por outra, sem qualquer efeito para os clientes desse serviço. Isso requer que as interfaces de serviços sejam independentes do local e do protocolo de comunicação que está envolvido.

SOA no Universo da AutomaçãoA maioria dos sistemas de grandes empresas são lega-

dos de antigas gerações de gerências, que viviam em um mundo onde os sistemas eram projetados com o único in-tuito de funcionar. Eles conseguiram, pois os sistemas real-mente funcionam até hoje; porém cada parte do sistema se comunica diretamente uma com a outra, e à medida que o sistema cresce essa rede de comunicações torna-se um emaranhado confuso e ilegível, e a qualquer necessidade de mudança, todo o sistema deve ser modificado, tornan-do-se indisponível e trazendo grandes prejuízos.

Se pensarmos nos aplicativos relacionados ao universo da automação, desde o controle do processo até o nível corporativo, podemos incluir diversos sistemas nesta lista: sistemas supervisórios – SCADA (Supervisory Control and Data Acquisition) –, sistemas de gerenciamento de energia – EMS (Energy Management System) –, sistemas de histórico de processo – PIMS (Plant Information Management System)

Art

60

Pesquisa é muito

boa sim mesmo,

interessatne até

é demais, dados

relevantes

p r a a r a

caramba

Controle & InstrumentaçãoNº 165 | 2011

cesso” [Ref. 6]. Com este nível de automação dos processos e trabalhos envolvidos, pode-se atingir o nível de fluxo de trabalho contínuo, sem interrupções.

O uso dessa tecnologia possibilita a execução das tare-fas de uma maneira mais eficiente, integrando áreas e mi-nimizando o problema da coordenação do trabalho entre os processos de um empreendimento industrial. Para tanto, essa tecnologia permite a troca multilateral de informações entre PLCs (Programmable Logic Controller), sistemas HMI/ SCADA, EMS, PIMS, MES, ERP, APS, etc.

Algumas soluções de mercado possibilitam a utilização de uma plataforma única para atingir um ambiente de geren-ciamento e configuração de produção centralizada – criando uma espinha dorsal de envio de mensagens com modelos de equipamento de dados de toda a instalação e modelo de cada atividade envolvida [Ref. 3]. Essa plataforma tem a fun-ção de gerenciar e permitir a troca de dados entre diferen-tes serviços, responsáveis pelas mesmas funções originais de supervisão, histórico, relatórios gerenciais, alarmes/ eventos, cálculo de indicadores de desempenho do processo, etc.

Essas soluções têm por objetivo consolidar e simplificar o sistema como um todo, diminuindo custos de operação, respondendo mais rapidamente às novas mudanças e faci-litando o treinamento de operação/ manutenção. Dentre as características dessas soluções, podemos citar: • Ambiente de Gerenciamento e Configuração Centrali-

zado; • Barramentos de Serviços em Tempo Real – para dados e

funcionalidades; • Interface do Provedor de Serviço para Terceiros e Inte-

gração para Sistemas Legados; • Dados Globais e Repositório de Serviços; • Segurança Baseada em Tarefas; • Serviços de Diagnóstico; etc.

Figura 4 – Interface gráfica de operação de processo industrial [Ref. 3].

Essas soluções permitem, em geral, a interface com os sistemas SCADA originais, habilitando os usuários para ope-ração do sistema em tempo real, de maneira integrada aos outros serviços do sistema. Exemplo desta funcionalidade pode ser visto na Figuras 4, onde é apresentada uma tela de operação de um processo industrial, com representação gráfica de elementos da planta e de alarmes do sistema.

–, sistemas de gestão da produção – MES (Manufacturing Execution System) –, de gestão do empreendimento – ERP (Enterprise Resource Planning) –, de planejamento – APS (Advanced Planning & Scheduling) –, etc.

A adoção de SOA possibilita que as funcionalidades de um sistema possam ser divididas em tarefas e abstraídas como serviços, que serão utilizados pelas aplicações do sis-tema. Esses diferentes serviços são entidades que podem se comunicar e podem ser combinadas para formar processos mais complexos, ou utilizadas em diversas tarefas através de uma interface comum, independentemente da platafor-ma de desenvolvimento das aplicações. Esse funcionamen-to acrescenta muito ao sistema em termos de interoperabi-lidade, reuso, flexibilidade e baixo acoplamento.

É no SOA que está a modelagem global dos dados que estão distribuídos pelos diversos sistemas. No caso de um sistema de gestão de ativos, por exemplo, pode-se utilizar o modelo de um motor configurado e disponibilizado no barramento. Através deste modelo, o sistema pode contex-tualizar as informações deste motor e disponibilizá-las para cada sistema consumidor de dados. Um software SCADA, neste exemplo, pode disponibilizar os dados de monitora-mento em tempo real, ao mesmo tempo que o MES forne-ceria os motivos de eventuais falhas ocorridas durante os últimos turnos. Para uma consulta das condições do mo-tor pelo módulo de manutenção do ERP, bastaria acessar o conjunto de dados fornecidos sobre esse modelo.

Com a modelagem e contextualização dos dados da empresa de maneira centralizada, é possível adicionar e modelar as regras de negócio da empresa em um único sistema responsável por “orquestrar” os processos do em-preendimento.

Neste cenário surge a aplicação da Gestão do Fluxo de Trabalho (Workflow Management), através da qual é pos-sível realizar a análise e o controle da interação entre os processos, monitorando todas as informações relacionadas a cada passo da produção, a chamada “orquestração” do processo [Fig. 3]. Essa tecnologia é proveniente do universo de TI e representa mais um bom exemplo de convergência tecnológica, adaptada para atender às demandas da TA.

Figura 3 – Exemplo de etapas do processo e a orquestração das tarefas para produção.

Workflow é definido pela WfMC (Workflow Manage-ment Coalition) como “a automação total ou parcial de um processo de negócio, durante o qual documentos, informa-ções e tarefas são passadas entre os participantes do pro-

Art

61

Pesquisa é muito

boa sim mesmo,

interessatne até

é demais, dados

relevantes

p r a a r a

caramba

Controle & Instrumentação Nº 165 | 2011

Outro exemplo interessante é apresentado nas Figuras 5 e 6, onde pode-se observar o sistema elétrico e seus diversos circuitos, enquanto administra-se as informações de manu-tenção corretiva e preventiva dos equipamentos envolvidos (transformadores, seccionadoras, disjuntores, etc.). Na Figura 6, nota-se que é possível, por exemplo, armazenar e demons-trar procedimentos e conhecimentos específicos através do sistema, de modo a auxiliar os usuários em suas tarefas.

Figura 5 – Gerenciamento de manutenção relacionado a sistema elétrico [Ref. 3].

Figura 6 – Detalhes sobre procedimento de manutenção [Ref. 3].

Exemplo de Aplicação: Smart GridDentro do contexto de geração, transmissão e dis-

tribuição de energia elétrica, a tecnologia de Smart Grid consiste numa rede de fornecimento mais inteligente que a convencional, possibilitando melhor resposta à demanda de energia, gestão inteligente de falhas, melhor integração das formas de energia renováveis e do armazenamento de energia, análise em tempo real do consumo, entre outros benefícios aos envolvidos.

De maneira geral, uma rede inteligente faz uso de tec-nologias da informação para melhorar a forma como a ele-tricidade passa de usinas de energia para os consumidores. Em segundo lugar, ela permite que os consumidores pos-sam interagir com a grade. Em terceiro lugar, que integra

tecnologias novas e melhoradas para a exploração da rede. O Smart Grid é um sistema de energia elétrica automático que monitora e controla as atividades da rede, garantindo o fluxo bidirecional de electricidade e de informações en-tre usinas, consumidores e todos os pontos entre eles. O que torna esta grade “inteligente” é a capacidade de medir, monitorar e, em alguns casos, controlar automaticamente como o sistema funciona ou se comporta em um determi-nado conjunto de condições. Na sua forma mais básica, a implementação de uma rede mais inteligente é a adição de inteligência para todas as áreas do sistema de energia elétrica para otimizar o uso da eletricidade [Ref. 4].

De maneira geral, as concessionárias de energia elétri-ca possuem diversos sistemas especialistas, cada qual com uma funcionalidade bem clara e definida. Exemplos destes sistemas são:• SCADA – sistemas supervisórios que permitem a ope-

ração e o controle remoto do sistema elétrico. É geral-mente utilizado em Centros de Operação Centrais ou Regionais. Possui funcionalidades como: telas de ope-ração para visualização da rede e comando remoto de elementos do sistema (disjuntores, seccionadoras, etc.), telas de alarmes e eventos (visualização de SOE, por exemplo), geração de relatórios de operação e de ma-nobras do sistema, etc.

• GIS (Geographic Information System) – sistema dedica-do a capturar, armazenar, analisar e demonstrar infor-mações referenciadas geograficamente.

• OMS (Outage Management System) – sistema utilizado para controlar o serviço de equipes de campo, gerencian-do o posicionamento e a disponibilidade destas equipes. Em geral, estes sistemas auxiliam o administrador a otimi-zar cada recursos e seus respectivos deslocamentos.

Quando se utiliza uma estrutura orientada a serviços, sistemas originalmente isolados como os citados acima, tornam-se serviços fornecedores/ consumidores de dados do sistema e, através do emprego da tecnologia de Web Services, por exemplo, pode-se disponibilizar de maneira fácil e intuitiva estes serviços e suas respectivas funcionali-dades para os usuários de interesse. Na Figura 7, é dado um exemplo bastante geral de Smart Grid e seus componentes de hardware e software.

Uma grade inteligente permite aos fornecedores e dis-tribuidores de energia benefícios como [Ref. 4]:• Transmissão mais eficiente da eletricidade;• Recuperação mais rápida da rede após os distúrbios de

alimentação;• Redução dos custos de operações e gestão de serviços

públicos, e mesmo dos consumidores, através da in-tegração de análises preditivas, auto-diagnóstico, e de tecnologias de auto-reparo;

• Redução de picos de demanda, o que também auxilia na redução das taxas de eletricidade;

• Maior integração da geração e da rede de distribuição;• Maior segurança.

Art

62

Pesquisa é muito

boa sim mesmo,

interessatne até

é demais, dados

relevantes

p r a a r a

caramba

Controle & InstrumentaçãoNº 165 | 2011

Figura 7 – Exemplo de Smart Grid e seus componentes de software e hardware.

Uma grade inteligente permite aos consumidores de ener-gia consultar seu consumo em tempo real, sem ter de esperar a conta ao final do mês. Isso possibilita um controle maior sobre a utilização da energia em residências e escritórios, trazendo a possibilidade de planejar um escalonamento de carga e de utili-zação de equipamentos, além de permitir a estimativa da conta de energia que deverá ser paga ao final do mês [Fig. 8 e 9].

Um Smart Grid também poderia permitir, por exemplo, que um pequeno fornecedor de energia (eólica, solar ou outro tipo de geração local) pudesse adicionar sua energia no siste-ma e vender a eletricidade excedente para a rede nacional.

Figura 8 – Smart Grid: exemplo de visualização de dados sobre consumo e demanda.

Figura 9 – Smart Grid: exemplo de visualização de dados sobre consumo [Fonte: iLink Systems].

ConclusãoO ambiente de automação tem utilizado cada vez mais

as tecnologias e os conceitos provenientes do universo de TI. Sem dúvida, softwares de TA e soluções de TI caminham para a mesma direção. Algumas soluções são adequadas aos dois ambientes desde seu surgimento. Em praticamente todas as demais, nota-se que o tempo entre o surgimento de uma nova tecnologia em TI e sua adaptação ao mundo de TA tem sido reduzido rapidamente.

Como visto, SOA é um modelo conceitual de arquite-tura, ou seja, não é uma ferramenta de desenvolvimento, ou um produto de software que se compra. SOA é um pa-radigma, um estilo de desenvolvimento largamente utiliza-do para sistemas distribuídos de grande porte. Portanto, a forma como o SOA é implementado depende apenas do gerenciamento de TI da empresa ou de um projeto, que vai determinar a infra-estrutura e a arquitetura que melhor se adaptarão às suas necessidades de negócios.

Vale ressaltar que SOA não é simplesmente uma questão de implantação de novas tecnologias e interfaces de serviços para construção de aplicações existentes; em geral, pode ser exigida a reformulação de todo o conjunto de aplicativos da empresa. Isso requer uma enorme mudança na operação do sistema e exige que a implementação da nova arquitetura seja muito bem justificada e largamente planejada.

Como foi visto, a utilização de SOA pode facilitar e tornar efetiva a criação de sistemas complexos, tais como a aplicação de Smart Grid em elétrica, Cadeia de Forneci-mento (Supply Chain), Gerenciamento de Ativos Industriais (Asset Management), entre outros sistemas.

Quando devidamente implementado, SOA traz bene-fícios aos seus usuários ao possibilitar a representação de um sistema através de serviços, que podem ser utilizados por aplicações diferentes através de interfaces bem defini-das, legíveis do ponto de vista dos negócios e independente da plataforma de desenvolvimento das aplicações. Afinal, interoperabilidade, reuso, flexibilidade e baixo acoplamen-to são características valiosas em qualquer ambiente.

Referências[1] MESA International, IBM Corporation e Capgemini. SOA in Manufac-

turing Guidebook - White Paper 27. Maio, 2008.[2] IBM Corporation. Patterns: Implementing an SOA Using an Enterprise

Service Bus. Julho, 2004.[3] GE Intelligent Platforms. Proficy SOA. Página visitada em 23 de feve-

reiro de 2011. [http://www.ge-ip.com/pt/products/2808/][4] SmartGrid.gov. Smart Grid Basics and Benefits. Página visitada em 20

de fevereiro de 2011. [http://www.smartgrid.gov][5] Eduardo Vieira. SOA – Eu realmente preciso disso? Página visitada em 25 de

fevereiro de 2011. [http://evieira.wordpress.com/category/arquitetura/][6] Workflow Management Coalition. Página visitada em 20 de maio de

2010. [http://www.wfmc.org][7] SOA Working Group of The Open Group. Definition of SOA. Página

visitada em 26 de maio de 2010. [http://opengroup.org/projects/soa/doc.tpl?gdid=10632]

[8] OASIS. Reference Model for Service Oriented Architecture 1.0. Página visitada em 26 de maio de 2010. [http://www.oasis-open.org/commit-tees/download.php/19679/soa-rm-cs.pdf]

[9] Boris Lublinsky, IBM Corporation. Defining SOA as an architectural style. Página visitada em 26 de maio de 2010. [http://www.ibm.com/developerworks/library/ar-soastyle/]

[10] Chris Harding, The Open Group. Achieving Business Agility through Model-Driven SOA. Página visitada em 26 de maio de 2010. [http://www.ebizq.net/topics/soa/features/6639.html]