服务的静态和动态演变

Question

我正在阅读面向模式的软件architecure vol 2中的并发和联网软件的挑战。

  

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

     

可以通过以下方式进行推荐

     

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

     

确定如何访问服务更具挑战性   被配置为系统'按需'并且其实现是   系统原始设计时未知。这里设计挑战   是双重的。

     

  

1. 首先，应用程序必须导出新服务，即使它可能不知道其详细界面。

  

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

  

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

1. 作者的意思是“组件​​服务角色之间的接口和连接可能会在运行时发生变化”？要求以易于理解的例子来解释。

2. 作者的意思是上述两点提到的按需挑战。请求elobartion以上两点。

感谢您的时间和帮助。

Answer 1

  

1.作者的意思是什么“组件服务角色之间的接口和连接可能会在运行时发生变化”？

我不确定。接口因加班而改变：

• 可以采用新的技术标准 - 例如从SOAP转向REST，或者将XML形式转换为JSON，但这会在部署过程中缓慢发生 - 对于我而言，“运行时”是一个内存空间，在这些内存中运行，而我不要看到界面快速改变 - 否则任何人都可以与它们集成？
• API或接口合约本身会发生变化，以满足业务需求。

  

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

嗯，良好的设计模式往往能够很好地存活（它们永远不会改变，因为它们永远不会被破坏 - 就像SOLID一样）。你所提到的这本书是在2000年写的，我认为 - 从那以后很多都发生了变化，所以虽然这种模式可能存在，但我们现在所描述的方式已经发生变化（即“出口新服务”的意思是开放的）解释）...

  

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

分离关注（基本的OO东西），你的应用程序的所有部分都不（不应该）固有地知道其他部分在内部做了什么;同样，只要有人（包括一个外部系统）满足界面，那么谁在乎内部如何做到这一点。

  

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

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