Algumas questões relacionadas a segurança SOA – Parte II

Existem dois caminhos para se implementar segurança em um ambiente SOA, um, utilizando Transpost-Level Security, também conhecido por TLS/SSL e outro através de Message-Level Security, padrão de segurança definido pela OASIS para segurança de web services.

Transport-Level Security/ Secure Socket Layer

TLS/SSL são protocolos de segurança que atuam sobre conexões TCP. TLS/SSL garantem a confiabilidade e  integridade dos dados além da autenticação, não se preocupando com  o meio utilizado para transporte das informações, independente do protocolo utilizado (http, smtp, rmi, etc).

Através do TLS/SSL,  um canal é estabelecido entre o consumidor e o servidor, garantindo a segurança das informações, feita através de um processo de criptografia dos dados (todos os dados transmitidos), garantindo assim que as informações não sejam capturadas durante o transporte, evitando possíveis adulterações durante a comunicação, enquanto este “canal” estiver ativo.

Com o TLS, podemos trabalhar com um conjunto de portas diferentes e seu algoritmo de criptografia permite trabalhar com HMAC (Keyed-Hashing For Message Authentication Code)  RFC 1024 que é um código de criptografia mais “forte” que o utilizado pelo SSL MAC (Message Authentication Code) RFC 2104.

Message-Level Security

Como exemplo de Message-Level Security, temos o Web Service Security (WSS), padrão OASIS para segurança de web services. Ao contrário do TLS/SSL que faz a criptografia de todas as informações que estão sendo transmitidas, o Message-Level Security, permite que somente parte das informações sejam criptografadas. Por exemplo, em uma operação de compra com cartão de crédito, poderíamos criptografar somente as informações relacionadas a identificação do cliente, como por exemplo o número do cartão de crédito, deixando as demais informações, por exemplo, o que está sendo comprado não criptografado.

Abaixo, temos visualmente as diferenças entre as abordagens de segurança Transport-Level Security e Message-Level Security

Com o Transport-Level Security, as informações serão completamente criptografadas e transmitidas.

Com o Message-Level Security, podemos definir qual parte da mensagem será criptografada.

Fonte das imagens : http://gdp.globus.org/gt4-tutorial/multiplehtml/ch10s02.html

OASIS WSS - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

Em breve, publicar como implementamos WSS em um ambiente SOA com Oracle Service Bus.

Twitter @javalittle

Linkedin -http://br.linkedin.com/pub/jos%C3%A9-renato-pequeno/28/524/244

Algumas questões relacionadas a segurança SOA – Parte I

Existem diversas tópicos que devemos abordar e nos preocupar quando nos deparamos com o assunto relacionado a segurança de aplicações.  Não existe uma lista obrigatória de itens a serem seguidos, porque cada aplicação e ambiente, por possuírem características diferentes, possuem também necessidades distintas relacionadas a segurança.

Abaixo, vou procurar relacionar alguns itens que acredito serem preocupações comuns a todos analistas e arquitetos envolvidos com segurança de aplicações, também relacionados a segurança SOA.

Confidencialidade das Informações -  Em um ambiente SOA, todas as mensagens que são trocadas, devem ser criptografadas por algum algoritmo, impedindo assim acesso não autorizado das informações que estão sendo trafegadas pela rede ou que estejam de alguma forma sendo persistidas ou manipuladas.

Integridade das Informações – Em um ambiente SOA, a integridade das informações deve ser suportada, impedindo que as informações possam ser alteradas. Essa integridade é garantida através de uma assinatura digital, que permite que as partes envolvidas possam verificar o conteúdo que está sendo transmitido e/ou recebido, avaliando se algo ao longo do percurso foi alterado/modificado de forma não autorizada.

Controle de Acesso as Informações – Em um ambiente SOA, muitos serviços são disponibilizados, serviços estes que serão consumidos por clientes. Uma boa prática é o estabelecimento de políticas de acesso, que são aplicadas aos serviços, impedindo ou restringindo assim os serviços a clientes específicos. Estas políticas também podem ser referenciadas como “Access Control Lists (ACLs).

