Por que não há linguagem orientada a serviços?

Editar:

Para evitar mais confusão: Estou não falando de serviços web e tal. Estou falando de estruturar aplicativos internamente, não é sobre como os computadores se comunicam. É sobre linguagens de programação, compiladores e como o paradigma de programação imperativa é estendido.

Original:

No campo da programação imperativa, vimos dois paradigmas nos últimos 20 anos (ou mais): orientado a objetos (OO) e orientado a serviços (SO). baseado em componentes (CB).

Ambos os paradigmas estendem o paradigma imperativo de programação, introduzindo sua própria noção de módulos. OO os chama de objetos (e classes) e permite que eles encapsulem dados (campos) e procedimentos (métodos) juntos. O SO, por outro lado, separa os dados (registros, beans, ...) do código (componentes, serviços).

No entanto, apenas o OO possui linguagens de programação que suportam nativamente seu paradigma: Smalltalk, C ++, Java e todos os outros compatíveis com JVM, C # e todos os outros compatíveis com .NET, Python etc.

SO não possui esse idioma nativo. Ele só existe em cima de linguagens procedurais ou linguagens OO: COM / DCOM (binário, C, C ++), CORBA, EJB, Spring, Guice (todo Java), ...

Essas estruturas SO sofrem claramente da falta de suporte à linguagem nativa de seus conceitos.

• Eles começam a usar classes OO para representar serviços e registros. Isso leva a designs nos quais há uma clara distinção entre classes que possuem apenas métodos (serviços) e aquelas que possuem apenas campos (registros). A herança entre serviços ou registros é simulada pela herança de classes. Tecnicamente, não é mantido tão rigorosamente, mas em geral os programadores são aconselhados a fazer aulas para desempenhar apenas um dos dois papéis.
• Eles usam linguagens externas adicionais para representar as partes ausentes: IDLs, configurações XML, anotações no código Java ou mesmo DSL incorporado, como no Guice. Isso é especialmente necessário, mas não limitado a, pois a composição dos serviços não faz parte do próprio código de serviço. No OO, os objetos criam outros objetos, portanto não há necessidade de tais instalações, mas no SO existe porque os serviços não instanciam ou configuram outros serviços.
• Eles estabelecem um efeito de plataforma interna sobre o OO (EJB, CORBA), onde o programador deve escrever todo o código necessário para "dirigir" o SO. As classes representam apenas uma parte da natureza de um serviço e muitas classes precisam ser escritas para formar um serviço juntos. Toda essa placa da caldeira é necessária porque não existe um compilador SO que o faça para o programador. É como algumas pessoas fizeram em C para OO quando não havia C ++. Você apenas passa o registro que contém os dados do objeto como primeiro parâmetro para o procedimento que é o método. Em uma linguagem OO, esse parâmetro está implícito e o compilador produz todo o código que precisamos para funções virtuais etc. Para SO, isso está claramente ausente.
• Especialmente, as estruturas mais recentes usam extensivamente AOP ou introspecção para adicionar as partes ausentes a uma linguagem OO. Isso não traz a expressividade necessária do idioma, mas evita o código da plataforma da caldeira descrito no ponto anterior.
• Algumas estruturas usam a geração de código para produzir o código da placa da caldeira. Arquivos de configuração em XML ou anotações no código OO são a fonte de informações para isso.

Nem todos os fenômenos que mencionei acima podem ser atribuídos ao SO, mas espero que mostre claramente que há uma necessidade de uma linguagem SO. Como esse paradigma é tão popular: por que não existe um? Ou talvez existam alguns acadêmicos, mas pelo menos a indústria não usa um.

Porque <5% do código está realmente definindo um serviço, e eu argumentaria uma quantidade substancialmente menor de tempo. Uma vez que a interface é definida, é feito em grande parte. O resto do tempo é gasto em OO (ou alternativas), fazendo as coisas funcionarem .

Simplificando, não é uma grande vitória criar um idioma especializado para essa pequena fatia do problema. Na verdade, ter dois idiomas (um para o serviço e outro para a implementação / consumo) está apenas pedindo uma complexidade de integração adicional.

[edite para os esclarecimentos dos OPs que é o layout interno do aplicativo, não o limite do aplicativo]:

O principal objetivo de ter esse layout de serviço é ter pontos de contato finos entre os serviços. Meu motivo original ainda é válido (imo) e acrescenta a essa resposta o fato de que relativamente poucos problemas se adaptam bem a uma estrutura interna de aplicativos baseada em serviços. Portanto, você não está apenas abordando uma pequena fatia do problema, mas uma porcentagem menor de problemas em geral.

