在SOA中，我们不应该在客户端和服务器之间构建或保持状态（或设计依赖关系）。这是理解的。但是，如果客户想要使用可能返回开放式数量的“行”的实时服务，可以遵循哪些模式？
Web应用程序，类似于SOA但允许状态（会话）已经通过分页解决了这个问题。分页需要（在大多数情况下，特别是使用SQL）服务器保存数据并且客户端以块的形式请求数据。
如果我们在哪里考虑类似于Web服务的类似分页的方案，那么遵循哪些模式仍然可以使SOA的原则得到遵守（或尽可能接近）。
思想家的一些规则： 1）由SQL数据库支持（因此在选择集中没有行号的概念） 2）在分页期间不要跳过一行或复制一行中的一行很重要 3）其他客户可以随时将数据插入和删除到数据库中 4）无需将数据集视为实时（可更新）数据集
就我个人而言，我认为上面的1和2已经通过约束解决方案空间满足要求来拼写我们的解决方案。
我提出的解决方案将数据（选择的数量）存储在只读存储/缓存中，在该存储/缓存中可以在结果集中为其分配行号，并允许在此数据快照上进行分页。我将拥有存储快照的基础设施（服务器，外部缓存，memcached或ehcache - 这必须扩展得非常大）。此类查询的结果将是快照ID，客户端可以使用快照API（Web服务）和快照ID从快照中检索数据。在x是合理的时候，结果将以只读，仅向前的方式处理x记录。
非常感谢竞争的想法和想法，批评或赞誉。
答案 0 :(得分：1)
SOA不适用于这种低级功能。
SOA旨在将业务领域粘合在一起，而不是将后端粘合到后端。不是因为您的应用程序使用Web服务与后端进行通信，而是您拥有“SOA”应用程序。这是没有意义的，因为SOA在1个孤立系统的环境中毫无意义。
从这个角度来看，很明显，在SOA中，调用者不应该知道您正在分页的SQL表，这是SOA应该隐藏的实现细节。另一方面，服务器不应该知道客户端的状态，因为它应该与客户端的细节无关，要真正开放。
所以，只要了解分页不是SOA。按照您的意愿，只需要了解您用于分页的Web服务是应用程序的内部工件，而不是用于SOA总线中的外部客户端。还要记住，它不能与服务器中的out状态一致。问题可能是您只有一个服务层用于应用程序的UI和SOA总线，您需要将它们分开。
在SOA总线中使用此Web服务会很糟糕。我不能像用户分页那样保持一致，并且当其他应用程序挂起时，它们会与特定的SQL绑定。
...然后你可能已经授予对表的直接SQL访问权限。
SOA用于系统之间的业务消息，而不是将应用程序的前端粘合到后端。
答案 1 :(得分：0)
Web服务中的分页结果实际上很容易实现。
您所要做的就是在Web服务调用中添加两个参数：Page Size，Page Number。
页面大小是要包含在页面中的结果数。页码是您要查找的结果页面的编号。
然后，您的Web服务将返回数据库（或缓存），检索结果，确定哪些结果适合所请求的页面，并仅返回这些结果。
然后，客户必须从服务中为每页结果发出一个请求。
答案 2 :(得分：0)
您对memcached的建议也适用于缓存表。第一个服务调用将（1）INSERT结果INTO缓存表中的快照ID（2）返回缓存表中的第一页和快照ID。后续调用将通过使用快照ID查询缓存表，根据页面大小和页码返回页面。
我认为这也可以通过使用内存缓存表进行优化，但这取决于您的数据库是否支持从磁盘表到内存表的INSERT-INTO。但是，在群集环境中，这可能会变得复杂。
如果您在请求之间保留特定于客户端的副本，无论存储是在会话对象，数据库表还是memcached数据存储中，这样的缓存本质上都是有状态的。但是，考虑到这些要求，您别无选择，只能以某种形式缓存结果，除非您有可能将已删除或不再相关的记录作为合法结果返回。
答案 3 :(得分：0)
同样的问题，使用Navision方法解决。
$ws->getList($first_record_id, $limit)
这将返回从传递的id
开始的$ limit元素页面select * from collection where collection.id > $first_record_id ASC limit $limit
由id ASC命令
Navision use Key（每个元素都有一个键）但在MySQL中自动增量id更好。
在这种情况下，分页用于处理大型结果集，而不是用于前端分页......
答案 4 :(得分：0)
我不确定SOA是否值得关注。您的问题似乎在于对API进行分页。我将指出twitter如何处理他们的分页dev.twitter.com/rest/public/timelines