Auditoria -  Um fator muito importante em um ambiente SOA, é o da implementação de “boas praticas” relacionadas a auditoria, permitindo assim que levantamentos sejam feitos em logs no sentido de detectar possíveis tentativas de fraudes relacionadas com as operações das aplicações. Eu particularmente trabalhei em uma multinacional americana,  auditada pela Sarbanes-Oxley Act (SOX),  empresa esta que constantemente era auditada, sendo a questão segurança,  item mandatório em todas a operações onde houvesse troca de informações, principalmente informações relacionadas a terceiros.

Privacidade das Informações – Muitas empresas, trocam informações confidenciais relacionadas por exemplo a consumidores. Por exemplo, uma concessionária, pode através de um serviços, solicitar e/ou enviar informações de um determinado cliente. Estas informações podem conter por exemplo, número do CPF, CNPJ, cartão de crédito, endereço, enfim, uma série de informações que devem ser confidenciais as empresas envolvidas em uma determinada transação. Em outros casos, pode-se solicitar e ou enviar comportamento de compra e/ou venda de um determinado cliente, e em alguns casos essas informações devem e podem ser mantidas como anônimas. Um ambiente SOA, deve possuir práticas que permita que as informações classificadas e/ou relacionadas como privativas, não seja acessada ou disponibilizada para pessoas/empresas erradas.

Autenticação – Uma outra questão em um ambiente orientado a mensagens, é o de estabelecer entre o consumidor e o servidor, uma forma de identificação e autorização (implementada pela política) das operações que estão sendo processadas. O consumidor ao enviar uma solicitação/mensagem ao servidor, envia uma “identificação”, provando sua identidade, que será recebida e verificada por um servidor de autenticação.

É claro que existe uma série de outras questões que devem ser levantadas e planejadas em um ambiente envolvendo troca de informações entre aplicações.

No próximo tópico, pretendo falar um pouco sobre “Message-Leve Security” e “Transport-Level Security”.

Abraços.

Twitter    - @javalittle

Linkedin - http://www.linkedin.com/pub/jos%C3%A9-renato-pequeno/28/524/244

Por que utilizar um Enterprise Service Bus e como não utilizá-lo

Ao longo de alguns treinamentos que tenho participado e/ou ministrado, tenho percebido que muitas empresas e muitas pessoas não têm a menor noção sobre qual é a importância do um "Enterprise Service Bus".

Trabalhei em uma empresa que de uma hora para outra, resolveu partir para o 1o. projeto SOA, e erroneamente, primeiro definiram que precisariam de um ESB.

Começaram então, a desenvolver um monte de webservices, sem critério algum, e a criar um monte de proxy para cada webservice. Não preciso nem falar que esse projeto foi por água abaixo.

A impressão que eu tenho é que o web service, virou a solução mágica para todos os problemas de TI, e que utilizar o ESB, entre outras coisas vai deixar a aplicação seja ela qual for extremamente rápida, ledo engano.

Estive recentemente em um projeto onde todos os EJB´s (Session Beans Stateless) são anotados como webservices e consumidos por um ESB. Vi lá, EJB´s/webservices para consultar combustível, sexo,

relatórios síncronos e outros absurdos mais.

Quando me deparei com isso, me questionei :

1. Realmente estes EJB´s devem ser anotados como web services para serem consumidos internamente?

2. Será que as pessoas esqueceram que um EJB pode ser utilizado remotamente?

3. Por que devo colocar este EJB/web service em um ESB?

4. Este EJB/webservice possui agora um intermediário, o ESB, será que isso é realmente necessário?

5. Será que um relatório seja lá do que for, deve ser gerado por um webservice síncrono plugado em um ESB?

A impressão que tenho é que quando surgiu o web service, tudo tinha que ser escrito como web service, e isso é um grande absurdo. Acredito que a mesma coisa aconteceu quando os EJB´s surgiram, todo mundo começou a utilizar os EJB´s sem o menor critério.

Um Enterprise Service Bus, seja lá qual for, deve ser utilizado quando temos as seguintes necessidades:

1a. As aplicações devem por algum motivo possuir um mediador que deve atuar entre os serviços oferecendo funcionalidades.

2a. Localização Transparente de Serviços :

Um "Enterprise Service Bus"   tem que agir como proxy para muitos "endpoints" para um mesmo serviço,  possibilitando que um mesmo serviço possa estar ativo em várias máquinas, realizando o balanceamento de carga entre os  possíveis servidores. Essa característica, permite que os webservices possam ser alterados sem que os clientes sofram  alterações.

3a. Agregação de Serviços :

Um "Enterprise Service Bus", atua com dois conceitos fundamentais : Proxy Services e Business Services.

Proxy Services são os serviços publicados no Enterprise Service Bus.

Business Services representam serviços que são externos ao Enterprise Service Bus.

Um serviço configurado em um "Proxy Service", pode utilizar vários "Business Services", agregando lógica adicional ao serviço que está sendo executado.

4a. Camada de Abstração de Serviços :

Um "Enterprise Service Bus", permite que seja criada uma camada de abstração entre os clientes e provedores. Isso permite que integrações sejam feitas através de transformações, possibilitanto a modificação de documentos XML´s, criando-se assim uma camada de abstração entre os clientes e provedores.

5a. Localização centralizada de log e monitoramento de métricas :

Um "Enterprise Service Bus", oferece mecanismos centralizados de log, permitindo através de métricas estabelecer SLA´s sobre os serviços, medindo sua performance. Essas métricas podem ser trabalhadas através de monitoramentos estatísticos obtidos através de relatórios que são fornecidos através de ferramentas disponibilizadas pelo ESB.

6a. Localização centralizada de políticas de segurança :

Um "Enterprise Service Bus", atua de forma centralizada como uma plataforma para o fornecimento de políticas de segurança aos seus serviços.

São estas as características que tornam essencial a utilização de um ESB.

Infelizmente muitas empresas não utilizam o ESB da forma correta, utilizando-o somente como um proxy para consumo de serviços.

Espero de alguma forma ter ajudado.

Abraços.

Códigos e Status HTTP

No TDC 2011, na trilha SOA, ouvi do Fernando Ribeiro a seguinte frase:

“Existe uma verdadeira legião que não sabe o significado das mensagens ou status do http”.

Como docente, e instrutor ao longo destes 21 anos, fiquei pensando:

“Acho que também sou culpado por essa falta de conhecimento. Afinal de contas, eu ministrei aula para várias pessoas sobre programação para a web e nunca toquei neste assunto”.

Essa postagem, é uma tentative de concertar esse meu erro.

Códigos de Informação:

Estes códigos, estão relacionados com uma resposta provisória do servidor, indicando aos usuários que eles realizem ou prossigam com uma nova solicitação.

Código	Descrição
100	O usuário deve continuar com a solicitação, os servidores apresentam este código indicando que conseguiram receber a solicitação e que está esperando uma nova interação do usuário. Geralmente a mensagem abaixo é apresentada : The request was successful. The process can now continue.
101	O usuário fez uma solicitação fizesse uma mudança de protocol e o servidor respondeu que recebeu a solicitação e que a está executando. Como por exemplo, a troca de FTP para http. Geralmente a mensagem abaixo é apresentada : The request for server to switch protocols was accepted.

Códigos de sucesso:

Estes códigos indicam que o servidor foi capaz de executar a solicitação do usuário com sucesso.

