为什么不使用SOA方式，要提出这个新的东东OData



A Perspective: OData in a SOA World

http://msdn.microsoft.com/en-us/data/hh237663.aspx

For anybody familiar with service-oriented architecture (SOA), OData raises an obvious question: Why not use a SOA approach to exposing data? Why invent something new with OData?

As described earlier, one clear advantage of OData is its commonality: Rather than having each application define its own unique set of services, they can all use the common data model and protocol defined by OData.

就像前面表述的，Odata一个明显的优势就是通用性：不是每一个应用程序都定义它自己的一套服务，而是他们可以使用OData定义的相同的数据模式和协议。

This makes it easier to mix and match clients and data sources, and it also allows using common libraries to create both.

But there's also another reason why OData can be better for exposing data than a traditional SOA approach. Suppose an application needs to expose data about customers and orders to various clients. With the SOA approach, the application's creators would
define a set of custom operations (using either REST or SOAP) that clients could call. They might, for example, create a GetCustomer operation that returned data about one or more customers. If the application's first client wanted the ability to retrieve
customers by customer number, this operation might have a parameter that allowed making exactly this kind of request.

但是也有另一个原因为什么OData可以比传统SOA方式更好的暴露数据。 假设一个应用程序需要暴露客户和订单的信息给各种各样的客户端。若用SOA方式，这个应用程序的创建者将会定义一套自定义个操作，以供客户端调用。 举个例子，他们也许创建一个GetCustomer的操作，返回关于一个或者多个客户的数据。 如果它的第一个客户端想要数据通过客户的。。

Now suppose another client wants to access this application's data through the same interface. This client needs to retrieve customer data by geographic area, however, rather than by customer number. To allow this, the creator of the application's interface
likely adds a new operation, perhaps called GetCustomerByGeo. When yet another client appears, it might well want to retrieve customer data in some other way, requiring still more changes to the interface.

It's common to see this kind of evolution in SOA interfaces today, and it's not a pretty thing. The problem grows out of a fundamental limitation, however, which is that services expose only specific views into an application's data. It's as if the data
is behind a curtain, with each service punching a hole in that curtain. The creator of this interface is forced to guess how the application's clients will want to access the data, deciding in advance what holes to cut in the curtain.

Contrast this with how OData works. Rather than exposing application-defined services, it allows access to an entire application-defined data model. Clients are free to query this model in any way they find useful. The application's creator still has control
over what's exposed, of course, and designing the data model likely requires making some predictions about what clients will want. Still, exposing a data model pulls back the curtain on an application's data, giving clients more flexibility in how they access
it.

Not every problem that relies on SOA today should use OData, of course. If an application exposes a functionality- oriented set of services rather than services targeting data access, for instance, OData probably isn't a good choice. But for applications
that wish to expose data in a broader, more consistent way to diverse clients, using OData can be an attractive option.

理解：就是SOA一个需求，你要给定义一个API,

而OData是把整个数据模型都暴露出来了。