为什么没有面向服务的语言？

编辑：

为了避免进一步的混乱：我不是在谈论Web服务之类的东西。我说的是内部构造应用程序，而不是计算机如何通信。它涉及编程语言，编译器以及命令式编程范例的扩展方式。

原版的：

在命令式编程领域中，我们在过去的20年（或更长的时间）中看到了两种范例：面向对象（OO）和面向服务（SO）。基于组件（CB）。

两种范例都通过引入它们自己的模块概念来扩展命令式编程范例。OO将它们称为对象（和类），并使它们将数据（字段）和过程（方法）封装在一起。相反，SO将数据（记录，bean等）与代码（组件，服务）分离。

但是，只有OO具有本机支持其范例的编程语言：Smalltalk，C ++，Java和所有其他JVM兼容，C＃和所有其他.NET兼容，Python等。

SO没有这样的母语。它仅在过程语言或OO语言之上才存在：COM / DCOM（二进制，C，C ++），CORBA，EJB，Spring，Guice（所有Java），...

这些SO框架显然遭受其概念缺少本地语言支持的困扰。

• 他们开始使用OO类来表示服务和记录。这导致在设计中，仅具有方法的类（服务）与仅具有字段的类（记录）之间存在明显的区别。然后，通过类的继承模拟服务或记录之间的继承。从技术上讲，它并没有那么严格，但是一般来说，建议程序员使类仅扮演两个角色之一。
• 他们使用其他外部语言来表示缺少的部分：IDL，XML配置，Java代码中的注释，甚至像Guice中的嵌入式DSL。由于服务的组成不是服务代码本身的一部分，因此特别需要但不限于此。在OO中，对象创建其他对象，因此不需要此类工具，但是对于SO而言，是因为服务不会实例化或配置其他服务。
• 它们在OO（早期的EJB，CORBA）之上建立了一个内部平台效果，程序员必须在其中编写“驱动” SO所需的所有代码。类仅表示服务性质的一部分，必须编写许多类才能一起形成服务。所有这些样板都是必要的，因为没有SO编译器可以为程序员做。就像有些人在没有C ++的情况下在C for OO中所做的那样。您只需将保存对象数据作为第一个参数的记录传递给作为方法的过程。在OO语言中，此参数是隐式的，并且编译器将生成我们为虚拟功能等所需的所有代码。对于SO，显然没有此功能。
• 特别是较新的框架广泛使用AOP或自省功能将缺少的部分添加到OO语言中。这没有带来必要的语言表达能力，但是避免了上一点中描述的锅炉平台代码。
• 一些框架使用代码生成来产生样板代码。XML的配置文件或OO代码中的注释是此信息的来源。

并非我上面提到的所有现象都可以归因于SO，但我希望它清楚地表明需要使用SO语言。由于这种范例如此流行：为什么不存在一个范例？或者也许有一些学术论文，但至少该行业不使用。

因为少于5％的代码实际上是在定义服务，所以我认为时间要少得多。定义接口后，就可以完成大部分工作。剩下的时间都花在OO（或替代方法）上，以使事情正常进行。

简而言之，为一小部分问题制作专门的语言并不是一个大胜利。如果有的话，使用两种语言（一种用于服务，一种用于实现/使用）正要求增加集成的复杂性。

[编辑操作说明，以确认它是内部应用程序布局，而不是应用程序边界]：

具有这种服务布局的主要目标是在服务之间具有较薄的接触点。我最初的原因仍然成立（imo），并补充了以下事实：相对较少的问题非常适合于基于服务的内部应用程序结构。因此，您不仅要解决一小部分问题，而且要解决的总体问题百分比较低。

功能语言的核心是面向服务。您可以创建函数并将消息传递给它们，而不是创建对象并对其调用函数。Erlang是此技术的主要示例，因为即使在语言的功能方面，它也确实在其核心框架中内置了进程间甚至机器间通信，使您可以将消息发送到远程进程，就像本地进程一样。 。

其他语言（例如Scala，Clojure和F＃）也提供“面向服务”的语义。问题不在于它们不存在，而是普通民众害怕它们，因此它们不那么受欢迎。

服务导向是/是集成问题的体系结构答案。理想情况下，集成是一种包罗万象的解决方案，可以将任何现有的语言，产品，设备，资源融入更大的视野。

不需要某种新的语言，因为问题是已经有太多的语言，这会导致较高的互操作性成本。

但是，引入了一种语言，即Web服务定义语言。WSDL是SOA的元语言（还有另一种废弃的REST，名为WADL）

我将转过一个问题，问“ SO语言是什么样？”

这些模块之间的合同将如何写入？
操作的基本原理将如何执行？

面向服务是应用程序的属性，不一定是所用语言。服务是依赖功能的构造。该函数是一种依赖于编程语言机制的构造，用于将操作转换为机器可执行指令。

BPEL是一种SO语言的示例，但是它非常高级，并且依赖于可用的模块来使用。这些模块依次使用非BPEL语言编写，因此可以执行工作（也称为翻译成机器语言）。

伟大的Q，给了我美好的时光。

我将回答我自己的问题，以了解有多少人同意和不同意。

一些可能性：

• 构造SO语言似乎很困难。主要是由于服务的执行及其组成部分的分离。我在大学听说过几种学术解决方案（没有参考资料，对不起），但似乎并没有进入行业。但是我认为这是一个借口，不是真正的原因。OO语言和编译器也很难实现，但是市场上有很长一段时间都存在解决方案。

• 程序员将OO语言用于SO，因为他们不了解OO，并以错误的方式使用它。我说错了，因为OO中有两个与SO相矛盾的基本概念：

  1. 功能归功于它们所处理的数据所在的类。代码和数据在同一模块中耦合在一起。具有单独的类来处理其他类的数据不是OO风格。这就是Züllighofen的“工具和材料”方法（WAM），它与SO范例相匹配。

  2. 对象创建其他对象并形成对象网络。他们可以创建层次结构或任何复杂的关系。服务始终形成由外部组成的扁平网络。服务通常只有一个实例（Singleton），而对象被实例化的次数与它们所代表的实体一样。SO中的记录未在网络中连接。

• OO的某些功能看起来与SO类似，或者可以用于促进SO所需的功能，因此使用OO语言非常方便。

  1. OO中的依赖关系反转原理类似于在外部组成服务的方式。

  2. 单例对象就像服务，对象工厂就像服务定位器。

  3. OO还具有类似于服务接口的接口。

  4. 类的继承可以与服务和记录的继承相似（相同？）。

• OO和SO对于不同类型的问题很有用。因此，在每个应用程序中，很容易在此处或此处使用范例。使用不同的语言会妨碍在同一程序中在两者之间进行切换。

• SO不仅是编程范例，而且还是程序行为：Web服务，操作系统组件等都是SO，但不一定需要用SO语言编写。这种“二进制组件”非常自然且成功。但这是另一回事：这是程序之间的通信方式，而不是程序内部的通信方式。我猜人们经常将其混淆。