Código	Descrição
200	O usuário fez uma solicitação ao servidor e o servidor conseguiu executar esta solicitação com sucesso. Por exemplo, o usuário solicitou a execução de uma página e o servidor conseguiu devolver a página como resposta. Geralmente a mensagem abaixo é apresentada : The item requested of the server is available
201	O usuário solicitou ao servidor que algum recurso fosse criado e a solicitação foi aceita pela servidor. Geralmente a mensagem abaixo é apresentada : A new resource has been created through the use of form posting.
202	O servidor está informando que a solicitação feita pelo usuário foi aceita, mas ainda não foi processada e que ainda não está completa. Geralmente a mensagem abaixo é apresentada : The request has been accepted (Keep in mind that the request has been accepted, not completed).
203	O servidor está indicando que recebeu a solicitação, que processou com sucesso e que está informando que está retornando informações que podem estar relacionadas a outras fontes. Geralmente a mensagem abaixo é apresentada: The information received is not from the server that the information was requested from, but from another source.
204	O servidor está indicando que recebeu a solicitação com sucesso e que não está retornando nunhum conteúdo ao usuário solicitante. Geralmente a mensagem abaixo é apresentada: There was no content to be given for the request. For instance if you click on a hyperlink, imagemap, or button that isn’t linked to anything or doesn’t do anything.
205	Idêntico ao código 204, a única diferença está na solicitação do servidor para o usuário reconfigurar o modo de exibição do documento. Geralmente a mensagem abaixo é apresentada: A script has reset the displayed content.
206	O servidor está informando que recebeu uma solicitação GET e que a processou parcialmente com sucesso. Geralmente a mensagem abaixo é apresentada: Only partial content has benn displayed. This could be due to bandwidth, poor caching, bad html, or other reasons.

Códigos de redirecionamento:

Estes códigos estão relacionados a redirecionamentos, sendo uma ação adicional necessária para completer uma determinada solicitação.

Código	Descrição
300	O servidor está informando que possui mais de uma ação disponível e que pode se basear em um user-agent ou enviar uma lista para que o usuário possa escolher a ação que deverá ser executada. Geralmente a mensagem abaixo é apresentada: You will either get a choice of pages or an error message when this occurs. The address is actually pointing to two multiple files and/or locations.
301	Isso indica que a página solicitada pelo usuário através de um get ou head foi transferida ou movida permanentemente para um novo local, redirecionando automaticamente a solicitação para o novo local. Geralmente a mensagem abaixo é apresentada: The requested page has been permanently moved. The server will automatically redirect you to the new location.
302	Semelhante ao código 301 relacionado a solicitação get e head redirecionando a solicitação para um outro local. A diferença é que o usuário deve continuar a fazer a solicitação através do local original. Geralmente a mensagem abaixo é apresentada: The requested page has been temporarily moved. The server will automatically redirect you to the new location.
303	O servidor está informando ao usuário que fez a solicitação que ele vai precisar fazer uma nova solicitação get para um outro local, obtendo assim uma resposta. Geralmente a mensagem abaixo é apresentada: The requested data is stored in an alternate location and the get method will be used to retrieve the data. If the actual error is returned then this may be due to a web server misconfiguration.
304	O servidor está informando ao usuário que fez a solicitação que o recurso solicitado não foi modificado desde a última solicitação. Geralmente a mensagem abaixo é apresentada: The requested data has not been modified since the last request.
305	O servidor está informando ao usuário que sua solicitação deverá ser feita através de um proxy. Geralmente a mensagem abaixo é apresentada: The requested data may only be accessed via the use of a proxy server.
307	Semelhante ao código 301, podem esse código indica que o redireciomanento é temporário e que o usuário deverá continuar usando o local original. Geralmente a mensagem abaixo é apresentada: The requested page has been moved. The server will automatically redirect you to the new location. Unlike Error 301 and 302 however, the server has not specified whether the move is temporary or permanent.

Códigos relacionados a solicitação:

Estes códigos estão relacionados as solicitações dos clientes indicando que provavelmente um erro na solicitação ocorreu independo assim que o servidor processasse a solicitação.

