应用开发：面向服务的应用

查找数据

服务处理的第二种类型就是查找数据。这种类型的数据是用来给服务请求中的操作传递参数的或者是解释服务回复的数据用的。这样，一个消费者也许会请求查找数据，使用这个数据来创建一条请求消息。例如，一个提供技术培训的公司可能会公布一些由它的培训地点和供货商组成的查询数据，这样，当消费者在请求一个计划的时候就可以给服务传递有效的数据。正像你估计的一样，查找数据是相对静止的，当它有改动的时候就应该被合理的翻译，并且每一种译本都是不可改变的。像消息数据一样，查找数据用于服务的外部，因此，它就需要一个公开的计划。

服务可以通过唯一地定义每个条目、给每个条目都设定一个翻译标识这种方法来处理数据；例如，Quilogy - LocationCodes - v012004。通过这种方法，当消费者提出请求的时候，他们就将参考数据使用的译本传递给消费者，这样，服务就可以提供合适的回答。因为查找数据最终需要刷新的，特别是在定义的间隔时间内，所以，服务通过使用push（使用电子邮件、HTTP，甚至是DVD）或者pull（使用HTTP，FTP，电子邮件）方式来向订阅者（消费者）们公布最新的译本。

处理数据Process data

在服务内部，你将处理的数据的第一种类型就是处理数据。不像消息数据和查找数据一样，处理数据对于服务来说是保密的，并且被封装在服务内部，所以不需要一个公开的计划。处理数据代表那些服务执行的商业加工或功能。最有代表性的是，它们是长期的操作，直至最后完成。处理数据的例子包括购物篮、购买顺序和发票。处理数据是独立于客户的或者是独立于会话的，所以它有很低的同步需求，因为它只能被单个客户顺序访问。不同于查找数据，它在操作正在进行的同时是可以升级的（可修改的），一旦操作结束之后，它就变成只读的了。随着时间的推移，它的引用将变得越来越少。

服务要处理请求消息并且还要处理为会话服务创建的处理数据。因此它们必须将处理数据和会话标识符一一对应起来。一个服务可以使用不同技术来操作处理数据。例如，当处理正在进行的时候，服务可以将处理数据封装到一个对象中去，并将它们存放到内存中去。服务必须还要能够清除那些失败的或者丢弃的处理。

商业数据

SOA中使用的最后一种类型的数据就是商业数据。这是当大多数人在谈论到应用的时候都会想到的一类数据――例如，客户信息，产品目录，还有银行帐号。同处理数据一样，商业数据同样也对服务保密，并且它也不需要公开的计划。但是，和处理数据不同的是，它的生命期要比一个单一的长期运行的操作要长，并且具有高度的同步需求，因为它可能同时被几个操作更改。这样，商业数据是非常不稳定的和易变的。

服务处理商业数据最重要的方法可能就是坚持单一用户的原则。换句话说，服务拥有机构中数据特定部分的所有权。例如，一个服务拥有消费者的数据，而其它的服务拥有雇佣者的数据。当数据需要共享的时候，每个服务都将改动过的数据公布给其它一些服务，这些接受改动信息的服务是那些将要在其内部处理用到这些数据的服务。服务数据的每个公布信息都应该随着标识符的增加而被翻译。只有服务的拥有者可以修改数据。所以，如果一个非拥有者想要修改数据的时候，它就提出请求，由拥有者来进行修改，并把修改以后的数据公布给那些感兴趣的订购者。

如何处理这些类型的数据，并且该如何存放它们呢？

一旦数据类型被定义了，你就会考虑在处理和存放这些数据的时候需要一些什么技术。简而言之，有三大技术――XML，对象和SQL构成了解决上述问题的方法。

消息数据

显然，消息数据，由于它需要一个公开的计划和不同的成分，这样，将它用于

SOAP是最合适不过的了。因此，你可以给使用WSDL的消息发布计划。另外，你还需要实现消息数据的某些功能（例如，时间戳和安全性），这些功能可以由SOAP

规格说明书来提供（如WS-*），实现部分可以使用像Web Services Enhancements (WSE) 2.0（微软的）的工具包来完成。

在服务内部，消息数据可以和它的定义属性一起存储，就想关系数据库中的XML一样，为的是能够实现幂等性。这种存储方式同样也是推荐的存储方式，因为你需要查询它们的属性，但是它的不变性却并不希望你经常阅读和分析消息数据的内容。另外，存储消息允许进行审计和未来的分析。然而，从定义中大家已经知道，消息数据具有最短的生命周期，所以如果在不使用其进行分析的时候非常容易存档。

另一个关于消息数据的考虑就是考虑在消息传送的时候会发生什么事情。在机构中，在消息结构被多个服务独立使用的时候，就有必要建立一个规范的或者是标准的计划，这样，消息数据在被传送之前就可以被翻译。这样就避免了每个服务代表同样的查找数据或者是商业数据的现象，并且只需要进行少量的转换。