Linguagens funcionais são muito orientadas a serviços em seu núcleo. Em vez de criar objetos e chamar funções neles, você cria funções e passa mensagens para eles. Erlang é um excelente exemplo dessa técnica porque, além dos aspectos funcionais da linguagem, ela possui comunicação entre processos e até entre máquinas incorporada em sua estrutura principal, permitindo enviar mensagens para um processo remoto como se fosse um processo local. .

Outros idiomas, como Scala, Clojure e F #, também fornecem semântica "orientada a serviços". O problema não é que eles não existem, é que a população em geral tem medo deles e, portanto, eles não são tão populares.

A Orientação ao Serviço foi / é uma resposta arquitetônica para problemas de integração. A integração ideal é uma solução abrangente que se encaixa em qualquer idioma, produto, dispositivo, recurso existente em uma imagem maior.

Não há necessidade de um novo idioma, pois o próprio problema é ter muitos idiomas , o que causa um alto custo de interoperabilidade.

No entanto, houve um tipo de idioma introduzido, o idioma de definição de serviço da web. O WSDL é a meta linguagem da SOA (e há outra abandonada para o REST chamada WADL)

Vou mudar a pergunta e perguntar "como seria uma linguagem SO?"

Como seriam escritos esses contratos entre os módulos?
Como a mecânica fundamental da operação seria executada?

Orientada a serviços é uma propriedade do aplicativo, não necessariamente o idioma usado. O serviço é uma construção que depende de uma função. A função é uma construção que se baseia na mecânica de uma linguagem de programação para converter a operação em instruções executáveis ​​pela máquina.

O BPEL é um exemplo possível de uma linguagem SO, mas é de nível muito alto e depende da disponibilidade de módulos para sua utilização. Esses módulos, por sua vez, são escritos em idiomas não BPEL, para que o trabalho possa ser executado (também conhecido como tradução para linguagem de máquina).

Ótimo Q e me deu um bom momento de reflexão.

Oferecerei uma resposta para minha própria pergunta para ver quantas pessoas concordam e discordam.

Algumas possibilidades:

• Parece ser difícil construir uma linguagem SO. Principalmente devido à separação da implementação de serviços e sua composição. Existem algumas soluções acadêmicas que eu ouvi na universidade (sem referência, desculpe), mas isso não parece entrar no setor. Mas considero isso uma desculpa, não uma razão real. Os idiomas e compiladores OO também são bastante difíceis de implementar, mas há soluções no mercado há muito tempo.

• Os programadores usam linguagens OO para SO, porque não entendem OO e a usam de maneira errada. Eu digo errado, porque existem dois conceitos fundamentais em OO que contradizem SO:

  1. A funcionalidade vai para a classe em que os dados estão localizados nos quais eles trabalham. Código e dados são acoplados no mesmo módulo. Não é estilo OO ter classes separadas que funcionam com os dados de outras classes. Essa é a abordagem de Ferramentas e materiais (WAM) de Züllighofen que corresponde ao paradigma SO.

  2. Objetos criam outros objetos e formam redes de objetos. Eles podem criar hierarquias ou quaisquer relações complexas. Os serviços sempre formam redes planas compostas de fora. Os serviços geralmente têm apenas uma instância (Singleton), enquanto os objetos são instanciados com a frequência da entidade que eles representam. Os registros no SO não estão conectados nas redes.

• Alguns recursos do OO parecem semelhantes ao SO, ou podem ser usados ​​para facilitar o que é necessário para o SO, por isso é útil usar uma linguagem OO.

  1. O princípio de inversão de dependência no OO é semelhante ao modo como os serviços são compostos externamente.

  2. Objetos Singleton são como serviços, fábricas de objetos são como localizadores de serviço.

  3. OO também possui interfaces semelhantes às interfaces de serviço.

  4. A herança de classes pode ser semelhante (a mesma?) Como herança de serviços e registros.

• OO e SO são úteis para diferentes tipos de problemas. Portanto, em todas as aplicações, é tentador usar paradigmas aqui ou ali. Ter um idioma separado dificultaria a alternância entre os dois dentro do mesmo programa.

• O SO não é apenas um paradigma de programação, mas também um comportamento do programa: serviços da Web, componentes do sistema operacional etc. são SO, mas não precisam ser escritos necessariamente em uma linguagem SO. Esse tipo de "componentes binários" é muito natural e bem-sucedido. Mas é uma coisa diferente: é como os programas se comunicam entre si, não como o programa se comunica internamente. Eu acho que as pessoas misturam isso com bastante frequência.