Designing an Application to Be Part of a Service-Oriented Architecture
Benefits of SOA
Service-oriented architecture consists of a set of services and resources that other services and client applications on a network can access without any knowledge of how they are implemented.
The primary objective of using SOA is to deliver more business benefits more rapidly.
SOA enables your business to respond to change without the need to develop new applications and services from scratch.
To use SOA successfully, you should be aware of the following principles.
The boundaries between services and client applications are explicit. You should never make assumptions about how a service should process a request, or about how a client should handle a response.
These services and clients should communicate only when required.
The independent nature of services makes them autonomous. Services can be running on networks controlled and managed by other organizations.
You must design loosely coupled solutions that can endure any changes to the availability of these services. For example, if you use a third-party Web service in your solution, you need to make sure that your solution will not fail, even if the third-party Web service becomes unavailable. SOA works best when the implementation details of services and resources are not exposed.
You should design schemas and contracts that define the functionality that your service exposes.
Other services and client applications should access only the functionality defined by these schemas and contracts.
You may wish to add additional contracts. This strategy provides a greater level of freedom for the implementer of a service to change the way in which the service works internally, or to even add new functionality, which can be exposed by defining additional contracts.
As long as the service continues to implement the original contract, existing clients can still use the original functionality.
Be sure to keep the nonfunctional policy requirements, such as security constraints, separate from the functional requirements, such as the implementation of the service.
For example, a service might specify that all requests must be encrypted and that client applications must provide a valid certificate for authentication. These security requirements do not change the functionality of the service but all client applications that attempt to access the service must conform to this policy
Designing an SOA Application
When you use SOA to build an application, you complete a design phase, which includes discovering the services that your application includes. You must discover services as part of the overall design and architecture of the application. For example, suppose there was a design meeting to discuss what happens when a user registers as a customer. The discussion would cover how the system registers the customer and go on to identify the service that the system uses to perform this task. That service would then be added to the list of potential services.
Get commitment for the major architectural effort that is required to deliver a successful SOA strategy.
Gather the services by:
- Harvesting services from projects that have been developed in a service-aware manner.
- Building new service interfaces for existing functionality.
- Having new projects build services as they go.
Group related functions
Group related business functions, but be mindful of granularity. You must not create a distributed data-access layer that strongly binds clients to the underlying schema and assumptions. You only need your client application to know about the service with which it wants to communicate, not the underlying implementation.
When you design an SOA, keep business methods at the level of coarse-grained business functions rather than at a detailed level. Each business method should perform a complete, self-contained function, be independent, and not require subsequent calls to other methods in a specific sequence. You should also follow a document-centric approach to defining an SOA. For example, your client should send a single message to the service, which contains all necessary data for the business function. Avoid an approach that uses remote procedure call (RPC). The RPC approach means that your client application must send multiple messages. Each message would only contain enough information to satisfy part of the business function
For more information about designing an SOA application read here
WCF and SOA
WCF is a framework that you can use to implement SOA solutions. SOA is a technology-independent design philosophy that guides you when you implement SOA solutions.
WCF supports SOA by providing an easy way of exposing language-level contract definitions in platform-independent terms.
In a developer role, you do not have to learn the many technologies that are involved in building a distributed application. This is because, when you use a framework such as WCF, the WCF runtime handles most rudimentary functions automatically. By using Visual Studio 2008, you can easily create and consume a WCF service even if you have little knowledge of WCF itself.
However, if you expose an interface over a protocol stack in a Web service, it does not mean that you have created an SOA. You must remember that WCF is only the framework that you can use to implement an SOA. Therefore, if you use WCF, it does not necessarily mean that your solution is service-oriented.
WCF in an SOA Context
At the language level, the system consists of persisted objects, business rules, and a business interface.
At the service level, there are operations that may be similar to the functions at the language level but you expose them as business operations that are designed as part of a service interface. These business operations may combine multiple language-level functions and probably use data types that are more suited to a distributed environment.
When you design and implement a system, there are objects that represent business data, code for storing and managing data, and business rules that determine how these objects interact. A service forms a business façade through which clients can invoke the business logic and manage the objects.
For example, at the language level of the Customer Management Service application, customer details are stored in a SQL Server database. There is also your business logic, which can manipulate the customer details and the business interface that interacts with the business logic.
Alternatively, at the service level, there is a business façade, or controller, that references more granular operations. For the business interface, the façade provides access to complete operations such as registering a customer. This then links to more granular operations such as performing a credit check and getting customer details. At the service level, the business needs to interact only with the high-level business operations that are exposed by the façade, not with the individual methods at the language level.