An SOA consists of a set of resources on a network that are made available as independent services, and that can be accessed without requiring any knowledge of how they are implemented. You can combine the services in an SOA to create an enterprise application. I will not consider the full theory of SOA, but the main benefits are that it enables you to create complex solutions that are independent of any specific platform and location. This means that you can quickly replace or upgrade a service or move a service to a different site (possibly running on faster hardware), and as long as the service exposes the same interfaces as before, you can continue to use it without needing to modify any code. However, SOA is not a magic wand that will instantly solve all of your distributed application architecture problems. To successfully design and implement an SOA, you should be aware of what has become known as the “Four Tenets of Service Orientation.” These are:
- Boundaries are explicit. Applications and services communicate by sending messages to each other. You should not make any assumptions about how a service processes a request or how a client application handles any response to a request. Following this principle can help to remove dependencies between services and client applications. Additionally, sending and receiving messages has an associated cost in terms of communications. You should design the operations that services implement with this in mind, and ensure that clients call services only when necessary.
- Services are autonomous. If you are building an application based on services, you might not have control over every service you are using, especially Web services hosted outside of your organization. The location of a Web service might change, or a service might be temporarily taken off-line for maintenance or other reasons. You should design your solutions to be loosely coupled, so that they can tolerate these changes and continue running even if one or more services are unavailable.
- Services share schemas and contracts, not classes or types. Services publish information about the operations that they implement and the structure of the data that they expect to send and receive. Clients use this information when communicating with the service. You should design contracts and schemas to define the interfaces that your services expose. This can reduce the dependencies that clients have on a particular version of your services. Services can change and evolve over time, and a new version of a service might appear superseding a previous version. If a service is updated, it should maintain compatibility with existing clients by continuing to implement existing contracts and send messages that conform to existing schemas.
- Compatibility is based on policy. The schemas and contracts exposed by a service define the “shape” of the service but not the nonfunctional requirements that a client attempting to access the service must fulfill. For example, a service might have security requirements that state that clients must connect to it in a particular manner and send and receive messages by encrypting data in a specific way. This is an example of policy. The policy requirements of a service cannot be specified by using contracts and should not require additional coding on the part of the client or the service–these requirements might change over time and so should be decoupled from the implementation of the service and clients. You should design services so that their policy requirements are independent of any implementation, and you should enforce clients to abide by any policies required by the service. Additionally, all services and client applications must agree on how to specify this policy information (typically by using some sort of configuration file). This is the purpose of the WS-Policy framework, published by the World Wide Web Consortium, and widely adopted by Web service developers.
No comments:
Post a Comment