Web服务与共享库

我的想法是:

Web服务是为机器互操作和访问用户而设计的

一个优点是,通过发布服务,您也打开了 为潜在广大受众提供的服务(通过网络或至少在整个网络) 你不介意,这是你想要的。作为客户端,该服务的使用要容易得多 只要有一个互联网连接和消费服务。不像图书馆

但是,web服务通常较慢,并且依赖于internet连接。
一般来说,它比代码库更难测试。
这可能更难维持。这在很大程度上取决于您的维护和编码实践。

如果需要上述几个特征或至少其中一个,我将考虑Web服务。

共享图书馆怎么样?

如果你更能“控制”你的环境,或者你想成为这样的人,该怎么办?你知道谁会使用代码吗 (维护接口不是问题),您不必担心互操作。你现在的处境是

我脑海中关于何时使用的示例:

您的控制中有许多应用程序,它们都托管在将使用该库的一两台服务器上。

不是很好的例子,您有许多应用程序,但都托管在十几台服务器上。Web服务可能是更好的选择。

您不确定谁或如何使用您的代码,但知道它对许多人都有很好的价值。网络服务。

您正在编写一些仅由有限的应用程序集使用的东西,可能是一些辅助函数。图书馆

其他人永远不会使用的应用程序。图书馆

还有很多,但这些是我对它的一些想法。。。

图书馆优势:

• 本机代码=更高的性能
• Simplest thing that could possibly work
• 没有集中式服务中断和影响所有消费者的风险

服务优势:

• 每个人都可以立即透明地获得升级(除非提供了版本化API)
• 使用者无法反编译代码
• 技术不可知论者。有了共享库,用户必须使用兼容的技术。
• 更安全。UI层可以调用位于防火墙后面的服务,而不是直接访问数据库。

1. 应提供一组执行常见任务(例如字符串解析、数字操作、生成器)的众所周知的操作
2. 应该封装通用的可重用代码
3. 对其他库的依赖性最小
4. 提供稳定的接口

服务

2. 提供通用业务服务(例如,回报率计算、性能报告或交易历史记录服务)
3. 可用于连接来自不同系统的现有软件或在应用程序之间交换数据

1. 服务

   • 有支架周围状态
   • 你需要经常发布更新
   • 解决主要业务问题并拥有与之相关的数据
   • 需要安全性:用户无法查看您的代码,用户无法访问您的存储
   • 需要与REST类似的不可知交互(您可以为客户端语言自动生成浅层REST客户端)
   • 需要单独缩放

2. 图书馆

   • 您只需要一组可恢复的代码
   • 需要在客户端运行
   • 不能容忍任何停机时间
   • 甚至不能忍受几毫秒的延迟
   • 可能有效的最简单解决方案
   • 需要将代码发送到数据(high thoughput或map reduce)

3. • 敏捷方法,你从最简单的解决方案开始,而不是扩展
   • 需求可能会演变,变得更像“服务”案例

4. 启动本地服务的图书馆。

5. 也不

   • 即使是图书馆的案子,你也不能认真地为之辩护
   • 商业价值值得怀疑

理想情况下,如果我想要这两个优点,我需要一个便携式库,带有不可知界面胶,自动更新,带有模糊(难以反编译)或安全的内部环境。