At an implementation level, web services serve the basic purpose of message exchange between potentially heterogeneous software systems. Through abstracting language- and platform-specific implementations into text-based, human-readable XML and JSON-based formats, different software systems are able to execute procedures and retrieve data from remote systems, in many cases provided by a third-party. In this thesis, we analyze web services from two perspectives: web services used to provide an interface with which third-party clients can integrate, and web services used as the components used to build a software system. This distinction is made in the sections below together with the different challenges addressed in this thesis. Web Services for Integration When studying web services as a means for integration, the major challenge we address in this thesis relates to how software systems naturally evolve to keep up with ever-changing laws, services and technologies. When using a static software library such as a Java ARchive (JAR), it is up to the client developer to decide when and if to integrate such new "evolved" versions of the library. Therefore, any effort of integrating a new version could be delayed at the developer's own discretion. When integrating a client with web services, this is no longer the case. It is then the web service \emph{provider} who decides when the web service will bear new features and/or (potentially breaking) changes in behavior. It is also the web service provider who decides whether the older versions will remain accessible and for how long. In such a scenario, client developers must deal with an added pressure of conformity. If their client is not compatible with the new version it may simply stop to work when support for the older version is removed. This power-shift in who controls the evolution pace of service integration led us to study two facets of this client/provider relationship: Web Service Providers. We investigated whether this power-shift actually happens in practice by studying real world examples of breaking changes pushed by high-profile web service providers (Facebook, Twitter, ...) and the impact they have on client source code. We found that, indeed, in many of these instances the changes are breaking and invasive. Moreover, some client developers are also unhappy with both the structuring and frequency with which web service providers structure their (breaking) changes. Another interesting finding is how web service providers lack standard best-practices which all the web service providers agree on. Instead, each web service provider independently decides on which policies they will follow regarding evolution, backwards compatibility and versioning (or lack of versioning). Web Service Client Developers. Seeing as client developers are sometimes inconvenienced by breaking changes, we also investigated whether they have then developed resilience against potentially unstable and frequently changing web services. To achieve this we make use of mutation analysis to simulate evolving and failing web services and observe the behavior of a set of Android applications which integrate with these web services. While the results are mixed, a considerable number of applications crashed upon facing these changes which hints that not all client developers are aware of the added responsibilities when integrating a third-party web service. Web Services for Service-Orientation Web services are also used as building blocks for software systems in the so-called Software Oriented Architectures (SOA). When that is the case, it is often difficult (and at times impossible altogether) to understand what are the repercussions of changing the functionality of a specific web service. This is due to the loosely coupled nature of web services which can, in some cases, resolve dependencies at runtime. In order to address this, we created and evaluated an implementation of a runtime topology (Serviz) which provides us with this information. The runtime topology provides the system maintainer with an overview of which web services communicated with which other web services. By having this overview of causality in web service requests and therefore which web service methods depend on which other methods, system maintainers are then better able to understand which users and which other web service methods are affected when performing maintenance on a specific web service method.Our runtime topology provides such an overview while also allowing for different types of filtering (which can be combined): - Time-based filtering, which allows for restricting the interactions to a specific period of time. - Service-based filtering, which in large service-based systems helps in pinpointing all interactions and thus other web services which are invoked together with a particular web service. - Version-based filtering, which allows the filtering to be done with a higher degree of granularity and for choice to be done on a particular version of a web service. - User-based filtering, which shows the web service interactions only for a single user. Besides the runtime topology, a usage graph is also computed per web service which allows system maintainers to visually identify high and low usage peaks. Such graph is potentially useful for identifying the potentially best periods for performing software maintenance. Conclusion Ultimately, whether for an integration or service-orientation scenario, our results suggest that the lack of backwards compatibility in an environment where services actively depend on each other is one of the major causes of pain for web service client developers. An aspect which remains yet to be explored is whether providing such backwards compatibility is feasible and at what cost and effort does it come for web service providers.