The Web Services Platform
The Web services platform provides all the facilities necessary to do the following:
Allow service requesters and service providers (both line of business services and reusable technical services) to interact in a consistent manner independent of the underlying software domains (i.e., programming languages, application servers, TP monitors, communication middleware, directory services, operating systems, and so on).
Enforce business rules and policies such as data validation rules, service-level security, service-level management, and service-level agreements.
Allow an SOA to scale up to handle enterprise-wide, mission-critical business requirements.
The Web services platform to the greatest extent possible is based on open standards that are product-neutral, technology-neutral, and middleware-neutral so that it can support and integrate services created using a wide variety of products, technologies, platforms, and middleware.
Figure is a high-level diagram showing the role of the Web services platform.
Web services platform.
The Web services platform provides the core facilities so that service requesters and service providers can interact in a consistent manner independent of the underlying technology platforms.
Elements of the Web Services Platform
Here are some of the key elements of a Web services platform:
Service contract Unambiguous, well-defined service interface using WSDL. Ideally, it should be human-readable and machine-readable.
Service contract repository A repository for storing, looking up, and versioning service contracts. This might include using taxonomies in UDDI or another registry to categorize services and then using these taxonomies to search for servicestaxonomies give you much better searching capabilities than just searching based on the WSDL documents. Ideally, it should be highly available and replicated.
Service registration and lookup A naming service for locating service instances and run-time resources in a high performance, scalable, and highly available manner. Whereas the service contract repository is used to look up service contracts, service registration and lookup is used for finding run-time instances of the services.
Service-level security Security facilities using the WS-Security framework for defining and enforcing service-level security policies including authenticating service requesters, enforcing access control to service providers based on role and context authorization (e.g., role-based access control), single-sign-on, privacy, integrity, and non-repudiation. Of course, there will be other security facilities in the systemfor example, for controlling application-level user login and controlling database loginbut these facilities are not part of the Web services platform.
Service-level data management XML Schema repository for storing and managing business-level data representations. Some organizations find it preferable to separate the service contract repository and the XML Schema repository because a single XML Schema definition can have many uses besides simply being included in a WSDL document, such as being used by data validation tools, data transformation tools, BPMS, reporting tools, rules engines, XML-relational mapping tools, and XML data servers. Data-mapping facilities for mapping data between different message structures including data filtering, data aggregation, and simple translation functions. Semantic-level data transform facilities define information taxonomies and perform semantic transformations across service domain boundaries.
Service-level communication Support for multiple interaction patterns and communication styles using SOAP. Ideally, the communication infrastructure should support multiple interaction patterns and communication styles so that business requirements can be easily mapped onto the Web services platform.
Multiple protocol and transport support Ideally, the messaging infrastructure should support multiple transports/protocols to support the wide range of clients, servers, and platforms.
Service-level qualities of service Support for reliable messaging technologies and various qualities of service including message-ordering, guaranteed delivery, at-most-once delivery, and best-effort delivery. Transaction management capabilities for defining and supporting transaction execution and control including two-phase commit and/or compensating transactions. High-availability capabilities include clustering, failover, automatic-restart, load balancing, and hot-deployment of services.
Service-level management Support for deploying, starting, stopping, and monitoring services. Of course, there will be other system management facilities in the systemfor example, for managing hardware serversbut these facilities are not part of the Web services platform. Support for versioning services. Support for auditing service usage. Support for metering and billing for service usage. Service-level support for business activity monitoring (BAM) including service monitoring, service status, service responsiveness, and compliance or deviations from service-level agreements.
Support for multiple programming languages Bindings for multiple programming languagesTo fully support a wide range of applications and execution platforms, the Web services platform needs to support multiple programming languages, including generating service proxies and service skeletons for all supported programming languages.
Service programming interfaces Typically, the Web services platform will provide service programming interfaces so that developers can access the facilities of the Web services platform from their favorite programming language(s) and so that developers can be isolated from the complexity of the underlying technical infrastructure.
The Web services standards (SOAP, WSDL, UDDI, WS-*) are the best bet for defining a service platform, but it may be several years before the complete set of standards is approved, implemented, and interoperable across most vendor products. Because the Web services specifications are composable, however, it's possible to start with what's available now and add the rest later. In most cases, the platform will be composed of a wide assortment of products from a number of vendorsalmost by definition, it can't come from a single vendor.
Web Services Platform Principles
One principle that applies to the Web services platform is that it should (a) only provide the facilities necessary for allowing service requesters and service providers to interact in a consistent manner independent of the underlying technology platforms, (b) enforce service-level business rules (sometimes called policy enforcement points or PEPs), and (c) scale up to handle enterprise-wide, mission-critical business requirements.
In particular, the Web services platform should avoid trying to include all reusable technical services because each reusable technical service that is embedded in the Web services platform makes it more complicated, harder to maintain, and harder to evolve as requirements change. Instead, reusable technical services should be built on top of the Web services platform using the core facilities provided by the Web services platform so that changes can be made to the reusable technical services without changing the Web services platform. For example, policy enforcement points can be implemented as SOAP interceptors or WSM agents. See Chapter 4, in the section "Applying SOA and Web Services for IntegrationEnterprise Service Bus Pattern" for an example of a reusable technical service that can and should be built on the Web services platform rather than being built into the Web services platform.
A second principle that applies to the Web services platform is that it should incorporate common facilities, especially when they can be used to automatically enforce business rules or move complexity out of the application layer and into the Web services platform. This principle explains why facilities such as single sign-on, role-based access control, audit logging, reliable messaging, and transaction management are included in the Web services platform. Even though each and every one of these facilities could be implemented at the application layer by the service requesters and service providers, this approach would make the application layer significantly more complex, would be errorprone, and would make it very difficult to automatically enforce service-level policies. For example, role-based access control rules should be built into the Web services platform so that it can automatically enforce these rules.
As you can see, there is some tension between these two principles because the first one suggests making the Web services platform as small, simple, and minimal as possible while the second principle suggests expanding the scope of the Web services platform to include any and all facilities that could conceivably move complexity out of the applications and into the Web services platform. We therefore define the Web services platform primarily in terms of adopted and proposed standards.