服务的静态和动态演变

Question

我正在阅读有关面向模式的软件架构第 2 卷中并发和网络软件的挑战。

服务访问通常涉及在可重用对象上调用远程操作 OMG事件服务等组件支持静态和 服务和应用程序的动态演变是另一个关键 网络软件系统的挑战。

进化可以通过以下方式发生

组件服务角色之间的接口和连接可以 通常在运行时更改，并且可以实施新的服务角色 并安装到现有组件中。

确定如何访问服务更具挑战性 被配置成一个系统'on-demand'，其实现是 系统最初设计的时间未知。这里设计挑战 是双重的。

1. 首先，应用程序必须导出新服务，即使它可能不知道它们的详细接口。

2. 其次，应用程序必须透明且稳健地将这些服务集成到自己的控制流和处理序列中，即使 在运行时。

我需要您的帮助，通过回答以下问题来理解上述文字。

1. 作者所说的“组件服务角色之间的接口和连接可以改变，通常在运行时”是什么意思？要求用容易理解的例子来解释。

2. 作者上面提到的按需挑战的两点是什么意思。就以上两点提出要求。

感谢您的时间和帮助。

Answer 1

1.作者所说的“组件服务角色之间的接口和连接可以改变，通常在运行时”是什么意思？

我不确定。接口随着时间的推移而改变，因为：

• 可以采用新的技术标准——比如从 SOAP 转移到 REST，或者从 XML 转移到 JSON，但这会在部署过程中慢慢发生——对我来说，“运行时”是运行事物的内存空间，而我看不到界面变化很快 - 否则怎么会有人与它们集成？
• API 或接口契约本身会发生变化以满足业务需求。

2.作者上面提到的两点按需挑战是什么意思。

嗯，好的设计模式往往能很好地生存下来（它们永远不会改变，因为它们永远不会被破坏——就像 SOLID 一样）。我认为您所指的这本书是在 2000 年写的 - 从那时起发生了很多变化，所以虽然这种模式可能会继续存在，但我们现在描述它的方式可能已经改变（即他所说的“导出新服务”的意思是开放的）解释）...

1.首先，应用程序必须导出新服务，即使它可能不知道它们的详细接口。

关注点分离（基本的面向对象的东西），您的应用程序的所有部分都不（不应该）固有地知道其他部分在内部做什么；同样，只要有人（包括外部系统）满足接口，那么谁在乎它在内部是如何做到的。

2.其次，应用程序必须透明且稳健地将这些服务集成到它自己的控制流和处理序列中，即使 在运行时。

我认为这意味着程序不应该中断，它应该始终编译，如果应用程序动态创建和执行代码（比如基于用户输入），那么需要就地检查，以便动态代码也不会破坏应用程序。