Código	Descrição
400	O servidor recebeu uma solicitação do usuário, mas não foi capaz de resolvê-la, provavelmente por uma questão relacionada a sintaxe errada. Geralmente a mensagem abaixo é apresentada: The request was denied due to a syntax error in the request.
401	O usuário fez uma solicitação ao servidor que necessita de uma autenticação. O servidor pode retornar uma página de login. Geralmente a mensagem abaixo é apresentada: Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data.
403	O servidor está informando que recusou a solicitação feita pelo usuário. Pode ser por uma questão de segurança e autorização. Geralmente a mensagem abaixo é apresentada: Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data. OR The server was unable to serve the data that was requested.
404	O servidor não encontrou uma resposta para a solicitação feita pelo usuário. Geralmente a mensagem abaixo é apresentada: The document that has been requested either no longer exists, or has never existed on the server.
405	O método utilizado pelo usuário na solicitação não é autorizado ou permitido pelo servidor. Geralmente a mensagem abaixo é apresentada: The method you are using to access the document is not allowed. Possible methods include: CONNECT DELETE GET HEAD OPTIONS POST PUT TRACE
406	O servidor não pode responder a uma solicitação com as características de conteúdo informadas solicitadas. Geralmente a mensagem abaixo é apresentada: The client (webbrowser) does not accept the document format. The formats that may be specified not to accept are charset, encoding, certain file types, languages, or ranges.
407	Semelhante ao código 401, identificando que o usuário deverá fazer uma nova solicitação e se autenticar usando um proxy. Geralmente a mensagem abaixo é apresentada: The browser has not been authenticated on the required proxy server to access the data. This error is probably most commonly returned by content filters/parental controls.
408	O servidor está informando ao usuário que o tempo limite ao aguardar por uma solicitação, atingiu o limite. Geralmente a mensagem abaixo é apresentada: The server has closed the socket due to communications between the client and server taking too long. This could be due to server load, bandwidth issues, the client being disconnected from the internet, etc.
409	O usuário fez uma solicitação e o servidor encontrou um conflito na execução da solicitação. O servidor vai incluir informações relacionadas ao conflito na resposta que será enviada ao usuário. Geralmente a mensagem abaixo é apresentada: Too many requests for the same file at one time. OR There is a conflict with an established software rule. (ie: you are trying to copy over a file with an older version, or you do not have permissions to delete a file) OR This could be caused by a DNS issue.
410	O usuário fez uma solicitação ao servidor e de um recurso removido permanentemente. Geralmente a mensagem abaixo é apresentada: his is like a 404 error in that the document requested is not on the server, however this differs in that the server 'knows' that the file used to be there and 'believes' that the file may be back, so it returns 410 rather 404.
411	A solicitação feita pelo usuário ao servidor, não possui no cabeçalho um comprimento de conteúdo válido. Geralmente a mensagem abaixo é apresentada: When trying to send a document to the server the server did not recieve a Content-Length specification in the header.
412	O usuário ao fazer uma solicitação de um recurso no servidor, informou algumas pré-condições que não são capazes de ser cumpridas pelo servidor. Geralmente a mensagem abaixo é apresentada: A precondition setting required by the client or server has not been met.
413	O usuário fez uma solicitação ao servidor porem o servidor não poderá responder porque a solicitação feita foi muito grande. Geralmente a mensagem abaixo é apresentada: The process is too large to process. (ie: a file you are trying to upload is too large to fit on the server, or a webpage you are trying to download is too large for the server to process)
414	O usuário ao solicitar um recurso ao seridor, informou uma URI solicitado (geralmente um URL) muito longa para ser processada pelo servidor. Geralmente a mensagem abaixo é apresentada: The URL requested is simply too long. It is most likely more than 1024, 2048, or 4096 characters in length.
415	O usuário solicitou ao servidor um recurso em um formato não compatível. Geralmente a mensagem abaixo é apresentada: This usually occurs if the server does not support the type of media the client is requesting. (ie: the server does not support streaming media, but streaming media is on the server and the client is attempting to access it)
416	O usuário fez a solicitação de um recurso ao servidor de uma faixa não disponível para ser retornada. Geralmente a mensagem abaixo é apresentada: The client request included a range for acceptable file size, however the document requested did not fit into that range.
417	A solicitação feita ao servidor,não pode ser cumprida porque os requisitos do campo "Expectativa" do cabeçalho da solicitação. Geralmente a mensagem abaixo é apresentada: The client's expect header requested certain server behaviors that the server could not perform.

Códigos de erro no servidor:

Estes códigos estão relacionados a possíveis erros do servidor ao tentar processor uma solicitação feita por um usuário.

