To implement an SOA application, create models that are either Service Providers (back-end data access) or Service Consumers (front-end presentation) and then combine them (flexibly) both for application testing and for publishing.
Using this methodology, teams of developers can work independently on the layers without the need to constantly coordinate and adjust to modifications made on the other side. Additionally, development can proceed without requiring access to the targeted back-end systems, simplifying life considerably for all, especially the UI team.
Service Provider model – defines service
These models define a service within the WebApp; the Model (and thus the service) is then referenced by Service Consumer models. The service can provide one or more operations (similar to the operations within a WSDL service). The service can return whatever results are required within an application, including gathering data from multiple back ends or databases and combining it in whatever form is required.Service Consumer model – invokes operations
It is often useful to define a service with multiple, related operations, even if the data sources represent more than one back-end system. For example, a customer information service might define operations to return a customer list (based on search criteria), customer detailed information, customer orders, customer complaints, and so on. A product service might define operations for products by category, products by price, product inventory, product costs, product sales performance, and so on.
As their name implies, these models use one or more Service Consumer builders to invoke the service operations made available by Service Provider models. Usually (but not necessarily), a Service Consumer model will generate UI, obtaining data via the service provider and then using whatever other builders are needed to generate pages with the forms, views, graphs, and so on, that comprise the presentation layer. The Provider/Consumer builder set provides insulation to UI models, and loose enough coupling between UI and service models to allow substitution of an alternate service provider model at runtime.
Parent topic: Creating a service provider model: wpf7