事务管理

Question

我们的客户遵循SOA原则，并有设计的Web服务是非常细粒度像createCustomer，deleteCustomer等

我不知道如果细粒度的服务是可取的，因为他们创造的事务有关的问题。例如，如果业务需求是每个客户在创建时都必须有一个地址。因此，在这种情况下，表示组件首先调用createCustomer，然后调用createAddress。这些服务在内部使用简单的JDBC来更新db中的相应表。由于服务是由外部组件调用的，因此它没有办法满足事务性要求，即如果createAddress失败，则createCustomer操作必须回滚。

我想，处理这个问题的方法之一是设计课程粒度服务（在单个JDBC事务中创建客户和关联地址）或者简单地创建反向服务（deleteCustomer） createCustomer的行为。

有什么建议。谢谢

Answer 1

简短的回答：服务的设计应该是为了服务客户端的方便。如果客户被告知“打电话给这个，那么不要忘记打电话给你”你让他们的生活太难了。应该有一个粗粒度的服务。

一个长的答案：客户可以合理地进入没有地址？所以我们打电话

createCustomer(stuff but no address) 

并且结果是一个客户的有效（如果可能不是理想的）状态。稍后我们拨打

changeCustomerAddress (customerId, Address) 

现在持续的客户更有用。

在这种情况下，API就好了。关键在于系统的完整性并不取决于客户端代码“记住”做些什么，在这种情况下添加地址。但是，更有可能的是，我们不希望系统中没有地址的客户，在这种情况下，我认为这是服务的责任，以确保发生这种情况，并给予主叫方错误发生的最少可能性。

我会看到粗粒度的createCompleteCustomer（）方法是迄今为止最好的方法 - 这允许服务提供者一次解决问题，而不需要每个客户端程序员实现逻辑。

替代品：

a）。有关原子事务的Web服务规范和主要供应商确实支持这些规范。原则上你实际上可以使用细粒度的方法和真正的事务来实现。实际上，当你沿着这条路线走下去时，我认为你进入了一个复杂的世界。 b）。 @mtreit提到的有状态接口（工作，工作，提交）。一般来说，有状态会增加复杂性或阻碍可伸缩性。服务在哪里保持中间状态？如果在memeory中，那么我们需要对特定服务实例进行关联，并因此引入扩展和可靠性问题。如果在某些状态或正在进行的数据库中，那么我们会有额外的实施复杂性。

Answer 2

如果需要事务性，可以在服务器上实现事务语义的粗粒度单一操作肯定会更容易实现。

这就是说，当然有可能构建一些方案，直到所有必要的细粒度操作成功为止，操作的目标不会被提交。例如，执行一个Commit操作来检查与服务器上的对象关联的某个标志;直到事务中的所有必要步骤都完成后才设置标志，如果未设置标志，则提交失败。

当然，如果重量轻，细粒度的操作是重要的设计要求，那么可能需要重新考虑具有事务性的需求。

Answer 3

好了，让我们开始：

我们的客户遵循SOA原则和 有设计的Web服务是非常 细粒像createCustomer， deleteCustomer等

没有，客户端已经忘记了达成SOA原则，并提出了大多数人的做法 - 界定不明确的泥潭。对于SOA原则，这个地区会走到一个更粗糙的界面（比如OData更新数据的机会主义），或者遵循过去25年中编写的多层架构书籍的建议。对于CORBA发明的东西以及SOA管理员今天所做的所有错误，SOA只是另一个词，10年前CORBA基本上出名的设计愚蠢。并不是说今天任何做SOA的人都听说过CORBA。

我不知道如果细粒度服务 是可取的，因为他们创造 事务有关的问题。

仅适用于不支持Web服务的用户和平台。认真。当然，如果您忽略了事务性问题 - 忽略编程中的事务性问题。这里的诀窍是人们进一步发现食物链并非如此，只是你的客户决定忽视常识（再次看到我对科尔巴的第一个评论）。

设计Web服务的人很清楚事务性问题，这就是为什么Web服务规范（WS *）实际上包含通过将提交操作移动到调用Web服务的客户端来处理事务完整性的机制。您的客户应该阅读的特定规格是WS-Atomic。

如果您使用当前的技术来公开您的Web服务（也就是MS平台上的WCF，类似的技术存在于Java世界中），那么您可以向客户端公开事务流信息并让客户端处理事务分界。这有它自己的份额问题 - 像客户端保持交易恶意开放 - 但仍然是处理在客户端定义的交易的唯一方式。

您给没有平台，只是提到java的，我指着你一些MS例子，如何能够看： http://msdn.microsoft.com/en-us/library/ms752261.aspx

Web服务，在一般情况下，有很多更强大和更大量的深思熟虑比大多数人在做SOA时所想的要多。他们看到的大多数问题很久以前就已经解决了。但是，SOA只是多层架构的一个流行词，但大多数人认为这是自切片面包以来最伟大的事情，甚至不知道10年前的情况。

作为您的客户，我会更关心性能方面的问题。他定义的细粒度非语义Web服务对非偶然使用来说是一个性能问题，因为您通过网络访问/更新小型小型小型网络的次数会导致网络延迟杀死您。在这种情况下创建类似于10件商品的订单可能很容易需要30-40次网络呼叫，这可能会花费很多时间。 SOA从一开始就宣扬（如果你忽略了那些不了解历史的人的话），不要使用细粒度的调用，而是去粗略交换文档和/或语义方法，就像OData系统一样。