Managing Web Services in Production
Realizing 24x7 Web services is difficult without taking management aspects into consideration right from the design phase
by Anant Kadiyala
October 13, 2004
Making Web services available 24x7 is a challenging task. As enterprise Web services mature from pilot to mission-critical phase, high reliability and robust performance are an absolute necessity. You need to consider many aspects to be able to run and manage mission-critical Web services in production.
Management Architectures
There are three common architectures for managing applications: agent model, proxy model, and hybrid model. Agents are add-ons that piggy-back on the infrastructure of the existing application container. In Java, Java Management Extensions (JMX) agents are commonly used to monitor applications. Proxies (in Web service deployments) are stand-alone applications that sit between the consumer and producer of a service. Each of these models has its own set of pros and cons. The hybrid model is a combination of agent and proxy models.
A Web service has two types of logic associated with it: business logic and management logic, but here we'll discuss only management aspects. The artifacts of managing Web services include versioning (and organic growth), dependency management, maintaining quality of service (QoS), provisioning, security, interoperability, auditing, logging, alerting, resilience, and reporting. Administrators also need to worry about the "ilities" of the system like availability, reliability, and scalability.
Separation of concerns has long been a golden rule in software development. While the producer concentrates on providing business logic, a separate framework, namely a Web services management framework, provides the necessary management support. Because most of the Web services have a common base set of minimum management requirements, externalizing the management logic so that it can be managed centrally is a good idea.
The OASIS committee is in the process of defining a standard interoperable model for managing Web services. The model is called Web Services Distributed Management (WSDM, pronounced "wisdom").
For non-trivial applications, consumers of a service seldom talk directly to the producer (or end point). In fact, the "middleman" (as depicted in Figure 1) intercepts requests from the consumer, reads the SOAP headers, and takes smart actions such as authentication, authorization, policy management, routing, logging, and so on. This "middleman" is called the intermediary. The intermediaries implement the facets of the Web service management framework. Apart from managing, intermediaries also provide a layer of indirection between the consumer and producer and make the infrastructure more resilient.
Figure 2 depicts a more realistic architecture with the intermediaries. In the real world, they comprise a set of servers, each specializing in certain aspects for Web services management infrastructure.
Depending on the vendor offering for the Web services management software, the intermediaries can be deployed with different architectures. Figure 2 depicts one of the possible architectures. The producers are deployed in clusters. In this case, they have one cluster of .Net Web services and another cluster of J2EE Web services.
There are internal and external consumers that would like to invoke services offered by these producers. A request from the client is initially processed by a load balancer (or by an XML appliance) and it is either rejected or forwarded to one of the gateway servers. The gateway servers in turn are managed by the Web services management engine.
Based on the information in the SOAP header, if the consumer has the required authorization to access the service, the request is forwarded to the appropriate producer. The gateway servers are usually lightweight applications. The Web services management engine performs most of the work, as depicted in the diagram. For the purposes of authentication, the management engine is integrated with the corporate LDAP system (or a security management system like Netegrity SiteMinder). Once the producer processes the request, the response is routed back to the consumer via the gateway server.
At no time does the consumer know which producer is processing the request. In the eyes of the consumer, the intermediary is the producer. The Web service management framework is transparent to the consumer. This gives a great deal of flexibility and resilience to the services and their hardware.
24x7 Web Services
Realizing 24x7 Web services is very difficult without taking management aspects into consideration right from the design phase. Thus, the facets of management—implementation, QoS, performance, security, and provisioning and servicing—are pervasive over the entire life cycle.
Implementation
Web service management strategy should start at the implementation phase. This involves selecting the right platform and making architectural decisions that lend themselves to proper organic growth. Now let's discuss some of the areas that need to be addressed during the design and development phase.
Managing interfaces. One of the major challenges faced by companies adopting Web services is schema proliferation. This problem is often the result of inadequate planning and feeble governance. Service-oriented architectures (SOAs) require discipline, planning, and strong governance to be successful. Developers should be discouraged from developing "one-off" schemas for application integration. Having corporate guidelines and best practices would mean up-front work, but they lead to smoother application integration down the road. It is best to think of services as black boxes and take an outside-in approach when implementing SOA for applications.
Look-up and naming. Consumers should have access to information about available services. Universal Description, Discovery, and Integration (UDDI) is a well-known protocol to find and use Web services dynamically. However, because of the complexity of UDDI, some vendors offer simpler repositories that provide similar lookup and naming services.
For a Web service, lookup can be based on the static attributes (like URL, service types, and so on) or dynamic attributes (like performance metrics or cost). The directory might even rank the Web services based on these attributes. Most of the current implementations use static attributes for lookup because of their simplicity and ease.
Dependency management. Consider Figure 3. In this scenario, Service B and Service C should be available for Service A so that it can complete its task. Typically, the intermediary keeps tabs on the "heartbeat" of the services and raises an alert when a service goes down. However, the intermediary can have control over the end points only when all the services are owned by the same entity. If, for example, Service C is hosted by a third-party company, certain trust levels need to be established.
Ironically, the more composite a Web service, the harder it is to manage its dependencies. To mitigate this risk, asynchronous (message-oriented) invocations can be used between Web services.
Versioning. Versioning is not built into the Web services specification. As such, this problem has to be tackled by following a few best practices. One strategy is to use the open-closed principle of object-oriented design. That is, the Web service definition language (WSDL) is open for extension, but closed for modification. Another popular strategy is to leverage XML namespaces. Each version of the Web service uses its own namespace. The intermediary routes the messages according to the namespace specified in the SOAP message.
Some vendors provide proprietary solutions for versioning Web services.
Interoperability. Interoperability is important, especially when services cross corporate boundaries. J2EE objects cannot understand .Net objects and vice versa. Differences in semantics across platforms lead to inconsistencies as well. To avoid interoperability pitfalls, it is best to develop XML schemas of objects that are passed between heterogeneous applications. Adhering to industry standard schemas and data models makes integrating with business partners easier. The Web services management framework therefore, should provide mechanisms to test for interoperability of Web services being developed. It should comply with the latest releases of Web services interoperability (WS-I) profiles.
Quality of Service (QoS)
For a service to be of business value, it should uphold certain QoS. In the case of commercial services, inability to maintain QoS could have legal and monetary implications. Let's look at some of the important artifacts that define and quantify QoS.
Service level agreements (SLAs) . An SLA is a formal contract between the producer and a consumer about the expected performance and availability of a Web service. SLAs help quantify the QoS. Depending upon the formality of the agreement, SLAs can be very generous to extremely rigorous. Typically, an SLA has components like purpose, parties, validity period, scope, restrictions, service-level objectives, penalties, optional services, exclusions, and administration.
SLAs can have long-tem and short-term designations. For example, consider a Web service that is supposed to be available 95 percent of the time in a given month. Let's say the service ran without any problem between the 1st thru the 29th, but on the 30th, it has been down for the past five hours. Technically, this has not yet violated the SLA, but if the service is down for five hours during peak business periods, it is unacceptable. Hence, the short-term designation could preclude the Web service from being unavailable for, say, more than 45 contiguous minutes.
The dynamic and composite nature of Web services (compared to traditional architectures) makes it all the more difficult to determine the SLAs. Because violating SLAs can have legal and monetary implications, understanding the system capabilities and dependencies is extremely important.
Resilience. Mission-critical, 24x7 applications demand high resistance to failure. Resilience is achieved by a combination of redundancy, failover, disaster recovery, and security. In the case of Web services, the end points are clustered and the intermediary performs smart routing of messages based on the policies set for messages and the state of end points. Having a messaging architecture in place also ensures SOAP messages are routed reliably to end points. In the absence of a messaging system, stateless HTTP session failover can be done.
Transactions. Transactional reliability is important for maintaining the integrity of an operation. Two-phase commit is a popular mechanism to manage transactions in distributed systems. Java Transactional Service (JTS), CORBA OTS, and most database management systems support two-phase commits. In the case of Web services, however, traditional two-phase commit is complex to implement because Web services can have long-running transactions. Hence, the WS-Transaction specification by OASIS provides two coordination types: atomic transaction and business activity. The former is used to coordinate activities that have a short duration, while the latter is used to coordinate activities that are of a long duration (for example, an activity that needs human intervention). With business activity, business exceptions can be handled based on use case requirements. WS-Coordination, a related specification, identifies the sequence of operations in a process needed to reach an agreement on the overall outcome of the business process. WS-Transaction and WS-Coordination work in conjunction to ensure a predictable outcome.
Logging. Logs are valuable tools for recording activities and for debugging problems. In the case of Web services, logging is delegated to another Web service that may be out-of-band with the transaction. Based on business requirements, corporate strategy, and regulatory compliance requirements, things like warnings, errors, security, and other information are logged.
Auditing. Activity auditing is necessary to complete tasks such as recording (and reconciling) service usage and tracking the sequence of events when a problem occurs. Industry-specific regulations like the Sarbanes Oxley Act (SOX—legislation providing financial practice and corporate governance regulation) and the Health Insurance Portability and Accountability Act (HIPAA—legislation to protect the privacy of health information) require companies to maintain records of certain activities. Logging is a common mechanism to realize auditing. The difference is that auditing is more rigorous and is in-band with the transaction. If the auditing mechanism fails, the transaction might have to be rolled back.
Alerts. Alerting is an important feature for system administrators. Alerts have to be raised when the system violates SLA or when certain events occur (like a server not responding). Sometimes the alerting mechanisms can take corrective measures.
Alerts can be classified into two broad categories: system-level alerts and business-level alerts. Some of the alerting features that should be provided by the framework include simple network management protocol (SNMP) traps, and e-mail and service (or script) invocation.
Performance
Proper workload characterization and capacity planning are important for the performance of any enterprise application. Understanding the usage trends and models of a service helps in allocating sufficient hardware resources.
Although HTTP is used for SOAP transportation, the payload of a SOAP message is much higher than that of most Web pages. Therefore, the networks should be able to handle this additional load. Now let's look at other techniques that could be leveraged to maintain good performance of services.
XML appliances. XML processing is one of the major overheads for enterprise applications. XML appliances are hardware-based XML processors. They are optimized for operations like XML compression, decompression, validation, and transformation. By delegating computing- and memory-intensive tasks of XML processing to specialist hardware appliances, the application servers can be used to run applications much more effectively.
XML appliances are often easy to deploy and manage. They are much more efficient than their software counterparts in their ability to process XML and are often used in conjunction with intermediaries. They can also guard networks from malicious XML traffic (like bad SOAP requests intended to overwhelm the network as in a Denial of Service attack). DataPower, Westbridge Technologies, and Sarvega are some of the leading vendors in this space.
Caching. Caching can be done at various levels of the application to enhance performance. Some of the key questions to consider for caching are:
How static is the data?
How soon should the data expire?
How large can the cache be?
Is cached data dependable?
Can data be shared between requests?
One way to perform caching in Web services is to use SOAP message handlers. This caches the results of frequent invocations of the Web service (assuming the results are static) and immediately returns these results when appropriate, without ever invoking the back-end components that implement the Web service. The SOAP message handlers could be used to check for popular invocations.
HTTP supports a rich caching functionality, and SOAP over HTTP is a common choice. However, there are limitations in leveraging HTTP caching in the context of Web services. SOAP is transported using HTTP POST. For an HTTP POST request, the body is outside the scope of HTTP. Therefore HTTP protocol implementations on proxies and clients will have a limited ability to determine how to cache responses to HTTP POST requests.
Security
In traditional architectures, the "trust boundary" was at the edge of the corporate network. That is, everything behind the firewall was considered to be secure. With Web services—by providing access of strategic information to partners, customers, and vendors—the lines of security have blurred.
Managing the security of Web services is one of the most significant tasks of the intermediary. Intermediaries may leverage some of the existing assets like LDAP servers and rules engines as necessary.
The WS-Security specification from OASIS defines message integrity, confidentiality, and authentication for SOAP. It dictates how security tokens are to be assembled in the SOAP header. A suite of other complementary specifications—commonly dubbed WS-*—specify usage of additional artifacts like trust, policy, and privacy for SOAP.
To ensure security for a Web service transaction, you'll need to address these items.
Identity management. Many of the systems in the enterprise are not designed with seamless integration in mind. Applications mostly work in silos. Consequently, John Doe could be johnd in System 1, jdoe in System 2, and johndoe in System 3. With Web services integrating these systems, enterprises find it challenging to manage and map the userids and to propagate security context between interacting systems. Specifications like Security Assertion Markup Language (SAML) provide a consistent mechanism to federate identities across enterprise applications and facilitate single sign-on, an important feature for integrated applications.
Policy management. Policy enforcement in Web services is important to ensure the right entities get access to the right resources in the right context. The WS-Policy specification (complements WS-Security) describes how senders and receivers can specify their requirements and capabilities declaratively.
As development platforms mature, policies can be configured through wizards without the developer having to deal with low-level detail of the specification. The intermediaries, as part of their security management framework, enforce the policies.
Identities and policies are complementary to each other. While identities facilitate authentication (that the user is indeed John Doe), policies facilitate authorization (that John Doe has access to this particular resource in the given context).
Securing the wire. Encryption is a common mechanism for providing confidentiality to sensitive data. Digital signatures ensure integrity of the data. A combination of these two technologies is used to secure "in-flight" information.
Some Web service deployments use Secure Sockets Layer (SSL) between machines to secure data on the wire. This is a brute-force approach because SSL encrypts and decrypts the whole message. In Figure 3, Service A makes a call to Service B, which in turn makes a call to Service C. If SSL is used for this, four sets of encryption-decryption have to be done for every round trip. Another disadvantage is that the sensitive data could be exposed between the decryption-encryption phases.
Instead, with XML encryption, XML signature, and related technologies, we can secure just those particular tags that carry sensitive information. Now Service B can look at the SOAP header and route the message (with the sensitive pieces of the SOAP body secured all the way to the destination).
End-point security. Another important, but often neglected piece of Web services security is securing the producer itself. For example, passwords have to be in an encrypted format at all times (in memory as well as in storage). This type of requirement has to be managed by the producer. Typically, the producer is secured by following best practices of application security for the platform on which services are developed.
As Bruce Schneier puts it, security is both technology and process. Without one another applications cannot be secure (see Resources).
Provisioning and Servicing
Provisioning is the process of setting up a service in the way it is intended to be consumed. For example, a gold version of the service may offer unlimited usage, while silver and bronze versions might offer restricted usage. To be able to enforce this, you should have a metering mechanism to track the number of hits. Other provisioning activities may include setting up security and business policies around the service and configuring the hardware. For commercial Web services, there might be additional requirements for leasing, pricing, and billing.
Understanding these facets of managing your Web services can help ensure that you provide a highly available, mission-critical enterprise application. So, use these guidelines to start building powerful Web services today.
Disclaimer: This article is based on the author's prior experience as a consultant in the industry; therefore, the views and opinions expressed do not necessarily reflect that of BEA Systems.
About the Author
Anant Kadiyala is a senior systems engineer with BEA Systems. He has keen interest in Web services, SOA, security, and portals. Anant also offers courses on Web Services Management and Web Services Security at UCSD Extension, San Diego. He can be reached at anant.kadiyala@bea.com.
|