Por COMPUTERWORLD

É preciso planejar os serviços

“Se você não tem um plano para cada serviço que será criado, e também uma ordem para eles, como coordenar as atividades e usar um conjunto de padrões, filosofias e abordagens, você vai terminar com a mesma confusão de um espaguete de serviços que nós vemos em todas as outras abordagens”, diz Paras.

O SOA, segundo DeBoever, incorporou os esforços em direção ao reuso desenvolvidos nos anos 90, incluindo COM, DECOM, CORBA e tecnologias de objeto como o Object Request Broker. A arquitetura adicionou novos padrões para definir tanto os serviços como os objetos repositórios e os métodos para descobrir quais serviços estão disponíveis entre os que foram mais debatidos no final dos anos 90.

Também foi optado por padrões de internet (HTTP, XML, SOAP) para definir um padrão de serviços de mensagens, outro principal bloco decadente que antes atendia à reutilização. Aqui, afirma Paras, é onde está a confusão originada entre o SOA e a web.

Muitas pessoas acreditam que o SOA envolve o uso de objetos que residem na internet, mas apesar de os desenvolvedores usarem funcionalidades sobre a web, eles podem igualmente construir suas aplicações exclusivamente a partir de objetos que residem dentro de firewalls corporativos ou até mesmo em um servidor único.

Também foi adicionado o padrão Business Process Execution Language (BPEL) para definir como os serviços são reunidos, outra questão da tecnologia orientada ao objeto. O que ainda não foi resolvido e pela sua natureza não pode se resolver é o quarto problema que maldiz a orientação ao objeto e outra abordagem anterior para o reuso, interrompendo a mentalidade “não inventado aqui” e desenvolvendo a cultura de reuso.

“A idéia de reuso vai voltar para a primeira linha de código”, acredita DeBoever. “Mas se nós não resolvermos o problema social de ter pessoas envolvidas com a cultura de reuso, o SOA não resolverá o problema. A questão secundária é confiável. Você não reutiliza a menos que confie nos resultados dos serviços que você pode solicitar.”

Isso também não soluciona o problema de gerenciamento do repositório de serviços. “No final do dia, quem diz que é um bom serviço ou que ele não é legal?”, pergunta.

“Esses temas vão dominar a liderança, os processos de governança, e até que nos descubramos, o SOA vai lutar para entregar essa promessa tremenda”, diz DeBoever. A liderança é uma função da arquitetura corporativa.

Outro problema do nível de negócios em SOA é a impressão comum de que todos os componentes em um serviço, da base até o nível de tecnologia, devem por si só serem um serviço. “As pessoas precisam se desvincular dessa idéia”, alerta Paras. Na verdade, para ser um serviço tudo o que é necessário é:

1. Desempenhar as funções que foram designadas para fazer e operar no objeto de serviço;
2. Usar as interfaces padrões de SOA – mensagens, protocolos e formatos – para comunicação;
3. Encontrar um nível de serviço designado que tenha utilidade na corporação

“Desde que você possa abstrair a definição lógica de um serviço, não importa se o serviço é construído com tecnologias que não são web-orientadas a serviços”, diz Paras. “Esta é a distinção de SOA como um design lógico construído para as empresas versus uma construção técnica de serviços web.”

A outra incompreensão vista pela EAdirections em grandes organizações é a tendência de desencorajar o contato entre o EA e os grupos SOA sob a crença de que eles não estão relacionados.

“Na realidade, esses dois grupos precisam ser unificados sob um processo consistente que pode racionalizar sistemas designados contra empresas no contexto de um mecanismo consistente de governança corporativa”, afirma. “Somente depois o SOA pode assegurado de ter lançado seu potencial total de capacitação não só como desenvolvimento rápido de aplicações, mas quanto mais importante é a capacidade da empresa envolver rapidamente com o negócio e a TI movendo para uma única ativação dos objetivos”.