Código	Descrição
500	Por algum motivo, o servidor encontrou um erro e não foi capaz de gerar uma resposta ao usuário. Geralmente a mensagem abaixo é apresentada: The server encountered an error. This is most often caused by a scripting problem, a failed database access attempt, or other similar reasons.
501	O usuário fez uma solicitação ao servidor que não  tem o recurso necessário para completar a solicitação. Geralmente a mensagem abaixo é apresentada: The method you are using to access the document can not be performed by the server. Possible methods include: CONNECT DELETE GET HEAD OPTIONS POST PUT TRACE
502	O servidor que recebeu a solicitação do usuário opera com um gateway ou proxy e recebeu uma respost inválida de um servidor acima. Geralmente a mensagem abaixo é apresentada: The document requested resides on a 3rd party server and the original server received an error from the 3rd party server.
503	O usuário fez uma solicitação ao servidor que por algum motive está indisponível, ou não está conseguindo responder a solicitações por sobrecarga ou inatividade. Geralmente a mensagem abaixo é apresentada: The server is overloaded or down for maintenance and due to this was unable to process the client request.
504	O usuário fez uma solicitação a um servidor que opera como um gateway ou como proxy que não recebeu a tempo uma solicitação de seu servidor superior. Geralmente a mensagem abaixo é apresentada: Most likely the client has lost connectivity (disconnected from the internet) or the cleint's host is having technical difficulties. This could also mean that a server that allows access to the requested server is down, having bandwidth/load issues, or otherwise unavailable.
505	O usuário fez uma solicitação ao servidor através de uma versão do protocol HTTP incompatível. O servidor não é compatível com a versão do protocolo HTTP usada na solicitação. Geralmente a mensagem abaixo é apresentada: The server does not support the HTTP version used by the client. (This usually occurs if the server is using an OLDER version of HTTP than the client.)

Espero que estas informações sejam bem utilizadas por todos que desenvolvem ou pretendem desenvolver para web.

Twitter @javalittle

Linkedin http://br.linkedin.com/pub/jos%C3%A9-renato-pequeno/28/524/244

http://www.soaexpert.com.br




 

O que é SOA?

SOA

Arquitetura Orientada a Serviços

                                                            O que é isso?

Antes de tentar responder esta pergunta, vou definer o que SOA não é.

SOA, não é :

1.     Uma nova tecnologia.

2.     Um novo framework de desenvolvimento.

3.     Integração entre aplicações.

4.     Webservices

5.     Técnica para deixar uma aplicação mais rápida

 Segundo Thomas Erl, SOA é

“Uma abordagem arquitetural de TI dirigida a negócios que suporta a integração de sistemas como tarefas de negócio ou serviços conectáveis e repetitivos. SOA ajuda hoje as empresas a inovar graças a garantia de que os sistemas de TI podem se adaptar rápido, fácil e economicamente para permitir rápidas mudanças nas necessecidades da empresa. Ela aumenta a flexibilidade dos processos de negócio, fortalecendo a infra-estrutura presente e reusando os investimentos já feitos na área de TI, criando conexões entre aplicações e fontes de informação que apresentam muita diferença entre si.”

Thomas Erl, usa em sua explicação termos importantes, como :

1.     Integração de sistemas

2.     Adaptação de sistemas

3.     Rápidas mudanças

4.     Fortalecimento da infra-estrutura

5.     Reúso de investimentos já feitos

6.     Conexões entre aplicações

Eu acredito que para se ter uma exata compreenção sobre a definição do Thomas Erl, com os termos acima, devemos analisar primeiro como ao longo dos anos, as empresas adotaram TI.

Eu iniciei na área de desenvolvimento de software em 1989. Iniciei como programador júnior em uma software house, desenvolvendo programas em cobol.

Nesta época, a grande maiorina das empresas, se quer, tinha computador. Suas operações eram manuais, e as empresas necessitavam de muitas pessoas para executarem seus procedimentos internos.

Imaginem uma empresa, que em média emitia 100 notas fiscais diariamente. Essa empresa com certeza necessitava de muitas pessoas trabalhando em seu setor de faturamento, datilografrando notas fiscais.

