Michael Stal

Web services: beyond component-based computing

Seeking a better solution to the application integration problem.

Using architectural patterns and blueprints for service-oriented architecture

Using software patterns and blueprints to express a service-oriented architectures fundamental principles supports the efficient use of SOA technologies for application development. Understanding SOA and all of its implications for software applications requires introducing a set of architectural principles that define SOA more concretely. Software patterns and blueprints can accommodate both forward and reverse engineering. Using the core SOA principles, software architects can derive best-practice pattern systems and catalogs that illustrate how to leverage existing SOA technologies.

What characterizes a (software) component

The definitions and discussions below were contributed via e-mail. They are arranged by date. The experts, listed alphabetically above, participated in this virtual round table during the first quarter of 1998.

An architectural view of distributed objects and components in CORBA, Java RMI and COM/DCOM

The goal of this paper is to provide an architectural analysis of the existing distributed objectoriented platforms. Based on a relatively small number of design patterns, our analysis aims at a unified view of the platforms. We achieve this by articulating a series of key issues to be addressed in analyzing a particular platform. This approach is applied systematically to the CORBA, Java RMI and COM/DCOM platforms.

Chapter 3 – Refactoring Software Architectures

This chapter describes how to systematically prevent software architecture erosion by applying refactoring techniques. Software architecture modifications are common rather than the exception in software development. Modifications come in different flavors, such as redefining or adding requirements, changing infrastructure and technology, or causing changes by bugs and incorrect decisions. But no matter where these changes originate, they need special attention from software architects. Otherwise, if software architects merely focus on adding new features—(changes or extensions that by themselves might not be adequate), design erosion will be the final result. In a systematic approach, software architects evaluate the existing software design before adding new artifacts or changing existing ones. Whenever they identify architecture problems, they immediately resolve architectural issues, thus assuring high quality and sustainability. Software architecture refactoring enables such iterative architecture improvement. It consists of indentifying problems, applying the right refactorings, and testing the results. Architecture refactoring is often combined with code refactoring activities to add the best value. Refactoring patterns offer proven solutions for recurring architectural problems, hence providing a toolset to software engineers.

Polyptychon: A Hierarchically-Constrained Classified Dependencies Visualization

Architects and developers are often tasked with evaluating or maintaining unfamiliar software systems. Reverse engineering tools help extract relationships between the system parts as they exist instead of as documented. Though node-link diagrams have a straightforward correspondence with the graph-represent able data generated, the scale and complexity of real-world data sets prevent efficient comprehension. This paper presents Polyptychon, an interactive node-link visualization designed for incremental exploration of dependency information. Given a hierarchical information space of software artifacts, Polyptychon constrains the visible dependencies to be related to the child nodes of a specified artifact node, called a view root. It then classifies these siblings as levelized, tangled and independent. It also includes context nodes, which are a filtered set of nodes elsewhere in the hierarchy that are related to the siblings. The context nodes are further grouped based on a project-specific partition function. The hierarchical constraints and partition function provide means to control the number of nodes displayed, while the dependency classification allows users to form a qualitative impression of the dependency structure. We demonstrate with examples from the Netty open source project. We conclude with areas of future work, in particular, as a basis of evolutionary dependency analysis.

Relating System Quality and Software Architecture: Foundations and Approaches

Abstract The field of software architecture has gone through significant evolution over the past two decades. Early research in software architecture focused on technological contributions such as the modeling of structural and behavioral properties of software systems. Automated analysis of these models resulted in the development of tools and approaches aimed at ensuring a system’s functional and nonfunctional properties such as performance, interoperability, and schedulability. More recently, however, software architecture research has shifted in fundamental ways. The emphasis on capturing design decisions and their relationship to both a software system’s requirements and its implementation is predominant. The synergy between the design decisions captured in the software architecture and system quality is the primary motivation behind this book.The field of software architecture has gone through significant evolution over the past two decades. Early research in software architecture focused on technological contributions such as the modeling of structural and behavioral properties of software systems. Automated analysis of these models resulted in the development of tools and approaches aimed at ensuring a system’s functional and nonfunctional properties such as performance, interoperability, and schedulability. More recently, however, software architecture research has shifted in fundamental ways. The emphasis on capturing design decisions and their relationship to both a software system’s requirements and its implementation is predominant. The synergy between the design decisions captured in the software architecture and system quality is the primary motivation behind this book.

Efficiently and transparently automating scalable on-demand activation and deactivation of services with the activator pattern

Computing systems are increasingly designed as a collection of interacting services that constitute a set of functionality offered by a service provider or server to its clients. Many service‐oriented computing systems have constraints on the resources they allocate and manage. In these systems, certain types of services should consume resources only when they are accessed by clients, and clients should be shielded from where services are located, how they are deployed, and how their lifecycle is managed. The activator pattern provides an effective means to efficiently and transparently automate scalable on‐demand activation and deactivation of services accessed by many clients. This paper motivates the need for the activator pattern, describes the structure and dynamics of canonical implementations of the pattern, and examines the benefits and liabilities of applying this pattern to services in resource‐constrained computing systems. Copyright

Onions, Pyramids & Loops – From Requirements to Software Architecture

Although Software Architecture appears to be a widely discovered field, in fact it represents a rather young and still maturing discipline. One of its essential topics which still need special consideration is systematic software architecture design. This chapter illustrates a set of proven practices as well as a conceptual method that help software engineers classify and prioritize requirements which then serve as drivers for architecture design. All design activities follow the approach of piecemeal growth.

Beyond middleware and QoS – service-oriented architectures – cult or culture?

State-of-the-art middleware such as CORBA, RMI or .NET Remoting represents a stack of interoperability layers to connect different islands of code. While all these existing solutions are widely used for the development of commercial and industrial software, they still lack essential features: First of all, there is no accepted middleware standard to connect different technology platforms with each other. And second, standard middleware promotes a tight coupling between peers. SOA principles introduce loose coupling which is important when even small parts of a distributed system are not under control of the developers. One implementation of these principles, XML Web services, are capable of bridging heterogeneous languages, platforms, and middleware. On the other hand, complain about immature, missing or even competing standards for XML Web services. And it still seems unclear how component-based technologies and services fit together. The keynote tries to illustrate how the upcoming universe of middleware, services and components could look like. Not only from a functional perspective but also keeping quality of service issues in mind.