Quando a software house que eu trabalhava, vendia um sistema de faturamento, inevitavelmente duas coisas aconteciam na empresa:

1a. A emissão de notas fiscais, ficou extremamente mais rápido, era somente necessário um cadastro das informações das notas fiscais e a emissão das mesmas.

2a. Muitas pessoas foram demitidas (sim, a área de TI causou e ainda é responsável pela demissão de muitas pessoas)

Nesta época, a tecnologia da informação (TI) oferecia agilidade de operações internas nas empresas.

Essa “agilidade de operações internas”, durante alguns anos, representou um ganho para as empresas que acabaram sob alguns aspectos da época, sendo eficazes e eficientes operacionalmente, obtendo com isso, vantagem competitiva.

É obvio, que com o passas dos anos, essa vantagem competitiva deixou de existir, porque outas empresas também passaram a utilizar a tecnologia da informação para dar agilidade em suas operações operacionais.

Com a ampla utilização da internet, isso em meados dos anos 90, as empresas para terem vantagem competitiva, se valeram da tecnologia da informação (TI) para se exporem ao mundo, através de sites e ai surgiram os B2B, B2C, etc.

Me lembro de um fato muito marcante desta época, só não tenho certeza qual montadora de automóveis foi, se foi a Ford ou a GM, mas uma delas, permitiu que seus clientes pudessem comprar um veículo através da internet. Me lembro que faziamos um cadastro e podiamos escolher o carro, os opicionais, a cor e até mesmo selecionar a forma de pagamento.

Neste momento, as empresas descobriram que a tecnologia da informação (TI) não só deveria ser utilizada para dar agilidade em operações internas, mas que TI deveria ser utilizada para também dar agilidade em operações de negócios.

E ai, segundo o que eu entendo, a confusão começou. Todas as empresas começaram a solicitar a TI o desenvolvimento de aplicações para no “momento” oferecer a empresa “agilidade em operações de negócios”.

Com o passas dos anos, e estamos agora em 2011, “o momento” fez com que as empresas tivessem várias aplicações para diversos propósitos com muitas funcionalidades praticamente idênticas.

Eu trabalhei em uma multinacional, na área de análise e desenvolvimento de sistemas (ADS), especificamente no setor de Marketing e Vendas. Neste setor, posso dizer que tinhamos muitas aplicações com muitas funcionalidades idênticas, aplicações praticamente com o mesmo propósito, mudando apenas o que chamávamos de política comercial.

O que fez com que estas aplicações fossem desenvolvidas, acredito eu que o “momento” fez. Acredito também que a falta de conhecimento sobre as aplicações, sobre as funcionalidades fez com que estas aplicações fossem desenvolvidas.

Com as muitas aplicações, começaram as integrações feitas de várias maneiras: tabelas, procedures, arquivos texto, etc.

Muitas vezes o “momento” fazia alguém de Marketing e Vendas ir até a área de ADS para solicitar uma nova funcionalidade ou um novo aplicativo que iria já na próxima semana alavancar uma ação de marketing para alavancar uma operação de negócio.

Neste momento, quem desenvolve software sabe que um abismo existe entre o “usuário e os analistas”.  O usuário quer uma alteração e realmente acredita que pode ser feita de forma rápida. O analista sabe que a alteração solicitada pelo usuário no mínimo vai levar algumas semanas para ser feita, isso sem falar que esta alteração poderá afetar outras aplicações, aplicações inclusive que talvez o analista desconheça.

Eu já vi, e já participei de projetos que foram solicitados pelos usuários e que quando foram implantados, já não correspondiam ao “momento”, ou seja, já não representava ou não oferecia vantagem competitiva e se quer foram utilizados.

Já participei de projetos que alteravam funcionalidades idênticas em mais de uma aplicação, desenvolvidas inclusive em mais de uma plataforma, no caso, asp, java e cobol.

Essa “demora” da área de TI em attender a área usuária, causa um certo stress entre as áreas. Os usuário leigos dos procedimentos relacionadas ao desenvolvimento e análise de sistemas, acreditam pela grande gama de aplicações que utilizam que o que eles estão solicitando é simples. Segundo eles, é só pegar uma informação de um aplicativos, juntar com a informação de um outro aplicativo e pronto, o que ele necessita já está pronto.

Isso seria ideal se as empresas tivessem seus aplicativos desenvolvidos de forma coerente, com funcionalidades como serviços, possuino um inventário evitando assim redundância de funcionalidades.

Sendo assim, SOA surge como uma nova abordagem para a utilização dos recursos de TI em apoio ao negócio da organização, permitindo a TI:

1.     Alavancar recursos existentes.

2.     Criar novos recursos de forma coerente para serem melhor reutilizados.

3.     Facilmente atender as inevitáveis alterações exigidas para suportar o negócio.

Com uma arquitetura orientada a serviços, podemos avaliar a solicitação da área usuária e com um inventário de serviços através da orquestração entre funcionalidades de aplicações distintas e heterogêneas expostas como serviços, resolver a nova solicitação.

Uma arquitetura orientada a serviços deve ser “vendida” em uma empresa, não como uma fórmula milagrosa, que vai deixar as aplicações mais rápidas, infelizmente é isso que muitos gestores pensam.

Ao sair da multinacional, fui trabalhar em um banco em um projeto “SOA”. Lá, “SOA” foi vendido ao gestor como uma solução mágica que permitiria que uma aplicação X ficasse rápida. Essa abordagem errada, faz com que muitas empresas desistam ou facassem na implementação de SOA.

Um grande esforço deverá ser feito para “ajustar” operações como serviços, para se criar um inventário evitando redundância de operações.

Esses foram meus argumentos, embasados em minha experiência profissional, para tentar justificar os temos utilizados por Thomas Erl para sua explicação sobre o que é SOA.

Segundo Thomas Erl, a chave para ser bem sucedido na implementação da arquitetura orientada a serviços esta em compreender o significado e a importância de seu bloco de construção mais importante: “o serviço”.

SOA não é webservice que é amplamente utilizado como serviços expostos e consumidos de forma síncrona e assincrona pelas empresas.

A plataforma de tecnologia mais utilizada para a realização de SOA, é a utilização de webservices.

E o que são os webservices?

Segundo Tanenbaum, os webservices classificam-se como sistemas distribuídos que podem aparentar para o usuário que são parte de apenas um sistema hospedado em um único computador, mas podem estar em diversos computadores independentes.

A utilização de sistemas distribuídos não é nova para nós. Ao longo dos anos, utilizamos RMI, Corba, DCom, como soluções para o desenvolvimento distribuído.

Essas abordagens apresentam divesos problemas e incompatibilidades como:

1.     Dependência de linguagem de programação ou S.O.

2.     Modelo de objetos e passagem de mensagens dependentes de fabricantes

Com os webservices, resolvem-se estes problemas e estas incompatibilidades através da independência de plataforma, SOAP permitindo assim a utilização da infra-estrutura já existente na empresa.

Como um guia para a compreenção de “serviços”, para a implementação de SOA, existem 8 princípios de design que devemos estudar e aplicar.

1.     Contratos

2.     Acoplamento

3.     Abstração

4.     Capacidade de reúso

5.     Autonomia

6.     Independência de estado

7.     Visibilidade

8.     Composição

Bom, este foi minha primeira postagem do blog. Espero que minhas explicações sejam coerentes e que de certa forma tenha ajudado alguém na compreenção sobre o que vem a ser SOA.

Minha próxima postagem será sobre os 8 princípios de design.

Abraços.

Pequeno

 Fontes Utilizadas no texto:

Livros : 

SOA Princípios de Desgin de Servicos - Pearson

SOA na Prática - Novatec

SOA Fundamentos e Estratégias - Editora Ciência Moderna

Material soa|expert :

SOA Foundation Classic and Next Generation

Twitter @javalittle

Linkedin http://br.linkedin.com/pub/jos%C3%A9-renato-pequeno/28/524/244

http://www.soaexpert.com.br